There is a lot of confusion about what microservices are, what service oriented architectures are, and how they relate to each other. Everyone from Martin Fowler to Steve Jones is weighing in on the subject.

What are Microservices?

Microservices are an architectural design pattern. In a microservice architecture, business logic is decomposed into a collection of small, loosely coupled, distributed components that collectively form the larger application. Each component is called a microservice and each microservice performs a single task or function in the collective whole. Each microservice may be called by one or more of the other microservices to perform specific tasks needed by the larger application; this provides a uniform way of handling things like search or displaying images or other tasks that might be needed multiple times and limits the need to develop or maintain multiple versions of the same bit of functionality in different places within the application.

Using a microservice architecture also provides a mechanism to increase the productivity of new developers and decrease the time to market of new features. Each microservice has a limited code base and associated toolset; developers no longer need to understand gigantic, complex systems before becoming productive, they only need to understand the subset pertinent to the microservice they work on. Microservices can be developed quickly because they can use the languages and toolsets best suited to the task at hand without worrying about what existing portions of the application already uses or whether other developers in the larger system know those languages and tools.

To fully take advantage of the speed to market possible from a small team, that team needs autonomy; they have to be able to make decisions quickly and without much oversight. To support this, working teams should include all of the relevant people from product management through release and operations. Because microservice components are loosely coupled and communicate via APIs, a high level of autonomy for most decisions does not affect the function of the application as a whole. As long as the microservice publishes its APIs and performs the function it advertises within those APIs, the system as a whole functions well.

Because there are so many independent components in a microservices architecture, using modern DevOps on an elastic network like a public or private cloud becomes important to ensure smooth operations of the system as a whole in most cases. In particular, things like automated monitoring of health and load in conjunction with automated deployment of additional instances (and to a lesser extend drawdown of underused instances) become vital in many cases.

What is SOA?

SOA, or service-oriented architecture, is a mechanism for integrating multiple larger components, typically applications, together so they form an interoperable suite. Each component typically performs a complete piece of business logic from start to finish, usually involving a variety of specific tasks and functions needed to complete an entire larger action. Components are typically loosely coupled but this is not a requirement of the SOA architecture patterns.

Although not a strict requirement, SOA typically uses some type of centralized governance – a review board, a head architect or architecture council, – to tightly define what each component of the system should do and how it should do it. The same type of functionality may be defined and written separately in multiple components if needed within each and the languages and toolsets used by components may or may not be centrally determined and uniform. SOA can use any type of SDLC, organizational structure, or development model consistent with this type of governance; agile, waterfall, kanban, or some combination are all possible without violating SOA tenets.

Further, while modern DevOps and cloud deployment are certainly useful for SOA, they are not essential requirements given the smaller number of components in use within this type of system. However, some of the larger components in these systems may be sufficiently complex that automation is at best difficult, and completely impractical at worst.

For example, one criteria for an automated deployment might be passing a suite of automated tests at 100%. This ensures that existing functionality still works in the new version (there are no regressions) and that new functionality works as expected. As more and more features interact, the likelihood of accidentally breaking some facet of an existing feature with seemingly unrelated development work increases.

Further, some of the tests might be brittle and fail a small percentage of the time because of environmental or network issues. When there are a hundred tests, having 5% of tests randomly fail 1% of the time isn’t a big impediment to regular releases. When there are many thousands of tests, the same percentages have a much bigger impact, causing at least one random failure a significant portion of the time. Thus, even if nothing is actually wrong with the release candidate it will often fail the criteria for deployment.

Direct Comparison – Building a Shopping Cart

Let’s look at an online shopping site. This site would have a handful of different features – a product catalog, user accounts, and shopping carts to name a few.

A development organization using SOA would typically break the shopping site up into major sets of business logic and develop each as a separate application to be integrated together.

For example, the entire shopping cart and all of its functionality would be one application developed by a large group of people who all need to know how the entire cart works in order to modify it. Within that application is code to do things like display items, add and remove items from the cart, check inventory, handle shipping options, handle tax calculation, handle billing, update the display when something changes, and email the final order details to the user (among other things). The code used to display products within the shopping cart is within the shopping cart application and may be completely different from the code used to display product items within a browse catalog view, resulting in two sets of similar but different code to maintain and also possibly some inconsistencies in the larger application UX.

