A Crash Course on Cloud Native Coordination & Service Discovery

The Cloud Native Computing Foundation (CNCF) has made quite a mark on the industry in recent years. The CNCF has brought together vendors and developers from across the industry to cultivate the growth of cloud native apps.

In addition to incubating projects and facilitating meetups, the CNCF helps educate the world about cloud native. One of their most impactful contributions has been their interactive cloud native landscape.

With all the nuance and variance in the world of cloud native, the landscape can be difficult to navigate. To make things easier, we’ve provided a Complete Overview of DevOps Cloud Native Tools Landscape in a previous post. In this piece, we’ll take a closer look at one of the orchestration and management subcategories: coordination & service discovery.

#An introduction to cloud native coordination & service discovery

The simple definition of cloud native coordination & service discovery platforms is “platforms that enable automatic, low latency, and distributed service discovery and health checks.” Generally, these services use protocols like DNS, gRPC, and HTTP to create service registries and enable coordination between microservices.

#The need for cloud native coordination & service discovery

Cloud native apps must be distributed and loosely coupled to remain scalable and resilient. Microservices help developers reach these goals, but they create unique challenges when it comes to service discovery.

You can begin to see the problem when you consider how microservices architectures work. Containers are constantly spun up and down to meet dynamic demands. IP addresses and hostnames are constantly changing. How then are clients able to connect to services or API gateways when they need to? Similarly, how can you ensure traffic is only routed to healthy nodes?

Manual configuration and checks were an option with old client/server paradigms but are impractical for cloud native. Therefore, developers require an automatic, scalable, and distributed alternative.

#Why cloud native service discovery is different

Our description of cloud native coordination & service discovery services above assumes cloud native apps require a different approach. So, let’s take a closer look at what has changed and why that is the case. We’ll borrow a bit from the OpenStack Foundation’s “Service Discovery and Registration in a Microservices Architecture- What, Why and How?” presentation in this section. If you have 40 minutes to spare, we recommend you check out the full presentation here.

Early on, web applications resided on a single server. As a result, there was a one to one relationship between application frontends and application backends. With this monolithic architecture, you discover services using a single hostname. That is, DNS to translate IPs to hostnames is the only requirement for service discovery.

Over time, applications evolved to be spread across multiple servers. With this additional complexity, you need to add load balancers and potentially virtual IP addresses to facilitate service discovery.

The next evolution of web applications was a 3-tier apps. A web-tier, an application-tier, and a database-tier all came together to enable application delivery. Now, each layer can scale up or down independently. In addition to DNS and load balancing, you need to run health checks to ensure you only send traffic to functioning servers.

Our next iteration of application delivery was virtualization. The creation and destruction of virtual servers occur in minutes. As a result, manual configuration of load balancers and health checks is impractical. You need to begin to automate when applications are at this level of complexity.

Finally, with cloud native microservices architecture you see even more complexity and speed. Containers are dedicated to discrete services. The creation and destruction of containers can occur in milliseconds. With this paradigm, platforms that enable automatic, hyper-scalable, low-latency service discovery and health checks are a must-have.

#Cloud native coordination & service discovery benefits

Given the demands of microservices architecture, you can probably guess the benefits cloud native coordination & service discovery platforms bring. These services help you shift away from manual processes and get the most out of cloud native. Their benefits include:

• Performance- Speed is an important attribute of cloud native apps. When you use platforms purpose-built for distributed service discovery, you can achieve significant performance gains.
• Simple coordination & health checks- With older paradigms, you often needed to manually configure service discovery and load balancing. With cloud native platforms, you can automate the process.
• Scalability- As a result of automating the service discovery process, you unlock the potential for hyper-scalability for your cloud native app. For an example of the benefits, check out Jeremy Eder’s Four Scalability and Performance Wins after etcd3 Migration.

#Popular cloud native coordination & service discovery services

