As a continuation from my previous blog entry of comparing Istio to Ant-Man, I’d like to continue with the superhero theme to provide a summary view of all the components of a microservice architecture, by comparing it to The Avengers!
Avengers Assemble: every microservice architecture needs these heroes!
Avengers Assemble!
IronMan is Kubernetes. Iron Man’s alter ego is the billionaire industrialist and genius inventor Tony Stark. Kubernetes origins are from billionaire and genius inventors Google! Kubernetes aims to provide a “platform for automating deployment, scaling, and operations of application containers across clusters of hosts.” Kubernetes is massively scalable, allowing Google to run billions of containers a week. Also, Kubernetes can scale without increasing your ops team. It can fly anywhere, in that it can run on-premises, hybrid, or in public cloud infrastructure. It can self-heal in the same way that Tony Stark replaces and upgrades his iron suit.
Tony Stark summons a squad of Iron Men in Iron Man 3, just like Kubernetes can run billions of application containers (source: Iron Man 3)
The Hulk is the Simian Army. Sure, the Hulk is a force for good, but when David Banner goes green, then chaos is unleashed against the enemy. The Simian Army consists of a set of services, the first of which was Chaos Monkey, which generate various kinds of failures and abnormal conditions in your environment. The chaos that they generate allows for your architecture to be tested for its ability to survive the failures. Adopting the principles of Chaos Engineering will mean that your microservices architecture will be more robust, as it’s designed and tested for failure, before it happens in production. Go ahead and let “Hulk Smash!” those services and see what happens!
Thor is your Tech Ops team. Thor is the Asgardian god of thunder; your TechOps team are gods too. They are a critical to the support and SLA of your production environment. TechOps probably know more about the non-functional requirements of your service architecture than any one developer working on a single service. They stand guard and monitor the environment to ensure that it’s up and running. And just like the Thor movies, it takes some attempts before you hit upon a success like “Thor: Ragnarok”. The interaction with your techops team doesn’t happen overnight and it takes effort and collaboration. But, when you get it right you then hit box office gold and your services are running in production with the appropriate SLA, even when Hulk is running amok.
Black Widow (Natasha Romanova) is the spy. You must have spying and monitoring in place in your microservice architecture. As has been previously described, there are so many things that can go wrong in your architecture that having a spy on your side who can report on what is happening, or not happening, is invaluable to keeping your production running. A spy should not just passively monitor, but should interact and interrogate the services. For example, interrogating the status of a service should be more comprehensive than just executing “ps aux | grep -i myservice”. Instead, proactive health checks should be performed against an well-known endpoint, such as “/health”, that performs various checks on system (mem, disk space), datastore (database connection pool), dependent microservices (response status from other services) etc. All of these combined give the actual status of the service.
Hawkeye – deliver a message where it is intended to go
Hawkeye is guaranteed delivery. When Hawkeye fires an arrow they always fly straight and true and will always hit their intended target. In a microservice architecture, you need to make sure that the messages between services will hit their intended target. With services that interact over HTTP or gRPC (i.e. remote procedure pattern) this can be achieved by introducing the microgateway, and thereby benefiting from the traffic management capabilities that the service mesh provides you. Another approach would be to implement a messaging-based system architecture, backed by Kafka or RabbitMQ. When using this architecture for your interservice communications, you gain reliability, availability and quality of service, which is provided directly by the messaging backbone. Many enterprises have both concepts in play simultaneously, with the remote procedure approach having wider adoption, due to tooling around swagger and the like. But, the messaging approach can be useful for long running services and asynchronous processing. Both approaches will help you hit the mark, just like Hawkeye’s arrow.
Captain America is the Edge Gateway. The Edge Gateway sits in the DMZ and acts as a shield to protect your organization from any malicious traffic. The Edge Gateway provides the ability that only trusted messages (authentication and authorization) can pass through. It will provide API firewalling to protect against threats (i.e. OWASP top 10). The Gateway provides mediation in terms of protocol, message and security content, which allows for the Edge Gateway to provide the routing (L4/L7) that would typically be found in application load balancers. Finally, since the Edge Gateway controls all inbound traffic, everything can be logged, which allows for visibility, reporting and analytics services to be applied.
There is another Marvel hero that we need to add to our add to our assembly, namely Ant-Man. As I described in my last post, Ant-Man is the MicroGateway. If we have Captain America governing our North-South traffic, then we have have Ant-Man for our East-West traffic.
Ant-Man for East-West traffic and Captain America for North-South
As you’d expect from a microservices architecture, it’s not one system that rules them all, but rather many systems that collaborate to comprise the whole. Just like the Avengers have different superheros making up the team, so too does the microservice architecture. Each hero/service has a distinct role and collectively they can battle evil and keep the world safe.
For more microgateway info, read the other blogs in this series: