BlogBuilding and scaling a web app often requires an architectural rethink. What might start as a simple prototype built with Ruby on Rails and MySQL can, after enough feature requests and active users, start showing signs of stress. After enough appearances of the veritable fail whale comes a feeling that changes must be made.
Microservices offers an answer to these scaling challenges by contributing this idea: stop bundling up features and responsibilities into a single monolithic app. Instead, dismember your behemoth app into its constituent body parts. Why? One reason, to continue with the anatomical metaphor, is that when you need your app to run faster, all you need to do is attach an additional leg or two. Or ten thousand. This is called scaling out, by the way. (But make sure to divide up your behemoth along natural service boundaries, or you might end up with split-brain syndrome.)
Kidding aside, despite helping with grisly problems of scale, there is plenty of room for doubt in microservices as a concept. In an article titled, "In the land of microservices, the network is the king(maker)," Sudip Chakrabarti writes:
Microservices, however, aren't free lunch. Part of the "microservices tax" can be chalked up to the operational complexity of a distributed system: more scripts and configurations to deploy, larger overall memory footprint because of replicated libraries and data stores across services, and potential performance degradation because of API calls going over the network.
As Chakrabarti notes, one tax imposed is that microservices must talk over the network. This can actually be wonderful—which we'll get to in a moment—if we can make that reality work in our favor. If we don't find a way to leverage this increased communication, if we view it purely as overhead and not an opportunity, then we'll end up having to pay that tax.
For example, let's say a team responsible for a certain microservice wants to deploy an update to how a specific API works. The team communicates the change and does everything in their power to ensure all dependent microservices will be compatible with their update. But after deployment, problems crop up, and it turns out one dependency was missed.
This kind of scenario can be much easier to avoid with a monolith, where compatibility problems are often immediately manifest. Unfortunately with microservices, compatibility problems might not be noticed until some time after a deployment, especially since any given microservices might not be written in a way to surface these kinds of errors. However, if you understand the protocols spoken on networks, dealing with a microservices architecture becomes more tractable.
The major events in the lives of these microservices are the things they're saying over the network, and if what they're saying is on the network, wire data analytics vendors (like ExtraHop, naturally) can see it. That's why microservices needing to talk on the network is so great: a compatibility problem like the one above might manifest itself as an HTTP 500 status code, which you can both see and alert on via wire data analytics. Perhaps a caching layer starts experiencing an anomalously high miss rate, which is a phenomenon you would now be able to detect, since the evidence is on the wire. Troubleshooting benefits aside, you can get a better sense of the performance of the entire system by watching the wire, including insights that might've been hard to come by with a monolith.
In summary, a microservices architecture actually results in the potential for increased visibility compared to a monolith, by leveraging the fact that you can now see and understand all the communication between components. In so doing, you can gain a profound view into complex systems, without having to instrument any code.
That's how to turn what would've been a microservices tax into a wire data dividend.
