15 Best Practices to Design Cloud-Native Modern Applications

Aymen El Amri - @eon01
DOIS 2019

The cloud is about how you do computing, not where you do computing.

~ Paul Maritz, former CEO of VMware and Pivotal

The cloud isn’t a place, it’s a way of doing IT.

Michael Dell, founder of Dell Technologies

The Only Constant is Change

The Evolution Journey

Netflix successful DevOps implementations,
The 12 Factor App of Heroku,
The Cloud Native Computing Foundation,
The 13 Factor App (Mesosphere),
Beyond the Twelve-Factor Application (Pivotal)
Web-scale IT (Google, Amazon ..)

The Golden Triangle

People
Processes
Technologies

People: The most important part of the equation as this involves leadership and a vision.
Processes: They refer to business goals that must be considered to help people drive successful changes in the business.
Technologies: The technology aspect of this triangle should be determined after the people and the processes that are in place. One of the mistakes is trying to retrofit the people and processes around technologies since this should go in the opposite way.

1 - Products (Over) / Projects
2 - Features (Over) / Releases
3 - Re-usability
4 - Technology Agnosticism
5 - Portability
6 - Abstraction
7 - Cost
8 - Speed
9 - Scalability (Business)
10 - Self-service
11 - Elasticity
12 - Resiliency
13 - Security
14 - Observability
15 - Simplicity

The mental model of a project:
Something is planned, executed then delivered within defined time and budget slots

Agile challenge:

The up-front determination
vs
On-going discovery and continuous optimization model.

Thinking about features makes implementing proven methodologies like “Feature Teams” and “Two Pizza Team” easier.

A feature team is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features - one by one (featureteams.org)

More known in software development, think of functions and routines.

The same principle can now be employed in infrastructure (like IaC) and automated builds.

Docker images are reusable and they are also using base images, that may use other base images .. etc.

A team responsible for a certain set of services can decide which tech stack they can use to solve a problem.

This approach, even if it has some drawbacks, increases the developer productivity and autonomy, therefore enhance the time-to-market.

Portability is usually attributed to a computer program that can run on different OSs.

Its alternative in the DevOps world would be a platform that can run on different infrastructures and cloud providers without requiring a major rework.

e.g: Docker, Kubernetes

Abstraction is more known in object-oriented programming.

A programmer can hide all but the relevant data about an object in an abstract class in order to reduce complexity and increase efficiency.

This is also applied to other models like infrastructure.

Cost is not an afterthought or a secondary topic.

Because developing at a fast pace is one of the value cores of most methodologies and implementations like ITIL, DevOps, and Agile.

An application is scalable when it allows adding new features and adapting old features to new business needs without a major rework.

Adopting self-service platforms within an organization helps teams deliver software continuously.

The degree to which a system is able to adapt to workload changes by provisioning and de-provisioning resources in an autonomic manner.

Time-based vs Value-based

The system stays responsive in the face of failure.

Monolith (multiple single points of failure)
=/=
Microservices

Because security is important.

Automation without security is risky.

Observability is a feature that makes a system monitorable.

With the complexity of distributed computing and cloud models, running an efficient computing infrastructure requires a spirit of radical simplification.

From Patterns to Practices

We started with the WHY,
let's see the HOW

I created a 2d table:

- Rows: Patterns

- Columns: Practices to implement them

1 — Design for Culture

Cloud-native is purely technical but the human side is important. There’s a link between your teams' structure and culture and what they produce as a result.

This is what Melvin Conway coined:

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.

2 — Design for Composability

Build microservices and decompose your monolith into simple, lightweight, loosely coupled services that can be developed and released independently of each other.

e.g: Polyglot microservices.

Polyglot microservices = developer independence and productivity

e.g: Containers, Serverless
- Cost-cutters.
- Increases the speed of delivery.

3 — Design for Automation

I think the automation of vision is a much bigger deal than the invention of perspective ~ Trevor Paglen

Automation has always been one of the good practices when building platforms.

Infrastructure using tools like Terraform, Ansible, and Saltstack
CI and CD using tools like Jenkins
System recovery and scalability

Make sure to simplify and secure before automating.

4 — Design for Statelessness

