4 ms·
Microservices are middleware. That's they way I treat them anyway. I build them as the glue between the backend and frontend. They handle things like authentica
by stillbourne 6y ago
Microservices are middleware. That's they way I treat them anyway. I build them as the glue between the backend and frontend. They handle things like authentication, business logic, data aggregation, caching, persistence, and generally act as an api gateway. I really only ever use microservices to handle crosscutting concerns that are not directly implemented by the backend but have a frontend requirement. The only way that is harmful is if you write bad code. Bad code is always harmful.
- Closi 6y agoYou aren’t really implementing a microservices architecture in that case though. The idea of microservices is that they are self-contained, not just middleware to a monolithic backend.
- stillbourne 6y agoThat statement goes against everything I have learned about SOA and microservices. https://apifriends.com/api-management/microservices-soa/ https://apifriends.com/api-management/microservices-soa/
- Closi 6y agoThe central premise of microservices architecture is that the services manage their own data. If you have a shared data store then you are not really implementing microservices. https://docs.microsoft.com/en-us/azure/architecture/microservices/design/data-considerations https://docs.microsoft.com/en-us/azure/architecture/microser... In fact, the linked article by Martin Fowler pretty much describes it as the opposite of what you are describing: https://martinfowler.com/articles/microservices.html https://martinfowler.com/articles/microservices.html
- stillbourne 6y ago> The central premise of microservices architecture is that the services manage their own data. No, microservices can handle data from a Bounded Context, that can be its own data, external data, or aggregate data. A Bounded Context is data that is part of a specific Domain that may connect to other Domains that have edges explicitly defined. Therefore the data is decentralized, it can connect to an API that is a monolith, it can interface with messaging services, send notifications over websockets etc because its... a middleware service. From the article that you linked to debunk me: > The Guardian website is a good example of an application that was designed and built as a monolith, but has been evolving in a microservice direction. The monolith still is the core of the website, but they prefer to add new features by building microservices that use the monolith's API. This approach is particularly handy for features that are inherently temporary, such as specialized pages to handle a sporting event. Such a part of the website can quickly be put together using rapid development languages, and removed once the event is over. We've seen similar approaches at a financial institution where new services are added for a market opportunity and discarded after a few months or even weeks. And if I am reading this right, they have a monolith backend, but the frontend doesn't read directly from that it reads from some 'thing' in the middle? Oh what's that called? Its on the tip of my tongue. Ah, right, its called middleware. Because microservices are middleware. Edit: Oh look that article you linked to debunk me also has the very image I am trying to describe with words: https://martinfowler.com/articles/microservices/images/decentralised-data.png https://martinfowler.com/articles/microservices/images/decen...
- Closi 6y agoCan you describe how that image is what you are describing?