Consistency, Coupling, and Complexity at the Edge
Glenn Engstrand
Facilitates better, faster, cheaper product delivery from requirements to production deployment
There has been a lot of stories published over the past decade on the subject of breaking monoliths up into microservices. Not all of these stories have happy endings, however. If you break up a monolith into microservices that all have to be updated at the same time you release new features, then you didn't get to realize much of the benefits for all of that effort. Microservices that are overly dependent on each other are said to be tightly coupled.
If the internal parts of the monolith all depend on each other and then you break it up into microservices, then how can you avoid the resulting microservices from also being tightly coupled? The answer lies in how you break up that monolith and what each microservice is responsible for.
These microservices almost always publish APIs. For the longest time, API design was bespoke with little to no emphasis on consistency. This lack of consistent design made it difficult to learn and use these APIs. How would you like it if, when driving a car, you had to learn a completely different set of rules for every separate make and model? That difficulty started to be addressed with the introduction of RESTful APIs which gave us a sort of rules-of-the-road for how to call APIs no matter what they did or who provided them. Recently, a new pattern of consistent API design surfaced called GraphQL. Like REST, GraphQL rules are also consistent but not with REST. Which type of API design should you chose?
领英推荐
Another recent trend is the introduction of Backends for Frontends which are client type specific microservices that provide an orchestrating and simplifying facade layer over the more data focused microservices. Since BfFs reside between the client and the other backend services, they are typically also known as edge services. They run in the Virtual Private Cloud but only just so. Another type of edge service is known as the API gateway.
If you are interested in how REST, GraphQL, and edge services can help you realize the full benefits of breaking up your monolithic application into microservices, then you will be interested in this article that I wrote entitled Consistency, Coupling, and Complexity at the Edge. This article also covers the different layers in a typical modern enterprise application and what types of features or requirements are best implemented in which of those layers in order to lower complexity and raise feature velocity.