BlogAll applications evolve, and the more they're used, the more they change. User demands drive the creation of new features until, eventually, you're living with an application that is so large and sprawling that effectively monitoring it becomes daunting. The monolithic app factor we're describing has become even more predominant in the cloud era, in which growth and scale are the primary objectives for every app.
Enter microservices, an architecture that has been much-bandied-about in recent years.
Of course, the reason enterprises are so interested in microservices as a concept is because it allows IT Ops to break down the management of the monolithic app into easier-to-digest morsels. By turning a monolithic app into microservices architecture, you have a microservice for authentication, which you could scale out. Then, you might have a dozen duplicate instances of your auth layer and you'd have the front-end components broken out into their own separate microservices, which might also be replicated. You'd have maybe a web service for interacting with whatever packet database you use, and so on and so forth.
In my opinion, the greater value of microservices is that they all have to talk over the network, which means the major events in the lives of these microservices (and therefore in the life of your uber-application) are captured by wire data. Ideally, we could correlate all of the wire data we currently have within these orchestration systems to tell us about what's running inside.
Think of it this way: If you had this big app broken out into a few different modules—for example, a module for the front end responsible for rendering some web pages for a browser to look at, and another module doing authentication, and a third managing some layer between whatever database you're talking to and whatever higher-level objects you want your front end to consume—how those components work together would be highly visible in a network-oriented approach.
When your monolith is broken into microservices, you can now see the communication between the front end, auth, and the database, as well as the communication between the front end and the intermediate layer. Those are all going to be most likely communicating over standard protocols—protocols understandable not only by the endpoints, but by tools that consume wire data.
For all the value propositions trumpeted by microservices champions, the fact that microservices results in the most wire data really should be at the top of the list.
How to make all that wire data pay off? Check out my post on turning network overhead into wire data dividends!
