Developing a Cloud Native platform for your organization is almost like building a startup from scratch. It requires discipline, culture, and planning, but most importantly, it requires a mission and a vision. As a Cloud Native and Enterprise DevSecOps consultancy, we often start the cloud native journey with our clients with a basic but important question of all; “Why are you moving to Cloud Native Architectures? What are the business drivers for becoming Cloud Native”? The answers we hear vary from cost considerations and lowering the total cost of ownership to rapid software delivery at any cost. At times it is to keep up with the norms in a rapidly evolving cloud world. The Cloud Native transformation, if done right, will undoubtedly yield many perks such as reducing your time to market, improving the reliability and availability of your services, lowering the total cost of ownership, and allowing for rapid innovation. The destination, while beautiful, requires one to embark on a complex journey that requires many moving parts to come together to realize the desired output.
Taking knowledge from our experiences and witnessing both failures and successes, we hope to highlight the most important lessons learned and the most common pitfalls you need to avoid and plan to address as you embark on this journey.
Before we get started, let’s first see how CNCF (Cloud Native Computing Foundation) defines what Cloud Native means:
Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. 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.
Ensure Organizational Alignment With Cloud Native
One of the biggest challenges in Cloud Native transformation is making sure that all the intricate moving parts are working towards the same goal. Too often, attempts to transform are often thwarted by a lack of acceptance or knowledge for the coming transformation. Oftentimes we notice that the technical teams on the ground do not have a good understanding or reasoning for why they are implementing a Kubernetes platform or a cloud native service. IT leaders should set clear vision and mission statements for cloud native transformation and define the outcomes (both business and technical) that will be achieved. Communicating these to the rest of the organization is equally important.
From there, ensuring alignment across teams for a shared purpose and common understanding of the transformation goals is critical. You do not want Dev teams to have a different understanding from Testing or Operations teams. In addition to giving your engineers the tasks of creating a cloud native service, urge them to understand the importance of this transformation for the company as a whole. To have a well-oiled Cloud Native transformation machine, all the moving parts must be in alignment and be developed with precision and focus towards a common goal.
Emphasize User-Centric Approach within Platform Teams
User Centric approach doesn’t just apply for software developers who write functional software for the organization’s outside customers/users. It applies for all of the engineers that are responsible for building or engineering a software solution; whether it is a platform, tool, report, service, batch process, etc.
One of the most critical issues in this article is the lack of alignment between Dev and Ops engineering teams. We have seen Infrastructure and Operations teams start to build out the Cloud and Kubernetes platforms without keeping in mind their user requirements. In this case, the users of the platform teams are the developers in the organization. If the cloud native platform is not built to optimize the development experience of your developers, then you will struggle mightily to drive the adoption of the platform. It is crucial that the platform team, as well as the development team, are on the same page in terms of what is needed and what isn’t. Oftentimes platform teams over-engineer wasting valuable time, resources, and money on features that are not required or incompatible with the necessities of the development team. Make sure that the communication and agenda between the Platform and Development teams are synergetic.
Secure your Future with Strong Cloud Native Foundations (Everything-as-Code)
You have to embrace automation across all layers of the tech stack to realize the maximum benefits of cloud native transformation. Do not assume that by moving your organization into cloud native architectures, you will achieve the optimization right out-of-the-box. One of the organizations we recently helped was trying to implement Kubernetes in a VMWare based data center environment. They wanted auto-scaling, elasticity, robustness and all the fancy capabilities that Kubernetes promises. However, they had zero automation at the VM levels and everything was manually provisioned and managed. The same use case / example applies for organizations that are currently in the cloud and have zero or minimal automation. You cannot expect strong results in a cloud native transformation when the foundations are weak. Make sure that you understand infrastructure as code concepts. It boils down to this simple adage: Building on a weak foundation is a sure way to render your future null and void.
Microservices aren’t for Everybody, and they are not Silver Bullets
Yes, Microservices are going through its hype cycle phase. But that is not to say that Microservices don’t provide tremendous benefits. There are many companies that have adopted microservices architectures and realize maximum benefits. However, Microservices are not a one size fits all solution. It’s dangerous to subject yourself to technological norms by using Microservices where they are not needed. Not every monolith needs to be broken down. Not every monolith should be broken down. Evaluate if your organization can manage hundreds and potentially thousands of services in a microservice world. Ask if your engineers truly understand the design patterns of microservice development. Ensure that your organization has the right tools and technologies to cope with the operational complexity of deploying, managing and monitoring microservices. If you haven’t calculated the ROI and TCO models for microservices, then chances are that you are following the hype and are at the risk of being part of a failed initiative.
Train your teams early-on and build an Enterprise Cloud Native Learning plan
Cloud Native transformation fundamentally requires a shift in understanding and mindset of how IT teams perform their day to day jobs. Engineering needs to be transformed from Virtual Machine based practices to Cloud practices. New technologies, new tools, new patterns are evolving rapidly. Most organizations that are about to start, or in the beginning stages of cloud native journey begin with Pilot projects and “hope” that their teams will learn very quickly. Hope is not a strategy. We have seen in large organizations a clear misunderstanding and misalignment across teams regarding the basic concepts of cloud native. It is important for your teams to have a common baseline understanding and speak a common language across the board as it relates to cloud native. Create an enterprise cloud native training plan. Train not only your engineers but also your project managers and executives. And do this early-on and avoid slow downs and performance problems. We have helped create and deliver enterprise cloud native training programs for organizations and have seen tremendous success. Check out https://oteemo.com/training/.
Fail Fast, Improve Faster
As with any project or enterprise initiative, one should be aware of the possibility of failure. Instead of fearing it, embrace it. Failing fast and continuously improving should be the theme of your organization’s transformation effort. Create a culture of blameless postmortems. Not everything is going to work the first time around. Acknowledging this and building upon it is essential. Without a mindset that doesn’t fear failures, it is easy to waste time and lose motivation, while being stuck with the same problems.
Know your Definition of Success and Use the Right Metrics
Throughout the process of Cloud Native transformation, the metrics to measure success become vague, or even sometimes non-existent. Without the right metrics, it is nearly impossible to scale and develop transformation projects. We encourage all organizations that are entering the space to ask themselves how they are going to be measuring success. Failing to do so can often result in an overcritical, yet counterproductive attitude. Define the metrics that truly are meaningful for your organization and your business. Don’t just use the “cool” stuff. The metrics we used at Oteemo are meaningful yet straightforward for our client’s businesses. Through our Cloud Native Discovery Sprints, we have helped IT leaders not only define goals but also define the right metrics to measure progress and success in their cloud native journeys. Look to improve in your Development and Cycle time; your service Availability and Capacity; Quality and Security and finally Usage and Performance.
Start small (not trivial)
We are going to assume that everyone has heard “not to boil the ocean” and “to start small”. In our experience there is one other mistake organizations make when they are proving a cloud native platform; They start too small. This is especially seen when technology evaluations or product bake-offs happen. When you pick a use case that is trivial during your evaluation phases, you end up not testing and validating most of the core operational use cases. Most of the time trivial pilot evaluations seek a happy path and not a realistic path. Starting small doesn’t mean picking a trivial application; it more so means not picking a mission-critical one. Choosing the right pilot projects when you are making technology decisions is key. You need to define the right attributes and then pick a pilot application or service that fits those attributes or criteria. Just don’t pick a mission-critical service as your pilot, even if it matches all the criteria.
Understand Your New Territory
As you move into the world of Cloud Native ecosystems, you will need to understand that the “old way” of doing things has to change. Developers interact differently with the platforms, testers provision and manage their infrastructures differently, operations teams are now responsible to ensure SLAs in a less controlled environment. The roles and responsibilities of teams change as the underlying interaction and communication models change. Understanding these new roles and responsibilities is vital to maintaining the structure of the company, especially as cloud native projects become mission-critical. This all boils down to truly understanding and implementing the right RACI (responsible, accountable, consulted, and informed) in the newfound structure of the organization. Lack of cloud native RACI for your organization might cause a lack of clarity and confusion for teams.
Don’t Build an App in the Cloud; Build a Cloud App.
Far too often, organizations decide to lift and shift old services and applications into the cloud. This is a huge problem because these applications were not originally optimized for the cloud and will not be taking advantage of the modern cloud native architectures. And on top of it, with the classic lift and shift model, you are also shifting all the legacy data center practices into the cloud. The technology is only as good as the underlying process. You cannot play the game the same way in a different field and expect a different result.
What we propose is a Lift + Transform + Shift methodology that will optimize the workloads for the target platform. The transformation of an application, infrastructure, and process should be optimized for your business goals. Always ask your engineers, “Are you building a cloud app or just building an app in the cloud?”
Containerize with Care
Containers are a great way to optimize your software delivery supply chain, allowing for increased efficiency, portability, less overhead, and consistent operation. Before jumping into the world of containers, it is essential to evaluate what applications you need to containerize and why. Containerization affects all aspects of your software delivery supply chain from development through to operations and maintenance so it is imperative to plan for this change appropriately.. Evaluating your risks and ROI before shifting to containerization is an essential first step. At Oteemo, we have a “Container Readiness” checklist that allows us to evaluate these risks, as well as create parameters to better prepare an execution roadmap. Identifying the correct pilot project(s), up-skilling or hiring the right technologists and defining criteria for success has been a consistently proven approach for successful adoption of containers and associated technologies like Kubernetes.
A successful Cloud Native transformation will enable an enterprise to thrive and perform at a completely different level. However, we have seen organizations fail to realize the full benefits of what cloud native has to offer. We have found avenues through which we can effectively help organizations to embrace and adopt cloud native architectures successfully. What worked for us may not work for you, but we hope that you can read through our “cheat sheet” and take a few key ideas that bring your organization closer to a proper Cloud Native approach than before. If you have questions and want to talk to us, feel free to shoot us a note at email@example.com