Observations Volume 2
The "ChatGPT did not write this post. There's no way that happened." edition
Capability models versus maturity models
I rather enjoyed this post on devops as a capability model for a variety of reasons:
I’ve bought into the systems over goals philosophy for a while now. Capability models is just another way of implementing systems.
It points out directly one often overlooked attribute of capability models in that those models imply and assume that things will change. Goals are rarely written to adapt.
Shows side-by-side the differences between the two, even though initially they were part of the same framework.
It mentioned Ineos Grenadiers. Not the one I’m a fan of, but still from the same company.
There’s a bigger discussion to be had about systems versus goals, and it’s something I’ve been thinking about for a long time. However for the context of finops there are things to learn here. If you look at the SEM at every point the facet is either exactly the same or there is something that finops has to contribute. Maybe as a model for systems versus goals I’ll create that mapping.
LLMs and costs
LLMs are the new hotness and of course everyone wants one. A fundamental problem, as with every new technology, is to make it cost-effective. How do you even begin estimating how much it costs to build a tool that massive? There are a couple of places out there that have estimated that ChatGPT costs $100,000 per day to run. I’m not so sure that’s nearly comprehensive - it doesn’t even cover the costs for gathering such a corpus which is certainly a monumental task.
If language modeling is the next big thing I fully expect the finops folks to have their hands full. There will be business pressure to get the costs as low as possible. As for now it's a neat toy, but it remains to be seen if there will be long term business value.
Context switching
I struggle with context switching, and always have. I’ve found that some things work, like blocking off schedules to dedicate to work. Then there are others haven’t worked, like creating follow up lists - search engines are low-key dopamine agitators too.
Context switching comes at a cost - I don’t think anyone disputes this. So how do you handle external forces insisting on context switching? It’s tough to do - on one hand you have a right to your time, especially of your work, and on the other hand you want to maintain good relationships and not come off as a jerk. Things can get even dicier if that external force is your boss. Interested in getting some tips here.
RISC-V as a value proposition
RISC-V is pretty exciting. We’ve seen what a competitor can do to traditional x86 hardware, now imagine a chip that is both open standard and royalty free, just as fast (maybe?) and just as power efficient (maybe?).
Because of these surface level promises there is a move to make them a part of the datacenter. Not exactly surprising - there are many things that were what was once niche hobbyist or academic toys that became industry standards.
I think it will be a little while before RISC-V starts cutting real inroads into this space. There is a lot of retooling that has to happen to provide support of a new chip. Teams that want to move their application to ARM often encounter problems like having to rebuild every thing (even for interpreted languages like Python) because of various underlying bindings and dependencies. It’s not as cut and dry as we want, but I’m still looking forward to it.
The rush to the cloud: a retrospective
We were warned early on about the rush to the cloud with concerns of security as well as overspending. AWS, according to their fearless leader Andy Jassy, spends a lot of their time developing customer relationships by helping customers optimize their cloud spend.
Anyone that has been around for more than ten minutes remembers lift-and-shift, the silver bullet for instant shareholder wealth and technology fame and glory. Except that it wasn’t. In hindsight it looks more like Lotus Notes. AWS, in particular, did a terrible job of providing the “after that do this” roadmap for so long that even some cloud proponents are rethinking their positions. Their lackadaisical approach created a whole industry (mostly good, I’d say) for helping customers cost optimize.
However, I think this has hurt AWS more than it anticipated and will continue to do so for the foreseeable future. Cloud native was always the right answer. This was pretty obvious early on to the engineers migrating workloads.
Lift-and-shift-and-then-what?
There was always a next step that was absent to many in the C-suite. Companies that took their time migrating slowly (in my experience) fared better than others - the pitfalls were obvious almost immediately so they had time to react. But for the others, sex sells and so does AWS. This acknowledgement from Jassy seems to be a step in the right direction, hopefully with spreading the gospel for cloud-native.
Now if we can just get some decent portability…
Pro-tip: if you want a place to start for cloud cost optimization Cloud Finops is the book to get.
Bonus: add annotations during changes
Add annotations notes to a file during deployments with Terraform. For automated deployments via CICD (you are doing these, right???) you may need to pipe in information or just skip it altogether. Don’t sleep on the local-exec provisioner, it’s very useful.
resource "aws_instance" "cluster" {
# ...
provisioner "local-exec" {
command = <<EOT
read -p " record some notes then hit enter" < /dev/tty && echo "$(date +%s): $REPLY" >> cluster-annotations.txt
EOT
}
}