CNCF Tools Overview: Are You Cloud-Native?

Cloud computing is becoming more and more of a household name, with even the most conservative fields of business figuring out how to make the best use of it. Cloud computing usually starts with running a private cloud solution on premises before venturing onto the public cloud. Of course, the cloud is not a single uniform being. It may come from different providers, Amazon Web Services, Google Cloud Platform, and Microsoft Azure being the biggest players here. Or it may come with different visibility and hosting, that is, public (resides with the provider), private (self-hosted), or hybrid (which uses a bit of both). And the cloud can use different tools and APIs for management as well.

In the past, when you subscribed to one provider, you were basically locked in forever. Changing a provider required a massive effort if it was even possible at all. Furthermore, even though cloud computing offered up a vast selection of tools to decrease costs and increase the availability of hosted services, many users treated the cloud as nothing more than a collection of Virtual Machines.

To overcome these obstacles, a new kind of software started to emerge in recent years. Cloud Native technologies make it much easier to take advantage of all the benefits the cloud provides while abstracting the underlying infrastructure. Why is this good? Well, it means that you no longer need to be tied to one particular provider and can move your application between providers with much less hassle.

The Cloud Native Computing Foundation (CNCF) acts as an umbrella for all the projects that aim to make software both cloud-native and cloud agnostic. This series of articles aims to highlight some of the popular tools that you may want to use.

CNCF’s first project was Kubernetes–an orchestration tool that makes managing containers easier, especially in cloud environments. Because of this, many CNCF tools are more or less tied to Kubernetes, although you can also find serverless solutions and tools that were in the market even before Kubernetes.

Migration to microservices doesn’t stop after you set up your Kubernetes cluster and move the workload inside containers. You’ll realize pretty quickly that the tools you’ve used so far are no longer fulfilling your needs. Faster releases simply require a different approach, and you have a lot more to monitor, although container APIs do make the job much easier. But with an increase in services, you also increase the number of dependencies and the size of the traffic.

This is why there are so many cloud-native applications under active development. Development has also surged because the cloud native landscape provides many new possibilities, not just new problems. And this, in turn, means that by going cloud-native you’ll want to learn which applications out there today can bring you the most benefits.

If you are interested in learning what exactly CNCF is all about, this interactive landscape shows you everything there is to know. Most every category of server-related software has its cloud native counterpart. There are cloud native databases, messaging systems, logging and tracing services, CI/CD services, and much more.

You don’t have to learn them all at once. In fact, you may not even need to learn most of them. But it’s a good idea to at least know what possibilities are available in the cloud native landscape. So, we’ll discuss a few of them here.

Istio is a powerful tool. First of all, it helps you connect microservices and control the flow of traffic they receive. As a side effect, this control eases blue-green deployments or canary releases. But that’s not all. With Istio, you automatically get secure communication between the services, and it takes care of managing encryption, authentication, and authorization via the use of mutual TLS. Finally, Istio gives you access to automatic logging, tracing, and monitoring. Wondering what to do with such data? Fluentd, which we’ll discuss below, may help you make the best use of it.

Even though the authors claim Istio should be compatible with a range of technologies, most resources are focused on Kubernetes at the moment. So if you feel your Kubernetes cluster requires better flow control and automated security, Istio would be a good tool for you.

Internally, Istio uses Envoy, another cloud native tool that we’ll present in this article as well. You can also check out Kiali, which visualizes Istio’s service mesh and allows you to monitor how your microservices are connected.

While Istio is a Swiss Army knife, Jaeger is much easier to describe. Its job is to enable end-to-end tracing in distributed systems. In a traditional three-tier web application, tracing transactions between the frontend, backend, and database can be tricky. When you add in the complexity of multiple microservices, this task can best be described as very difficult.

Jaeger aims to address the problems of monitoring distributed transactions and propagating the distributed context. This allows you to optimize performance or latency, perform a root cause analysis, or analyze the inter-service dependencies. As it’s compatible with the OpenTracing API, an open standard for tracing and instrumentation, Jaeger has access to many client libraries, and there are numerous examples and tutorials on how to use it for tracing. It can be run as a single binary using its own backend, or it can use an external backend such as Elasticsearch, Cassandra, or Kafka. Jaeger also comes with its own UI for displaying call graphs. You can see how OpenTracing and Jaeger work together via this tutorial/demo.

Envoy is a service proxy. It works much like Nginx or HAProxy but with the added benefit of automation provided by cloud native capabilities. Setting it up is also much easier than the previous solutions discussed. There’s an edge proxy Envoy process that faces the outside world, and then there are service proxy processes. Those service proxies are deployed as sidecars alongside your current services.

Some of the tricks Envoy performs well include full HTTP/2 support with bidirectional translation to HTTP/1.1 when needed, service discovery, bidirectional SSL, ability to proxy any TCP protocol, and increased visibility into the traffic flow. As predicted, both HAProxy and Nginx compete with Envoy in the service proxy space, and so does Traefik, another cloud native solution.

Before Istio, the service mesh category was proudly represented by Linkerd. Actually, there are two Linkerd versions that can be thought of as separate projects. The original Linkerd was designed to run in various environments (not necessarily on Kubernetes clusters) and runs on JVM, meaning that it’s rather heavy on resources required versus the other tools mentioned here. Complaints of sluggishness due to the use of JVM led to a rewrite named Linkerd2. Even though this was supposed to be a replacement of the original Linkerd, at the moment it’s mostly targeted for competing with Kubernetes. Also, instead of using Envoy as a proxy, Linkerd (both versions) uses its own proxy solution.

One of the advantages that Linkerd may have over Istio is the paid support of the company behind it, Buoyant. You may also want to check out how Istio and Linkerd compare against Consul.

CNCF’s website describes Fluentd as a data collector for a unified logging layer. What this actually means is that Fluentd makes it easier to collect and process logs from various sources (like Syslog, Docker, or application logs). These logs can then be filtered, buffered, or routed to appropriate services (like Elasticsearch, Nagios, or S3). Fluentd uses an internal JSON format to store and process the logs, and communication with sources and outputs is handled via plug-ins. This all makes it possible to realize the promise of a unified logging layer.

Fluentd is more or less a competitor to Elastic’s own Logstash, and they are very similar when compared.

This is by no means a complete picture of all the interesting tools CNCF can offer. And if you are interested in the details for each tool mentioned above, make sure to follow our upcoming series where we will present the use cases and examples for each one. After reading those, you should be more than ready to easily make your application cloud-native.