Goldilocks — A Cautionary Tale for Enterprise IT (Part 1)
Once upon a time, there was an IT professional named Goldilocks. One day, Goldilocks went for a walk in the forest and came upon a house, from which a delicious scent was emanating. Goldilocks knocked on the door, and when no one answered, walked right in!
On the kitchen table there were three bowls of porridge. Goldilocks was hungry, and tasted the porridge from the largest bowl, which happened to be a nice polentina.
“This porridge is too hot!” said Goldilocks, and spit the porridge right back into the bowl! Goldilocks was terribly disappointed, and expressed loudly (to no one in particular) that porridge that hot just wasn’t at all acceptable! And also, polentina was a fad and was unlikely to reach critical mass!
Goldilocks then tasted the porridge from the medium-sized bowl, which was made from oatmeal. “This porridge is too cold!” said Goldilocks, and again spit the porridge back into the bowl. Goldilocks was once again terribly disappointed, and exclaimed (again, to no one in particular) that oatmeal porridge was old-fashioned and outdated and that if she didn’t get a proper porridge soon she was going to get cross…
Finally, Goldilocks tasted the last bowl of buckwheat porridge. “This porridge is just right” Goldilocks said happily, and ate it all up…
But then the residents, 3 bears (that happened to also be IT professionals) came home. They were outraged that an intruder was in their house and that their porridge had been defiled and chased Goldilocks out of the house forthwith!
Traditionally, Goldilocks is the villain of the story — and we’ll get to Goldilocks in part 2. First though, let’s consider whether the 3 bears could make some improvements.
Lock the door!
Shame on the bears for not locking their door! The security system also must not have been enabled. If the bears cared so much about their precious porridge, they should have taken precautions!
If your organization doesn’t care about its reputation and/or the functionality provided by your applications, then you should immediately decommission them. Otherwise, you should too be taking precautions. Mandating good coding practices, secure-by-default baseline configurations, independent security reviews, vulnerability scanning, firewalls (and application firewalls), etc.
Perhaps you didn’t realize that you were exposing your unsecured Kubernetes API server to the internet(for example). Or maybe you just thought that nothing bad would happen. But there are millions of “Goldilocks” roaming the forest just waiting to eat your porridge…
How many options is too many options?
Do the bears really each need their own porridge, all at different temperatures? For the sake of argument, let’s assume that none of the bears have a medical condition or dietary restriction.
Very few bear families have unlimited resources. Making 3 (or more) different kinds of porridge each morning may not be the most effective use of those resources. Different porridges will require somewhat different techniques and skills, ingredients and perhaps even different or additional utensils or implements. A larger cooking appliance may be required. You will also likely consume more electricity, natural gas or whatever it is that fuels the cooking process.
Similarly, very few organizations have unlimited resources. As an example, running 5 different platforms to run containers (ECS, EKS, OpenShift, MicroK8s, AKS, …) or coding applications in 8 different languages or using 3 different cloud providers for analogous services without one or more clear and significant differentiating drivers will either:
a) require significant investment in “under-the-water” capabilities, and will waste resources that could otherwise be spent on achieving your organization’s actual business goals
or
b) reduce the quality of your IT environments because you didn’t invest in what was necessary to produce a really good outcome
…not to mention the fact that it will be more difficult to achieve a critical mass of skill for each of variation of technology that you choose — “a jack of all trades is a master of none”.
How do we determine the best tool for the job?
Polyglot thinking has spread into many IT organizations— “use the tools that are the best fit for the job”. This shouldn’t be controversial — it is a truism.
But are the bears best served by having 3 different sizes of bowls? Sure, perhaps there might be some mixing bowls or salad bowls of various sizes for various purposes, but could they easily make do with just one size of cereal bowl? And perhaps that cereal bowl could also work equally effectively as a soup bowl?
Sometimes, a decision may be presented as “this is the best tool for the job”, but in actuality the truth may be closer to “this is the best tool for my part of the job” regardless of the broader implications to the whole organization over time. We need to make sure that we are thinking about the full lifecycle of the application, as well as the broader implications on the organization as a whole.
Yes, one size doesn’t fit all, but this should be nuanced and contexted
A large bear will need more food than a smaller bear, but does this mean that they need different sized bowls? Perhaps they could use the same sized bowls and simply put a different amount of porridge in the bowl.
Maybe baby bear has a veterinarian-confirmed oat allergy, and polentina makes one of the adult bears violently sick… but if baby bear simply prefers buckwheat, then it may not be reasonable that this preference should require the parent bears to make multiple different kinds of porridge every morning… after all, baby bear isn’t cooking the food or cleaning up afterward, and isn’t buying the supplies or paying electricity bills.
Part of being a family is sometimes making wise compromises
Different areas of the organization may indeed have different requirements. Perhaps the bear family could have made some compromises. Oatmeal today, buckwheat tomorrow — so that they don’t need to wash 3 different pots every day and wouldn’t have needed to upgrade their 2-burner cooktop. Perhaps the polentina-eating bear could have popped breakfast in the microwave for a minute or two to bring up the temperature to make the food preparation process a little easier.
Being in the “family” of an IT organization also means making wise compromises. Developers, operations, infrastructure, security areas — even the business owners of the applications, we all need to work together to take security seriously. We need to ensure that we consider the costs and implications to all the teams that might be required to participate, not just our own. When choosing to adopt new technologies, we should make sure that we are choosing the optimal solution for the organization as a whole, both now and for the whole lifecycle of our applications.
