How to Adopt Cloud Native Architecture in your Organisation?

In today’s digital age, end to end planning to deliver customer outcome in a water fall approach may not work because, what customer wants today, gets changed tomorrow. By the time you deliver outcome, customer may not need that at all.?

In this rapidly changing digital world, organisations need to plan enough to deliver functionality in the first or two iterations and be quick enough to adapt to customer’s changing requirement, plan for those changing requirement – and continue with this cycle.?

This approach requires agile business practice and require organisations to deliver at a pace customer wants.

Cloud Native architecture help organisation to adopt this approach. It defines changes at cultural level, organisational level, and technical level to meet the competing and changing requirements of customer in this digital age.?

In this article we will start by discussing what is cloud native architecture and why it is needed, what benefit it provides to organisation, then we will discuss how to define cloud native architecture, and finally we will discuss what changes are required to adopt cloud native architecture in an organisation.?

1.?????What is Cloud Native Architecture?

Cloud native architecture is a set of guiding principles and practices to design applications to take advantage of cloud computing model. It is about how applications are created and deployed, not where. It relies on loosely coupled services that run entirely on public or private cloud. It helps prevent organisations from becoming reliant on a single cloud provider

In order to deliver outcome to customer faster and respond to the changing customer requirements, organisations need a platform for building and operating application at scale and automate and deliver functionality using the concept of DevOps, continuous delivery, microservices, and container. We will discuss each of these concepts in detail in later.?

Figure 1: Cloud native architecture

2.?????Benefits of Cloud Native Architecture

Let’s discuss the benefits that organisations get by adopting cloud native architecture.?

Figure 2: Benefits of cloud native architecture

Let’s briefly look at each of these benefits.

2.1?????Business Agility

Business Agility is the ability to compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative business solutions.

Cloud native architecture enables organisations to achieve business agility and respond to market changes by providing framework and platform to develop and deploy applications at scale while leveraging the DevOps and continuous delivery cycle.

2.2?????Speed

In order to achieve business agile and quickly respond to market changes, organisation need to launch features into production as quickly as possible.?

For a traditional organisation it takes weeks or months to launch small changes into production which is usually done in a change cycle and in a deployment window in non-business hours with risky deployment.?

Cloud native architecture enable organisations to lunch features into production faster. Developer can see their code go live in few minutes once they checked-in their code. Changes gets deployed to production through CI/CD pipeline after passing through automated unit tests, function tests, integration tests, performance/stress tests, and security scans.?

In traditional organisations, it usually takes weeks or months to provision environment as developers are dependent upon infrastructure team to provision environment for them. Cloud native architecture massively speeds up development process. It enables developers to provision environment (i.e., Dev/UAT) through self-service portal or automation scripts.?

2.3?????Safety

Deploying faster requires deploying safely without interrupting the business. Small downtime for mission critical applications may cost organisation thousands of dollars. Therefore, it is important for an organisation to not only deploy changes faster, but should also have processes in places to recover from failures quickly.?

Cloud native architecture enables organisation to deploy faster and safer during business hours. Developers can use blue-green-deployment which provides safer rollouts of features to production, or rollback to previous version in case of failure. Developer can also use canary deployment to test features on production only for specific users before doing full rollout.

2.4?????Visibility

Visibility gives insight into your application and enables team to quickly respond to failures.?

Cloud native architecture recommends building microservices which requires incorporating observability as a design principle. Cloud native architecture recommends metrics, monitoring, alerting, data visualisation frameworks and tools to gain insight into cloud native architecture.?

2.5?????Fault Isolation

Cloud native architecture limits the scope of failure by designing small fined grained microservices for a particular business functionality. If one service goes down, it does not bring down the whole system.?

Microservices employ patterns such as bulkhead to isolate the fault. Bulkheads partition a service to confine errors and prevent the entire service from failing due to failure in one area. They are named for partitions that can be sealed to segment a ship into multiple watertight compartments. This can prevent damage from causing the entire ship to sink.

2.6?????Fault Tolerance

Microservices in cloud native architecture implement the fault tolerance patterns to prevent cascading failure. Cascading failure occur when one fault in the system spreads across other areas of system causing to bring down the whole system.?

Microservices in cloud native architecture implements the fault tolerance patterns such as timeout, retry, circuit breaker, service degradation, and rate limiting.

2.7?????Automated Recovery

Cloud native applications can automatically recover from failure without manual intervention. Applications can simply retry on transient failures. Cloud native architecture uses the cloud native infrastructure which continuously monitors the health of application, and restart or redeploy the application in case of failure.?

