Cloud native agility without the complexityThe 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.