Deciding to adopt a cloud native approach for your application or services is usually driven by business reasons. Whether your business wants to scale to millions of users and you need the scalable infrastructure to support or your product team needs to ship features to market faster, cloud native can support.
Just as you will have addressed your journey across people, process, policy and technology in support of cloud native, you also need the ability to clearly communicate the value your business should expect. The CXO board and/or business leadership should all be in receipt of that communication and understand the value. This requires you to align your business goals to how cloud native will help you achieve those. Some examples may include:
- Scale to 1 million users: Provide flexible, scalable infrastructure based on users at any given time equipped with fast failover in the event of a problem.
- Deliver exceptional customer experience: Ensure the app is reliable as to not frustrate users
- Get features to market faster: Enable a microservices approach to building apps. Smaller teams are more agile because each team has a focused function. APIs minimize the amount of cross-team communication required to build and deploy.
It is important to accept that your cloud native maturity is not a linear evolution and there will be setbacks. Remember to communicate this clearly. For example, you may have put the infrastructure in place to ensure a reliable application for your customers, but due to a misconfiguration in code, the outcome is delayed. As with all development, communicate the pros and cons to stakeholders so they understand before passing judgment on cloud native.
Level 1 of the Cloud Native Maturity Model is where your team has a baseline implementation in place and you are in pre-production. Here you will have completed a successful POC. Based on the POC, you should have initial findings on how cloud native will help improve your app. In a dev environment, you could, for example, have seen that:
- An app is using less resources (cost savings / more efficient use)
- A new feature shipped faster (faster time to market and thus increased revenue)
- There was no downtime (improved reliability for customers)
- Improved business continuity thanks to resilient cloud architectures
These are just examples, they are not a guarantee based on your environment as results may vary.
In this phase, you will determine how you’ll measure (your initial KPIs) the success of your cloud native journey; and just as important, how you will demonstrate it to stakeholders. This is a major outcome of Level 1 as the entire success of the journey should be mapped to this measurement. Remember it won't be immediate on day 1. Some quantitative and qualitative example KPIs may include:
- Reduced spend on app infrastructure by 25% by optimizing for cost
- Dev cost lowered by 10%
- Reduced team focus on app infrastructure by 15% by automating as much as possible
- Increased security for the application by automating CVE identification in containers
- Improve compliance as you can restrict and track access to the application; demonstrate compliance with SOC 2
- Accelerated development life cycles as you implement CI/CD pipelines shipping 10% more features per quarter
- Migrate plan - this will vary depending on your organization, but you should have a migration plan in place. Whether that’s to migrate one application first, or several, you should have this established.
- Improved customer experience measured by increased performance scores
- Elimination of information silos: departments no longer isolated; unique, integrated ecosystem in place.
- Alignment of business and IT goals: everyone is involved and aware, so that resources are better addressed to meet those goals efficiently.
- Increased internal communication: cross-pollination offers new perspectives with shared knowledge.
In this phase, it’s important that the business outcomes are examined and explained to business stakeholders. It should be a discussion with engineering leadership, the application owner (finance, marketing, etc), the CEO, and even the board. Without these discussions and alignment, maturing to the next phases will come with little appreciation and possibly even skepticism.
Cloud native is now established and your technologists are moving to production. While the technical outcome of Level 2 is a fully functional application or group of applications migrated to cloud native tools and practices, the business outcomes are the ability to evaluate the benefits of the migrations. This is also the level that most customers/corporations get to and plateau. This is when a cloud native maturity model shows its true value.
With your established KPIs from Level 1, you will measure success and communicate this to stakeholders.
In the operation phase, you will be focused on moving to production. You’ll have established standards around technology, your people will be operating it and implementing policy and process. Your business outcome will be around production migration. The business leadership of your organization will want to understand what applications are being moved and why. Be able to clearly communicate the plans to your business leaders. Repeatable patterns will also emerge as teams operate in Level 2. These will be applied to your business outcomes so that benefits you see in one migrated application can be applied to another without as much as a heavy lift. These patterns will help streamline operations across your dev, sec and ops teams.
Your KPIs can also include your return on investment ROI, but know that in Level 2, your ROI will be lower than when you reach Level 5. This is because you are investing a lot in acquiring tools, establishing the right team and skill set, whereas in Level 5 you are optimizing.
In Level 3, your competency is growing and you are scaling. Up to this point, your teams have been focusing on learning cloud native. In this stage, your business outcomes are dependent on your team’s experience. As the team builds confidence, their competency around security, efficiency and reliability grows and they will implement defined processes for scale. All of these will impact your services and applications as the team improves. Your business should start to notice operations are more scalable and if not you will need to improve lines of communication to demonstrate this scale, or review the actual scaling results, so they can be optimized further.
You will have safeguarded your application or service from a single point of failure or disappointing performance in Level 3.
Monitoring is implemented. This will help the business get reports on what’s working and what isn't working. While the monitoring may be very specific, it will also provide insights into resource utilization to control costs and performance to ensure availability.
Finally, you should be observing the flexibility and scalability of cloud native by comparing old vs. new:
- Deploying a server takes minutes with Infrastructure as Code instead of days. Business translation: faster time to market.
- Monitoring for security attacks. Business translation: less risk, stolen data.
- Observability: Logging, metrics and tracing. Business translation: quicker responsiveness to changes in application behavior or business demand. Better customer experience and reduction in lost sales due to service degradation.
- Improved Reusability: containers and microservices make it easier to reuse components already available from previous projects. Business translation: 1. guarantee of brand image consistency and standardized functionalities throughout the multiple apps; 2. a lower learning curve for customers using those apps.
Level 4 is focused on improvements around security, policy and governance across your environment. The team can focus more of their time on your business instead of maintaining Kubernetes. Level 4 is also the next level where clients and customers plateau. And most customers can stay at this level as they further mature.
Your team has cloud native confidence and now it’s time to take that knowledge and apply it more thoroughly to your business goals.You have continued to measure yourself against established KPIs in Level 1 and provided those to the business. You’ll have alignment on goals because you can demonstrate outcomes. The business should expect to see:
- Established protocols and procedures
- Policy enforcement of compliance standards
- Comparison of cloud native apps vs. non-cloud native
The business should expect more reporting in this phase. Reporting should cover compliance, security, performance and cost. These should be easily aligned to the business goals established in Level 1.
At this point, you may start to migrate your other applications and have a better understanding of what you want to achieve and where you will see value during each level of maturity.
This phase of optimization will see lots of changes with people, process, policy and technology. For the business, you should have achieved your business goals and have the measurable results to show your leadership teams, CEO, CFO or the board.
You will continue to optimize your workloads against further / more advanced cost and performance metrics. You will never stop optimizing your cloud native infrastructure and apps. Here the expected business outcome is the ability to track how optimization continues to move the bar against established goals.
You may also revisit your goals at this point, adjusting them to what has been achieved and what you want to achieve in future.
You’ll automate as much as possible according to cloud native best practices to remove human error as to avoid security and performance problems.