Cloud-Native Architecture and Scalability. Hello dear friends, in this lesson we will talk about cloud-native architecture. You know in the last few years it became the most preferred architecture amongst server solutions. I want to start with a simple definition. Cloud-native architecture is an approach to designing, constructing, and operating workloads that are built in the cloud and take full advantage of the cloud computing model. According to the official definition of the Cloud Native Computing Foundation, 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. The Cloud Native Computing Foundation was created as an offshoot of the Linux Foundation to make cloud-native computing ubiquitous. They shepherd many of the projects that enable cross platform cloud-native software.

It can be said that cloud-native is about speed and agility. Business systems are evolving from enabling business capabilities to weapons of strategic transformation that accelerate business velocity and growth. It's imperative to get new ideas to market immediately. At the same time, business systems have also become increasingly complex with users demanding more. They expect rapid responsiveness, innovative features and zero downtime. Performance problems, recurring errors and the inability to move fast are no longer acceptable. Your users will opt for your competitor. Cloud-native systems are designed to embrace rapid change, large scale, and resilience. Of course, cloud-native architecture facilitates your deployment and management workload, but you should dare to struggle with some challenge. But you should dare to struggle with some challenges. You need to establish a DevOps pipeline. If you don't, you might encounter difficulty in managing the distributed workflow and responsibilities involved with microservices. The rapid scaling of containers can introduce security risks if not monitored appropriately.

Transitioning from a legacy application into a microservices architecture can result in complex interdependencies or functionality issues. All right, dear friends, so we have talked about some benefits and challenges with the cloud-native approach so far, now we need to understand certain cloud-native architecture principles. First, stateless processing. Stateful applications or those that manage and store data directly create risk and complexity. Therefore, organizations should use them as little as possible. Stateless applications are far easier to scale, repair, rollback, and balance. Microservices. A microservice is an independent process that communicates with others by a language agnostic API. Each service is fully isolated and dedicated to completing one specific task. Microservices are ideal elements to establish a well-organized cloud-native architecture. Through using microservices, you can form cloud-native architecture like a Lego toy. Containerization. Containers leverage Linux namespaces to maintain isolation between network stacks, file systems, and processes.

Containers are secure partitions based on the namespace method each running one or multiple Linux processes. A Linux kernel on the host supports these processes. Containers work similarly to virtual machines, although containers are much more flexible. While it is only possible to install VMs with the support of full operating system, containers can support applications by using packaging software. This packaging approach allows developers to add applications easily. Another important difference is that containers are lighter than VMs, requiring fewer resources and less maintenance. They can start faster, deploy easily, and offer high portability. Communication and collaboration. Cloud-native services must have the ability to communicate and interact with each other and with external services. APIs enable communication between cloud-native applications and legacy or third-party applications.

Microservices can facilitate management and internal communications by building a dedicated infrastructure layer called a service mesh that handles these communications. The main role of a service mesh is to secure, connect, and monitor services in cloud-native applications. Although Istio is the most widely used service mesh, several open-source implementations are available. Automation. Cloud-native architectures facilitate infrastructure automation, allowing developers to implement continuous integration/continuous delivery, also known as CI/CD pipelines and accelerate tasks such as deployment, scaling, and recovery. Cloud-native systems also support automating processes such as rollback, recovery, canary deployment, and monitoring. Defense in depth. Cloud-native architectures use Internet services by definition, so they must have built-in protections to mitigate external attacks.

Defense in depth is a security approach that emphasizes the system's internal security and is based on the military strategy of slowing down an attack with multilayered defenses. In computing environments, this works by implementing authentication challenges between all components within the network, eliminating implicit trust between components. Cloud-native architectures can extend the principle of defense in depth to script injection and rate limiting in addition to authentication. Every design component must protect itself from all other components, even when part of the same architecture. This approach makes cloud-native architecture more resilient and enables organizations to deploy services in cloud environments without a trusted network between the users and the service.

All right, dear friends, we have covered all the basic principles in a cloud-native environment. The last thing I want to say is about sustainability. Actually, it is related to environmental problems and carbon emissions. When you use on-premise physical servers for your applications with traditional methods, you will probably use resources inefficiently because it causes more energy consumption. When you use containers, you can utilize resources in a better way. You can scale your resources when you need to so you decrease consumption. All right, take care of yourself and the environment. So, I'll see you in the next lesson dear friends.