Amalgam8 is a platform that simplifies the integration of polyglot microservices to form an application and provides developers with powerful DevOps capabilities, such as canary testing, version-aware routing, red/black deployments, A/B testing, and resilience testing in production. It provides a centralized control point to manipulate the flow of requests across an entire system of microservices based on intelligent routing rules. It is designed to be platform- and provider-agnostic: whether your platform of choice is Kubernetes, Marathon, or Swarm, or you use cloud offerings such as IBM Bluemix, Amazon AWS, Google Compute Cloud, etc., you can easily leverage Amalgam8 to run your microservices.

Cloud native agility without the complexity

The fact is, monolithic applications don’t scale. As demand increases, it’s difficult to make changes without breaking other parts of the application. And that’s why microservice-based architecture has become so popular. The microservice-based approach advocates using small 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 might 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 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. That’s where Amlagam8 comes in. It’s designed to help developers follow cloud native principles and best practices without being an expert in networks or spending too much time on system integration.

What makes Amalgam8 different?

There are several technologies out there to build microservice applications. You can leverage service discovery and load balancing features offered by container runtimes such as Kubernetes, Docker Swarm (1.12), and Marathon, or you can use integration fabrics like Netflix OSS, AirBnB smartstack, Vamp.io, etc. So why do we need to invent another one? The answer is simple. We tried all the solutions for both our internal applications and customer-facing applications. Their focus was simply to facilitate integration of microservices. They didn’t have first-class support for the main reason one moves to microservice architecture: agility. While those solutions simplified integration of microservices, they left us on our own when it came to doing actual DevOps activities like canary deployments, simple A/B testing based on request-level attributes, failure-recovery testing, and so on. Phased roll-outs using red/black deployments were easy as long as the microservice dependency graph was one or two levels deep. But the moment we got down to managing real-life complex applications consisting of a long chain of dependent microservices, or even simultaneously managing more than two versions of microservices, things started getting tricky. Ugly scripts and hacks reared their head. Essentially, all of these solutions lack the ability to allow us, the developers, to dynamically control and manipulate how requests are routed across microservices. For example, Kubernetes, Marathon, and Docker Swarm push the request load-balancing down into the kernel level, using IP tables to manipulate routing. This is exactly the approach that the Software Defined Networking industry has tried to avoid. There are two primary disadvantages to the IP-tables-based approach:
  • The mesh networking approach used by these solutions results in a large number of IP table rules when you have hundreds or thousands of instances of microservices. IP table rule management gets extremely complex, and any errors in updating the IP table rules destabilize the entire host and the microservices in that host.
  • The use of IP tables precludes the ability to inspect the request traffic at application layer (for example, HTTP layer) and make intelligent routing decisions based on the request content. Since HTTP is the most commonly used communication protocol in typical microservice applications, the inability to do content-aware routing forces these applications to write an additional layer of tools on top of these frameworks to support activities such as canary testing, dark launches, and version-aware routing across microservices.
HAProxy-based solutions (for example, SmartStack) provide some level of flexibility but when requirements are complex, such as when you need to embed a lot of intelligence while handling HTTP requests, HAProxy’s configuration files can quickly become a nightmare. In essence, 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. Amalgam8 hits that sweet spot. It leverages a super scalable Nginx with the programmability of OpenResty. Arbitrarily complex Lua code can be written to decide how to handle requests of various types, with minimal loss of performance. What we end up with is a programmable communication fabric much like an SDN, except its all done at Layer-7.
Amalgam8 architecture: A Multi-tenant control and data plane
It is important to understand that Amalgam8 is not a replacement for container runtimes. It complements them. Amalgam8 runs on Kubernetes, Marathon, and Swarm while taking advantage of the native service registration mechanism that these runtimes offer. 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, Marathon, Swarm, IBM Container runtime, VMs, or bare metal with mix-and-match configurations. In contrast with NetflixOSS, it’s designed to support polyglot applications, not just Java.

How Amalgam8 works

Amalgam8 consists of three main components: a service registry, a controller, and a programmable sidecar proxy (nginx+openresty) that runs alongside the application.
How Amalgam8 microservice fabric works
Applications are automatically registered with the service registry. The user provides high-level rules that dictate request routing between microservices. The controller breaks these high-level rules into appropriate low-level rules and programs the sidecars in the microservices. The sidecars then execute these rules while processing outbound requests. For full details on how the components work together, visit the Amalgam8 website.

Version-aware routing

The version-aware routing capabilities of Amalgam8 enable developers to granularly split traffic across two or more versions of their microservices. Amalgam8’s version-aware routing is applicable for both edge and mid-tier microservices in the application.
Amalgam8: Version-aware routing across microservices
Amalgam8 comes with a set of pre-built filters for routing traffic to a specific version. Thanks to the flexibility of Lua, you can easily write your own filters and push them down to all the sidecars using the Amalgam8 controller. This core capability allows you to do a lot of cool stuff, like A/B testing across two or more versions of a microservice, sending a percentage of user traffic to a specific version of a microservice, canary deployments, dark launches, red/black deployments, and so on.

Systematic resiliency testing

Amalgam8 enables testing in production. It leverages the Gremlin resilience testing framework to provide you with the ability to conduct systematic resiliency testing of your entire application. Gremlin leverages the controller’s fault injection API to inject failures such as delays or errors like HTTP 503 between microservice API calls. Gremlin creates and executes reproducible failure scenarios using Amalgam8’s APIs. Failure injection is just one half of the equation. When a logging framework is integrated with Amalgam8, Gremlin enables you to run assertions on the recovery behavior of microservices by automatically analyzing the request logs emitted by the sidecars during fault injection.

Amalgam8 at DockerCon 2016

We were happy to showcase Amalgam8 DockerCon 2016. We spoke with a lot of developers and other platform providers, and the audience really appreciated the programmable nature of Amalgam8. Many were able to readily relate Amalgam8’s routing capabilities to potential use cases in current their deployments. We also received great feedback on what additional features are immediately needed, such as support for ACLs and integration with different service registry backends such as Consul and Etcd. In addition to ongoing work to incorporate these feature requests, we are working towards publishing example deployments of Amalgam8 on various public cloud platforms available in the market today. If you would like to contribute to Amalgam8, or if you’re interested in providing feedback for the project, please check us out on the Amalgam8 website! Credits: This post was a team effort: Frank Budinsky, Etai Lev-Ran, and Tamar Eilam from IBM Research each contributed to the content. Save

1 comment on"Amalgam8: Simplifying microservice orchestration and integration"

  1. […] Amalgam8: Simplifying microservice orchestration and integration (blog) […]

Join The Discussion

Your email address will not be published. Required fields are marked *