Over the last 2 years, I have had more and more conversations with customers about their Docker experiences, and how complicated it is to build anything, and how long it all takes. And quite a few of these customers have experimented with Kubernetes because it was pitched as the popular framework that allows you to quickly build things out. Not true.
Although Kubernetes comes with the ultimate flexibility to run absolutely anything in a container, you need to build it yourself, which is difficult and expensive.
As Platform.sh has grown bigger, we’ve attracted larger and larger enterprise customers looking for better, less expensive ways of embracing container management, and we’re seeing many repeating use cases. In short, building your own Kubernetes infrastructure starts with** 5-8 man years of effort **and will cost you upwards of $1.5m, to achieve just a thin layer of container management for a limited set of technologies, benefiting some aspects of development only. Operating and maintaining it will then cost you a further $500k per annum, and that’s before you start counting the cost of running production services with a decent uptime SLA.
Compared to a market leading PaaS, you will have about 30% of the value for developer workflow, about 40% of the value for infrastructure management, and no SLA for your production services.
Based on our own investment and running costs, allowing your Kubernetes build team to bridge the gap to a PaaS such as Platform.sh, would take you 40-50 man years of effort, cost you 10 times as much to build, and several times as much to operate.
Kubernetes is an incredible piece of software, but also an incredibly complex system. It gives you the flexibility to run any sort of container you want, but your infrastructure team will still need to solve many problems around the configuration and ongoing management of those containers and their associated CI/CD workflows.
No reproducible build chain or read-only infrastructure - which will take you many man years to build, and unless you do, you are running services you may not always know how to update, because once you deploy your container, there is nothing to prevent it from changing. And if you don’t have a repeatable build process with deterministic results, plus an “immutable read-only infrastructure”, once your container reaches production, you can’t be sure something malicious isn’t going to update it.
Not enough intelligence in the cluster orchestrator - which will take 2-4 man years to build, and unless you do, the orchestrator can’t know what specific processes are doing at any one time, so abruptly shutting down a container whilst writing to disk would mean certain data corruption, and a catastrophic impact to the application.
You still need a lot of DevOps and scarce knowledge to run it - Ongoing day-to-day operations will require a team of DevOps and Support staff. Investigating and repairing runtime issues for example, requires everything from specific Kubernetes semantics knowledge, Docker knowledge, networking and storage knowledge all the way down to Kernel specific behavior; all of which are changing very rapidly!
A great developer experience will still be a long way off - Multiple development environments for parallel feature development workflows will still be very expensive unless delivered with cloning technology in the Cloud. This is where the vast majority of developer gains will be achieved, in terms of accelerating the velocity of new features into production. Developers need perfect consistency between environments, which means copies of live or staging, and performing this sort of operation with any degree of safety plus performance requires native copy-on-write support and immutable containers, which will also take you many man years to build.
So, are your requirements really outside the 99% of what most other companies are doing? Kubernetes allows you to build and support any possible back-end service, important when your requirement falls outside the 99% of most commonly required services. If you think you could make do with the 99% of what’s out there and already available, you probably don’t need these extreme levels of flexibility.
A good PaaS delivers pretty much all the container based management you could ever want out-of-the-box, allowing your development teams to focus on writing code and delivering new features within hours of making the decision to start a free trial. A great PaaS will also offer one-touch zero-risk deployments onto a choice of highly available clusters (99.99% uptime) across hundreds of AWS/Azure/Huawei locations around the world, backed up by 24*7 global support.
This blog summarises a ten page paper that goes into technical and financial detail based on the experiences of Kubernetes customers adopting our container based PaaS. Please get in touch if you would like to discuss this further.