The Cloud Needs More Native Speakers

Guidelines for modern cloud-native architectures

AWS started in 2006. At that stage, it was almost unthinkable to foresee what we are going through today. Cloud was thought for start-ups and not ready for Enterprise. It took several years to become mainstream.

Today, that has changed. Companies are writing new software on the cloud and migrating legacy applications. Most likely, if your company is less than 10 years old, then you may not even have a physical server.

Software created to run on the cloud is sometimes referred to as cloud-native. However, does it mean that every application running on the cloud is cloud-native? Well, I believe it is not. Cloud-native architectures should follow principles to support certain qualities, and this article reviews them.

So, what is a cloud native architecture?

Think about the qualities that are supported and usually sought after in a cloud native architecture:

• Minimal downtimes. The system is resilient to planned / unplanned changes and infrastructure failures. Independent deployable units and redundancy are key characteristics to achieve minimal downtime.
• Release frequency. Autonomous and loosely coupled components combined with automated development pipelines allows the team to achieve high release cadence with trust on quality.
• Clients running on any device, anywhere. Humans and/or non-humans from mobiles, desktops, IoT devices. All of these different clients can be supported with this type of architecture.
• Elasticity. Unpredictable workloads, increasing/decreasing number of requests without needing a dedicated team to provision or remove instances to our clusters. Workload getting load balanced according to predetermined rules.

These key attributes allow us to define what a cloud-native architecture is:

A cloud-native architecture is highly distributed, it reliably operates in a constantly changing environment, and is itself constantly changing.

Cloud-native architectures principles

Traditional architecture tends to optimise for a fixed, high-cost infrastructure, which requires considerable manual effort to modify. Traditional architecture therefore focuses on the resilience and performance of a relatively small fixed number of components [5].

Meanwhile, cloud-native architectures focus on automation, resilience and performance of the whole solution, distributed processing, and frequent changes.

I have collated 7 principles that I consider important to follow when designing a cloud-native architecture.

Principle 1. Maximise business continuity

The system must be designed to achieve high levels of availability according to agreed Service Level Agreements (SLAs). It should be resilient to planned and unplanned changes as well as infrastructure failures. Cloud native architectures treat multi-zone and multi-region deployments as the default.

Repeatability reduces errors and allows easy provisioning and de-provisioning. Basically, no snowflakes are allowed in this party. Following automated deployment techniques creates predictability. Infrastructure as code enables you to have the same environment every time and ensure control. Also, ensures that Dev, Test, UAT and Prod are alike.

Principle 2. Technology independence

A technology-independent architecture means not being biased towards any particular platform or software language. It is about selecting the right technology that fits the solution, not fitting the solution around the technology.

Each deployment unit can be written using the best language for the problem at hand with the most suitable framework for the job. However, use it with care. It is advisable to understand your team/s strengths and weaknesses and keep costs under control for the long-term. You do not want to end up in a situation where no one in the team can support some modules/applications.

Principle 3. Deliver applications and services at high velocity

Respond to market needs quickly and accurately. Continuous integration / Continuous delivery (CI/CD) along with other DevOps techniques and tools enables your organisation to release systems frequently and reliably. High levels of confidence provided by automated pipelines is important to reliably achieve the desired pace.

It is worth mentioning that continuous delivery is not the same as continuous deployment; continuous delivery allows you to be ready to release after each cycle, however no need to release to Prod every time. Other techniques such as feature toggles (a.k.a. feature flags) can also be used.

Achieving high levels in the Definition of Done (DoD) maturity model ensures that Software Engineering processes are followed which provides code that is robust and of higher quality. [2]

Principle 4. Minimise operational costs

Favour small independent units of deployment such as containers to be cost-aware by: [4]

• Reducing hardware costs. More efficient use of resources will decrease the total cost of ownership.
• No vendor lock-in. Hybrid cloud enabled. Containers are portable, meaning there is no lock-in with a specific vendor. However, this is relative as using other services will create migration costs.
• Reduce licensing and maintenance costs. Simplify deployments and upgrades, improving productivity, and even improving efficiency by allowing operations to deliver more applications with the same amount of resources.
• Reduce time to market due to an increase in productivity. Docker easily integrates into all the popular Continuous Integration / Continuous Delivery pipelines enabling Development and Testing to deliver seamless updates to production much more efficient.

Principle 5. Design to support change

• Loose coupling between components. This means that changing one application or service should not impact another one. Allowing to have release independence.
• Immutability. In the immutable change management model, immutable infrastructure elements are built from scratch (or from artefacts and configuration with a known state) as a new instance of the element. The artefacts of an immutable infrastructure are composed of scripts, binaries, containers, images, and server templates while the configuration is the declaration of what that infrastructure should look like after it is instantiated. [8]
• Stateless components. A cloud-native app stores its state in a database or some other external entity, so instances can come and go. Any instance can process a request.

Principle 6. Contract-first based interactions

Interfaces must first define the contract, and then implement the service. This allows to achieve great benefits: [6]

• Parallelise work. The service provider and the consumer can work at the same time towards a shared goal.
• Clear expectations. Coding against a contract/interface definition allows both teams to develop and test up-front even if the other team hasn’t finished or is not ready for integration.
• Lower development effort and cost. Creating the contract is many times cheaper than implementing it. After the contract is reviewed/exercised by stakeholders, and we have achieved some level of confidence, then we embark on development.
• Better Developer Experience. The fact that the contract is defined up-front provides a good incentive to achieve good levels of documentation, which majority of it will be produced automatically based on the contract. This also ends up increasing discoverability and hence reusability.

Principle 7. Think about elasticity in every decision you make

Unless your system load almost never changes, you need to think about elasticity [3]. In order to achieve this your design needs to follow certain principles highlighted before such as statelessness and immutability to be able to provision and de-provision automatically. Repeatability is a key factor to achieve elasticity.

Conclusions

Cloud is about where we run our workloads, cloud native is about how we run our workloads [1].

Cloud native architectures take full advantage of on-demand delivery, global deployment, elasticity, and higher-level services. They enable huge improvements in developer productivity, business agility, scalability, availability, utilisation, and cost savings.

Understanding these principles will point you in the right direction towards your next cloud native architecture design.

References

[1] Cloud Native Patterns: Designing change-tolerant software with Cornelia Davis

[2] The evolution of Definition of Done (DoD) from zero to DevOps by Pablo Iorio

[3] Elasticity does not equal Scalability by Pablo Iorio

[4] Container based Architectures II/III: Business benefits by Pablo Iorio

[5] 5 principles for cloud-native architecture — what it is and how to master it by Tom Grey

[6] Great API design matters by Pablo Iorio

[7] Cloud Native Application Architecture by Siddharth Patnaik

[8] Cloud Native Immutable Infrastructure Principles

Disclaimers

This is a personal article. The opinions expressed here represent my own and not those of my employer. It contains affiliate links. If you use these links to buy something, I may earn a commission. Thanks.