An organization using a microservices architecture would take that shopping cart and break it up into smaller task-oriented services. Instead of a shopping cart application there might be a tax calculation service, an add/remove item service, a shipping service, a billing service, and a compose final order service. The shopping cart functionality may also use some common services used in a multitude of places within the shopping application such as a display item service, a display product image service, a check inventory service, a user payment preferences service, and an email service – there is no boundary around “shopping cart” vs “product catalog” vs “user account” and common code is encapsulated into various services and used by all of those features as needed.


At some point your company decides to license product images from a central licensing organization. The source of images must be changed and statistics around views must be added to the larger shopping application. In the SOA architecture, both the product catalog application and the shopping cart application must be independently updated to reflect these changes.

Both applications would then need to be retested to ensure the changes didn’t affect any other functionality and then redeployed, a process that may be delayed further (depending on the development processes in place) if other features within either or both applications are in the process of being modified and are not in a releasable state. Once redeployed, it might become apparent that the new mechanism for serving images is slower than the old one and is now a bottleneck.

The slowdown is found by customer complaints and reported to management. Someone makes the decision to solve it by deploying additional instances of the entire product catalog application and of the shopping cart to handle the extra load (this could be automated if proper monitoring and deployment rules are in place). The whole process requires great deal of additional processing power and storage space since the entire applications would need to be scaled up, including a lot of features that were probably functioning just fine without the additional deployments.

In the microservices world, only one change would be necessary – an update to the display product image service. This service can be quickly modified, tested, and deployed on its own without affecting any other portion of the larger system. Further, when the bottleneck is discovered (most likely through automated monitoring), additional instances of this service can be deployed (probably automatically) without deploying more instances of the rest of the services used by the product catalog features or the shopping cart services, limiting the additional resources needed to support the increased deployment.

All of the above assumes you’re trying to launch a larger online store selling a variety of products to a variety of people in a variety of locations. Suppose you just want to sell just one product just to customers within the continental United States using UPS as your only shipper. A lot of the infrastructure and complexity of a real online store is unnecessary.

You still need to track user information, provide a shopping cart and checkout functionality, and have a page with product information, images, and perhaps even a few reviews or testimonials but each of these requires a lot less functionality than their counterparts in a more diverse online store. Gone is the need to categorize products, the need to figure out different shipping options, the need to handle adding and removing skews from the system, and all sorts of other features that a full multi-product store needs.

In this case, using SOA with a shopping cart, user account, and product display components integrated into the rest of your website might make more sense than using a microservices architecture with more granular components as defined above. Not only is each larger component reduced to a manageable level of complexity in this simpler set up, but the number of developers and other staff needed to implement this type of site is small enough to invalidate the need to scale via small, independent teams.

Similar But Different

So microservices and SOA have a lot in common. They are both systems that typically contain sets of loosely coupled distributed components. However, the intention behind the two architectures is very different: SOA is trying to integrate applications and typically uses a central governance model to ensure that applications can interoperate. Microservices is trying to deploy new features and scale development organizations quickly and efficiently. It focuses on decentralization of governance, code reuse, and automation to do this.

To summarize:

Which one is right for your organization? That’s up to you to decide.

On January 27, Datawire will host the Microservices Practitioner Livestream, bringing leading early adopters (developers, architects, and practitioners) together to share their lessons learned and best practices. Speakers include Uber, Yelp, Netflix, Hubspot and more. You can register at

Microservices Versus SOA in Practice

