Entering the Cloud Native path is quite a challenging experience. It is a very new (still under active development) Software Development paradigm and there are, so far, no ready to use handbooks or manuals while the number of questions and possible paths may be overwhelming. If we look into the Cloud Native transformation from a very high level perspective and from multiple different angels (processes, management, culture, architecture, maintenance, people, delivery, etc..) it is pretty clear that the bar is raised very high and what is even worse - the learning curve is a bit different than it was in the past decades and we need to "throw away the old maps" as described by Pini Reznik in one of his recent blog posts: https://container-solutions.com/going-cloud-native-without-a-map.
Is it really that hard? Do we really need to think of Cloud Native transformation as a challenge similar to Elon Musk's Mars colonization plan? The answer is not that obvious, there are still some areas where you need to "walk around a little bit, in circles, getting the lay of the land nearby, then in widening circles. eventually, through experimentation and gradual learning, you will find your way" like described by Pini in his post, but there are also some areas that are a little bit less blurred, and this is where I think Cloud Native Infrastructure is today. Kubernetes is already 5 years old, we've gone through an experimentation phase (eg. Service Brokers being replaced by Operators and Controllers), we've learned how to deploy, maintain and develop production ready Kubernetes clusters at the Enterprise scale. There are many companies running Kubernetes in production for two, three, even four years, some even longer (with use of Kubernetes precursor - Mesos). There are a lot of lessons learned and when it comes to the Cloud Native Infrastructure - the staring point is not that hard. We can easily indicate what is proven to work well, which tools are the right tools for the given job, we already know how to orchestrate Kubernetes clusters so they give us "Cloud Native" sense. Cloud Native Infrastructure is not rocket science anymore, it is relatively stable ground, still developing but in organized and predictable way.
In the table below I would like to share an example Cloud Native Infrastructure Roadmap allowing us to take a high level view of the current state of the given infrastructure - what needs to be done and a rough estimation of the effort needed (employees/time) to achieve mature level of the Cloud Native Infrastructure. I am pretty sure many companies and organisations will find some parts of the roadmap as superfluous, some others will find a lot of pieces missing but in general I see the roadmap as a very useful starting point for introducing Cloud Native Infrastructure into your organization (after adding your own customizations and specific requirements).
In a typical Excel sheet it may look as below:
After the roadmap is defined it is relatively easy to estimate the effort needed and the exact timelines:
|1x fully dedicated FTE||~6.75 years||~14.5 years|
|2x fully dedicated FTEs||~3,5 years||~8 years|
|3x fully dedicated FTEs||~2,5 years||~5years|
|4x fully dedicated FTEs||~2 years||~4 years|
|6x fully dedicated FTEs||~1,5 year||~3 years|
|8x fully dedicated FTEs||~1 year||~2 years|
PS: keep in mind that specialised companies like Container Solutions, Heptio, Bitnami, or us - Cognitive may speed up the process by 30-60%, it may be worth to accelerate the process with use of an external partner.
So in the end a small team of 3-5 dedicated engineers is capable of (gradually) build production ready Enterprise scale Cloud Native Infrastructure within 2-3 years. As Cognitive We've went through the process a number of times and we didn't face any bigger surprises so far, all the estimations were accurate and we finished all the projects in time. Cloud Native Infrastructure is a relatively predictable field of much broader Cloud Native Transformation scope.