For example, when Kubernetes detects unhealthy Pod, it destroys the unhealthy Pod and deploy the new Pod. Whole process is automatic without manual intervention.?

Microservices in cloud native architecture are designed to be stateless for automatic shut down and start-up.

2.8?????Scale

Microservices in cloud native architecture are designed to be stateless for scaling. Cloud native infrastructure provides the scaling capability.?

When demand increase, service should automatically scale up based on metrics such as CPU percent, memory percent, or number of incoming HTTP requests. Service should scale down when demand decrease. Service can also be scaled up during the schedule time when team anticipates high demand, for example, selling exclusive tickets of a popular event.

3.?????How to Define Cloud Native Architecture?

In this section we will discuss in detail of how organisation can define cloud native architecture.?

Following diagram shows the building blocks of cloud native architecture.

Figure 3: Building blocks of cloud native architecture

Let’s discuss each of these in detail.

3.1?????Microservices

Rather than building big monolith application, cloud native architecture recommends building small fined grained microservices which are built around busines capabilities – which do one thing and do it well. These services are loosely coupled and independently deployable units.?

These microservices exhibits the speed, safety, and scalability benefits of cloud native architecture.?

These services are built around the particular business functionality and delivered by the dedicated business capability team. Such business capability teams can quickly make change to the service they own or build new functionality and can quickly deploy to production without any dependency on the other teams. This massively speeds up development and go to market compared to monolith approach which require thorough testing of system even for a small change.?

Microservices are deployed using CI/CD pipeline after going though automated unit tests, functional tests, and security scans. Microservices are safely deployed using blue-green and canary deployment patterns, which allows deployment and rollbacks during business hour without business interruption.?

Microservices are stateless by design while keeping immutable infrastructure in minds. These services can be scaled up when demand grows or scaled down when demand decreases.?

3.2?????Twelve Factor Principles

The 12-Factor app is a collection of patterns for cloud-native application architectures, originally developed by engineers at Heroku. These patterns describe an application archetype that optimizes for the “why” of cloud-native application architectures.

They focus on speed, safety, and scale by emphasizing declarative configuration, stateless/shared-nothing processes that horizontally scale, and an overall loose coupling to the deployment environment.

Cloud native platforms like Cloud Foundry, Kubernetes, Heroku, and Amazon Elastic Beanstalk are optimized for deploying 12-Factor applications.

In the context of 12-Factor, application refers to a single deployable unit. Organisations will often refer to multiple collaborating deployable as an application. In this context, however, we will refer to these multiple collaborating deployable as a distributed system.

Following table shows 12 factors:?

3.3?????API Based Collaboration

Microservices in cloud native architecture should interact with each other via published and versioned APIs. These APIs are typically RESTful APIs with JSON serialization, but other protocols and serialization formats are supported.?

Business capability teams who own a particular microservice should freely deploy new functionality whenever required, without depending on or synchronizing with other teams. This brings speed and agility. Deployed APIs should be versioned and backward compatible to avoid breaking interfaces for consumer applications.?

3.4?????Self Service Agile Platform

Teams developing cloud-native architecture are typically DevOps teams who are responsible for the deployment and ongoing operations.

The need of cloud-native architecture gives rise to the self-service platform in which team simply push the code using the continuous delivery pipeline and platform takes care of building the application artifact, constructs an application environment, deploy the application, and start the necessary processes. Teams do not have to think about where their code is running or how it got there, as the platform takes care of these types of concerns transparently.

The platform also provides the services in the form of backing services e.g., a database or mail server. These service instances can then be “bound” to your application, with necessary credentials automatically injected into your application’s environment for it to consume.

These platforms provide capabilities such as:

• Autoscaling based on load and scheduled scaling
• Application monitoring and health checks including shutdown of unhealthy instances and spin up on new instances?
• Traffic management, service discovery, and load balancing?
• Logging, monitoring, and alerting?

The team should adopt the self-service agile platform such as Cloud Foundry or Kubernetes to deploy their cloud-native architecture to gain speed, safety, and scaling benefits.

3.5?????Antifragility

Antifragility is the important aspect of cloud-native architecture. What this means is that if fragility is the quality of a system that gets weaker or breaks when subjected to stressors, then antifragility is opposite to that which is a quality of a system that gets stronger when subjected to stressors.

