MICROSERVICES ORCHESTRATION: IT’S NOT FOR EVERYONE, BUT IS IT FOR YOU?

Microservices architecture, and Microservices orchestration in particular initially seen as the solution for larger software systems due to its clear advantages over existing solutions. Product owners knew that their services could now be loosely coupled and scaled faster. 

As orchestrated systems grew bigger, related issues became more pronounced too. In fact, more software engineers start questioning if this type of architectural pattern should be used as the default setting or if it should only be used if there is a specific reason to do so.

If you need to migrate to microservices architecture, want to know the difference between the microservices orchestration and choreography, or are curious about the pros and cons of orchestrating microservices, this piece will help.

Just Checking: Do You Really Need Microservices?

Orchestrating your loosely coupled microservices is just one approach — you could also choose choreography. If you decide that neither monolith nor SOA is your cup of tea, you’ll choose between these two types of microservices architecture.

Before making a final decision, it’s worth checking out the advice of Sam Newman, the author of the best-selling books “Building Microservices” and “Monolith to Microservices”. In a chat with Martin Fowler he argues that you need a reason to choose microservices architecture to start with, while monolith should still be the default option in 2021.

According to Newman, there are three big reasons to use Microservices to start with:

1. When a business concept can’t afford much [if any] downtime and calls for independent deployability of services

[for example, a SaaS system, where downtime is the same as demise].

2. When data partitioning is a requirement, as in cases where confidential data needs to be processed and stored separately

[This is an urgent issue for HealthTech, LegalTech, FinTech, and InsurTech companies, as they deal a lot with highly regulated ecosystems with PIID, GDPR issues, and the right to be forgotten].

3. To reflect a higher level of overall organizational autonomy

[To share responsibility between teams and make them more autonomous, requiring less coordination].

In other words:

Microservices architectures buy you options

James Lewis

With this quote Lewis implies that you pay a price for enjoying the benefits of microservices. It’s up to you to decide if the tradeoffs are worth it. 

What Is Microservices Orchestration?

Here’s a quick definition for those just starting to nibble at the topic:

Microservices orchestration is a method of implementing microservices architecture for software systems and applications, which suggests that loosely coupled services get their commands from a central controller — a so-called orchestrator. Under this structure, the orchestrator sends a call to each service and awaits a reply before proceeding.

As the title suggests, this controlling module is compared to a director of an orchestra, who needs to communicate with all musicians [loosely coupled services]. This kind of setup has its drawbacks and benefits — let’s start with the good news first.

Benefits of Keeping your Services Loosely Coupled with an Orchestrator

The majority of the benefits of microservices architecture apply to this orchestration architectural pattern too. 

Multi-language compatibility

Disparate services within an application can be coded in different languages using diverse frameworks, which offers flexibility to software engineers.

Independently deployable

One of the biggest advantages of the Micro Services [MS] architecture is that each of them is seen as a loosely coupled body with little influence over other components. They easily integrate into DevOps continuous CI/CD lifecycle.

Relatively easy to read, observe, and manage

When compared with monolithic architecture, this type of architectural pattern is easier to comprehend. That’s because developers only need to deal with one service at a time and can disregard the rest of the ecosystem.

Shift of communication protocols from synchronous to asynchronous

Orchestration suggests that as the application grows in complexity, communication protocols can be shifted from synchronous messaging to asynchronous.

Another popular pattern is Microservices Choreography. Let’s see how they are different.

Microservices Orchestration vs. Choreography

Microservices Choreography offers a more pronounced level of flexibility and service independence. This architectural pattern uses event brokers to pass messages asynchronously. Once the message is sent, a microservice is no longer waiting for responses, but rather observes its own environment.

Orchestration is an autocratic process model with centralized control and a single executor, while choreography is an autonomous interaction model with truly distributed control and decentralized peer-to-peer messaging.

In orchestration the workflow is controlled centrally, while in choreography it’s more independent, because predefined event scenarios determine the next steps.

Like orchestration, this culturally-tinted term is also rather descriptive. Choreography allows dancers to know what to do in a predefined manner, as they learn every move beforehand and then follow the music. Similarly, the event broker is your choreography.

Event streams are predefined and offer a few advantages over choreography when compared to a more limited orchestration approach. Since the broker makes calls based on predefined events, there is no latency from the response time of a certain service. As soon as the event broker makes a call, a microservice deals with the execution on its own, which doesn’t delay other components.

Microservices choreography offers a more loose coupling that makes downtime less likely due to the fact that various elements function independently. It also leads to increased agility.

Microservices Orchestration Tools

These tools are used to design, develop, deploy, and test software systems using a microservices orchestration approach. 

A litany of instruments — from operating systems, frameworks, and API systems to service mesh tooling — work together to create these software solutions.

The mere abundance of these tools may seem overwhelming to a non-technical person, so we will only briefly enumerate the major technology. However, this footnote also emphasizes how vital it is to ensure that a professional, practiced team of software engineers works on your project – be it migration from legacy systems, cloud-native app development or a hybrid environment.