Stateless services are “smarter” than stateful services.

They allow these features to be implemented easily:

Scaling up/down
Gracefull termination for replacement (repairing)
(zdt) Rollback tasks
Load balancing

5 — Design for Dev/Prod Parity

As it’s described in The 12 Factors App: Keep development, staging, and production as similar as possible.

Dev/Prod parity makes tasks like CI/CD easy.

6 — Design for Isolation

Cloud-native applications are designed in a way to run without having affinities with the server and the operating system.

Use containers (Docker), microVMs (Firecracker) ..etc

7 — Design for Reactiveness

Reactive systems are responsive, elastic, resilient and message-driven.

8 — Design for Interaction and Collaboration (API-centered applications)

Cloud-native services communicate using lightweight APIs that are based on protocols like REST, NATs or gRPC.

9 — Design for Abstraction

Develop, and deploy your services using highly automated platforms that provide a service abstraction.

Abstraction and automation are highly related.

The example of abstracting the data and separating it from the computing and the business logic layer allows automation and makes operations on data like data caching easy and more performant.

This is when Kubernetes can become a universal abstraction layer that allows all kind of workloads to runs on top of it.

10 — Design for Business

DevOps is about aligning teams around common business goals, but this will not happen unless you design accordingly.

Create business capability teams and deploy business services.

11 — Design for Immutability

Immutability is replacing the old version of an application by building new servers from an artifact and totally replacing the old one.

12 — Design for Observability

Design observable applications that can interface with observability tools and give insights (metrics, logs, traces ..etc) into what your code does in production (or any other environment).

Observability enables :

- The white box monitoring.

- The understanding of a system behavior through its internals.

13 — Design for Security

Develop with security in mind and secure by design.

Security is not an afterthought.

14 — Design for Simplicity

Simple can be harder than complex.

To build complex systems that work, you need to build it from simple subsystems that work.

Unix philosophy:

Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.

15 — Design like Nature

Mother Nature CV:

13 billion years of experience in research and development.

The dinosaurs (weighty and slow creatures) have disappeared and left the earth for smaller, more agile and more intelligent species.

This is how software engineering is evolving:

Monolith applications vs cloud-native

Don’t think that monolith will totally disappear, they will continue to support the IT ecosystem for years.

The fact that more sophisticated approaches were invented, doesn’t mean a total instantaneous disappearance of other approaches.

When a whale dies, it supports a community of organisms and provides life for hundreds of marine animals for more than 50 years.

The “afterward optimization” approach

Dinosaurs evolved into birds

Richard P. Gabriel (computer scientist) suggests that a key advantage of Unix was that it embodied a design philosophy he termed “worse is better”, in which simplicity of both the interface and the implementation are more important than any other attributes of the system — including correctness, consistency, and completeness.

This design style has key evolutionary advantages.. it has better survival characteristics than the-right-thing

Monolith First approach

Microservices and cloud-native are to monolith what birds are to dinosaurs. Don’t feel that you should start with since you can evolve into them.

Thanks !

15 Best Practices to Design Cloud-Native Modern Applications

By eon01

15 Best Practices to Design Cloud-Native Modern Applications

There are two types of applications in this world: Cloud-native applications and non-cloud-native applications. In this story, we are going to discover the best practices to design and build the first type of applications.

1,149

15 Best Practices to Design Cloud-Native Modern Applications

The Only Constant is Change

The Evolution Journey

The Golden Triangle

From Patterns to Practices

We started with the WHY, let's see the HOW

I created a 2d table:

- Rows: Patterns

- Columns: Practices to implement them

1 — Design for Culture

2 — Design for Composability

3 — Design for Automation

4 — Design for Statelessness

5 — Design for Dev/Prod Parity

6 — Design for Isolation

7 — Design for Reactiveness

8 — Design for Interaction and Collaboration (API-centered applications)

9 — Design for Abstraction

10 — Design for Business

11 — Design for Immutability

12 — Design for Observability

13 — Design for Security

14 — Design for Simplicity

15 — Design like Nature

The “afterward optimization” approach

Thanks !

15 Best Practices to Design Cloud-Native Modern Applications

More from eon01

We started with the WHY,
let's see the HOW