Adoption of Antifragility is the Netflix Simian Army project, with the submodule called “Chaos Monkey”, which injects random failures into a system with the goal of identifying and eliminating weaknesses in the architecture. By explicitly seeking out weaknesses in the architecture, injecting failures, and forcing their remediation, the architecture naturally converges on a greater degree of safety over time.

3.6?????Continuous Delivery Pipeline

Microservices in cloud native architecture should be deployed using continuous integration and continuous deployment pipeline, commonly referred to as CI/CD pipeline.?

CI/CD pipeline is the backbone of the modern DevOps environment. It bridges the gap between development and operations teams by automating the building, testing, and deployment of applications. It provides speed, safety, and agility in your business processes. It enables team to do risk free deployments during business hours by adopting patterns like blue-green-deployment. It also provides faster and error free rollbacks.?

Following diagram shows the sample pipeline for both infrastructure and application deployment.

Figure 4: Sample CI/CD Pipeline

CI/CD pipeline should automate the infrastructure deployment. It should build, integrate & deploy the code after performing automated unit tests, function tests, integration tests, and performance/stress tests. Team should automate security scan using static analysis security testing (SAST) and dynamic analysis security testing (DAST) tools in their DevSecOps pipelines.

4.?????How to Adopt Cloud Native Architecture?

In this section we will discuss how an organisation can adopt cloud native architecture.?

Following diagram shows the changes required at an organisational level to adopt cloud native architecture.

Figure 5: Changes required to adopt cloud native architecture

Let’s discuss cultural changes first.

4.1?????Cultural Change

Before organisation can adopt cloud native architecture, cultural and organisational changes are necessary. These are the foundational non-technical changes which are essential for a successful adoption of cloud native architecture. These changes are around people, processes, and efficient use of resources.?

Following diagram shows the aspects of cultural changes.

Figure 6: Cultural changes

4.1.1?????DevOps

Traditional organisations have different departments or business units such as development, quality assurance, operations etc. Each of these units consists of people with specialised knowledge and skills. These units have different management hierarchy, toolsets, structures, incentives, and communication style. They work on their own goals.?

Development unit is often incentivised for delivering number of software features. Quality assurance is typically incentivised for keeping software bugs low, while technology operations will be incentivised for maintaining IT systems safe and available while keeping RPO and RTO to an agreed level.?

It creates silos between different units. These silos resist change in order to meet their own goals. For example, software change would require quality assurance to ensure bug free software into production. Quality assurance may resist frequent changes to production to keep production bugs low. Similarity, operations team may resist frequent changes to keep IT systems safe and available. This becomes more complex with the time-consuming process in place. Quality assurance would have process in place to manually test each software features using detailed test case before it goes to production. Similarly, operations team would have ticket system and requirement of release planning meetings to review change before it goes to production.?

These silos spoil the idea of speed of cloud native architecture. Changes are necessary at an organisation level to bring these different units work together to achieve a common goal.?

DevOps removes this silo and brings different units to work together to achieve business outcomes rather than each unit focus on their own individual activities. Development team would make frequent software changes to achieve business agility and speed to market while all teams work together to maintain safety of production systems.?

Figure 7: DevOps

4.1.2?????Continuous Delivery

Original idea behind agile manifesto is the working software on every sprint cycle. Development teams often adopt agile practices to develop software in sprint cycles. They complete their sprint cycles after showing the demo and acceptance of user stories, but change have to wait to go live in release cycle. Changes gets piled up after every sprint cycle waiting to be part of monthly or quarterly release which typically goes through review cycles.?

Such organisations fail to adopt agile practices at organisation level. Customers not only have to wait to see actual changes to production, but development team also have to wait for feedback. Business may also loose the opportunity window that may have been arouse in the market, especially when there is a high competition.?

Cloud native architecture brings the idea of concept-to-cash in every sprint cycle. Changes goes to production after every sprint cycle, or ideally on every code commit using CI/CD pipeline after going through automated tests and security scans. Business can make decision of turning on new features on production using feature toggles.?

4.1.3?????Decentralised Autonomy

Organisations often have centralized governance body such as architecture board around application architecture and data management. Such committees are responsible for maintaining guidelines and standards, as well as approving individual designs and changes.

These practices are established to enforce architecture standards, keeping architectures and technology stack consistent, bring consistency in cross-cutting concerns, and maintaining ownership of architecture and data.??

Downside of this approach is that it prevents the speed of delivery sought from cloud-native application architectures. It also creates bottlenecks as architectural committees often only assemble periodically with long waiting queues of work to endorse. Due to which even small changes takes longer to implement.

