I've yet to see a big reason for this whole SOA / microservices architecture other than in 2 specific instances:

1) massive projects with lots of developers/teams that work on well-defined functionality

2) massive projects that need to have precise capacity at each service level rather than the application level

Other than these situations, monoliths (both in architecture and deployment) will likely be faster, easier, more reliable and more productive.

> A micro-services architecture does force you to be more conscientious about following best practices and automating workflows.

This 100x. With a monolith, you can get away with SSH'ing into boxes once in a while to fix or debug stuff. Micro-services must be automated.

The only good way I've found to do it is to have each service define it's logical (network) dependencies in a formal way, just like it does with it's GAV dependencies (including versions). This way the graph can be statically analyzed, cycles and transitive conflicts can be identified, deployment and roll back can be automated, the graph can be output to graphviz and visualized, and an automated tool can set up QA environments with a given vector of versions.

All that being said, the above setup only addresses about 1/2 the problems mentioned in the post.

> Only using optional fields and coding for missing fields helps us ensure our services are resilient to version mismatch.

I've seen this before and I've always been suspicious of it. So if version 1 has field r,g,b and version 2 has fields r,g,b,a and i use version 1 in a version 2 stack any data on alpha field is ignored. O.k. so you didn't get a stack trace, but is that working software?

Totally agree. Actually went in depth on this with Heroku for an article a while back.

https://blog.codeship.com/exploring-microservices-architectu...

Re Distributed Debugging / Centralized Monitoring, Logging and Alerting, this is exactly the kind of problems that our team at Takipi (www.takipi.com) tackles. It's a new way to get all of the information you need (source, stack, and state) to understand what's going on in a large distributed deployment in production - without relying on logs

Tons of good stuff in there. Best deployment post I've ever read.

undefined

Key point: don't use microservices in small teams or on v1's.