DZone
Microservices Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Microservices Zone > Microservices vs. SOA: Let's Put an End to the Eternal Debate

Microservices vs. SOA: Let's Put an End to the Eternal Debate

Thomas Jardinet discusses the relationship between SOA and microservices, two types of architecture that are total opposites and at the same time very close.

Thomas Jardinet user avatar by
Thomas Jardinet
CORE ·
Oct. 21, 16 · Microservices Zone · Opinion
Like (22)
Save
Tweet
20.55K Views

Join the DZone community and get the full member experience.

Join For Free

Microservices and SOA: the uphill battle. In my previous article on the integration stack, we discussed all of the digital integration stacks.

Image title

We had discussed the relationship between SOA and microservices, two types of architecture that are total opposites and at the same time very close. Thus, it is common to read literature about anything and everything about this infernal couple, such as:

  • Microservices will kill SOA.

  • Microservices are SOA well done.

  • Microservices are not SOA.

  • SOA are microservices and that's all (see Uber).

  • Nothing is common between microservices and SOA.

It almost goes without saying that the truth is much more subtle and less Manichean than that. So what exactly are the differences between these two types of architecture? How are these architectures so close and so different at the same time? How can an IT architect handle all of this?

If we had to sum it up, we would say this:

  • The microservices and services-oriented architecture are two different philosophies for two different worlds, but both involve designing services.
  • SOA: share as much as possible. Design is led by the need for abstraction and reuse in order to decompartmentalize your legacies.
  • Microservices: share as little as possible. Design is governed by the concept of bounded context to manage finely its software architecture.
  • But first, let’s take a step back. Both architectures define a way to design by services, but with different goals:

    • While SOA focuses primarily on exposing a legacy application through services, microservices are about defining a software with services.

    • While SOA seeks to expose a large number of services to make them available to all, microservices are about defining small in order to be scalable.

    It is, therefore, clear that these architectures do not have to be opposites, but rather should be complementary. We must, therefore, be wary of any SOA bashing, which would only be the result of the opposition of two worlds that do not understand each other. While microservices come from the world of software development, SOA is primarily from the world of IT architects. When we take a closer look at the literature, the similarities are striking.

    For example, as we traditionally speak of enterprise architecture, the domain-driven design that governs many microservices projects is already a kind of entreprise architecture. Past a certain size of microservices teams, architects of these teams should be aware of all the IT, both technologically and functionally. Doesn't it remind you of anything?

    Then, of course, after understanding differences and similarities, we must now understand how to make these two types of architecture coexist.

    Two issues are raised by this coexistence:

    • Do they have a common denominator?

    • Will one kill the other?

    For the common denominator, the answer is simple. It is API management. Both are likely to be made available over the internet. Both gain from having a good documentation and good governance. Both gain from using an API management solution.

    Regarding the risk of killing, it is real and we must think carefully about coexistence. According to the reference book Building Microservices written by Sam Newman, microservices will themselves expose services from a legacy application. Two choices are available to handle this:

    • Define governance (but that may be complex and hard to monitor).

    • Use microservices-oriented ESB as Tibco may propose, for example (and surely other actors in the very near future).

    There's one last important point for us. Choices of solutions for both architectures must be agnostic on environments. They must be able to switch from on-premise to the cloud and vice versa. This approach is to dig, as literature on microservices agrees with using different solutions for the implementation, while at the same time limiting these choices of technologies. The problem is that market maturity is not that rich, and very few solutions correctly answer the question of deployment for SOA solutions. So it requires making the right choices in SOA and Microservices solutions.

    As we have seen, microservices and SOA are born to live together. Only time will tell how this cohabitation will happen, exactly, but it is sure that the debate is not about the relevance of each of them. In addition, we see the arrival of SOA solutions that are Microservices compliant. It is, therefore, important to prefer technical solutions that are agnostic on deployment choices in order to establish an architectural strategy aligned on the roadmaps of the relevant technical solutions.

    SOA microservice

    Opinions expressed by DZone contributors are their own.

    Popular on DZone

    • Why Is Software Integration Important for Business?
    • Challenges to Designing Data Pipelines at Scale
    • What Is Cloud-Native Architecture?
    • 11 Best Practices to Do Functional Testing on the Cloud

    Comments

    Microservices Partner Resources

    X

    ABOUT US

    • About DZone
    • Send feedback
    • Careers
    • Sitemap

    ADVERTISE

    • Advertise with DZone

    CONTRIBUTE ON DZONE

    • Article Submission Guidelines
    • MVB Program
    • Become a Contributor
    • Visit the Writers' Zone

    LEGAL

    • Terms of Service
    • Privacy Policy

    CONTACT US

    • 600 Park Offices Drive
    • Suite 300
    • Durham, NC 27709
    • support@dzone.com
    • +1 (919) 678-0300

    Let's be friends:

    DZone.com is powered by 

    AnswerHub logo