10 Steps to navigate your cloud native journey

Published on Aug 31, 2020 | 10 Mins Read

View fullsize

The Cloud Native Landscape «Source:CNCF»

Are you trying to navigate your cloud native journey and feeling daunted?

If you're a CIO or a tech leader overseeing digital transformation initiatives to transform your business and build the next-generation platform, probably you'll be going cloud native at some point.

View fullsize

The Cloud Native Trail Map «Source:CNCF»

Cloud native is a set of practices, technologies, and processes that enable you and your organization to build more reliable systems, reduce cost, avoid vendor lock-in, and accelerate innovation while taking advantage of the unique features of cloud computing such as elasticity, self-service, and high-availability.          

In this article, I will walk you through the ten steps to navigate your cloud native journey with ease. There's no doubt that every enterprise's journey is unique. At the same time, there are many patterns seen throughout the past few years and hence we should be able to establish a baseline.

In 2017, the Cloud Native Computing Foundation ( CNCF )  — The non-profit supporting the advancement of cloud native —  published the Cloud Native Landscape. While the cloud native landscape is vast and challenging to navigate, it provides a single view of cloud native technologies ( DIY, open-source, commercial,...etc ) including cloud providers, vendors,...etc.   

CNCF released the  Cloud Native Trail Map about a year later. The map represents a pathway for enterprises to get started with their cloud native journey. 

Few things to point out before we go over the 10 steps:

• Next to each step you will see a production-readiness checkmark to indicate wether this step is essential before going live. You may skip an unchecked step and come back to it later . This is based on findings working with enterprises adopting and operating cloud native technologies. 

• In the upcoming  posts , I will drill down on some of those steps in more detail. 

1. Containerization ( ✔ )

A cloud native application is a container-based application that can be moved around ( from on-premises to the cloud, multi-cloud,...etc ) with minimum or no changes while decoupled from the underlying infrastructure. The container is where you want to start.   

Docker democratized and simplified the container technology for both developers and operators. It has a lively ecosystem, available in many integrated development environments (IDEs), and it works on both Linux and Windows.  Later on in the journey, as you will see,  you might consider other alternatives depending on the type of workloads, supportability, or security.    

The biggest myth about containerization is that it's another lift-and-shift effort. Nothing could be further from the truth. Just modularizing a monolithic application into a container won't get you far and you're destined to a long and difficult journey ahead.   

The crawl-walk-run approach is applicable here and can lead to long-lasting benefits. The way to approach this initiative is to develop a process. Starting with a microservices-like list of candidate applications and go from there. Legacy, mission-critical, and stateful applications should be at the bottom of the list while net new, stateless, and non-critical applications should be at the top.   

For example, a lightweight web server or an API-based application is a good candidate whereas a 3-tier trading application that's reading and writing to a data lake is not. As you go through the journey and learn more, you can always go back, rinse, and repeat.    

2. CI/CD ( ✔ )

After containerizing your applications, you'll soon realize that the container image is the new build artifact.   What does that mean? 

For example,  you might have used web archives (WAR) for Java or NuGet for .NET to package and deploy applications. In the cloud native universe with the container as the main unit of computation, such deployment artifacts have to be built into the container itself. Think of the container as a single isolated process such as a lightweight web server with accompanying (minimal) applications or libraries to get it up and running.  

The idea here is to have a process in place to take care of the container image life cycle management.  This can be summarized in three steps:

1. Code has to be pushed to a source control system

2. The container image is then built and then pushed to an image registry 

3. The container image is now ready to be pulled and deployed on the host.   

This will allow for automated testing, rollouts, and rollbacks if necessary.  The underlying tools to accomplish this doesn't matter. You might do it yourself and develop scripts to build your own CI/CD or use commercial offerings of Git, Jenkins,...etc.   

At the end of the day, the goal is to automate as much as you can of the process end-to-end such that it's integrated into your software development life cycle and the container image is becoming the new standard build artifact.  