Here’s a short overview of the major categories:

Operating system

There’s not much to talk about in this section. It’s Linux.
Linux, the free open-source, virus-resistant OS, is the choice for most of the software development engineers who want to build a loosely coupled system. Ubuntu, Debian, CentOS, and RedHat Linux distributions are the most popular.

Programming Languages Used for Microservices Orchestration

The multi-tech, multi-language environment is a huge advantage of microservice architecture, as it allows any programming language to be used. 

Still, these languages remain the most popular due to their MS development:

• NodeJS (Express, KOA, Nest, etc.)
• Spring Boot

API Management and Testing Tools

API helps connect individual microservices and enable their communication. Software architects often use APIGEE and AWS API Gateway to manage the API ecosystem. Postman and API Fortress are employed for testing purposes. These tools enable API health monitoring and testing, and ensure visibility and timely alerts distribution in case of a malfunction.

• APIGEE
• AWS API Gateway
• Postman
• API Fortress

Message-Broker Software And Event Streaming Platforms 

Depending on the cloud service provider, you may want to opt for a vendor-native solution from AWS, GCP, or Azure, or a popular third party messaging tool, like Kafka or RabbitMQ.

• Apache Kafka
• RabbitMQ
• Amazon Simple Queue Service (SQS)
• Google Cloud Pub/Sub

Toolkits

These toolkits may contain public libraries and repositories as part of their offering. They also sometimes work as PaaS or FaaS, helping architects integrate microservices via HTTP APIs or with third-party services.

• Eclipse JKube [toolkit for java, successor to depreciated Fabric8]
• Seneca [toolkit for Node.js development]
• Google Cloud Functions

Architectural Frameworks

Both of these popular frameworks help leverage MC and container design, but GOA is used for systems written exclusively in Golang.

• GOA
• Kong

Containerization & Kube Development

Kubernetes is the centerpiece of this collection of microservices orchestration tools. Along with a host of less popular rival container orchestration tools, Kubernetes helps software developers automate software deployment and management.

• Kubernetes
• Docker
• Istio
• Telepresence
• Minikube

Orchestration Tools

These orchestration tools are a mix of open-source and for-profit software solutions whose function is to help orchestrate microservice communication without losing autonomy.

• Conductor [by Netflix]
• Azure Kubernetes Service
• Mesos
• Camunda

Tools for Monitoring & Testing

Event monitoring and alerting helps developers observe the microservices infrastructure environment for system failures and errors so that they can minimize downtime.

• Prometheus
• Graylog
• Logstash

Serverless

If you decided to run your microservices in serverless mode, these tools are usually used [the ideal scenario for serverless deployment is when a microservice only needs to run occasionally]:

• Claudia
• Apache Openwhisk
• Kubeless
• Microsoft Azure Functions
• AWS Lambda

Service Mesh Tools

A service mesh layer is often used in microservices architecture. These systems are popular with different levels of compatibility with other tools [Linkerd being Kubernetes-focused, for example].

• Linkerd
• Kuma
• Istio
• Consul
• Maesh

Service Mesh Orchestration

These auxiliary tools help orchestrate the service mesh infrastructure:

• SuperGloo
• Kiali
• Dive

Microservice Orchestration Use Cases

When it comes to microservices orchestration use cases, Netflix’s Conductor and Uber’s Cadence orchestration engines are among the most effective.

Both unicorn companies enjoyed the advantages of a microservice architecture so much that they created their own orchestration system and eventually made them open-source.

Microservices Orchestration Netflix

Conductor by Netflix is a now open-source workflow orchestration engine that runs in the cloud. It was devised to support a distributed server environment, with visibility and traceability in mind.

The instrument helps this popular content streaming platform manage content quality control, marketing tech, studio engineering, localization of content functionality, and other use cases.

Its new features are part of its continued success. Since it became open-source, many of these features have come from members on GitHub. V2.0 of Conductor features gRPC Framework, Cassandra Persistence Layer, External Payload Storage, ES5/6 Support, and other upgrades.

Uber’s Microservices Orchestration

Uber’s Cadence has also been made publicly available on GitHub and is now an open-source service.

This fault-tolerant microservices orchestration engine helps perform asynchronous business logic. Resilience and scalability are its main assets.

Both of these SaaS companies are great examples of Sam Newman’s first reason for why you would want to opt for microservices in the first place. Neither of them can possibly afford even a minute of downtime. 

The popularity of these open-source engines among users and contributors suggests that scaling microservices will continue to be a topic of interest for decades to come. 

Takeaway

Microservices orchestration is not for everyone. Monolith is still seen as the default option by many industry leaders.

But if you fall under one of the categories described by Newman, microservices presents a variety of options for a scalable, resilient, fault-proof microservices orchestration pattern, with choreography as an alternative.

If your company is considering breaking down a monolith into smaller loosely coupled modules, or building a cloud-native application with microservices from scratch, DevPro’s software architects can help.

Reach out to our sales team or speak with one of our system integration engineers to see how we can help you thrive using this architectural pattern.