How to fail at Cloud Native
Cloud native is the most popular and abused term in the modern digital industry. Every CIO, enterprise architect, and developer wants to use cloud native in their organizations, architecture, and application. But the majority of them don’t have a clear understanding of what the cloud native is, and many organizations fail in the cloud native journey.
What is Cloud native?
If you ask this question from ten industry leaders, you may get ten different answers. The majority is referring to cloud native as moving the workload to a cloud infrastructure. Some say microservices or applications that ship as containers are cloud native, and some say that containers deploying in Kubernetes are cloud native. All of these are true to some level but not comprehensive enough in my point of view. Adding some more definitions, deploying applications in the cloud, writing applications to run in the cloud, and software delivery with CI/CD or GitOps are other variants described as the cloud native.
If you generalize all of these definitions, most of them are tight up with some kind of architecture or technology but missing a significant component: the culture.
Why Cloud native?
Why do you want to move to the cloud native? I think it is a fair question to ask. The following list captured a few main reasons that organizations are looking for. This list is gathered based on my experience working with many enterprise customers on their cloud native initiatives.
- fast to market
- reduce cost
- high scalability
- wider availability
- because everybody else is doing it
In an era of digital transformation, enterprises are looking for fast innovation to deliver more value to their customers. Reducing the time taken to market give an immense advantage to stay ahead of the competition. Moving to the cloud native helps automate the delivery pipeline to go fast to market with the product and services.
Another key motivation to move to cloud native is to reduce cost. The pay-as-you-go model optimizes the infrastructure and service utilization along with the demand and helps to expand organizations without having large capital expenditures.
Every organization wants to scale its business. Many businesses are dying because of failing to scale with customer demands. Cloud native is the modern way to scale your businesses.
Cloud services can access from anywhere if you have the connectivity. Making wider availability is key to become a successful business. We knew this as a fact, but it has proven in the 2020 pandemic where we all had to do our business remotely. Businesses with the cloud presence had a clear win while others were struggling in the pandemic time.
Even though many organizations are looking for all the above benefits, some organizations are looking to move into the cloud native mainly because everybody else is doing it. They don’t have a clear idea of what problem they want to solve, but they fear missing out on new, cool technologies.
If you carefully analyze these, you can see that the benefits and expectations are the same as what we expected by moving into the cloud in the last decade. But many organizations fail in their journey to the cloud as well. Learning from the previous mistakes, now the organizations are looking into getting the same benefits by adhering to the cloud native. So what should we do differently to succeed in the cloud native journey?
Cloud native needs a cultural change
Cloud native is a philosophical approach combining with a set of technologies that allow organizations to build, deploy, and operate software applications more frequently, resiliently, and reliably. The culture is an important one that is mostly ignored when describing the cloud native. In addition to the architectural and technical requirements, it should include cultural changes like more agile processes, dynamic and decentralized decision-making, and autonomy teams that will allow the organizations to utilize the benefits of all those modern technologies.
Cloud native do frequent releases. It required agile requirements gathering, design, architecture reviews, development, testing, and deployment. If we have to wait a long time to get approval in any of these stages, we can’t do frequent releases. I think without having an autonomous team structure, this is a hard problem to solve. Classic software development models like waterfall, fast water-fall are not 100% fitting into cloud native culture.
Scalability is required in every phase to be a cloud native. Having the Kubernetes platform, shipping applications as containers are only addressing the technical aspect of the problem. The two-pizza teams, feature-driven teams, and sprints-based development help to gain scalability in the early stage of the software development life cycle.
Iteration and continuous delivery are essential in cloud native. The majority of organizations claim cloud native by just having CI/CD or GitOps platforms in place in the delivery pipeline. But sometimes their release cycles are in once a year or twice a year and they are missing an important point here. Cloud native is about fast innovation through the customers’ continuous feedback and delivers an improved product on a daily or even hourly basis.
Quality assurance is important in the product delivery process. Many organizations are having so many test methodologies like unit testing, integration testing, and so on. But automated consumer-driven contract testing is essential in cloud native. Decentralize architectures like microservices required API driven communication, and contract-based testing is the best way to test end-to-end scenarios. Two pizza autonomous teams can do fast innovations in their silos, but they can’t break the other dependencies in the system. Having proper governance helps to mitigate the risk but automated testing is the only way to assure. Every organization should have a mantra saying “If we can’t have automated testing for a new feature, then there is no new feature”.
DevOps mindset is also critical in the cloud native journey. At the beginning of the application or feature development, the developer should have a proper understanding of how it is going to be rollout. It can be canary deployment or A/B testing, but it should properly design, plan, and develop. This is one of the common failures but the fact is deployment should not be an afterthought in the cloud native.
Conclusion
Every organization wants to move into cloud native to increase innovation and productivity. Many organizations are failed in the cloud native journey by only adapting a set of cloud platforms, tools, and techniques. But Cloud native is more than architecture or technology. It is a philosophical approach and a culture change that allows organizations to utilize the benefits of all modern technologies like microservice architecture, containers, Kubernetes, and CI/CD.