3. Orchestration & Application Definition ( ✔ )

As you start to build and deploy more containers you'll encounter a problem. How to make sure all these containers are being created and terminated as needed, scaling up or down, and not consuming all the resources on the underlying hosts?  

That's when Orchestration comes into play. Kubernetes (greek for helmsman)  is the most popular orchestration system today. It's open-source, has a large ecosystem, and is supported by plenty of vendors and cloud providers. 

However, it has a steep learning curve and requires a lot of automation and skill on your part to run effectively. It comes as no surprise as it was donated by the tech behemoth  — Google — to CNCF in 2015. Vendors and cloud providers are working tirelessly to simplify such complexity and make it easier to operate and adopt Kubernetes.  

The good news is that there are alternatives and you don't have to start adopting Kubernetes from the outset. Some of the open-source alternatives include Docker Swarm, HashiCorp Nomad, and Apache Mesos just to name a few. If you're opting for simplicity, Swarm or Nomad is a place to start.   

The idea here is to get you started on your journey rapidly without being stuck on a steep learning curve. You can always go back and change the orchestrator in the future as you start to experiment, practice, and learn more.     

Once you select an orchestrator, you'll reach a point in which you want to deploy your application (composed of one or more containers) as a single unit,  track its dependencies,  and rollback a certain deployment if necessary. Docker Compose is the go-to solution for Swarm and Helm is the one for Kubernetes. You always have a choice of the tool you select and it's wise to make sure to weigh the tradeoffs.   

4. Observability & Analysis ( ✔ )

While the first three steps are essential for enterprises, I consider Observability & Analysis another one. For example, you're progressing into your journey and going live next month without much effort put into monitoring, logging, and tracing.  

• How are you going to manage such environment when you encounter issues?  

• How are you planning to improve performance? 

• How can you measure the user experience?     

Certainly, you don't have to have very sophisticated and expensive tools. The term "Observability" might be somehow misleading. The idea here is that you are eventually able to figure out what happened in your system, when, and where. Usually, that's accomplished using a trio.   

1. Monitoring to provide you with telemetry of the health of your applications and the underlying IT infrastructure.   

2. Logging to understand the chain of events when they occur.   

3. Tracing to pinpoint the different parts of the system when issues occur.     

There are plenty of open-source and commercial tools to utilize. The most popular open-source are  Prometheus for monitoring, fluentd for logging, and Jaeger for Tracing. You can always mix and match open-source and commercial tools if invested in enterprise observability solutions or planning to do so.  

5. Service Proxy, Discovery, and Mesh

Throughout your journey and with the right intention, you will become microservices-driven. That's going to add complexity and you'll be looking for ways to take care of service-to-service communication needs such as reliability, observability, routability, and discoverability.    

A Service mesh will serve that purpose. It's another layer of abstraction to reduce complexity, increase application resiliency, provide a uniform way to monitor microservices, and control traffic.  

In the meantime, you want to pay close attention to the overhead introduced by using a service mesh. It's simply another layer of abstraction which might not be beneficial in certain use-cases. Istio (greek for sail) is the most popular open-source service mesh. It's based on an extended version of Envoy. An open-source high-performance network proxy. 

6. Networking, Policy, and Security ( ✔ )

Cloud native applications are distributed applications in nature. They require communication between different services or components of the application to fulfill web a request or process data.   

Without changing much to your existing physical network, you can leverage Software-defined networking (SDN). This will allow you to manage, and control your network programmatically.  In other words, your network infrastructure is going to be programmable using APIs.  

There are many container networking solutions. The most popular ones are based on the Container Network Interface (CNI) — a CNCF specification project for writing plugins to configure network interfaces to provide connectivity for containers — and they vary in terms of the feature set, enterprise readiness, complexity, and extensibility.   

Later on, you will want to limit the traffic from or to applications. Using micro-segmentation and network policies are a few things you can implement to establish zero-trust security. That's another reason to fully understand the features and capabilities of the CNI plugin selected to make sure it meets your requirements and needs in the long-term especially when it comes to security and enterprise readiness.     

