My laptop didn’t return from service center. RIP. I’m waiting for new dell now to get back on track with high performance 😉
When browsing the internet on occupied laptop (borrowed from my wife) I came across article by Marcus Eisele. I like Marucus’ blog and perceive him as one of the leading evangelists in Java EE. I was happy to read that Marcus also thinks that DDD Bounded Context is a good way to start with choosing what parts of monolith to include in microservice if the monolith is to be divided into microservices. Or if we are convinced to start with microservices.
From a technical, day-to-day perspective I still see the need for ESB’s. Thing like security policies, throttling can be done in API gateway. But some things like transformations or protocol translation are not supported by every API Gateway (are there any that support tranformations… – it would be against smart endpoints and dumb pipes). So the default starting point to consider a solution would be to use API Gateway on the border of integrated systems solution and ESB inside as it still offers more features. API Gateways are more specialized on external usage (e.g. provisioning policies). API gateways are also more fitted for smart endpoint and dumb pipes solutions. When using microservices and smart endpoints and dumb pipes you have to get over some possible code duplication like aggregating calls from two services in a few other serivces. So one should be aware not start writing an ESB at one point 😉
Microservices are very popular nowadays. This is a tool that must be used wisely. I like very much the In defense of a monolith article and think alike. You now the paper by Winston Royce that made waterfall model popular was actually showing downsides of this model. But the buzz took off 🙂