About The Author
- In addition to extensive experience as a technical writer focused on development tools, databases, and APIs, Janice has worked as a freelance reporter, editor, and reviewer with contributions to a variety of technology websites. She began her career as a software engineer modeling acoustic sensors (microphones) then moved on to work as a technical writer for companies like Intersystems, Lucent, Macromedia (now Adobe), Art Technology Group (now Oracle), and Nokia. She was the news editor at and wrote or edited content for a variety of other PDA-related websites including the Tip of the Day, the FAQ, and the Gadgeteer.


  • Willem

    I don’t agree with your observations. Service-orientation, as taught by Thomas Erl, has always focused on the delivery of individually shaped and reusable services, not specific to any application or process. Services respect a set of design principles: loose coupling and autonomy are one of the major principles to design for!

    Service-orientation focuses on governance to bring consistency to each service interface or contract. It doesn’t make any claims on how the service must be implemented, leaving great flexibility to the project team to choose the appropriate technologies and data stores! The standardized contract facilitates the composition of heterogeneous services, because enterprise-wide some standards exist on protocols, data format etc. Microservices equally benefit from this kind of IT Governance, if not you’ll end up with a jungle of communication protocols that need complex broker products the communicate.

    Service-orientation also focuses on governance to centralize business functionality into services and avoid duplication and overlap between services. In that sense it is identical to the microservices approach and in a broader context to the concept of bounded context from DDD.

    In your shopping cart example you compare two solutions with a completely different granularity. The SOA approach could be equally fine-grained as the microservice solution. Plus, I doubt that the business decomposition in the microservices solution is the best possible one, because business logic is scattered across a lot of different services, violating the bounded context principle and the fact that services should be autonomous and self-contained.

  • BobK

    Nice article and nice to read. I agree with Willem though. This is what would happen if SAO went bad. Microservices, as far as I can see software wise, are just a new term for SAO and how it should be. Each service only doing stuff on it’s domain, such as product or user CRUD or sending emails or something and then using “microservice patterns” so the services communicate where needed.

  • L

    A nice article. I agree with most of what you say and the above comments.

    The only real flaw I found with the SOA example was that you only show how the larger application would be viewed as a combination of smaller applications, but didn’t demonstrate the services that would be exposed on top of those applications, nor how service layering can be applied to abstract away the smaller applications, so to protect the larger application from the smaller applications.

    The simple fact is that the principles of microservice architecture are not new and those who have been doing SOA well will already be satisfying many of those core principles. However, it doesn’t matter that a new term (microservices) has come along. All this will do is refresh the core, pure principles of SOA and help many to think properly about how they design their solutions.

    If you think microservices is just SOA done right then great – you are not wrong. It just doesn’t really matter what we’re calling it. Comparisons that try to make a distinction are only going to highlight the flaws of many attempted SOA solutions.

    My personal view is that a SOA solution is a cross application, enterprise solution that exposes and integrates the functionality of one or more applications for the purpose of providing some or all of the functionality of another application or system. Microservice solutions define an application’s functionality as services so to allow us to leverage multiple technologies easily within a single application and to aid modularity and replaceability.

    In short:
    When we talk about SOA, we mean SOA at the enterprise, cross-application, integration focused level.
    When we talk about microservices, we mean SOA at the application level.

  • Cyriac Peter

    The author has shown as a key difference between SOA and Microservice i.e. the ability to scale individual services. While I agree with some of Willem’s comments, I have not seen above ability to scale at an individual service level as a requirement in SOA implementations. While this is a good thing, I am also wondering what will happen if we “overdo microservices”. Too many fine grained services lacking a coherent view? Shouldn’t loose coupling and flexibility be balanced with coherence and modularity? Would like to see author’s and others’ views on this.

  • Tom

    In response to some comments and observations here:

    As far as I’m concerned there’s really no difference. Someone stuck “micro” on there simply to be more specific. Both SOA and mSOA are architecture strategies to accomplish the same goals…But SOA is nothing new nor is it limited to web/server applications. I think the mSOA helps clue people in to this new application of SOA specifically for web/server applications in the cloud. That’s all. Just a simple little distinction, but in practice, it’s the same thing. Your development approach is exactly the same. Your tools and deployment locations may be different, but the architecture and benefits are the same.

    The key difference is not in the ability to scale individual services. You can scale everything listed in this article. Remember, we’ve scaled monolithic MVC apps for years. You could also have a “micro” data store service that doesn’t scale at all. Scaling is not better because you put “micro” in front of SOA or reduced the functionality down to a single function. There’s many factors that go into creating something that can scale and a SOA isn’t even required for scale. By defining a more finite service you may have a more cost effective way to scale – I can buy that – but it doesn’t mean one scales “better” than another. It doesn’t even mean you wrote a service that is capable of scaling for that matter. Scale is not defined by SOA or mSOA.

  • Janice Karin

    There are a lot of different thoughts around microservices and SOA and whether they are fundamentally the same or fundamentally different things. Although many people have very passionate views on this, I think a reasonable case could be made for a variety of opinions on the matter. People who say microservices are just SOA on a smaller scale are not fundamentally wrong in my judgement, but I do think it’s a matter of degree and also whether you look at things conceptually or in practice. I suspect the lines may be more blurred in specific implementations (where people tend to take the bits of a concept or method that work for them and adopt it to their own needs) than they are conceptually. Also key in my mind is the organizational goal; people are adopting microservices to speed time to market and scale their development teams quickly while SOA is aimed primarily at getting integrations right. Both are fine goals, but they are different and having different goals can significantly change the way things get implemented even if the broad strokes are similar.

  • Robert Cornwell

    I believe there are difference not necessarily in the Architectural framework but more in the context in which they are used. If you talk with Google, Amazon, or Microsoft it is a same approach to SOA but on a much larger scale. Meaning Hyperscalability, Development teams in completely different organizations contributing to the overall service offering (In the case of Google) and the requirement to have a mindset of supporting hyper-scalability while minimizing resources required for scaling fast. Governance in this case also has to be Loosely coupled as centralized governance will slow down innovation from the different organizations delivering different service features. The SOA was designed more from an IT perspective for Enterprise Class applications but was not designed with the idea of Hyperscalability and the massive services being offered by the likes of Google and Amazon. Talk to Netflix about this, I grew up in the Enterprise SOA world but now I’m in the Internet World the MSA makes more since to me. Hope that makes since…

  • Scott

    When we’re talking about applications, we’re not talking about services. You can tell because the word “application” is used rather than the word “service”. Applications are not services. That’s fundamental. Applications are the result of the composition of services. They are an “application of services”; the result of “applying” services.

    What _is_ described above is EAI, ie: Enterprise Application Integration. SOA is the other end of the architectural spectrum. EAI is what you get when you fail to design boundaries properly, and presume that services, like applications, are allowed to respond to queries (and thus countermand one of the four basic tenets of service architecture).

    There is no real difference between SOA (the one that didn’t devolve into what ended up being called “vendor SOA”) and Microservices. Microservices derives from the kind of SOA that was not undermined by vendors. Consequently, SOA done poorly has little difference from Microservices done poorly.

    The only way to describe Microservices as something divergent from its SOA progenitor is to presume something about SOA that is inconsistent with SOA itself, and then describe that inconsistency. Given that SOA was already muddied in its own time, it’s not surprising that misconceptions are still bouncing around the ecosystem – especially now that vendors are getting involved.

    SOA is absolutely not concerned with “getting integrations right”. Again, that’s an EAI concern, and EAI and SOA are not reconcilable.

    SOA is about designing boundaries and preserving encapsulation (which is how “service autonomy” is achieved). Once we’re talking about applications though, we’re past the point of no return for services and the only recourse left is often EAI (short of a reengineering effort).

    There is indeed a lot of misunderstanding of SOA and Microservices in the wild. There has been for years. That may change, but it’s going to require a lot more experience and study than developers, architects, and the like have been willing to invest in the subject.

    The point of the “Microservices” coinage is to come up with a term that can differentiate from the ambiguity that SOA became. In a few years, the same might be said of Microservices. It depends on whether professionals get informed beyond the usual level about this topic. If not, the ambiguities, misconceptions, and popular myths will continue to be perpetuated.

    The most important thing is learning as fast as possible why veterans of both of these terminological skirmishes, as well as services projects are more apt to say that SOA and Microservices are the same thing – not just in degree, but in every way possible except for some minor updates that are to be expected with the passage of time.

  • privettoli

    You compare your views of Microservices and SOA, not the architectures in their own description. This is why this topic was just a waste of time. Don’t recommend to read.

  • Rami

    Based on all the comments, it looks to me that SOA and mSOA approaches / technologies are meant to be combined and work together. You would use mSOA if you really benefit from granularity. I agree that having just a bunch of micro-services w/o any ‘main’ program to tell a full story, is hard to imagine working fine.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>