Now that you understand the basics of cloud native coordination & service discovery, let’s take a look at the services in this category. Projects in the coordination & service discovery category make automated service discovery and communication between microservices possible.

As with most things in the world of cloud native, you need to take your use case into account when selecting from the different services listed here. In some cases, such as etcd & CoreDNS, it is common to use the services in conjunction with one another. In other cases, you may require a solution that didn’t make the CNCF landscape at all, like Consul.

#etcd

etcd is a popular key-value store for distributed systems. It is written mostly in Go and is being incubated by the CNCF. You can use etcd for use cases as simple as storing feature flags as key-value pairs or as advanced as the implementation of database leader elections.

If you’d like to get an idea of how etcd works in practice, Kunal Pariani walks through using NGINX and etcd for service discovery in this blog article.

#Apache Zookeeper

Apache is a big name in the world of cloud native. ZooKeeper is their service for providing reliable service coordination and synchronization at scale.

ZooKeeper uses data registers known as znodes to coordinate data sharing between processes. Znodes use a hierarchical namespace structure, and ZooKeeper provides clients with access to znodes in a low latency and scalable way.

ZooKeeper has a solid reputation for scalability and is used by many enterprises and open source projects. For example, Box uses ZooKeeper as a service discovery and service coordination solution. Additionally, Yahoo! Uses ZooKeeper for leader election, configuration management, and more.

#CoreDNS

CoreDNS is a DNS server that is written in Go and emphasizes simplicity. It is also a CNCF graduated project.

Speed and flexibility are two of the core tenants of CoreDNS. As a result of its emphasis on flexibility, CoreDNS offers a wide variety of plugins. In fact, the ability to chain plugins together is one of the unique value propositions of CoreDNS. The use of plugins helps keeps CoreDNS lightweight and extensible, and enables you to optimize it for your needs. The CoreDNS Kubernetes and etcd plugins are two of the most popular for service discovery.

For a practical example of how to implement CoreDNS with Kubernetes, check out Chris O'Haver’s Scaling CoreDNS in Kubernetes Clusters doc on GitHub.

#Nacos

Nacos is a popular service discovery, configuration, and management platform from Alibaba. The project has a large user base in China and over 9,000 stars on GitHub. Nacos provides you with both RPC-based and DNS-based service discovery. The platform also supports health checks, which allow you to avoid sending traffic to unhealthy hosts. Additionally, Nacos supports a dynamic configuration service that allows you to more easily implement stateless services.

For a deep dive on Nacos, check out the Alibaba Tech team’s Introducing Nacos: Alibaba’s Open Source Solution for Cloud-native Development Medium post. There, you’ll see how Nacos enables you to replace traditional configuration methods such as hard-coding, configuration files, and databases with a more dynamic and scalable approach.

#Netflix Euerka

Euerka is a Netflix built service registry for load balancing and failover. Interestingly, you will find that Eureka 2.0 is discontinued but the 1.x project is still active.

The use case for Euerka is simple. Cloud native apps require automatic ad-hoc creation and destruction of containers and servers. It makes dependence upon well-known IPs and FQDNs for service discovery and load balancing impractical. Because of the hyperscale nature of their business, Netflix had a need for a middle tier load balancer that could register and deregister servers dynamically. Eureka fills this gap.

At this point, you may ask: “what exactly is middle tier?”. In short, middle tier means a given AWS region. As you may expect given that definition, Eureka’s primary use cases are in AWS. You may find this surprising given cloud native’s emphasis on platform independence, but it makes sense when you consider Netflix’s application delivery model.

#Final thoughts

We hope you enjoyed our explanation of the coordination & service discovery category of CNCF’s Cloud Native Landscape. You should now have a sound understanding of the tools, protocols, and techniques associated with coordination & service discovery. With this understanding, you can decide what services work best for you and build more resilient scalable cloud native apps.

To learn more about cloud native, subscribe to our blog or contact us today!