I really like the idea of microservice architecture, but my gripe with it is the one this post explicitly neglected to deal with. That is, deployment and service orchestration is a nightmare.

I recently experimented with a micro service architecture using Flask, but after wasting time trying to figure out how to properly deploy and orchestrate all the services (especially when running tests), I reverted to a simple backend/frontend model. It's still technically a "microservice" architecture, but the "services" are an API and the web-app. They're ~1000 lines instead of 100.

I get the sense that this kind of architecture is over optimization for a lot of projects. Martin Fowler himself describes it as an "architecture for monolithic applications." I suspect that for smaller applications, where services are not spread across multiple departments and locations, a microservice architecture is more trouble than it's worth. The deployment is simply too much of a headache (again, especially for testing). You're moving all of your maintenance work from maintaining one big service to maintaining the orchestration and deployment of dozens of small ones.

Again, I really like the idea behind this kind of architecture. But I had a lot of trouble with a solid deployment and orchestration mechanism. I want to be able to be able run tests quickly. And that doesn't just mean unit tests for each service, because necessarily when you use this architecture, integration tests become far more important.

If anyone with experience deploying microservice architectures using non-Java components wants to write a blog post on your experience, I would love to read it.