In today's cloud-driven landscape, organizations are transitioning from legacy monolithic systems to agile, scalable, and secure cloud-native solutions. Some are even forging new cloud-native applications. However, the concept of cloud-native design remains subjective, lacking a universal blueprint. This blog aims to provide clarity and guidance for designing precise cloud-native applications and container deployment. It addresses the intricacies of end-to-end cloud development, encompassing architecture, development, testing, deployment, security, and observability.
Traditionally, separate development teams handle these aspects in isolation. This blog bridges these gaps and outlines seven practical models for standardizing cloud-native architecture, drawing from real-world experience in cloud-native application design and development.
Seven Models of Cloud Native Design
Cloud-native entails developing microservices/micro-frontends apps and deploying them within containers on private, public, or hybrid cloud platforms. These platforms autonomously manage, automate, orchestrate, and secure these applications and their data. Container orchestration engines handle most cross-cutting concerns. This blog outlines key approaches to creating and deploying modern cloud-native apps, emphasizing performance optimization and cost efficiency. These apps leverage cloud-managed SaaS and automatically deploy new source code changes on cloud container platforms. We will now briefly explore these seven models and their business-value components.
Please refer this diagram for quick overview:
1. Modern Design & Development Model
Components
Business Value / ROI
Beyond 12 factor principles
It's a set of principles widely adopted for cloud-native applications and dev teams offering usability, agility, scalability, modularity, and security. It saves operational costs and improves developer productivity. It's a set of abstractions of cross-cutting concerns or non-functional requirements (NFR). These are 12+3 factor principles for modern cloud-native apps, where 3 important principles are recent additions. We call it beyond 12-factor principles.
One codebase, one application: A single code repo for a single responsibility should exist. Every microservice should have its code repo.
API first: New cloud native app development should start from designing API first.
Dependency management: Explicitly declare and isolate dependencies. All dependencies should be declared without implicit reliance on system tools or libraries.
Design, build, release, and run: The delivery pipeline should strictly consist of build, release, run.
Configuration, credentials, and code: Configuration that varies between deployments should be stored in the environment.
Logs: Applications should produce logs as event streams and leave the execution environment to aggregate.
Disposability: Fast startup and shutdown are advocated for a more robust and resilient system.
Backing services: All backing services are treated as attached resources and are attached and detached by the execution environment.
Environment parity: All environments should be as similar as possible.
Administrative processes: Any needed admin tasks should be kept in source control and packaged with the application.
Port binding: Self-contained services should make themselves available to other services by specified ports.
Stateless processes: Applications should be deployed as one or more stateless processes with persistent data stored on a backing service.
Concurrency: Concurrency is advocated by scaling individual processes.
Telemetry: Add observability and monitoring.
Authentication and authorization (A&A): Provide proper IAM support for user and application to application security.
Domain Driven Design (DDD)
It's a design pattern that helps identify separate business use case domains and microservices. The best use case is to migrate legacy monolithic apps to modern micro-services and micro-frontends. Example: Catalog, order, payment services.
API Driven
It's a method for API design that prioritizes business logic or services ahead of development, promoting service-to-service communication via API interfaces. Cloud-native apps utilize this approach, managing API endpoints with tools like GCP Apigee, Spring Cloud Gateway, and more.
Microservices Design
It's a backend application architecture where a small application is developed as a collection of services based on a specific business domain (usually derived by DDD). It provides a framework/guidelines to develop, deploy and manage cloud-native apps.
Micro-Frontend Design
It's a frontend application architecture where a big UI app is decomposed into smaller UI apps developed by separate dev teams. These micro UI apps can be deployed and managed independently. They can also be divided based on business use cases.
WebAssembly (Wasm)
It's a next-generation UI platform. It's an enhancement over Java script, which makes Java script code compilation faster and offers better performance; both are companions as of now. It's a binary instruction format, which is lighter to compile and understand for a browser. It also has a lighter payload to perform faster on web browsers.
Modern Databases
In the past, we only had traditional SQL databases as our option. But today, we have a wide variety of modern databases such as NoSQL, which are suitable for various purposes. Additionally, there are numerous companies, both in the public cloud sector and as independent software providers, that offer Database as a Service (DBaaS) through Software as a Service (SaaS) platforms. This means they make databases available to applications through APIs, and they handle the management of these databases on their cloud infrastructure, offering them to clients through subscription-based services.
Event-Driven Design
It’s the latest de facto standard for microservices communications. In this design, microservices connect with each other using a message broker on every event. Microservices can publish/consume messages to topics. It's an asynchronous way of communication, which provides a lot of benefits like agility, high transactions, high availability, cost cutting, reliability and decoupling.
Distributed Caching Design
In decoupled microservices/micro-frontend development and deployment of ephemeral containers, distributed caching is essential to store state of data in cases of container crashes or spawning new containers as replicas. It also helps data center/multi-region real time data cache synchronization. It can be used for various use cases like boost API performance by reading cache.
2. Modern Infrastructure/DevOps - CI/CD
Components
Business Value / ROI
DevSecOps
It's an advanced DevOps concept for development, security, and operations. It provides tools and practices to secure data, code, and containers during the CI/CD process. It covers scanning source code for vulnerabilities, early threat/malware detection/prevention, security design audit review, static code analysis, container docker image, payload, database security, etc.
Immutable Infrastructure
This kind of infra is never modified once it's deployed on the cloud. A new infra has to be deployed for any new change, and the older one must be retired. It reduces operational complexities, debugging time and improves security. No patching or backward compatibility is needed.
Service Mesh
It's a dedicated infra layer that controls and manages cross-cutting concerns out of the box like service discovery, API tracing, observability, microservices internal east-west communication, circuit-breaker/failure recovery, load balancing, traffic management, mTLS payload security, A&A, etc. It helps to move/extract cross-cutting configurations from business logic source code. It also moves the responsibility of common configurations from the business code developers, to the DevOps developer/team.
Declarative API (IaaC)
It's a very powerful modern way of managing infra as a code. It's a desired state system automatically managed by the DevOps system. We need to tell the system to maintain the state provided without manual intervention. It's an intelligent way of managing infra by Kubernetes and Terraform apps.
Platform as a Service (PaaS)
It's a cloud computing model that provides a ready-made development platform on top of infrastructure to write direct code and deploy without an understanding of cloud-config complexities for the developer. It gives a developer-friendly environment to build and deploy code on the cloud without any help from the DevOps team. It improves developer productivity.
3. Build & Deployment Model
Components
Business Value / ROI
Serverless
It's a pure cloud-native development model which provides ready-to-use infra on-demand for app deployment. It saves a lot of costs because it is a spin-up based on on-demand events. Cloud providers manage the infra of serverless servers. They automatically scale up/down based on traffic usage. It works on an event-driven model.
GitOps
An infra-operational framework where the Git source code repository is integrated with CI/CD DevOps pipeline. It automatically triggers when any commit change happens in the Git repo. It provides many benefits like security, compliance, lesser complexity to create/update Kubernetes config script, improved developer productivity, automation, reliability, and faster development. It provides a self-managed declarative infrastructure.
4. Cloud Observability
Components
Business Value / ROI
Tracing
It tracks microservices API interactions and shows interaction and response time with request and response data. It also helps to find out the performance of primary API and buggy API. Apps send app usage metrics details, which APM and other observability tools read. Those tools visualize data, generate reports and send preventive notifications.
Performance Monitoring
Application monitoring measures application performance, availability, and user experience. It uses data to identify and resolve application issues before they impact customers. For the above mentioned performance activity APM and performance testing tools are used. Infra can be scaled based on the API reports and the SLA.
5. 4C's of Cloud Security
Components
Business Value / ROI
Container Security
This practice ensures that the container where the app is deployed is also secured. It’s a policy to secure potential security vulnerabilities. Container security tools usually protect it.
Cluster Security
Practice to secure container orchestration cluster components and apps running on that cluster.
Cloud Security
It comprises the security of data center and availability zones servers in cloud environments. If the Cloud layer is vulnerable (or configured in a vulnerable way), then there is no guarantee that the components built on top of this base are secure. Public service providers have a lot of security services like DDOS.
Container Image Security
Docker images are stored in container repositories. These images must be scanned for any security vulnerabilities. Many tools are available with container repo which continuously scan updated images.
Endpoint Security
It’s a cyber security approach to defend end-consuming endpoints such as laptops, desktops, and mobile devices. An endpoint is any device that connects to the corporate network from outside its firewall. An endpoint security strategy is essential because every remote endpoint can be the entry point for an attack, and the number of endpoints is only increasing with the rapid pandemic-related shift to remote work.
6. Cloud Platforms
Components
Business Value / ROI
Private
It’s managed by either on-prem (inside organization) or private instances isolated with physical secure boundaries on public cloud service providers.
Public
These physical servers are shared with multi-tenants/organizations, provided mainly by the third-party vendor as a SaaS solution.
Hybrid
It's a combination of private and public clouds. Sometimes, organizations keep their databases and other secure information on-prem and host applications and other services on the public cloud. It's the most sustainable model for cloud migration. Most of the organizations, around 65%, prefer hybrid models. Public cloud service providers provide hybrid cloud orchestration tools to manage multi-cloud. Sometimes, when many public clouds are combined, they are also called hybrid clouds.
7. Automation
Components
Business Value / ROI
BDD
Behavioral Driven Design framework is based on a given-when-then model. It mainly focuses on the behavior of the product and user acceptance criteria. It provides simple English like the Gherkin language.
Chaos Engineering
It's a method of testing distributed microservices/micro-front-end apps deployed on a cloud that deliberately introduces failure and faulty scenarios to verify its resilience in the face of random disruptions. These disruptions can cause applications to respond unpredictably and break under pressure. Chaos engineers detect those issues. It's a must for any true cloud-native app.
Conclusion
Every application has different types and needs. The cloud-native definition is different for other apps and organizations. This same "Seven model" can't fit on all cloud-native applications architecture. They are sometimes driven by business unit/LOB, technology compliance, cost, and operational overhead.
These are some of the latest and modern industry practices that many IT organizations widely accept.
In today's cloud-driven landscape, organizations are transitioning from legacy monolithic systems to agile, scalable, and secure cloud-native solutions. Some are even forging new cloud-native applications. However, the concept of cloud-native design remains subjective, lacking a universal blueprint. This blog aims to provide clarity and guidance for designing precise cloud-native applications and container deployment. It addresses the intricacies of end-to-end cloud development, encompassing architecture, development, testing, deployment, security, and observability.
Traditionally, separate development teams handle these aspects in isolation. This blog bridges these gaps and outlines seven practical models for standardizing cloud-native architecture, drawing from real-world experience in cloud-native application design and development.
Seven Models of Cloud Native Design
Cloud-native entails developing microservices/micro-frontends apps and deploying them within containers on private, public, or hybrid cloud platforms. These platforms autonomously manage, automate, orchestrate, and secure these applications and their data. Container orchestration engines handle most cross-cutting concerns. This blog outlines key approaches to creating and deploying modern cloud-native apps, emphasizing performance optimization and cost efficiency. These apps leverage cloud-managed SaaS and automatically deploy new source code changes on cloud container platforms. We will now briefly explore these seven models and their business-value components.
Please refer this diagram for quick overview:
1. Modern Design & Development Model
Components
Business Value / ROI
Beyond 12 factor principles
It's a set of principles widely adopted for cloud-native applications and dev teams offering usability, agility, scalability, modularity, and security. It saves operational costs and improves developer productivity. It's a set of abstractions of cross-cutting concerns or non-functional requirements (NFR). These are 12+3 factor principles for modern cloud-native apps, where 3 important principles are recent additions. We call it beyond 12-factor principles.
One codebase, one application: A single code repo for a single responsibility should exist. Every microservice should have its code repo.
API first: New cloud native app development should start from designing API first.
Dependency management: Explicitly declare and isolate dependencies. All dependencies should be declared without implicit reliance on system tools or libraries.
Design, build, release, and run: The delivery pipeline should strictly consist of build, release, run.
Configuration, credentials, and code: Configuration that varies between deployments should be stored in the environment.
Logs: Applications should produce logs as event streams and leave the execution environment to aggregate.
Disposability: Fast startup and shutdown are advocated for a more robust and resilient system.
Backing services: All backing services are treated as attached resources and are attached and detached by the execution environment.
Environment parity: All environments should be as similar as possible.
Administrative processes: Any needed admin tasks should be kept in source control and packaged with the application.
Port binding: Self-contained services should make themselves available to other services by specified ports.
Stateless processes: Applications should be deployed as one or more stateless processes with persistent data stored on a backing service.
Concurrency: Concurrency is advocated by scaling individual processes.
Telemetry: Add observability and monitoring.
Authentication and authorization (A&A): Provide proper IAM support for user and application to application security.
Domain Driven Design (DDD)
It's a design pattern that helps identify separate business use case domains and microservices. The best use case is to migrate legacy monolithic apps to modern micro-services and micro-frontends. Example: Catalog, order, payment services.
API Driven
It's a method for API design that prioritizes business logic or services ahead of development, promoting service-to-service communication via API interfaces. Cloud-native apps utilize this approach, managing API endpoints with tools like GCP Apigee, Spring Cloud Gateway, and more.
Microservices Design
It's a backend application architecture where a small application is developed as a collection of services based on a specific business domain (usually derived by DDD). It provides a framework/guidelines to develop, deploy and manage cloud-native apps.
Micro-Frontend Design
It's a frontend application architecture where a big UI app is decomposed into smaller UI apps developed by separate dev teams. These micro UI apps can be deployed and managed independently. They can also be divided based on business use cases.
WebAssembly (Wasm)
It's a next-generation UI platform. It's an enhancement over Java script, which makes Java script code compilation faster and offers better performance; both are companions as of now. It's a binary instruction format, which is lighter to compile and understand for a browser. It also has a lighter payload to perform faster on web browsers.
Modern Databases
In the past, we only had traditional SQL databases as our option. But today, we have a wide variety of modern databases such as NoSQL, which are suitable for various purposes. Additionally, there are numerous companies, both in the public cloud sector and as independent software providers, that offer Database as a Service (DBaaS) through Software as a Service (SaaS) platforms. This means they make databases available to applications through APIs, and they handle the management of these databases on their cloud infrastructure, offering them to clients through subscription-based services.
Event-Driven Design
It’s the latest de facto standard for microservices communications. In this design, microservices connect with each other using a message broker on every event. Microservices can publish/consume messages to topics. It's an asynchronous way of communication, which provides a lot of benefits like agility, high transactions, high availability, cost cutting, reliability and decoupling.
Distributed Caching Design
In decoupled microservices/micro-frontend development and deployment of ephemeral containers, distributed caching is essential to store state of data in cases of container crashes or spawning new containers as replicas. It also helps data center/multi-region real time data cache synchronization. It can be used for various use cases like boost API performance by reading cache.
2. Modern Infrastructure/DevOps - CI/CD
Components
Business Value / ROI
DevSecOps
It's an advanced DevOps concept for development, security, and operations. It provides tools and practices to secure data, code, and containers during the CI/CD process. It covers scanning source code for vulnerabilities, early threat/malware detection/prevention, security design audit review, static code analysis, container docker image, payload, database security, etc.
Immutable Infrastructure
This kind of infra is never modified once it's deployed on the cloud. A new infra has to be deployed for any new change, and the older one must be retired. It reduces operational complexities, debugging time and improves security. No patching or backward compatibility is needed.
Service Mesh
It's a dedicated infra layer that controls and manages cross-cutting concerns out of the box like service discovery, API tracing, observability, microservices internal east-west communication, circuit-breaker/failure recovery, load balancing, traffic management, mTLS payload security, A&A, etc. It helps to move/extract cross-cutting configurations from business logic source code. It also moves the responsibility of common configurations from the business code developers, to the DevOps developer/team.
Declarative API (IaaC)
It's a very powerful modern way of managing infra as a code. It's a desired state system automatically managed by the DevOps system. We need to tell the system to maintain the state provided without manual intervention. It's an intelligent way of managing infra by Kubernetes and Terraform apps.
Platform as a Service (PaaS)
It's a cloud computing model that provides a ready-made development platform on top of infrastructure to write direct code and deploy without an understanding of cloud-config complexities for the developer. It gives a developer-friendly environment to build and deploy code on the cloud without any help from the DevOps team. It improves developer productivity.
3. Build & Deployment Model
Components
Business Value / ROI
Serverless
It's a pure cloud-native development model which provides ready-to-use infra on-demand for app deployment. It saves a lot of costs because it is a spin-up based on on-demand events. Cloud providers manage the infra of serverless servers. They automatically scale up/down based on traffic usage. It works on an event-driven model.
GitOps
An infra-operational framework where the Git source code repository is integrated with CI/CD DevOps pipeline. It automatically triggers when any commit change happens in the Git repo. It provides many benefits like security, compliance, lesser complexity to create/update Kubernetes config script, improved developer productivity, automation, reliability, and faster development. It provides a self-managed declarative infrastructure.
4. Cloud Observability
Components
Business Value / ROI
Tracing
It tracks microservices API interactions and shows interaction and response time with request and response data. It also helps to find out the performance of primary API and buggy API. Apps send app usage metrics details, which APM and other observability tools read. Those tools visualize data, generate reports and send preventive notifications.
Performance Monitoring
Application monitoring measures application performance, availability, and user experience. It uses data to identify and resolve application issues before they impact customers. For the above mentioned performance activity APM and performance testing tools are used. Infra can be scaled based on the API reports and the SLA.
5. 4C's of Cloud Security
Components
Business Value / ROI
Container Security
This practice ensures that the container where the app is deployed is also secured. It’s a policy to secure potential security vulnerabilities. Container security tools usually protect it.
Cluster Security
Practice to secure container orchestration cluster components and apps running on that cluster.
Cloud Security
It comprises the security of data center and availability zones servers in cloud environments. If the Cloud layer is vulnerable (or configured in a vulnerable way), then there is no guarantee that the components built on top of this base are secure. Public service providers have a lot of security services like DDOS.
Container Image Security
Docker images are stored in container repositories. These images must be scanned for any security vulnerabilities. Many tools are available with container repo which continuously scan updated images.
Endpoint Security
It’s a cyber security approach to defend end-consuming endpoints such as laptops, desktops, and mobile devices. An endpoint is any device that connects to the corporate network from outside its firewall. An endpoint security strategy is essential because every remote endpoint can be the entry point for an attack, and the number of endpoints is only increasing with the rapid pandemic-related shift to remote work.
6. Cloud Platforms
Components
Business Value / ROI
Private
It’s managed by either on-prem (inside organization) or private instances isolated with physical secure boundaries on public cloud service providers.
Public
These physical servers are shared with multi-tenants/organizations, provided mainly by the third-party vendor as a SaaS solution.
Hybrid
It's a combination of private and public clouds. Sometimes, organizations keep their databases and other secure information on-prem and host applications and other services on the public cloud. It's the most sustainable model for cloud migration. Most of the organizations, around 65%, prefer hybrid models. Public cloud service providers provide hybrid cloud orchestration tools to manage multi-cloud. Sometimes, when many public clouds are combined, they are also called hybrid clouds.
7. Automation
Components
Business Value / ROI
BDD
Behavioral Driven Design framework is based on a given-when-then model. It mainly focuses on the behavior of the product and user acceptance criteria. It provides simple English like the Gherkin language.
Chaos Engineering
It's a method of testing distributed microservices/micro-front-end apps deployed on a cloud that deliberately introduces failure and faulty scenarios to verify its resilience in the face of random disruptions. These disruptions can cause applications to respond unpredictably and break under pressure. Chaos engineers detect those issues. It's a must for any true cloud-native app.
Conclusion
Every application has different types and needs. The cloud-native definition is different for other apps and organizations. This same "Seven model" can't fit on all cloud-native applications architecture. They are sometimes driven by business unit/LOB, technology compliance, cost, and operational overhead.
These are some of the latest and modern industry practices that many IT organizations widely accept.
What you should do now
Schedule a demo with Squadcast to learn about the platform, answer your questions, and evaluate if Squadcast is the right fit for you.
Curious about how Squadcast can assist you in implementing SRE best practices? Discover the platform's capabilities through our Interactive Demo.
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
.png)
