Intro to Cloud Native

What is Cloud Native?

Cloud Native refers to a set of development practices that organizations use to deliver their products at scale with the help of either private or hybrid or public cloud providers.

To deliver products at scale and at the same time at high speed and with great agility, we make use of containerization software such as Docker or Containers, etc. Think of containers as small computers used to run a specific application. This helps us deploy parts of our application independently as containers and this whole process is not that hard.

All of the above mentioned technologies will perform in-efficiently if the right type of development architecture is not used. In comes Microservices.

The idea behind microservices is that instead of making a tightly coupled system with different features close to one another, what we do instead is break our system into different services based on what it does. Let’s understand it by comparing it with monolithic architecture.

Note: To understand the difference between Monolithic and Microservice architecture, we are going to take an example of an e-commerce website.

Monolithic Architecture

In monolithic architecture, all of the product’s features are tightly coupled. By tightly coupled, what I am trying to say is that either everything will work or it won’t work at all. Even though some parts or most parts of your application might be working properly, the application as a whole won’t work because of some silly error or a bug.

Let’s say there is a bug in the Payments feature of our e-commerce application which results in the application exiting. Now, since we are using monolithic architecture, we know that all the features are tightly coupled.

Because of this tight coupling, the system running on the server will stop resulting in our application as a whole being down. What we are seeing here is that a bug in the Payments part of the system is causing the whole system(Ordering, Display Items, Search, User Auth, etc) to stop working.

So what is our goal? Our goal is to design an architecture in which our system’s features are decoupled(separated) from one another and errors in one part should not cause the whole application to go down. This type of architecture is called Monolithic Architecture.

Microservices Architecture

…First of all, there’s no concrete definition of what can be called a microservice architecture. But what we do know from examining the patterns followed at firms both large and small scale is that in a microservice architecture, we create services that are small and are deployed independently. (Remember, this is what we wanted to achieve using Cloud Native practices).

It is an approach to develop a suite of small services modeled around a business domain that can be deployed independently and are good at one thing in particular. Each of these services is running its own processes, has its own data storage, and communicates with other services via mechanisms like HTTP APIs and RPC calls. One more thing to note about them is that they are automatically deployed using some CI/CD toolchain.

For example, one service might be used for keeping the items list, another for processing payments, and one for shipping but as a whole, they form an e-commerce system. Take a look at the following diagram.

You can see that we have 5 different services. First, we have users(on the right) whom we are using CockroachDB to store their information. Then we have the Items list service whose sole purpose is to keep details of items that are present on our e-commerce website with a database of its own.

Microservices embrace the concept of information hiding. Information hiding is described as hiding as much information as possible inside a component and exposing it as little as possible via external interfaces.

This allows for a clear separation between what can change easily and what is more difficult to change. And since from the outside, service is seen as a black box, it can be written in any language of your choice.

So one service might be written in Go and the other in Java and yet they can still communicate with each other via network endpoints. This also means that for a particular service, we can use a specific DB type to our advantage.

In the example shown above, for Users service, we are using CockroachDB since it will help us with managing the relations. On the other hand, in the OAuth service, we are using a NoSQL database in Cassandra because it would be more beneficial for storing auth tokens and other details.

• Intro to Cloud Native
• Front-End And Back-End Web Development, Which Is Better?
• Programming, Graphic Design & Digital Marketing-Which Is The Best-Selling Skill?

Pheww, that was one heck of a side tour…

Cloud Native Tools

Now that we know what our aim is by using Cloud Native technologies and what Microservices architecture is, let’s take a look at some of the tools which come under the Cloud Native umbrella.

In a microservices architecture, we learned that we want to deploy the different services rapidly and independently. For this, we make use of containerization tools such as Docker, Containers, etc.

Now that we can deploy the services independently as containers, we want to be able to easily configure, manage and scale them. We use tools such as Docker Swarm, Apache Mesos, and Kubernetes for orchestrating these containers. The majority of the companies use Kubernetes which has a vast ecosystem of integration tools that further provides different capabilities like:

• Runtime Environment – Docker, CRI-O
• Networking – Weavenet, Flannel
• Storage – OpenEBS, Rook
• Service Mesh – Istio, Linkerd
• Logs & Metrics – Fluentd, Prometheus, Grafana
• Tracing – Jaegar