I think of microservices as an implementation of SOA. Guess that is not that helpful, but it's almost like a battle tested guide on what the best way of implementing SOA is via trial and error. If you look at how startups are using microservices today, you will find almost a blueprint or common theme coming out. Use an API, embedded metrics in the microservice, how to do monitoring, tracing, use CI/CD, app+dependancy packaging, operations tools, etc.
FWIW, it seems early SOA placed a lot of emphasis on the bus and the middleware[1], with the problem being solved having more to do with enterprise governance[2], not one of software architecture. It seems to me, true scotsman and all, that modern micro services architecture has emerged from a first-order attempt to solve actual problems around both scaling vertically and collaborating on large systems in large organisations.
2: "OMG how do we keep track of all the stuff running on all the servers? Multiple versions, multiple languages, multiple OSs? This sounds really scary, no, leaving it to the nerds is not an option, think of the BUS COUNT!" (caricature).
We use NServiceBus, and Microservices for a lot of stuff and its really helped development. It handles retries(for network unreliability), transactions, and monitoring for us. Generally most of the issues of distributed systems.
Thanks for the info, very much appreciated. My job is basically to import best practices from good tech companies into an ancient silo'ed giant dev shop. Any idea where I should start for finding best practices with microservices?
I've read the Oreilly book, but I'm not seeing any significant difference from how we run things. Is this eXP vs. Agile all over again, or do I need this?
If you are not hitting one of the -- 1) slow rate of deployed changes, 2) app performance is sluggish, or 3) freedom to choose language<->problem issues, 4) poor resource utilization across a fleet of boxes, then I don't see the rush to change anything. In that one of these issues would need to justify the investment to make the switch. Normally people are looking for a solution to one of these really broken/festering issues and they see microservices as a solution. For example, maybe your code deploys are super slow due to developer contention and a competitor is going to kill you -- maybe it's worth a look. Or, maybe you are blowing 100k / month on cloud servers, that if only you could get better utilization, you could save all that money. You get the idea.
Here are some pretty good war stories told by people in the trenches. Highly suggest watching these talks by TellApart [1] & Wunderlist [2]. Both talk about the pain points of why they moved to microservices. FYI - Youtube 2x speed is your friend ;)
