Adopting an Omakase Approach to Containerized Infrastructure
Last updated: August 07, 2024 Read in fullscreen view
Recommended for you
- 01 Apr 2022
Ishikawa (fishbone) diagram in software project management - 24 Nov 2022 Genba Genbutsu Genjitsu (3Gs), (Go to the Genba & see for yourself!)
- 09 Sep 2022 Kaizen, Kaikaku and Kakushin – what’s the difference?
- 02 Feb 2022 Yokoten: Best Practice Sharing from a success
- 21 Dec 2023 Top 12 Low-Code Platforms To Use in 2024
How too many choices is having a negative impact on adoption of containerized environments
Recently I was in a restaurant. You know, the kind with a 20-page menu with different sections, each section with plenty of options, pictures, extras and then some more. And of course, there was a drinks menu, just in case you didn’t find the food menu anxiety-inducing enough.
We are all familiar with the feeling, whether in a restaurant or in a supermarket choosing from 24 different types of eggs, all organic, free-range, antibiotic-free and all from ecstatically happy chickens, having the time of their lives and laying eggs for fun.
At the same time, I guess you can say we all love having options. We love the freedom of deciding what food to eat, what to wear, where to go and how to conduct our work. This is no different when it comes to the tools we choose as developers and operators in our projects. We want to assess each tool based on its merits and our needs and choose the best ones we can find.
Want a registry for your containers? Here are five different options. A container runtime? Take your pick from these three. Container networking you say? I have four options for you. How about six options for logging, monitoring, APM or metrics?
Of course, all of these are open source so you can assess the size of their communities, the companies behind them, the quality of their codebase and decide for yourself which one is the best one for your needs. We also have gone further and created benevolent organizations to be custodians of these projects, promote them and create tiers and labels based on their maturity: sandbox, incubation, graduate and perhaps more. We are all well-informed so we can make the best decisions for our situations.
This all is great, right?
I have been writing code and building infrastructure for the past 25 years but I only need my last week’s restaurant experience to say, No! It is not.
Software building blocks or infrastructure projects such as these are like cooking ingredients, and I am not convinced having more ingredients is going to make me a better cook. I surely still want to be able to choose the ingredients based on my taste, dietary requirements and budget, but that doesn’t mean I can make the best choices or cook the best food, even if I follow someone else’s recipe.
I think the current landscape of containerized infrastructure is a testament to this situation. Too many ingredients and too many online recipes mixing every conceivable concoction of ingredients possible with visible and sometimes hidden motives by numerous vendors active in the space has led to great confusion by the end users. This confusion shows itself when we get a glimpse of the internal conversations of potential adopters of containerization. The resulting outcome ranges from the abandonment of containerized projects to a great deal spent by vendors on educating potential prospects, not about the solution or the technology, but on keeping them up-to-date on the ever-changing landscape of tools and technologies that pop up every morning in their inboxes. There, of course, is a great market for consultancies and professional services companies who are paid in dollars for hours spent on education, complete solutions or turnkey deliverables but not for product companies and even worse for those who have commercial interests in the very same projects that make up this supermarket of choice. This ultimately will not be good news for anyone.
Sticking with the culinary analogies (now you are starting to guess I need to lose a few pounds), if each project in this space is like a food ingredient, then the CNCF and other such organizations provide food labeling and promote healthy habits such as the Food Pyramid, while consultancies and professional services are the equivalents of private chefs that come to your house or your office and make you the best meals based on your requirements. This arrangement might work well for a few companies with deep pockets and for a short while, but it is not going to foster a thriving ecosystem of symbiotic vendors, customers, educators and lasting partnerships that go beyond PR exercises.
Not too long ago, Docker Inc. promoted a new way of running infrastructure based on deeply integrating a few, existing technologies. The company also tried to promote a concept it used to call “Batteries Included But Removable.” Docker wanted to provide full working solutions while letting customers make changes to the final configuration based on their individual needs. In the end, this approach didn’t work for Docker, not because it was a bad idea, but partly because of the company’s position in the market. Docker had the aspiration of becoming a platform while competing directly with the vendors in the ecosystem from day one. This meant small vendors either went out of business or lost trust in Docker Inc. and jumped on the first opportunity to support a rival company or technology with a better track record of taking care of their partners. Larger vendors of the Docker platform not only had deep enough pockets to build and market their own competing technologies but also a much better track record of building communities around them. However, it is worth noting that Docker’s failure as a company doesn’t mean its “Batteries Included But Removable” approach is always going to fail for everyone.
I am going to borrow an analogy from DHH, the creator of Rails and use it instead of Docker's “batteries” name: I’m going to call this the Omakase approach. This is when you leave your dinner menu to the chef. The issue with Docker’s approach was that the seller of the ingredients, the chef, the restaurant owner and the food health agency became the same company.
An Omakase approach to containerized infrastructure can be a great facilitator in growing the pie for everyone involved. Omakase vendors can navigate customer requirements without the rigidity of set menus at much lower costs than custom à la carte options provided by consultancies, effectively opening up the market to many more potential customers who otherwise would be left out of enjoying the benefits of this fundamental change in IT infrastructure, because of high costs, scarcity of experts to hire or perhaps simply paralysis by choice.
Good Omakase chefs keep their customers happy by reflecting their needs into their creations, let customers change parts of the menu if they have a strong feeling about them, listen to their vendors and create new businesses for them without competing with them. They also don’t take over businesses that would have gone to consultancies since their unit economy and metrics is different from a consultancy.
Ultimately, an Omakase infrastructure is an opinionated way of choosing the best tools and projects which is not as rigid as a solid product with predefined attributes and is not as confusing as a 20-page food menu in front of a hungry customer, all wrapped in a simple-to-use product, aimed at a specific market. I believe there is a huge opportunity in building these types of products that not only would help with the adoption of cloud-native technologies at a much larger scale but also could ultimately be the true manifestation of Geoffery Moore’s “Crossing the Chasm” by capturing a market first and then growing into its adjacent ones.
| About the Author | Khash Sajadi | Senior Architect | Khash founded Cloud 66 at the beginning of 2012 when he found himself frustrated by the manual way infrastructure was provisioned and configured. Finding PaaS very expensive and restricted, and scripting languages like Chef overly complex and not suitable for the cloud workloads, he set out to change the way applications are deployed to the cloud. Before starting Cloud 66, Khash worked as a senior architect at Chicago Mercantile Exchange, VP of Fixed Income Division at Lehman Brothers and SunGard Trading and Risk Systems and founded Sentimnt, as social search engine, and worked in various startups in London and San Francisco. As well as his role as the CEO, Khash is responsible for all Cloud 66 products and has deployed and operated 1000+ node Kubernetes clusters. |
Explore more on these topics
Guest Blogging: The Definitive Guide