Organisations need to move from centralized governance to decentralized autonomy in which every team building cloud-native applications should own the business capability. These teams are responsible for delivering end to end business capability which includes owning the application architecture, and the design and development of software components. Decisions are often made at team level with mutual agreement and executed upon by the teams.

4.2?????Organisational Change

To successfully adopt cloud native architecture and utilize its benefits, organisation need to make necessary changes at team level and come up with the dedicated business capability teams, platform operations team and onboarding team.?

Figure 8: Organisational changes

4.2.1?????Business Capability Teams

Organisation typically design a system involving specialists from different teams such as UI, backend/server-side team, database team etc. When they design the system, it reflects such organisation’s structure, which Conway’s Law mentioned as:

Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure.

-- Melvyn Conway, 1968

With this example, design typically emerged as shown in following diagram.?

Figure 9: Example of Conway’s Law

Drawback of this approach is that any small change in a system would typically require engaging all teams across the organisation, which also require budgetary approvals. It also promotes bad system design as it gives freedom to teams to implement business logic to whichever system they have access to. It also becomes obstacle for an organisation to adopt business agility, and quickly bringing value to the customer.

Cloud native architecture talks about services being built around business capabilities. Before we start building the services, we need to build business capability team which typically comprises of a cross functional agile team across different organisation units.?

Inverse Conway Maneuver describe such an approach as:

Rather than building an architecture that matches their org chart, they determine the architecture they want and restructure their organisation to match that architecture. If you do that, according to Conway, the architecture that you desire will eventually emerge.

-- ThoughtWorks, 2014

This suggest that one business capability agile team should comprise of UI specialists, backend/server-side team, database engineers and all other teams required to deliver that business capability.?

Resulting architecture will emerge as shown in the following diagram.

Figure 10: Example of Inverse Conway Maneuver

These business capability teams are independent teams which owns one business functionality or product. These teams develop and own the product and are responsible for the whole lifecycle of the product.

Business capability team should not be too big or too small. We apply the Amazon’s idea of Two-Pizza team, which states that team should be small enough that it can be fed with two pizzas.?

4.2.2?????Platform Operations Teams

Business capability team relies on self-service agile platform to deliver business capabilities at scale with speed and safety in mind.

Such self-service agile platform requires a dedicated team to operate and manage the platform. Platform operation team typically comprises of system engineers, network engineers, storage administrators etc. They work in collaboration to provide an agile way of working instead of traditional way such as ticket-based system. Platform team present the APIs to consume platform service and provides as-a-Service model. Business capability teams should utilize those APIs to automate the provisioning of platform service.

4.2.3?????Onboarding Team

The onboarding team is a dedicated team which helps organisation to modernise and migrate workload to cloud or CaaS platform at scale. The onboarding team is separate from business capability teams who are solely responsible for building microservices for a particular business functionality. The onboarding team consists of a team of cloud native architects who not only works with business capability team and platform operations team, but also acts as a front door for applications teams to help them start their application modernization journey.

Cloud onboarding team provides specialized services like cloud native expertise, building reusable assets, fast track services, and the target platform selection.

Cloud Native Expertise:?Cloud onboarding team engage with application teams directly and provides expertise to architect application using cloud native architecture, 12-Factor application, microservices, cloud architecture patterns and best practices.?

Cloud onboarding team recommends target cloud architecture for a particular workload. Team also reviews and recommend an efficient and cost-effective utilization of cloud resource. Onboarding team also works with application team to access their current cloud architecture and recommend the efficient use of cloud resources and recommend reducing cloud consumption cost.

Onboarding team works with operations and finance team to develop dashboards, cloud consumption reporting, develop charge back and costing mechanism of cloud consumption for each of the respective business unit.?

Onboarding team works with security team to monitor, control, and secure the cloud environment. Team review target architecture with security team to make sure that target architectures are compliant as per company policy.??

Reusable Assets:?Cloud onboarding team runs optimization sprint cycles to iteratively build path to production. Team produces reusable artefacts in the form of architecture and integration patterns, best practices, automations scripts, reference CI/CD pipelines, code sample, cookbook etc. Team assesses and develop a pattern-of-use and get security endorsement of every new technology/service of cloud provider before it could be used by the application teams. This helps to fast-track security certification and usage of new services for any application utilizing those new services.

Fast Track Services:?Cloud onboarding team works closely with different teams within customer organisation to break down organisational silos, simplify complex processes, and work on ‘as a Service’ (XaaS) model for various services such as Integration as a Service, API Gateway as a Service, Database as a Service, Logging as a Service, Monitoring as a Service, Configs as a Service etc. Onboarding team helps to automate various services such as security scans and integrate it in DevSecOps pipelines.?

