Amalgam8: An integration fabric for microservices in the cloud

Share this post:

What is Amalgam8?

Amalgam8 is a Microservice Fabric that works to reduce microservice development costs. It takes the tedium out of microservice management, enabling faster development, more control, and better resiliency of microservices without impacting existing implementation code. It allows developers to avoid the boring task of connecting the microservices, and instead lets them focus on app logic, and advanced DevOps capabilities such as systematic resiliency testing, red/black deployment, and canary testing necessary for rapid experimentations and insight.

Amalgam8 simplifies integration of polyglot microservices by decoupling service registration, discovery, and client-side load balancing from the application logic. Its key feature is a centralized command center for configuring routing of requests across an entire system of microservices based on rules. It is designed to be platform agnostic – whether your platform of choice is Kubernetes or swarm, or anything else, you can still use the benefits of Amalgam8 to run your microservices.

Amalgam8 consists of three main components: a service registry, a controller, and a side-car service proxy.

We have open sourced Amalgam8. If you’re eager to start using it or even contribute to it, you can start now at You can also catch the IBM Container session at DockerCon on Monday June 20th, 2016 at 2 p.m. PST for more information.

The Challenge: Cloud native agility without the complexity

Everyone knows that monolith applications don’t scale. As the demand increases, it is difficult to make changes without breaking other parts of the application. This is the reason why microservice-based architecture has become so popular. A microservice-based approach advocates much smaller, loosely coupled components, where each component has an independent lifecycle. This approach allows developers to make independent progress on individual components without requiring coordination.

But, as with all good things in life, this approach comes with a cost. You may end up with a system of many microservices in separate scaling pools, and the complexity simply shifts from managing an individual monolith to integrating many loosely coupled components. Developers, following this approach, are challenged with controlling communication across these microservices, automatically introducing new versions of these microservices, automatically removing dysfunctional ones, and avoiding cascading failures. Concepts such as A/B testing across a system of microservices, testing in production, and systematic resiliency testing by failure injection capture the imagination of many but are hard to implement in practice if you are not an expert.

Amalgam8 is designed to address these challenges. It can help developers follow cloud native principles and best practices without being experts in network, or spending too much time on system integration.

How is Amalgam8 different?

Clearly, there are a variety of microservice fabrics, including Kubernetes, Marathon, Swarm, Netflix, and Airbnb Smartstack. So, why do we need to invent another one?

The answer is simple: We tried all of the existing frameworks, and they all lacked programmability. There was no clean solution for client-side load balancing that was highly programmable yet did not result in excessive complexity in the infrastructure we manage. A8 hits that sweet spot. We leverage a super-scalable Nginx with the programmability of OpenResty to program the communication fabric, much like SDN but done in layer 7. We support integration with Kubernetes and Swarm to take advantage of the native registration mechanism, so that if you are a user of one of these platforms you really do not have to choose – you can use both.

Amalgam8 apps can be built on top of Kubernetes (current examples), Marathon, Swarm, IBM Container runtime, VMs, or bare metal with mix-and-match configurations. In contrast with NetflixOSS, it is also designed to support polyglot applications, not just Java.

It also allows developers additional flexibility when deploying their applications, so they can split traffic more granularly and across more than two versions of their applications. This is great for A/B testing across an entire solution, not just a single microservice.

Finally, Amalgam8 enables testing in production and resiliency testing. Systematic resiliency testing leverages the controller to inject failures and delays according to scripted failure scenarios. You can separate the traffic so that only testers see the impact of your failure injection for resiliency testing, and it can all be done in production without requiring a duplicate environment

How it works

At the heart of Amalgam8 are two multi-tenanted services:

  • Registry – A high-performance service registry that provides a centralized view of all the microservices in an application, regardless of where they are actually running.
  • Controller – A tool that monitors the Registry and provides a REST API for registering routing and other microservice control-rules, which it uses to generate and send control information to proxy servers running within the application

Applications run as tenants of these two servers. They register their services in the Registry and use the Controller to manage proxies, usually running as sidecars of the microservices.

  • Microservice instances are registered in the A8 Registry. There are several ways this may be accomplished, including using the Amalgam8 sidecar for the automatic registration, or leveraging Kubernetes native registration mechanism with an Amalgam8 adapter.
  • An Administrator specifies routing rules and filters (such as version rules and test delays) to control traffic flow between microservices.
  • An A8 Controller monitors the A8 Registry and administrator input, and then generates control information that is sent to the A8 Proxies.
  • Requests to microservices are made through an A8 Proxy (usually a client-side sidecar of another microservice).
  • The A8 Proxy forwards requests to an appropriate microservice, depending on the request path and headers and the configuration specified by the controller.

These give steps are illustrated in the following diagram:

An open and extensible solution

Because Amalgam8 is based on open source, it can be easily extended to support new platforms and runtimes. For example, the proxy engine of Amalgam8 is Nginx with the OpenResty/Lua extension that provides built-in implementations of the most common proxy control features, but can be extended. By extending the sidecar implementation to include matching Lua implementation code, contributors can add new additional rules that can be specified to change the system behavior.

Only the beginning

As IBM continues to contribute to Amalgam8, we are looking at new potential features on the horizon, including:

  • Improved seamless runtime integrations: Amalgam8 plans to release a plugin for Kubernetes post-Dockercon that will automate registration of microservices with Amalgam8. Similar plugins are possible for other runtimes, including WeaveFlux.
  • Automated Resiliency Testing: Beyond providing the ability to script resiliency testing through integration with Gremlin, Amalgam8 may be extended for a new automated resiliency tool that would provide a testing user interface.
  • Integrating Active Deploy: By adding integration, it would support fast rollback during Red/Black deployments while serving as as the basis for integrating with Canary Advisory used to automate the decision to roll forward with intelligent analytics.

If you are at DockerCon, you can attend the IBM Container session on Monday June 20th, 2016 at 2 p.m. PST. If you would like to contribute to Amalgam8 or provide feedback to the project, please check out the latest information on the website.

More Community stories
January 14, 2019

Knative Monitoring with Sysdig on IBM Cloud

Learn how to monitor your Knative Kubernetes cluster using IBM Cloud Monitoring with Sysdig.

Continue reading

January 14, 2019

Predicting the future with Monte Carlo simulations over IBM Cloud Functions

We’re going to demonstrate how IBM Cloud Functions can provide a phenomenal boost to Monte Carlo simulations, allowing them to execute in a fraction of the time as compared to a conventional execution model.

Continue reading

January 11, 2019

How-To: Running HA IBM DB2 on Kubernetes

You can easily run an HA IBM Db2 container on Kubernetes using Portworx for replication, snapshots, backups, volume resizing, and even encryption.

Continue reading