Cloud Native Maturity Model
Are you ready to migrate your applications to the cloud? Are you ready to make the changes that are necessary to reap the benefits of the cloud? Dante's Cloud Native Maturity Model (CNMM) will help you gauge your current situation and help you define a roadmap for success.
- Level 0: Lift and Shift
- Level 1: Embrace Software Defined Infrastructure
- Level 2: Liberate Cloud Native Architecture
- Level 3: Transcend to Continuous Deployment
Simply transplanting your applications to the cloud unaltered is a classic mistake that can be avoided. To reach the first level you must embrace automation. Cloud resources can be deployed and terminated at the push of a button. The benefits of these disposable resources cannot be fully leveraged unless your applications can be deployed on demand as well. At the next level applications must be decomposed into their constituent parts and refactored to leverage the native capabilities of the cloud to ensure that they can operate at web-scale. Armed with the power of automation and cloud native architecture it is possible to fully implement a continuous deployment lifecycle that enables you organization to adapt to the marketplace in lock step.
This series of postings will take a deeper dive into each of the maturity levels.
Level 0 - Lift and Shift
Many, if not most, organizations venture into the cloud with the assumption that they can simply transplant their applications without change and reap the benefits of the cloud. Some of the best known companies admit that they made this classic mistake and discovered that they had to change course. Even the best applications that were designed to run in an enterprise datacenter are monoliths by cloud standards. These systems inevitably cost more when transplanted to the cloud, fail to fully leverage all the scalability features provided by the cloud and are still unable to adapt to market forces with the agility that the cloud promises.
In a typical enterprise datacenter, resources are statically provisioned to support application components regardless of their workload characteristics. This is ok in the sense that datacenter resources are purchased in bulk at volume prices and amortized over several years. Thus when these resources go under utilized there is no incremental penalty because the sticker shock is all up front. The opposite is true in the cloud, because resources are purchased by the hour and the bills keep coming every month. As a result, the monthly bills can be staggering, when applications are simply transplanted into the cloud and their resources are statically provisioned per usual. The problem is further exacerbated when this typical pattern is repeated for testing, staging, demonstration and production environments. In our own experience we have seen invoices that ranged from 200% to 400% more then they needed to be. It can certainly be said that the total cost of ownership (TCO) is still reduced due to the elimination of overhead such as utilities and real estate. But the total cost of ownership in the cloud can be further reduced by matching the dynamic nature of the cloud to the workload characteristics of the application components. As we have progressed through the maturity model ourselves we have been able to significantly increase our capacity while reducing costs.
Well designed enterprise applications are architected as multiple, loosely coupled components. But there is a limit to the number of physical deployable units that can be supported before the cost of datacenter resources out grow budgets. This drives decoupled components to be packaged and deployed together to reduce costs. Again, in the cloud this tends to have the opposite effect and impede scalability as well. In the cloud it is generally preferable to have more small instances verses fewer large instances. These smaller units can scale faster to meet spikes in demand and when volumes are low they can contract to a smaller minimum capacity to reduce costs.
Transplanting an application from an enterprise datacenter into the cloud is essentially business as usual. If nothing about how the application is architected has changed then nothing about the development methodology and business practices around the application will have changed either. As such, no further agility in adapting to market forces can be achieved by simply transplanting to the cloud.
A different approach is essential to fully realizing the benefits of the cloud. Continue reading this series of postings to learn more about how to advance through the levels of the maturity model. Future installments will discuss how embracing automation will help increase quality and control costs, how liberating cloud native architecture leads to global scalability and how continuous deployment in the cloud facilitates agility.
Engage Dante to help you avoid the classic mistakes and navigate a successful transition to the cloud.
