This blog post is one in a series that will give you some insight into the full day training class (Microservices Solution Architectures) I will be teaching at the ITARC Austin on October 6th, 2016
That’s a great question. Maybe you shouldn’t. I have had this debate with more than one person:
“Isn’t a microservices architecture just another iteration of SOA?”
In a way, it is. SOA is a natural offspring of distributed computing, which had been (and still is) evolving.

Service orientation purports to be a way to expose data and/or capabilities via “services”. A service can be exposed in a number of ways, however the prevailing methodology at SOA’s inception was to use SOAP/XML behind an ESB. REST had not come to fruition, and neither had JSON. Heavy canonical models and WSDLs had not yet given way to consumer contracts and API interfaces. Waterfall still ruled the SDLC world. Monolithic applications and multi-month release cycles were the norm.

Even Wikipedia, in it’s definition, talks specifically about these types of technologies.
Here are some of the differences between SOA and Microservices, in my opinion:

1. SOA architecture describes horizontal slices (ie, the Monolith). Microservices are vertical slices.

2. For better or worse, in many eyes, SOA is tied to the technologies/SDLC available at the time of it’s heyday. Microservices support polyglot and most closely related to modern delivery techniques like DevOps/Cloud First.

3. Microservices intend to be individual entities owned and managed by separate (and potentially disparate) teams.

4. SOA is a model where the services are reused. Microservices do not place any emphasis on this; in fact it’s focus on bounded context implies the opposite.

5. SOA is traditionally transaction based. Microservices focuses more on eventual consistency.

The similarities, however, cannot be ignored. They are both service based architectures. They should be a “black box” to the consumer. Contracts are a must. They are remotely accessible.

Ok, enough about SOA vs. Microservices. You can Google it and find more information than you care to read on this topic. So, why should you choose a Microservices architecture? The best reasons to do so, I believe, have to do with how the implementations (I intentionally made that plural, think about it) fit into the way we as architects create a business case and/or business value. We need to be able to deliver new and enhanced capabilities at a breakneck pace. We need to account for the consumption of those capabilities to be distributed and different. We need to scale, but do it efficiently. We need to take advantage of the skills of large teams, regardless of their location. We need to manage complexity. These needs are much better served by implementing a Microservices architecture. Yes, there are a host of new problems that need to be addressed (failure tolerance, operational changes and consistency are my top three) – and a major culture change needs to be absorbed by any adopters – however I believe being able to tell the CTO “Hey, that capability you asked us to enhance? We just pushed it to production in three hours” is an extremely powerful way to make yourself a partner with business, and not just a cost center.

Now… has anyone heard of containers?