Cloud native did not occur overnight. Many events contributed to this paradigm change. Let’s examine the history and explore key concepts that will help us understand cloud native. Why is it considered necessary today? How did we get here? Did we learn from the past? Here is a fast-forward list of the critical historical events influencing what we now know as cloud native. We are looking at it in chronological order. Therefore, we will be jumping between hardware, software, and design paradigms.

The foundations for ML, AI, and cross-functional teams

Machine learning (ML) and artificial intelligence (AI) are nowadays often used when discussing cloud native, and various cloud service providers (CSPs) provide many prepackaged ML and AI services. The history goes a long way back.

In 1950, an English mathematician, Alan Turing, published the paper Computing Machinery and Intelligence, proposing the Turing test as a criterion for machine intelligence...

What is cloud native? There are many different definitions, and for the context of this book, we will go with the definition of the CNCF:

“Cloud native technologies, also called the cloud native stack, are the technologies used to build cloud native applications. These technologies enable organizations to build and run scalable applications in modern and dynamic environments such as public, private, and hybrid clouds while fully leveraging cloud computing benefits. They are designed from the ground up to exploit the capabilities of cloud computing, and containers, service meshes, microservices, and immutable infrastructure exemplify this approach.”

According to Gartner the term “cloud native” is an approach that “refers to something created to optimally leverage or implement cloud characteristics.” The key phrase here is “optimally leverage or implement cloud characteristics.” This area is exactly...

In the The evolution of cloud native section, we discussed Conway’s Law, the Agile Manifesto, the rise of Agile software development, and the first DevOps conference in 2009. But what exactly is DevOps?

The culturural aspect

DevOps is a cross-functional combination of development and operations. Key characteristics are shared ownership, workflow automation, and rapid feedback. DevOps uses cultural behavior, practices, and tools to automate development and operations to improve the end-to-end SDLC. Its goal is to improve the software quality and decrease the time from a committed change to production. DevOps is mainly about culture and, as a result, it impacts the software toolchain. The cultural change aspect of DevOps adoption is quite often underestimated. Let’s elaborate on the impacts to understand why this is the case.

DevOps adoption means that different disciplines work together, which we call cross-functional teams. The...

We have already covered many aspects of cloud native solutions, including the cultural impact, cross-functional teams, DevSecOps culture, and tooling complexity. We will now examine observability and resilience, two areas that need more consideration during the early design phases of cloud native solutions.

If we do not establish comprehensive observability, we will not know whether we achieve our targets, such as response times. And if we fail, we will not know where the bottleneck is. Therefore we need to have a holistic logging, monitoring, and observability strategy in place. The same applies to withstanding failures. We need insights to validate that our deployment architecture matches the resilience expectations. We will explore both aspects, starting with observability and what it means in a cloud native context. We cannot fix what we cannot see. Observability helps get actionable insight into an application’s internal state and measure...

By now, we have a good understanding of cloud native. But why are there so many misunderstandings? The concepts are complex and require different ways of working. Technology is changing rapidly, and there is a lack of standardization, which leads to various interpretations. Moving toward cloud native requires a lot of training and a new mindset.

Misunderstandings can lead to the following shortcomings:

• Slow time to market
• Lack of security
• Lack of fault tolerance
• Lack of backup and recovery
• Inefficient DevOps and CI/CD best practices
• Increased operational effort
• Increased total cost of ownership (TCO)

We will now examine some common cloud native misunderstandings. Each will result in several of the listed shortcomings.

The shared responsibility model

Not understanding the shared responsibility between the CSP and the customer is a misunderstanding with very severe consequences. The shared responsibility model articulates...

This introductory chapter has already covered a lot of ground. We learned about the evolution and benefits of cloud native. We discussed how culture is part of cloud native and how DevOps evolved to DevSecOps. It is critical to consider security throughout the complete SDLC. We also looked into foundations for CI/CD, observability, and resilience. We also clarified common misunderstandings, which will be helpful for conversations with stakeholders and the remainder of the book. Now that we are equipped with an excellent foundational understanding, we are ready to look into anti-patterns. We will start with objectives and strategy in the next chapter since they will be defined at the beginning of our cloud native adoption.