When reading into the matter you can define four phases of cloud adoption. My first introduction was this cool graph:
You start at Opportunistic with your existing applications and legacy apps. This step is mostly still on-premise. Next you’ll go to the cloud with the basic implementation called Cloud-first or Cloud-ready. You pay the cloud bill and stopped your own servers, but the developers start to improve the setup. Processes are changed, software is made resilient and every new feature is made with the cloud in mind. Now you are All-in: there is no way back and nobody actually wants to go back anymore.
The last term is the only one with general agreement on it. We all end up at Cloud-Native but the journey has lots of synonyms and definitions. Let’s just say that cloud-native is using the cloud with maximum benefits.
The common term for this scheme is a Cloud Maturity Model. There are many versions of this to try to objectively define the journey to the cloud. At the time of writing, I could not find a generic Cloud Maturity Model that has been wide spread, but we can still try to define cloud-ready vs cloud-native with this setup.
So, what is “Cloud-Ready” exactly? I found a nice definition in cutter.com:
“These applications can be moved to the cloud, but they do not fully utilize all features of the cloud environment”
For “Cloud-Native” I couldn’t find a catchy definition, but it would at least talk about how deeply rooted this is in design. Cloud-native is not just an extra sauce you pour on top your on-premise applications. To work right in the cloud, it must be made for the cloud. Examples often mention serverless, managed services and autoscaling. To top it off monitoring and alerting is also an important part in it.
The Cloud Native Computing Foundation (CNCF) states the following:
“Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.”
What stands out to me in this definition is how closely related to the DevOps movement this is. Also, there is no one cloud-native package, they talk about ‘technologies’.
Microsoft also uses this approach and calls it ‘characteristics’ in their documentation pages:
I like this approach of defining Cloud-native as a set of characteristics instead of describing all as compulsory.
Scanning the documents on the internet about cloud native I came to the following characteristics:
Serverless design, managed services, autoscaling, horizontally scalable, monitoring/alerting, governance, microservices, API driven, stateless, retries/idempotency, cross platform, orchestrated (i.e., Kubernetes), containers (i.e., Docker), cost optimization, DevOps, Continuous Integration (CI), Continuous Deployment (CD), fault tolerant and fault resilient.
Of course, a lot of these characteristics stand for themselves. It is nice to have a checklist, but pick your favorites and don’t implement them all.