Cloud onboarding team work closely with infrastructure teams at customer organisation to make infra service such as connectivity, firewall, load balancing and DNS, to be API based for fast onboarding.?

Cloud onboarding team iteratively build know-hows and training material on cloud native architecture, and cloud technologies for application teams to quickly learn and adopt new technologies.?

Fast tracking services massively speed up application modernization efforts and speed to markets. It enables teams to release new features on every sprint cycle. It enables organisation to be more agile and enable it to innovate using technology faster.?

Target Platform Selection:?Organisations typically run workload in multiple environments, which includes on-premises, multi-cloud, and PaaS environment. It often become difficult for an application team to decide where to deploy their workload. It becomes more complex in a case where organisation runs similar platform on multiple environments. For example, organisation may run Kubernetes platform in on-premises and on one or two public cloud providers. Almost all public cloud providers offer managed Kubernetes platforms, such as EKS on AWS, and AKS on Azure. Cloud onboarding team provides the specialized expertise to help select right target platform for an application. Onboarding team assess the application based on the factors such as application architecture, company’s compliance requirements, data requirements, performance & availability requirement etc. Based on assessment, cloud onboarding team recommends the target platform. Cloud onboarding team also develop flow charts and self-service tools to help application team select target IaaS, CaaS, or PaaS platform for simple workloads.

4.3?????Technical Change

Once the foundation has been laid down after doing cultural and organisation change, organisation need to adopt technical change in order to adopt cloud native architecture.?

It starts with modernising existing applications into cloud native architecture, decompose monolith data and containerising the applications.

Following diagrams shows three aspects of technical change.

Figure 11: Technical Change

4.3.1?????Decompose Monolith

Legacy applications pose many challenges when it comes to speed and safety in today’s digital age. It limits organisation’s capability of innovation as organisation cannot independently deploy business capability. Individual business services cannot be scaled independently based on load. Also, spaghetti code base is hard to manage, test and train new developer on it.?

To get the benefit of cloud native architecture, business capability team need to decompose legacy application into microservice based architecture in which each microservice would be built around a business capability.?

4.3.2?????Decompose Data

Microservices are independently deployable services which is based on shared nothing architecture. In order to fully adopt microservice based architecture business capability team need to decompose data and make separate data store for each of the independent microservice.?

One common technique is to design services using domain driven design. This concept of Domain Driven Design was first introduced by Eric Evans in his popular book ‘Domain Driven Design – Taking Complexity in the heart of Software’.?

Domain Driven Design talks about software design as a top-down approach which primarily focus on business and its particular domain. We develop the models of that domain and make our software conformed to that.?

Domain Driven Design helps to develop the services around the subdomains of a particular business domain which we call bounded contexts. Business capability team owns the bounded context and build microservices providing those capabilities. Bounded contexts are coupled with the database per service pattern, where each microservice encapsulates, governs, and protects its own domain model and persistent store.

4.3.3?????Containerization

Once business capability team build microservices they need to package and deploy it. One popular approach is to package the service using Docker image. Docker image contains all the dependencies, libraries, and binaries required at runtime. Once packaged, developer can deploy to container-based platforms such as Kubernetes, Rancher, or AWS ECS.?

Platform operations team provides such self-service agile platform for deployment of containerised workload. As we discussed earlier, platform operations teams are responsible for operation and management of such container-based platforms.?

Container based platforms provides the features such as deployment, scaling, service discovery, and load balancing. Additionally, Kubernetes provides features like storage orchestration, automated rollouts and rollbacks, automatic bin packing, self-healing, secrets, and configuration management.

5.?????Final Words

In order to cope up with faced paced digital world, organisations need to adopt cloud native architecture which enables organisation to innovate faster, deliver functionally to customer with speed and safely while bringing business agility into organisation’s processes.?

Cloud native architecture is not pattern. It is digital way of working which requires having digital minds set throughout the organisation which requires adopting the cultural, organisational and technical changes.?

Such cultural and organisational changes provide the foundation for cloud native architecture. It promotes the change in people and processes while bringing automation into organisation’s complex processes. It tears down the organisation silos which is the biggest limitation in innovation and speed to market.?

Once this strong foundation has been laid down, it provides enough tool and process for business capability team to work on the next level which is the decomposing monolith application and containerizing it.?

Most of the organisations fail in their modernisation journey because they start the technical changes without laying down the required foundational changes.?