7. Distributed Database & Storage

At some point in your journey, you'll be looking into modernizing stateful workloads that require both resiliency and scalability. Whether the underlying data store is using NoSQL or SQL databases, persistent data storage is hard in cloud-native environments. Let's not forget that cloud-native applications are containerized applications with a temporary storage layer to store runtime changes that don't exist beyond the container lifetime.   

Fortunately, an industry-standard emerged — the Container Storage Interface (CSI) — which enables storage vendors to develop a plugin for their storage solutions  and run across several container orchestrations.  

Now you will be able to use your preferred cloud providers storage solutions (i.e: AWS EBS, Azure Disk,...etc) and on-premises 3rd party storage appliances (i.e: NetApp, Pure Storage,...etc) for stateful cloud-native applications   

Once you have integrated a storage plugin, you should be able to run resilient and scalable distributed databases. For example, Vitess is an open-source solution for running scalable MySQL databases at scale using sharding.    

8. Streaming & Messaging

With more microservices applications built in your environment, you will want those services to communicate across environments and platforms. JSON-REST is usually preferred for building many APIs due to its simplicity and scalability.  

If you reach a point in which you are using hundreds or thousands of microservices for your applications, then performance becomes of paramount importance and those milliseconds of latency will add up. This will degrade the overall performance which is going to affect the user experience.  

You might want to consider using gRPC — A high-performance RPC framework developed by Google in 2015. gRPC relies on  Protocol Buffers (a.k.a protobuf) to serialize structured data instead of using JSON over REST APIs. Protocol Buffers is a binary-like format that's compact and hence faster to transfer over HTTP/2.  

 For a messaging system with publisher/subscriber, load-balancing, and sophisticated messaging capabilities you might consider NATS. An open-source messaging system for cloud-native applications, IoT messaging, and microservices architectures.   

9. Container Registry & Runtime

Once you establish that the container image is the new standard build artifact, you might want to look into solutions to store, sign, and scan such container images. While Docker Hub is the world's largest library for container images and a start, you might be looking into other alternatives to be able to meet certain requirements and needs (cloud-first, compliance, security,...etc).   

There are open-source and commercial alternatives you might look into. Harbor is an open-source registry that can run as a cloud-native application or standalone.   

Some of the commercial container registries (in no particular order) are: 

• Amazon Elastic Container Registry 

• Azure Container Registry 

• Google Container Registry 

• Docker Trusted Registry 

• RedHat Quay   

Similarly, you might be looking for alternative container runtimes. Each container runtime has its strengths and weaknesses. A container runtime standard — the Container Runtime Interface (CRI) —  came about to give you such flexibility to use a wide variety of container runtimes.  The most common container runtimes are Docker, containerd, and cri-o.

10. Software Distribution

With the paramount importance of data security and an increase in data compromises, there's a vital need to be able to secure the entire supply chain of container images. 

That goes beyond just signing a container image cryptographically giving you the ability to define a policy on the usage of a particular container image. For example, only images signed by a particular party can be used at runtime and deployed.  

Notary — donated by Docker to the CNFC in 2017 — is a tool for managing trusted content whereby publishers can digitally sign content and consumers can verify the integrity and origin of such content. Notary implements The Update Framework (TUF), a general design for solving the problem of securely managing software distribution and updates.  

---

Where do you start? Begin right where you are today. Assess where you are in your cloud native journey and determine where you want to go. Build a portfolio of handful applications to containerize and set up CI/CD from the outset. Pick an orchestrator and better not to consider observability, security, and networking as an afterthought.

There are plenty of choices to make when it comes to going cloud native . You want to make sure you decide to start your journey and you can always go back and change tooling and tweak things

Not sure how to start your cloud native journey in your enterprise or struggling along the way? Book an online consultation and let’s come up with a roadmap to get you where you need to be.