As entrepreneurs and technologists, we are all waiting for that moment when our traction turns in to a problem. A welcomed problem that makes us feel like a new parent, where our child is named Pagerduty. Awake all hours of the night manually adjusting our infrastructure and product, hoping, in direct opposition to the goals of our business, that things slow down so we can get some sleep. The brutal reality is that statistically speaking, for 90% of us, we will never actually have that problem.
Instead of focusing on optimizations that can benefit the business, enhancing either the product, or the process of releasing the product to customers, too many companies spend exorbitant amounts of time focusing on premature optimizations, with the expectation that they will be one of the 10% of startup companies that need to worry about scaling. Add to that the deep desire to always be doing things by the coolest way of today, and it presents a real problem for small technology companies that are hunting for product-market fit.
When given the next 8 hours at your desk to accomplish something to drive your startup forward, time management is paramount. Maybe you need to work on your email drip campaigns. Maybe you need to add a new feature. Maybe you need to take a nap (don't tempt me, i need some coffee badly). Or maybe you want to focus on something fun! Like rigging together Kubernetes with 20 other projects with the hope of something resembling your own PaaS being produced on the other side.
If you're the type who looked behind that last door because it's interesting to you, we may be cut from the same cloth. However, unless you want to start a company that specializes in container deployments, there is a high chance you are wasting your time, money, and effort.
Kubernetes on it's own is very powerful, but it's low level. If you're going to do it right, you'll need to spend time thinking about how to automate the provisioning of your clusters and how it plays with your cloud of choice. In addition, the ongoing management overhead that you will incur to keep it up to date and running smoothly should not be underestimated. For mid-market, smaller technology businesses, and startups, that are interested in containers and how they can accelerate the software development lifecycle, the goal of a fully automated Kubernetes hosting environment can seem very enticing, but I would advise those companies to proceed with caution. The eventual acceleration you would see in your SDLC will be offset a few times over by the overhead of getting the setup perfected, and production ready. In other words, you're going to need someone to be managing it almost full time, or at least dedicating much of their time to it.
The good news is that there are alternatives that still give you the Kubernetes power you want, but get you there without needing to rip your hair out in frustration, or add another full time employee. Container-as-a-Service platforms exist to take you from dream to deployment with Kubernetes today, so you can actually speed up your SDLC, without the need to become an expert.
This really comes down to the age old question in IT: Build it or buy it?
Far too often the decision is made to build instead of buy. Some number of people in the company embark on a journey which forces them to stop worrying about product and growth, and instead head down the murky path of "rolling their own" platform.
The cases where rolling your own platform from scratch make sense are few and far between. Maybe a solution doesn't exist that meets an edge case need, you have a specific need for a custom crafted solution because of your industry, or you just like owning and operating every piece of your specific business puzzle. Generally speaking though, unless your name is Tommy Chong, you should probably not be rolling your own. When I need social posting automation, I don't roll my own Buffer. When I need a CRM that my salespeople know, I don't reinvent that thing called Salesforce. So why do so many startups, growth businesses, and even enterprises set out to reinvent the wheel of cloud automation? It's something I have seen happen time and time again. Usually it's a matter of wanting to avoid lock-in to a provider or product, ensuring job security of a team, or simply being accustomed to this hand-rolled process being normal.
We are in the infancy stages of standardization around how servers interoperate to become a scalable distributed system. Prior to containers, service discovery and all of these other new fangled things we have to think about, it was the wild wild west when it came to scaling on the world wide web. Some companies figured it out, some sort of did, and some just couldn't. Google is one of the companies that had enough cash in the bank, a real need, and enough brilliant engineers to figure it out. Because of that, we all grew up using a service that was almost always available and fast (if you don't count our dial-up connections), and it was beautiful. That is one part of the the power that Kubernetes has in this market. The power of years of actual personal interaction with a brand that has proven that it knows enough about computers to reliably answer our questions when we ask. They certainly must know what they are doing.
And they are masterful at assembling a community around an open source project that leads to success.
But does that mean that you need to prepare today to be the next Google? Not necessarily. But you can do so without the overhead of trying to build a platform from scratch yourself.
Instead, focus on being the next 10% of companies that are successful. Pick an existing solution that fits your needs, gives self service to your team, and get all of your people working twice as hard on executing on your product roadmap and vision. Heck, there is probably a pretty good chance that whatever you buy off the shelf is using Kubernetes under the hood anyways. If you don't focus on your core competencies, you'll be another one of those companies that was ready to scale and never had the chance, and nobody will ever give a dang about how your infrastructure was prepared for them to give a dang.