Why Should I Choose a Microservices Architecture?

Home/Microservices, SOA, Software, Software Architecture/Why Should I Choose a Microservices Architecture?

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?

 

Tags: |

About the Author:

Phil Helm is a Solution Architect in Raleigh, NC. He is also the president of Iasa Raleigh, a Triangle-based IT architecture chapter of Iasa Global. Phil has over 18 years of experience working in software. He is currently solutioning a microservices architecture. Phil is a Sun certified Java programmer, an Iasa and SEI certified architect and holds both a Bachelors and a Masters in Computer Science.

2 Comments

  1. Maciej August 9, 2016 at 8:45 am - Reply

    I cannot agree with sticking SOA concept to technology solution. SOA is architectonic concept of logical architecture layer. It can be implemented in many ways. One of possible solution is using ESB but it is not required. You can build SOA architecture without using integration platform component.
    Putting technology to SOA concept was forced by vendors to give them better selling possibilities for their products.
    Microservices are one of way for implementing SOA concept (with some limitation).

    • Phil helm August 17, 2016 at 1:54 pm - Reply

      Thanks for the response Maciej, there is certainly no direct connection between the concepts of SOA and the specific technology implementations. I completely agree, SOA was bastardized to a degree by vendors and now it has left a bad taste in the mouths of many without truly understanding, as you smartly point out, microservices can be considered an implementation of SOA.

Leave A Comment