Disintegrating monolithic application with Micro services vs ESB approach?

Question

I have only theoretical knowledge about ESB.

Use case:-

1. I have ecommerce like application where I can receive orders from multiple sources in different formats .
2. Once application is submitted I need to send emails to couple of systems
3. Once application is submitted, I need to submit one output file to third party system . Today its XML only but we may need to support formats down the line
4. Similarly I need to perform analytics and report preparation.

I see both ESB vs Micro-services can fit here theoretically. Both makes the application loosely coupled and scalable instead of single monolithic application. I am not sure what are the criteria's/attributes I should consider to select off the shelf ESB product(paid or open source ) over disintegrating the app into micro services?

My Understanding :- ESB can be more fit here as it makes the application more loosely coupled where one component/application will simply put the message over channel(which is nothing but java object in java based ESB apps on which other components listens). Now other components like routers/transformer/adapters/endpoints etc. will come into picture and take further action. Here Sending component just needs to know the destination address which will be single channel address.

In case of microservices this is also true, but here consumer need to know URL for each specific operation.

But now a days I have observed most of the folks are preferring micro services over ESB. I think reason can be ESB has its own learning curve/ DSL/ Paid products but micro services is nothing but service is divided in to smaller maintainable restful components. So no learning curve and no paid products.

Answer 1

I think my observation would be that either way you have to do some coding.

If you code everything yourself, the you have the cost in dev salaries and time of coding up every new thing you want to add

Off the shelf ESBs promise super configurability and drag and drop interfaces so that you can easily connect everything together and avoid this cost.

However, in practice I have found that the things you connect don't have to be very complicated to exceed the capabilities of the drag and drop interface and you are forced to fall back to coding special functions.

Soon you end up hiring a team of ESB programmers who work solely with that product, your ESB setup becomes so complex that no-one understands it anymore and basically you have just swapped one programming language for another more expensive one with vendor lock in.

You shouldn't confuse microservices with HTTP microservices though. You can hide your hand coded microservices behind all sorts of gateways. If http is a problem for your customer, why not let them email the file across? or FTP it up, or use a Message Queue to make it more event based etc.

I would add one more (controversial) observation. As a company gets bigger it becomes less important to automate some of these processes. Hiring admin staff to do things semi manually adds a level of flexibility and quick response to change that an automated interface cant compete with.

That one customer that always gets the file name wrong? The big business that cant schedule the API development because they have a 5 year tech plan? That third party software you are lumbered with that doesnt expose an API?

Once you have a few of these problem there is enough on going work to keep an admin team busy and you have better things for your dev team to do on your core product.