1
Benefits of Cloud Native and Common Misunderstandings
Several thousand years ago, households had to dig and build wells, draw water from rivers, or set up rain barrels to collect water. They had to manage the filtration and purification to ensure water was safe for drinking and other uses, and they had to maintain that infrastructure. Water supply turned into a commodity by centralized municipal water systems. Users can now access clean water through a faucet and pay for the amount they use.
Similarly, cloud native commoditizes information technology aspects that we had to manage in the past. It can enable the simplification of solution architectures and operational complexity. It can also make securing our applications easier and help us meet regulatory goals. This commoditization aspect can make it easier to manage and refresh our data. The word can was used on purpose in the previous sentences. All four authors have worked for professional service organizations focusing on cloud technology. The cloud provides significant new opportunities, but we must understand the risks, anti-patterns, and how to mitigate them. Despite the huge potential that cloud native brings, we have seen many things going mindbogglingly wrong. That includes accidental deletion of entire environments, and leaking secrets, and the core part of the book will focus on that. Quite often, we were involved in remediating those applications or helping customers with security breaches or data losses. Of course, other times, we were working on greenfield solutions and could help to stay away from anti-patterns.
The goal of this book is to help steer away from these anti-patterns, remediate them, and move toward best practices. In this chapter, we will lay out the foundations. The following chapters will build on top of that gained knowledge. Therefore, it is important to digest the information in this chapter, which includes the following:
- The evolution of cloud native
- The benefits of cloud native
- DevSecOps culture, IaC, and CI/CD
- Observability and resilience
- Common misunderstandings
The evolution of cloud native
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. American scientists and researchers coined the term AI in their proposal for the Dartmouth conference in 1956.
Many see virtualization as a major foundational step toward cloud native development. It started in the 1960s when IBM released the Control Program/Cambridge Monitor System. It enabled the division of hardware components. For example, several virtual machines (VMs) running on a physical computer can use the same physical processors and memory. VMs allow multiple users to share hardware resources.
In 1967, Melvin Edward Conway developed a theory named “Conway’s Law.” It describes how designers of software components that interact with each other also have to communicate with each other. Conway summarized this behavior with the following quote: “Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.” This is a significant finding that influences how we structure teams nowadays. We use terminology such as squads, agile teams, and DevOps. We know that we have to set up cross-functional teams and excel in collaboration to deliver cloud-friendly solutions.
The age of virtualization
IBM continued developing further enhancements in 1980. However, the market was not ready yet for a wide commercial adoption of VMs. Personal computers became popular in the 1980s, slowing down the VM market. It was only in the late 1990s that VMs went mainstream. One of the market leaders was VMware.
The beginning of distributed applications
A new design paradigm, service-oriented architecture (SOA), emerged. It introduced the concept of services and promoted reusability. SOA is often seen as a precursor to micro-services. At the same time, a little bookshop called Amazon realized that they needed to change their architecture to scale it in a way that makes it future-proof. An intelligent group of Amazon engineers released the internally published Distributed Computing Manifesto, which explained that the architecture of our application needs to scale to manage a demand 10 times the current size of what it was back then. The paper called out that applications should not be tightly coupled. It explained a service-based model. It also proposed a three-tier architecture to separate the presentation layer (also called client or application), business logic, and data.
It also described that synchronization should be used when an immediate response is required. Asynchronous calls can be used for workflows where an immediate outcome is not required. The workflow only needs to move to the next stage. Asynchronous API calls made perfect sense for Amazon’s order processes. Amazon Web Services (AWS) launched years later as a new brand. The first web services were released for public consumption. The first public launch was a message queuing service called Simple Queue Service (SQS).
The philosophy of queuing aligned perfectly with the Distributing Computing Manifesto. Elastic Cloud Compute (EC2), a virtualization service, and the blob storage service called Simple Storage Service (S3) were released next. S3 was a very significant milestone in the evolution of cloud native history. In 2000, Roy Fielding defined REST architectures in his PhD dissertation Architectural Styles and the Design of Network-based Software Architectures. REST is designed for scalable client-server applications. REST suggests that the coupling between the client and the origin server must be as loose as possible. Within the context of REST APIs, “stateless” means that each request from a client to a server must contain all the information needed to understand and process the request, without relying on any stored context on the server. This ensures that the server does not retain any session state between requests, allowing for scalability and reliability.
The rise of Agile, DevOps, and the cloud
In 2001, 17 software engineers gathered in Utah to outline values and principles for agile software development. Some of those engineers became famous software development advocates, including Alistair Cockburn, Martin Fowler, and Kent Beck. As a result of this get-together, they created the Manifesto for Agile Software Development, often called the Agile Manifesto. It highlights the importance of individuals and collaboration within software development engineering teams and with customers to deliver better software more efficiently. The collaboration aspects address some of the problems described in Conway’s Law. That cross-functional team approach is still embedded in most agile delivery frameworks.
Google Cloud Platform (GCP) and Microsoft’s Azure cloud platform were launched in 2008. In the same year, Google released App Engine, one of the first serverless computing offerings. It included HTTP functions with a 60-second timeout and a blob store and data store with timeouts.
The need for collaboration emerged even more during this decade, and software industry experts pointed out the problems that result from separating development and operations.
The term DevOps was coined. The first DevOpsDays conference took place in Belgium in 2009. In its early days, DevOps focused on continuous integration/continuous delivery (CI/CD) and infrastructure automation.
Edge computing – microservices, and addressing security
In 2010, edge computing gained significance, especially within the Internet of Things (IoT). Edge computing is an extension of the cloud. It brings the entry points to cloud infrastructure closer to the consumer. Some of the key benefits are latency reduction and increased resilience and reliability. The use case of edge computing has evolved since then. For example, content can be cached closer to the end user. This caching approach is known as a content distribution network (CDN). Well-known CDN solutions are provided by Cloudflare, Akamai, and the three major cloud platforms (AWS, GCP, and Azure).
In 2011, the term microservices gained popularity in the software engineering community. Microservices enhance SOA with a strong focus on continuous incremental change and lightweight communication between services and endpoints. Sometimes, people use the term microservices interchangeably with the term cloud native. We will talk more about that when we explore common misunderstandings.
Engineers at Heroku also developed the 12-Factor App methodology during that time. The 12-Factor App principles provide best practice guidance for building scalable and maintainable software as a service (SaaS) applications. They emphasize a declarative setup, a clean contract with the underlying operating system, and maximum portability between execution environments. Some key principles include managing configuration separately from code, treating backing services as attached resources, and strict separation of build, release, and run stages.
Between 2012 and 2013, the term DevSecOps was mentioned more and more. It was seen as an extension of DevOps. DevSecOps advocates embedding security early in the software development process, automating security testing, and embracing a culture of shared security responsibility among teams.
Containers and function as a service
In 2013, Docker containers were released. The main difference between VMs and containers is that VMs provide an abstracted version of the entire hardware of a physical machine, including the CPU, memory, and storage. On the other hand, containers are portable instances of software. Containers are unaware of other processes running on the host operating system.
Google released Kubernetes about a year later, which is a container orchestration platform. Kubernetes is still widely used for scaling containers, container management, scalability, and automated deployments.
The first function as a service (FaaS) capability was released in 2014. AWS released Lambda functions. Later, other CSPs adopted FaaS, such as Microsoft with Azure Functions and GCP with Google Cloud Functions. FaaS provides a fully managed runtime where we only need to manage our code. This was a fundamental shift that allowed DevSecOps practitioners to fully focus on the work that distinguishes their organization from others, including application code, and architectural design. We only pay while the function is running, and there is zero cost when the function is not being invoked.
The concept of service meshes was also introduced during that time, which are a dedicated infrastructure layer for monitoring, managing, and securing network communication between microservices in a cloud native application.
Cloud native and best practices
The Cloud Native Computing Foundation (CNCF) is a Linux Foundation project that started in 2015. Two years later, in 2017, Google, IBM, and Lyft open-sourced the popular service mesh implementation Istio.
In 2018, researchers at the National Institute of Standards and Technology (NIST) and the National Cyber Security Center of Excellence (NCCoE) published the Zero Trust Architecture (ZTA) framework. It describes a “never trust, always verify” approach. This requires strict identity verification for every device and human attempting to access resources, regardless of location within or outside the network. ZTA is now increasingly becoming more important in cloud native architectures. It is seen as a robust approach to reduce the risk of data breaches and enforce the least privileged access approach.
OpenTelemetry is an open source observability framework. It was created in 2019 when CNCF merged the two projects, OpenCensus and OpenTracing. Its purpose is to collect traces, metrics, and telemetry data. OpenTelemetry is commonly used to monitor microservices and other distributed applications.
The FinOps Foundation was established in 2019 and became a project of the Linux Foundation in 2020. It is dedicated to “advancing people who practice the discipline of cloud financial management through best practices, education, and standards.”
Between 2020 and 2012, GitOps evolved from DevOps. It is a practice for CD using Git, a distributed version control system, as a source of truth for infrastructure and application configuration.
In 2023, Open Policy Agent (OPA) emerged as a security framework in the Kubernetes community. It addresses several use cases, including authorization of REST API endpoint calls, integrating custom authorization logic into applications, and a policy-as-code framework for cloud infrastructure pipelines. It had previously been a CNCF incubating project.
Also in 2023, the trend of ML and AI integration emerged. The major CSPs released their managed services, including Google’s AI Platform, Amazon SageMaker, and Azure ML.
Where are we now and what does the future bring?
Many of the described frameworks and best practices continued to trend through 2024. One of the biggest trends is embedded AI services for productivity, operations, and security. Let’s go through some examples before we move to the benefits of cloud native.
AI for operations (AIOps) provides predictive insights, anomaly detection, and automated responses. Cloud native application protection platform (CNAPP) solutions are taking the world by storm. They provide holistic protection and compliance validation throughout the software development life cycle (SDLC), from development to operations. Chatbots and other generative AI services that assist developers and improve their productivity are also rapidly becoming popular.
The AI trend includes technologies such as ChatGPT by OpenAI, Microsoft’s GitHub Copilot, AWS Code Whisperer, Amazon Q, and Google’s Cloud AI and Vertex AI. There are legal concerns regarding generative AI services. One concern is that our sensitive data could be used to train the AI model. The main concerns are whether the data could become visible to a third party and whether the data remains within our region, which might be required for compliance reasons. Another concern is intellectual property ownership. Who owns the result if the generative AI service generates foundational parts, and a human enhances that generated outcome? Different jurisdictions have different laws, and there are often gray areas because this is a fairly new concern. Discussions about these concerns will continue for quite some time.
We now have a good understanding of significant events that contributed to what we now understand as cloud native. But what are the actual benefits of cloud native and why is it so significant for modern architectures? We will explore that in the next section.
Benefits of cloud native
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 where we have seen many large organizations go wrong. Quite often, they treat the cloud the same as their data centers. We will dive into that in the following chapters when we go through anti-patterns in detail.
Faster time to market
Let’s start with the first key benefit: faster time to market. It is one of the key drivers and the reason why so many start-ups have commenced using cloud native services. Those start-ups started without legacy systems and needed to show outcomes quickly to get venture capital and generate income streams for growth. Developers can leverage self-service provisioning of resources, saving them a lot of time compared to traditional mechanisms where they had to request infrastructure to be provisioned.
With a cloud native approach, they can quickly create new environments or serverless functions. Depending on the resource type, the provisioning might take seconds or minutes. Database provisioning usually takes several minutes, whereas blob storage, such as an Amazon S3 bucket or FaaS, can be deployed within seconds. This helps to achieve a quicker time-to-market goal. It also helps for quicker innovation cycles. If we want to perform a proof of concept to compare the productivity using differing programming languages, using FaaS will save a lot of time because the runtimes are already pre-provisioned by our CSP. It is easy to try out some functions in Golang, and others in Rust or Java. Provisioning and decommissioning are a minimal effort and developers can focus on the application development without any waiting times.
Scalability and elasticity
Scalability and elastic infrastructure are other benefits. Applications can easily scale up and down on demand. Cloud native architectures typically leverage horizontal scaling over vertical scaling. This is a big advantage for applications with significant peaks, such as shopping websites or payment applications. They need to scale up during day peak times or seasonal peaks. Once the traffic spike decreases, we can automatically scale back the underlying infrastructure.
This is very different from traditional on-premises deployments, where we need to permanently provision for the absolute highest traffic volume to avoid outages. The cloud infrastructure is elastic. So is the pricing model to some degree. For instance, if we dispose of a compute instance after a scaling event, we are not being charged for it anymore. However, if we store data without deleting it, we continue paying storage fees.
Managed services
Managed services are managed by the CSP. They improve the operational efficiency for customers and reliability and availability. Therefore, they are a significant advantage in cloud native architectures. The CSP manages the underlying infrastructure of managed services. Depending on the service, that may include the application itself, such as a queuing or notification application. This includes the provisioning, configuration, maintenance, and network constructs. If we use a managed relational database service such as Amazon Relational Database Service (RDS), Microsoft Azure Database, or a Google Cloud database, the CSP manages the patching and upgrading of the underlying infrastructure, including the database engine. Managed database services also implement security and compliance with industry regulations up to the database layer. The customer is responsible for the security above that layer, such as the data encryption. The way our business drives business value is not impacted by how we patch our database or run a hypervisor. Managed services are abstracting away a lot of this operational overhead. This allows us to focus on the business differentiators, such as the application logic and data offering. Managed services typically provide monitoring and reporting capabilities, such as method invocation for FaaS. Managed database or data storage services usually come with out-of-the-box backup and recovery mechanisms. Managed services can scale automatically and have built-in cost management and optimization features.
Security and compliance
Further security and compliance advantages of cloud native architectures are unified access controls. Role-based access control (RBAC), attribute-based access control (ABAC), and identity and access management (IAM) services ensure we can implement the least-privilege principle. Encryption by default for data protection in transit and at rest ensures that the customer data can always be encrypted, which is a best practice and also required in many regulated industries.
There are also built-in security features, such as DDoS (distributed denial-of-service) protection, firewalls, network access control lists (NACLs), and security information and event management (SIEM) tools. Most CSPs also support multi-factor authentication (MFA) and single sign-on (SSO). Having these two controls in place is quite often an internal security requirement. MFA is also mandated by some regulatory requirements, such as the Payment Card Industry Data Security Standard (PCI-DSS). SSO integration makes it easier to manage human and machine access permissions centrally. This centralized approach reduces operational effort and also helps to meet regulatory requirements.
Cloud native also provides preventive and detective guardrails, which are instrumental in protecting our teams from some human errors. Preventive guardrails ensure that specific actions, such as deleting a backup vault, can never be performed. Detective guardrails still allow specific actions, but they can send notifications if a particular event happens, and findings can be visualized on a dashboard. For example, we would like to see whether we have any unencrypted databases in a development environment. We could enforce encryption via preventive guardrails for higher environments such as testing or production. Detective guardrails can also trigger auto-remediations for existing cloud resources. If a blob storage does not have access logging enabled, an auto-remediation can perform that change. Automated vulnerability scans are another feature that many CSPs offer. They help to scan VMs, containers, FaaS code, and networks. The scanning tools typically provide a report with findings and remediation recommendations.
Reliability and availability
There are also other reliability and availability benefits of cloud native applications. Anomaly detection services help to detect suspicious user behavior or unusual system behavior due to a flaw. They help to identify incidents at an early stage. Deployment architectures can easily leverage several independent locations within one geographical region. AZs are physically isolated from each other and have separate power supply and connectivity, but highspeed interconnects within a region. A region could be Sydney or Singapore. Independent locations are called availability zones (AZs). The term AZ has a different meaning depending on our CSP, but for now, this definition is good enough for us. It is best practice to architect our application so that it leverages several AZs, ideally all the AZs we have in our region. Multi-AZ deployments help with automated failovers from one AZ to another. In an outage in one AZ, the other AZs can absorb the load and reply to incoming requests, such as API calls. This failover is a built-in feature, but the application needs to be architected correctly to leverage those benefits. We could even deploy our application to several regions. In the unlikely event of a total region failure, the second region can take on the entire load and respond to incoming requests. A total region outage is very unlikely. Therefore, this use case is less common than the other use cases for global deployments.
Regional outages are a segway into the next advantage we want to discuss.
Global deployments
With global deployments, it becomes easy for organizations that operate in several countries or even globally to address that in their deployment architecture. With global deployments, we can reduce the latency between our customers’ devices and our applications. We can leverage a CDN; this caches data closer to our customers and is helpful if customers are not located in our geographical region. For example, suppose our application is hosted in Sydney, on the east side of Australia, and our customers are 4,000 kilometers away on the west coast of Australia. In that case, we can leverage a CDN to store cacheable information in Perth, located on the west coast. Those distributed locations are called edge locations. We can even run certain forms of authentication on the edge location to reduce the latency for a login procedure. This additional caching layer increases the availability of content. It can also reduce the bandwidth cost because the amount of data that needs to be provided by an origin server is reduced, and therefore, we are charged less egress data. We can potentially downsize our provisioned infrastructure. CDNs can handle large traffic spikes. Hence, they protect against DDoS attacks.
Another driver for global deployments could be regulatory requirements, such as data sovereignty laws. For regulated industries such as financial services or health services, customer data must reside in the originating region. For instance, data of United States citizens must be stored within the United States, and data of European customers must be stored within the European Union. With global deployments, it becomes easier to deploy applications to different regions. The application will then store the data within that region and stay there. With a CDN, we can also use cloud native geo-restrictions. We can limit the content to particular continents or countries; usually, we can define allow and deny lists. Those geo-restrictions are why some media content is unavailable in other countries. E-commerce platforms typically deploy their applications globally as well. That way, they can have different product catalogs per region and have all the reliability and availability benefits. The reduced latency of global deployments is also why they are ubiquitous for gaming or large IoT solutions. Another use case for global deployments is disaster recovery (DR). Data can be backed up in a different region to improve business resilience.
CI/CD – automate all the things
Cloud native typically offers automation capabilities for CI/CD. They enable automated build, test, and deployment of applications.
When using CI/CD, every change goes through a controlled process that should include peer reviews of code changes. Since everything is code-based, creating new environments ad hoc is low effort. Creating environments in other regions or tearing down temporary environments is also easy. Automation helps to decrease the time to market, improve the robustness of the change management process, enable consistency between environments, improve security and reliability, and help reduce cost.
Cost benefits and paradigm change
Hosting our applications in the cloud instead of on-premises moves the cost model from an upfront capital expenditure (CapEx) investment to a pay-as-you-go model. Rather than having substantial infrastructure investments every five years, we will have an ongoing spend in the cloud.
Some of the previously described features, such as auto-scaling and automation, help with cost optimization in the cloud. But there are more native features. Each cloud resource should have tags. Tags are metadata that describe a resource. Common tags include environment, data classification, cost center, and application owner. Tags can be used for a cost breakdown or security controls. Native cost dashboards provide cost insight and give different views based on tags, regions, or resource types, such as VMs or managed API gateways. The cost dashboard solutions are AWS Cost Explorer, Google Cloud Billing Reports, and Azure Cost Management & Billing.
We can also set up budgets to ensure we are notified if the projected spending exceeds the forecasted spending. We can define budgets manually or use built-in AI capabilities to set budget values. The AI component usually takes a few days to figure out the usual peaks and lows. Most CSPs also provide rightsizing recommendation services. This service helps to reduce costs where the customer has overprovisioned resources, such as VMs or databases. CSPs also offer a committed spending plan, which grants discounts if we commit to a spending amount for longer than a year.
Portability
Cloud native also delivers a couple of portability benefits. Containers and orchestration tools such as Kubernetes promote standardized configuration and deployment processes. A container-hosted application can easily migrate to a different CSP. Cloud native solutions are hybrid cloud-compatible and can integrate with our data centers. Hybrid deployments are widespread for massive application migrations where the migration from on-premises to the cloud happens over a long period. Typically, the frontend part of the application is moved to the cloud first, starting with components such as the CDN, APIs, and user interface. For cases where low latency and a reduced jitter are required, we can use cloud native connectivity services. These connectivity services require our data center to be in one of the colocations of the CSP and underlying infrastructure changes in our data center, such as new cable connections, are required. Examples are GCP Cloud Interconnect, AWS Direct Connect, and Azure ExpressRoute.
Cloud native architectures offer many benefits. However, we have only scratched the surface of cloud automation, and we have not even discussed the cultural aspect. Let’s get onto it now.
DevSecOps culture, IaC, and CI/CD
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 two-pizza team topology, created by Amazon’s Jeff Bezos in the early 2000s, is a strategy for keeping teams small and efficient by ensuring they are small enough to be fed with just two pizzas. This approach fosters better communication, agility, and productivity within the team. The you build it, you run it mentality fosters business agility. It empowers teams to react faster and innovate to deliver customer value. It also results in high-quality outcomes since people are motivated to avoid incidents they get called into. Those things should sound familiar by now. Let’s have a look at how this looks when we add security to the mix.
DevSecOps
A mature DevSecOps culture adopts a shift-left approach. Functional and non-functional quality controls are performed very early in the SDLC. Shift left means testing activities such as requirement definition and design start early, so the testers are involved early. Testing is usually automated to a high degree, including unit tests, integration tests, non-functional tests, regression tests, contract tests, and others. Tools for static code analysis help to analyze code quality.
DevSecOps augments DevOps and suggests embedding security in the software delivery process. This empowers development teams to produce high-quality changes that meet security and regulatory requirements. DevSecOps integrates security tools into the CI/CD toolchain. This integration includes static application security testing (SAST) tools to analyze the source code for vulnerabilities. Software composition analysis (SCA) is an analysis of custom-built source code to detect embedded open source software or libraries and validate that they are up to date and contain no security flaws. Other usual security scans include secret scanning to ensure no security keys or passwords are embedded in the code. Vulnerability scans inspect machine images, container images, and source code for common vulnerabilities and exposures. These types of scans have become increasingly important due to a surge in supply chain attacks. A supply chain attack uses third-party tools or services to infiltrate a system or network.
There are many new trends with the word Ops in them. One that gets a lot of attention is AIOps, which promotes leveraging AI capabilities and embedding those in the DevSecOps approach to identify anomalies and suspicious behavior early. As a result, we want to see improvements in delivery and operation, and we will look into that next.
Measuring the progress
The DevOps Research and Assessment (DORA) team published the DORA metrics. Their purpose is to measure and improve the performance and efficiency of the software development process. Providing actionable insights helps identify bottlenecks and improve the process. The four key DORA metrics are as follows:
- Lead time for changes (LTFC) is the time from the first code commit to deployment. Shorter lead times mean faster delivery of business value.
For instance, we can track the time from when a developer commits a change to a production release. On average, this takes 24 hours, which allows the company to respond swiftly to market demands and user feedback.
- Deployment frequency (DF) is the number of deployments in a given duration of time. A high frequency indicates the ability to deliver new features and bug fixes and respond to customer needs.
For example, we release updates to our mobile app twice a week. This frequent deployment helps to quickly deliver new features and bug fixes to users, ensuring the app remains competitive and user-friendly.
- Change failure rate (CFR) is the percentage of failed changes over all changes. A lower rate indicates higher quality and stability in releases.
For instance, out of 50 deployments in a month, 5 resulted in rollback or required hotfixes due to bugs or issues. This gives our organization a CFR of 10%, highlighting areas for improvement in their testing and review processes.
- Mean time to recovery (MTTR) measures the average time it takes to recover from a system failure. A shorter MTTR demonstrates the ability to recover quickly from incidents.
Tackling the cultural challenges
Now that we have looked into DevSecOps, we can see that adoption is not trivial. There is a lot to consider. Starting from a waterfall software development approach will be a steep learning curve. A considerable percentage of humans have some degree of resistance to cultural change. If an organization is separated into silos, it will take a while to break those down. DevSecOps requires more collaboration and broader skills. Therefore, it is crucial to provide sufficient training. Training will be required to gain cloud native knowledge including the tools used to build, test, and deploy the code.
As the term Ops in DevSecOps suggests, the team also operates the applications. Therefore, the team is motivated to release quality code to ensure they do not need to solve too many incidents. This ownership approach is a crucial differentiator from traditional methods, where development and operations are separated. It also means the team members need the skills to build observability capabilities and react to incidents. Learning all this will require training, which can be a combination of classroom training, online training courses, and pair programming. Providing learning environments for experimenting and creating proof of concepts is also very effective in upskilling our teams. These environments are usually called sandpits or sandboxes. We use the word developer here because they will likely produce application, test, infrastructure, or configuration code. But that term can be used interchangeably with engineer, software engineer, full stack developer, and others.
There are different ways organizations can drive cultural change. Top-down means the change initiative starts at the leadership level, and bottom-up means it begins with the delivery team and eventually reaches the management and leadership levels. For a successful DevSecOps adoption, we will need buy-in from the leadership. Otherwise, the required cultural changes won’t happen. The adoption process is mostly successful when it gets adopted first in parts of the organization that already have an agile delivery approach. Those teams will find it easier to experience DevSecOps, and they can start swarming after a while. That means the team members can be augmented and act as mentors in other teams. Getting external help through a DevSecOps consultancy can be good if we are at the beginning of our transformation journey. The external consultants can coach the team, contribute to the code base, and ensure that best practices are applied. For a successful DevSecOps journey, the consultants must transfer the knowledge to the internal development teams.
IaC
The source code is the source of truth for every cloud native solution. Individuals responsible for the infrastructure create the infrastructure or patterns via infrastructure as code (IaC). IaC defines components such as network constructs, servers, policies, storage, and FaaS in code.
Cloud native versus cloud-agnostic IaC
CSPs offer their own IaC technology and there are also third-party offerings that are platform-agnostic:
- Cloud native IaC:
CSPs have their own IaC service for their platform, including AWS CloudFormation, Azure Resource Manager (ARM), and Google Cloud Deployment Manager. Those services come with their own IaC language. Compared to higher programming languages such as Golang or Java, the IaC languages are less complex and can be learned quickly. Simplicity benefits individuals with a strong infrastructure background who do not necessarily have much coding experience except for Bash or PowerShell scripts.
- Platform-agnostic IaC:
There are also IaC tools available that use one common language to deploy to several cloud and on-premises platforms. Terraform is a popular IaC tool that can deploy to all major CSPs and thousands of other platforms, including collaboration platforms, firewalls, network tools, and source code management tools. Terraform used to be open source, but when it was shifted to a Business Source License in 2023, the community reacted quickly. The code base was forked, and a new open source project called OpenTofu was established.
It sounds as if IaC has the potential to bring significant advantages, which we will discuss next.
Advantages of IaC
What are the advantages of defining our cloud resources via IaC? Whenever we deploy something repeatedly, such as a temporary or new testing environment, the architecture and deployment approach will always be consistent, and the approach is easy to repeat. Typically, we use different parameters for a different environment, for example, a different IP range for a different network segment or a smaller auto-scaling group for non-production environments. The rest of the code stays the same. Hence, IaC is also very efficient in achieving scalability or implementing global deployments. Configuration and code are fully version-controlled in Git. Therefore, it is easy to go back to the previous version.
We can also easily use version pinning if we want our production environment to be further behind than the development environment. IaC also helps to achieve a good DR response time. Instead of manually or semi-manually building a new DR environment, we can fully automate this with IaC and CI/CD technologies, which we will cover in a minute. IaC also helps to meet security and compliance requirements. Security requirements are embedded in the code. For instance, if we only want to allow HTTPS traffic, our code will only open port 443, then we articulate that in the source code. As best practice, the code will be peer-reviewed to ensure we meet our requirements. When we redeploy, we can be sure we don’t expose our application since the deployment will deliver a repeatable outcome. All changes are tracked in Git, which helps with auditing and compliance. Some regulatory frameworks require a repeatable approach. That is exactly what IaC establishes. There is also a cost benefit to IaC. Because creating and destroying resources is so easy, it helps avoid over-provisioning. If test environments are not needed, then resources can be easily shut down if they are not required. If we take a complete serverless approach, we will need to worry less about this. We will talk about this later when we get into the strategy.
How do we deploy the cloud resources that we have defined via IaC? How do we build and deploy our application code? How do we execute all the functional and non-functional tests in an automated way? The answer is CI/CD, and we will explore it now.
CI/CD
CI/CD is a combination of continuous integration and continuous delivery, sometimes referred to as continuous deployment. The main difference is that continuous delivery requires a manual approval step, whereas continuous deployment deploys automatically after a code change. CI/CD bridges gaps between development and operations. It enforces automation during the build process, functional and non-functional testing, and deployment.
Defining a structure
There are many ways to structure the CI/CD process and even more combinations of tools. The fine-tuning will depend a lot on organizational and regulatory needs. We will go with a standard structure, where we want to adopt a shift-left approach. The following diagram helps us step through this process:
Figure 1.1 - Simplified conceptual CI/CD process
The process starts with the developer using the preferred integrated development environment (IDE). Sometimes, developers use just a command-line tool. However, IDEs are commonly used because they provide practical built-in features and plugin architecture. This architecture enables the installation of extensions or plugins. Visual Studio Code is a popular open source IDE developed by Microsoft. Even though the software is open source, the available extensions are not necessarily open source. IDEs usually have a built-in Git integration. However, we can install an additional extension that visualizes the Git repository and the Git branches.
Git branching and shift left
A Git branch is a separate version of the code repository created for a new change. There are different branching models, such as trunk-based development or feature branching. We will look into that in more detail in Chapter 5, and for our example, we will use the feature branching model. When the developer wants to commit a change to the repository, it is important to work off the latest version in the repo (short for repository). Therefore, a git pull command is required to ensure the latest version is in the local copy. After that, the developer creates a new feature branch and updates the code. There are a lot of checks that can now be run automatically to provide early feedback. For example, a security extension could scan the code and identify weaknesses. For instance, if the code is a Terraform template that defines a public Amazon S3 bucket, then the plugin can provide feedback that the bucket should be private. S3 buckets are blob storage constructs in AWS, and misconfigured S3 buckets have been the reason for many data breaches. This early feedback is an example of shift left, and the developer can fix the code before it is validated in the CI/CD pipeline. Code formatting, linting, and syntax validations typically run on the client side. Once the developer is happy with the changes, the code is committed to the Git repo.
Optionally, a commit can trigger a pre-commit hook, executing the steps we just described. It can also auto-generate documentation.
Approval and deployment
The developer then raises a pull request (PR). Someone performs a peer review. The PR gets approved if the code meets the expectations. Then, the code is merged into the main branch. The merge will trigger the pipeline to run. In the beginning, there will be some validation steps similar to the ones the developer had already run. Still, we want to ensure that some validations are mandatory and don’t rely on individuals. As a next step, the build process will kick off and run some static code analysis, functional and non-functional tests, and further security scans. Once the pipeline run is successful, an authorized individual can trigger the deployment. These steps are a simple example of a CI/CD pipeline.
We can see the many benefits of automating those steps. Building out the required pipelines for an organization will take a while, but once they are established, the development process becomes much quicker, more reliable, and more secure. But how can we validate that it also runs as expected? Let’s find out.
Observability and resilience
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 it by evaluating outputs.
Logging – the observability enabler
Logs are the key enabler for monitoring and observability. The scope of logs is very broad, and they can include operating system logs, access logs, application logs, infrastructure logs, network flow logs, domain name service (DNS) logs, and more. Logs enable monitoring, alerting, debugging, incident discovery, and performance optimization. Earlier in this chapter, we clarified that a typical DevSecOps team (aka product squad) writes the code and also manages their application, also referred to as “product.” Therefore, the team will be motivated to establish good observability practices and tooling.
A good maturity level can be achieved when the team has a good mix of skills and experience mix across development and operations. Individuals with operational experience know the value of observability. People with a software engineering background also see the value of observability, especially on the application layer.
However, sometimes, the other layers, such as the network or operating system layer, need to be considered more. Getting a holistic picture covering all layers is critical to getting good insights into our systems. It is also essential to be able to correlate data. For instance, if we have a hybrid cloud application, a business transaction might start at the CDN, get to an API layer, and then write to a cloud-hosted queue where the on-premises business logic pulls the data from and writes it to an on-premises-hosted database.
Additionally, there is an on-premises firewall that inspects all incoming traffic. This architecture is complex but also common. If we have performance service-level agreements (SLAs), we will not only need to measure the end-to-end transaction time. We will need to identify the bottlenecks if we run the risk of failing to meet those SLAs. The problem could be anywhere on the entire traffic path. Good insights will help to pinpoint the bottleneck. Collecting all those logs leads us to another challenge. Because we know we need to collect all relevant logs, it is easy to fall into the trap of over-collecting, leading to alert fatigue. We will examine the typical anti-patterns in Chapter 10 and discuss how to address those pitfalls.
Log quality
Consistency, standardization, and good quality of log information are foundational for helpful dashboards and meaningful alerts.
A couple of things need to be considered to achieve this. We will need an agreement on the severity levels we want to log. Not all severity levels require logging all the time. The debug level, for instance, should only be logged when we are debugging. If we don’t make a sensible decision about when to use what severity level and what levels need to be logged, we will have inconsistent log files. It is also very likely that we will then log too much. This means we need a bigger log file indexer, increasing operational expenses. An increasing size of log volume makes it harder to find relevant information in case of an incident. That is especially the case if we don’t have a standardized log structure.
Therefore, we also need to define what information is captured in the log files and the sequence and structure. Structured data formats such as JSON help achieve this, and they help include key-value pairs to provide context. The log entry could include a key of userID or sessionID and the actual ID as a value. The log entry should contain other helpful contexts during troubleshooting, such as timestamps, transaction IDs, and correlation IDs, to trace and correlate requests between microservices. We should not store sensitive information such as credit card details, customer names, and addresses in log files. Some regulatory frameworks, such as the PCI-DSS, mandate data categories that must not be stored in log files. Centralized logging will also help to find data correlations because logs from APIs, the database, and infrastructure events will be saved in the same storage. Examples of popular open source logging tools are Logback, Graylog, and Log4j. The latter became famous in 2021 due to a vulnerability known as Log4 Shell, which allowed hackers to take control of devices running unpatched versions of Log4j. Therefore, we should always protect ourselves from vulnerabilities, and we will discuss this in more detail in Chapter 6. Some service mesh solutions, such as Istio or Linkerd, provide logs, metrics, and traces out of the box.
What else do we need to consider for logs? We need to ensure that only authorized individuals and systems have access to log files. If they contain sensitive information, they need to be encrypted. However, we will check with our applicable regulatory frameworks and internal security policy to see whether that is allowed. If our source code contains recursions, we should ensure that the same exception or error is not logged multiple times. We must also consider data retention for log files to avoid a bill shock. A sound logging approach will enable a good monitoring and observability capability, which we will discuss next.
Monitoring and observability
A monitoring solution is needed to make sense of the logs, and we need alerts to be notified about any critical events.
OpenTelemetry is an open source observability framework. It is designed to capture and process telemetry data, including metrics, logs, and traces from cloud native applications. It provides a set of APIs, libraries, agents, and instrumentation to help DevSecOps teams monitor application behavior. It fosters standardized data collection and consistent observability across applications and environments. A significant benefit is the interoperability with various backend systems. Because, with OpenTelemetry, we can instrument a standardized code, we can easily swap to different backends and tools. This reduces the vendor lock-in. OpenTelemetry has strong community support and is backed by major CSPs and observability vendors, ensuring ongoing improvements, broad compatibility, and shared knowledge and best practices. When choosing a new observability product, it is worthwhile to make OpenTelemetry support an evaluation criterion.
Popular open source tools that support OpenTelemetry are Prometheus for metrics collection, Grafana for visualization, Fluentd for log collection, and Jaeger for distributed tracing.
When setting up alerts, it is also critical to consider a team roster for on-call times. This defines when a particular DevSecOps team member needs to be available to solve incidents. It should also provide some flexibility and allow temporary roster changes if an individual is unavailable due to personal circumstances. If our team operates across different time zones, the tool must address that. Popular commercial offerings are PagerDuty and Atlassian Opsgenie. Observability helps to gain application insights in real time and to be able to react swiftly to any unexpected behavior. We aim to architect robust, scalable, and elastic solutions. But we also need to address the insights that we gained from an incident to improve resilience, which we will elaborate on in the next section.
Resilience
Addressing resilience in a cloud native architecture is crucial to understanding how the application can withstand failures. Failures can occur on any layer in the architecture and in any of the components involved. AWS released the first version of the AWS Well-Architected Framework, Microsoft followed with an Azure version in 2020, and Google released the Google Cloud Architecture Framework in 2021. All three frameworks have a Reliability pillar or chapter in their framework. Nevertheless, this area is often misunderstood, especially in the early days of a cloud adoption journey. It is the architect’s and engineer’s responsibility to design and implement the application in a way that addresses possible failures. If we leverage managed services, then the CSP will take a lot of considerations into account, and we can reduce the reliability surface that we need to manage. We will discuss this in detail in Chapter 7.
Humans can fail – so can the cloud
Even though the CSP is responsible for the resilience of the cloud services, outages can and will occur. “Everything fails, all the time” is a famous quote from Amazon’s chief technology officer, Werner Vogels.
There are a variety of infrastructure failure scenarios on the CSP side, such as service outages, AZ outages, region outages, or global services outages, such as a DNS outage. These are just some examples, and, of course, we can also have outages within the actual application. Examples are misconfiguration of load balancing or database connection pools, running out of disk or storage space, not allocating enough compute power such as memory or CPU size, unexpected configuration drift, or software vulnerabilities. We need to consider guiding principles when architecting resilience, and we will step through these now.
Automating recovery
First, an application should automatically recover from failure. This behavior is also known as self-healing. A failure needs to be discovered to initiate an automated recovery process. We put health checks in place. Those health checks can trigger follow-up actions. For example, we can configure health checks on a load balancer, and if a container instance behind the load balancer fails, it will be automatically replaced with a new instance. For this recovery scenario, it is essential to have a quick start-up time. Therefore, lean container images such as Docker Alpine are widely used.
Another guiding principle is that all change must be managed through code and automation. Automation enables a repeatable outcome and allows all changes to be tracked and reviewed. CI/CD becomes one of our best friends when we move into a cloud native world. Write access should be limited to CI/CD pipelines. Developers should be limited to read-only access for all environments except for sandbox environments. If human access is required in an incident, then there should be a break-glass mechanism. That means the elevated permissions are limited to the required timeframe and audit logs capture all manually performed changes.
Resilience and scalability
Recovery procedures must be tested. A working backup routine does not guarantee backup integrity or that the recovery procedure will work as planned. Our business continuity plan needs to address recovery testing. We must validate the documentation during a recovery test and update the documented recovery steps if required. A data criticality framework will help to define the proper recovery time objectives (RTOs) and recovery point objectives (RPOs). The RTO defines the maximum time to restore a failed application after an outage. The RPO defines the maximum time we tolerate for a data loss. For instance, if the RPO is 1 minute, we accept the risk that we could lose data for 60 seconds. Therefore, we will need to configure automated backups for every minute. The shorter the RTO is, the more frequently we need to perform backups. We need to consider cost and performance trade-offs to make informed decisions. We must test other recovery scenarios, such as network recovery.
Another resilience guiding principle is that an application should scale horizontally to increase availability. Horizontal scaling means we scale out in the event of a traffic spike. Typically, additional instances are spun up behind a load balancer to distribute the load. If we architect the solution for auto-scaling, capacity guesses become somewhat irrelevant. We still need to consider hard service limits published by the cloud vendors. But with dynamic provisioning and auto-scaling, we rely less on capacity estimates. Auto-scaling also helps reduce the CSP cost since we can right-size based on dynamic demand changes instead of statically provisioning for peak times.
Testing the recovery
Game days are an excellent way to validate resilience and uncover weaknesses that require remediation to improve application reliability or security posture. These are structured events where teams simulate different failure scenarios to test the auto-recovery, the efficiency of human processes, and the accuracy of the recovery documentation. The goals of the game day need to be defined before we can select failure scenarios. We will also need an environment where we can simulate outages. If our applications, including infrastructure, are defined as code and can be deployed via CI/CD pipelines, creating a temporary environment for that purpose will be easy. The game days usually start with a team briefing before the incident simulation commences. Typical scenarios include shutting down servers or containers, throttling network bandwidth, or simulating cloud service outages.
We can simulate outages with fault injection simulators. Netflix developed tools for this purpose and released Chaos Monkey in 2011. It randomly terminates instances. Other tools followed, including Latency Monkey, to simulate network latencies or unreliable network conditions. Nowadays, the major cloud platforms offer cloud native fault simulators: AWS Fault Injection Service, Azure Chaos Studio, and Google Cloud Chaos Engineering.
Once the fault injection has started, the team members need to detect where the problem is by using the observability tools and diagnosing findings. Data recovery needs to be validated. The validation includes data integrity validation and performance testing.
The insights gained will lead to mitigation steps, such as improving data recovery or fixing a misconfigured auto-scaling. The day ends with analyzing what worked well and what did not. These required improvements need to be implemented and tested again at a later stage. Game days are a good way of embedding feedback loops in our DevSecOps culture.
Now that we have explored a holistic picture of cloud native benefits, both cultural and technological aspects, we will finish this chapter by clarifying some common misunderstandings. This knowledge will help us to navigate through the anti-patterns that we will discuss afterward.
Common misunderstandings
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 security and compliance ownership. The CSP is responsible for the “security of the cloud.” That means they protect the underlying infrastructure that runs the services offered to the customers. Those are the data centers and the infrastructure that delivers cloud services. The customer is responsible for “security in the cloud,” for example, for their data or ensuring that encryption is enabled.
In an infrastructure as a service (IaaS) model, the customer has the highest level of responsibility. The CSP only manages foundational infrastructure, such as networks, data storage, and VMs that can host the guest operating system.
The customer’s responsibility is to manage their network constructs, such as a network address translation (NAT) gateway. The customer must also manage application-level controls, identity and access management, endpoints, and data.
In a platform as a service (PaaS) model, the CSP manages infrastructure and platform components such as the operating system, libraries, and runtime. Customers are responsible for data management and user access for their applications.
The SaaS provider manages most security responsibilities in a SaaS model, including software, infrastructure, networks, and application-level security. The customer is responsible for data protection, account management, and user access.
The following figure shows how responsibilities change when we move from on-premises to IaaS, PaaS, and SaaS. Whether we choose IaaS, PaaS, or SaaS, the following areas will always be our responsibility: data, endpoints, access management, and account or subscription management.
Figure 1.2 - The shared responsibility model
When we look at serverless technologies such as FaaS (AWS Lambda, Azure Functions, and GCP Cloud Functions), the customer’s responsibility is between SaaS and PaaS. The customer user is accountable for the serverless service’s deployed code and user-defined security or configuration options. Many organizations have a cloud platform team that establishes a platform for the product teams. They will often use a cloud native landing zone offering that provides a preconfigured, secure, and scalable environment designed to streamline cloud adoption, enhance security and compliance, and improve operational efficiency. In large organizations, the cloud platform team typically manages AWS accounts, Azure subscriptions, and Google projects. The cloud platform team will leverage cloud native account vending services such as the AWS account vending service or the Azure subscription vending service to perform this task.
The cloud platform team typically provides a service catalog that contains self-service artifacts, such as containers, network constructs for routing, guardrails, observability tooling, and more. Some artifacts will be provisioned as part of the automated account creation, including networking constructs, logging and monitoring capabilities, and guardrails. The product teams might publish other items to the service catalog or the container registry. In this case, we have a three-tiered shared responsibility model: the CSP, the cloud platform team, and the product teams. This can result in confusion around the operating model, which we will discuss next.
Operating model confusions
The operating model needs to address the responsibility model, and a clearly defined RACI matrix will help everyone understand what to do (RACI stands for responsible, accountable, consulted, and informed). The RACI matrix should include all phases in the SDLC, from source code to operations. Some example tasks that should be in the RACI matrix are certificate management, DNS management, key management, backup, and recovery.
When I worked for a cloud and DevOps consultancy, I started a new engagement with an educational institution. It was my first morning on site when an administrator accidentally deleted an entire data warehouse environment. Unfortunately, this was the only non-production environment. The data warehouse is a very business-critical application since it manages all the data of university applicants and students. We then tried to recover from backups. Unfortunately, the data recovery had never been tested. The backup data was corrupt and, therefore, useless.
Another administrator then asked whether we could call Amazon and ask them for backups. This question demonstrates that the shared responsibility model is not always understood. The administrator should not have had permission to delete an environment in the first place. Access and identity management, including the principle of least privilege enforcement, is the customer’s responsibility. Also, data management, including backups and recovery testing, is the responsibility of the customer. After that incident, we built a self-healing solution for the client and improved the permission model.
Missing out on cultural transformation
Another common misunderstanding is that cloud native is only about technology. We have talked about the DevSecOps culture before. The full potential will only be utilized if we are changing the culture. Otherwise, business innovation will be limited. It is easy to experiment in the cloud, create new proofs of concept, tear them down, or change them, but only with a DevSecOps mindset when mature automation practices are established. We need to put an effort into cultural transformation and leverage training and team augmentation. Otherwise, the resistance to change will continue, and the opportunity for quick change and release cycles can never be unleashed.
The lack of DevSecOps maturity will result in poor governance, limited agility, and slow responsiveness to market needs. A siloed approach where development and operations are separated will be reflected in the application structure as described in Conway’s Law. Eventually, the end customer experience will not be as good as possible. Another consideration is that cost management and ownership differ from an on-premises CapEx model. We are shifting toward operational expenses (OpEx), and without cost ownership and cost tagging, we cannot achieve effective showback or chargeback models.
If cloud native is solely seen as a technology enabler, we will not achieve efficient cost management. There will also be security challenges, which brings us to the following fundamental misunderstanding.
Treating cloud like on-premises
Believing that security controls in the cloud are the same as on-premises can also lead to many anti-patterns. This misbelief brings significant security risks and challenges and can dramatically reduce efficiencies and slow down our time to market.
We must manage data encryption, access controls, and backups for an on-premises environment. CSPs offer native security controls for encryption and access control. However, these controls need to be configured by the customer. It is critical to understand the responsibility demarcation, and it shows why understanding the shared responsibility model is so important. In other words, we can establish data security controls much easier in the cloud. Still, we must remember to look into our security and regulatory requirements and assess the attack vector.
Because of the global nature of the cloud, it is also easy to copy data to different regions. Cross-region support is a feature, but it can also be a trap with severe consequences. Since it is straightforward to switch between areas, it is recommended to have a policy-as-code framework in place that prevents that from happening by accident.
To manage network security on-premises, we use firewalls, VPNs, and intrusion detection and prevention systems, which we must manage ourselves. Cloud native offers virtual network segmentation and security features such as NACLs, security firewalls, and managed firewall services. Those controls need to be configured by the customer, but this can be done much easier than on-premises. We can guarantee consistent security controls between environments if those controls are managed via source code and deployed via CI/CD pipelines. This approach has similarities with application security. For on-premises workloads, we need to build all the controls, including vulnerability management and application firewalls. If we utilize a fully managed service, such as a managed database service or FaaS, the CSP is already taking care of the majority. We still need secure coding practices and scan our code, but we don’t need to scan the managed runtime environment. The CSP manages that for us; they have comprehensive compliance coverage. The coverage applies at least to the level managed by the CSP and we can download compliance reports for external audits. The customer still needs to take care of the layer above, as described in the shared responsibility model. However, cloud native provides compliance and audit features that can be configured for our needs. Cloud native services include Azure Compliance Manager, AWS Config, and Google Cloud Compliance Resource Center.
Lift & shift will leverage the full cloud potential
Thinking that a lift and shift approach will leverage all cloud benefits is another widely spread misbelief. Lift and shift means an application is moved from on-premises to the cloud without rearchitecting and refactoring. Lift and shift does not leverage any cloud native benefits. Instead of leveraging a managed database service, the database will be built using VMs, which requires installing the operating system and database. That means we must patch the database server, scan it for vulnerabilities, and develop and manage the entire security from scratch instead of leveraging built-in features. It would be much simpler if we could migrate our database to a managed database service. That way, we can significantly reduce the operational complexity and simplify the security approach. Cloud native services also have built-in scalability, resilience, and observability features. They simplify the application architecture and make it easier to operate the application. A lift and shift approach is very costly; such an application’s operational cost can be higher than on-premises. A driver for lift and shift could be a data center exit strategy. The overall effort will be higher because we need to build all the security controls and building blocks traditionally and then refactor the application toward cloud native. The effort duplication brings many challenges and a high likelihood of a budget blowout.
Containers solve everything
“Moving everything onto containers will make my application cloud native” is another widespread misconception. A containerized application does not necessarily utilize all the cloud native features we have explored. There are several variations of this misunderstanding. Another one is that cloud native requires containers. Even though containers are a fundamental technology in this space, they are not necessarily required. We might be able to use FaaS if that is a good architectural fit for our goal. In that case, we don’t need to manage containers or a cluster. A further variation of the container misunderstanding is that Kubernetes is required. Kubernetes is the most popular container orchestration platform, and the CSP offers managed Kubernetes services. There are some excellent use cases for it, such as microservice architectures. However, it comes with a steeper learning curve compared to Faas, and it is often underestimated. It is also worthwhile checking whether the required skills are available in the geographical market where the team needs to be.
Security can be an afterthought
A very concerning misunderstanding is that security can be bolted on afterward. Security must be considered and integrated from the beginning. “Security is job zero” is a well-known quote first mentioned by AWS’s chief information security officer in 2017. It means that security is everyone’s responsibility and should be considered the foundational priority in all cloud and IT operations, even before other jobs or tasks, hence job zero. In the DevSecOps section of this chapter, we discussed how security aspects need to be addressed early, ideally starting with security checks in the IDE, having scans embedded in the CI/CD pipeline, and continuing with scans in our environments. A lot of this end-to-end coverage will not be present if security gets retrofitted later on. That means the application has an increased attack surface, and data breaches become more likely because of a lack of guardrails. There might be operational interruptions, maybe because a cloud native firewall that would protect from DDoS attacks or SQL intrusions is not used from the beginning onward. Or certificates expire because the cloud native certificate manager that also renews certificates is not being used. There will also be a risk that compliance requirements cannot be met. These factors can result in reputational damage, negatively impacting our business. Therefore, it is best to address security right from the beginning.
Cloud native versus microservices
Another misunderstanding is that cloud native and microservices have the same meaning. People sometimes use the two terms interchangeably, but they differ in some respects. Cloud native is an overarching approach that includes a variety of practices and tools for developing and running applications in the cloud. It focuses on scalability, resilience, continuous delivery, and leveraging cloud infrastructure. Cloud native includes containerization, orchestration, a DevSecOps culture, and automation through CI/CD pipelines. It addresses the entire SDLC and operations in the cloud. The microservices concept provides architecture guidance specifically on how to break down applications into smaller, independently deployable components. Cloud native applications leverage features and infrastructure. They are designed to run in the cloud. A microservices architecture can be applied to any application, whether hosted on-premises or in the cloud. Microservices hosted in the cloud can be part of a cloud native strategy.
Other misunderstandings
These are the main misunderstandings, and let’s just quickly step through a couple more.
Cloud native adoption will automatically save money. This is only true if the solution is architected in the right way. We went through that when we talked about lift and shift and containers. Another one is that cloud native is not as secure as on-premises. This is also totally wrong: the security controls are different from on-premises. If we utilize managed services, then the complexity of the security will decrease.
There are many drivers for adopting a cloud native stack, such as business agility, operational efficiency, time to market, developer productivity, and others. Our key drivers will depend on our business strategy. The cloud strategy needs to align with or be embedded in it to ensure the cloud native adoption delivers the best possible outcome. We will look into the strategy in the next chapter.
Summary
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.
