Just to be clear, I’m going to be talking about mistakes you can make with a microgateway, not micro mistakes you can make with a gateway. Yes, that’s a bit pedantic, but it’s a distinction worth noting.
In a few weeks, I’ll be sitting down with Randy Heffner from Forrester Research for a webinar to chat about microservices and microgateways. Randy is someone I have a ton of respect for, but that doesn’t mean I always agree with everything he says, and the converse of that is certainly also true. We’re going to be talking about 3 mistakes people make with microservices, and I’ll let the cat out of the bag a bit here. I think one of the biggest mistakes you can make with microservices is to try and use a microgateway in the first place. There are plenty of challenges facing companies who are building and deploying applications as sets of microservices, and there are also plenty of excellent emerging solutions for these challenges.
One of the fundamental principles described by James Lewis and Martin Fowler in their seminal blog defining microservices is that of Smart Endpoint, Dumb Pipes. The idea is that microservices should be independent, self-aware, and able to communicate with each other without having to use an intermediary. This has given rise to mesh management solutions that use a sidecar pattern like Istio with Envoy. Istio provides a control plane for microservices applications, while Envoy co-deploys with microservice instances themselves in a sidecar pattern intercepting inbound and outbound traffic to perform simple security, routing, and monitoring tasks. We could certainly argue that Envoy is a microgateway, but it’s more of what would have been called an agent in the old days of web services management.
This does rather beg the question of what role an API Management platform can play in a microservices application. The answer is that that most modern applications are surfaced via one or more APIs. These APIs should be properly protected by an API Gateway, and probably published to a developer community via an API Developer Portal. Over time, I believe we’ll see strong integrations between API Platforms and the mesh management solutions so that the infrastructure groups can ensure the end to end security and reliability of their applications, and can effectively troubleshoot issues at all layers.
I for one am looking forward to discussing the future with Randy. Hopefully, we don’t agree on too much or it won’t be fun. I somehow doubt that will be a problem. Hope to see you all on October 25th.