I think the big problem with the microservice movement is that it is easy to understand but difficult to implement. It reminds me of when OO was new on the block and people designed these really elaborate OO hierarchies only to have them break down over time. Then came "OO SUCKS" because there was a level of experience required to understand what level to take your modeling to.

The same thing is happening with microservices. Engineers are microservcing ALL THE THINGS at such a fine grained level that it becomes a nightmare to maintain, orchestrate and manage. Therefor "microservices suck!".

Most of the time, you can model your domain into a few key areas, say 'customers/security', 'interface' and 'processing'. That's a good 3 service start. You may never need to go beyond that. However, as your needs grow or change, you can start to refine your model based on changing business needs or scale/performance/infrastructure issues.

In my experience it's a completely logical way to design a system and is really no different than making 'libraries' of code all housed under a single master application. The only real difference is the underlying communication infrastructure.

I think of it as a "where do you want complexity?" tradeoff in this whole debate. Monolithic codebases have complex code but easy deployment and monitoring and coordination (in the sense you deploy and manage one big thing). Microservices have simple code individually but have complex deployment, monitoring and interface coordination. As my team (40 people) moved toward microservices, we spend extra effort ensuring passive changes. Then we have to update and release the multiple services that need updates to gain some new feature. In the past, what was some complex code updates is now complex packaging and intricate versioning. Less code changing...but in more places.

For several reasons, I think our move toward microservices is a good one. But in our case I have seen complexity move from code to coordination.

I think the pushback can be summarized by the fact that there are more moving parts with a microservice architecture. Harder to test, more things that can break, more coordination for deployments.

Are you referring to mashups in that the application is using external APIs? I'd say that's similar with the difference being you don't have to coordinate the deployment part. With mashups you still have the testing challenge and reliance on another system to be running that comes with a microservice architecture.

I guess I'm confused about why you would need to coordinate deployments. In my mind each microservice is completely decoupled from any other. There are a large number of tools to automate the process of testing and deployment. I think we as developers understand the need to code defensively and we understand how to build applications that have large amounts of asynchronous operations. I'm also not sure why people keep insisting on using messaging as a way to allow one microservice to communicate to another. Wouldn't exposing a RESTful interface over HTTP work well enough? The concept seems so simple and refreshing. What am I missing?

Interesting, I feel like I've seen much more literature about RESTful microservices than message oriented approaches. I've done it both ways and I'm of the opinion that RESTful services are more complicated for a couple reasons:

* All RESTful services must be up and running for application to be fully up and running * application must have all knowledge of RESTful services it calls

With messaging (and PubSub), services don't need to be running at all times and you can add as many services you'd like without the application needing to know. Applications just says "hey, something happened" and services go to work.

I agree with you, in either case, it is important to code defensively and be aware of possible request version mismatches. Deployment coordination is probably awash between the 2 approaches. I think testing is more of a challenge with message oriented too, as most integration testing tools are geared towards HTTP interactions.