About Petri Kainulainen

Petri is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

The Microservice Architecture Sounds Like Service-Oriented Architecture

I didn’t understand the service-oriented architecture. I thought that it was just one of those highly theoretical and very impractical software architecture patterns.

In other words, I considered it to be an architecture fanatics’ wet dream.

Then I read an article titled Microservices by Martin Fowler, and the service-oriented architecture started suddenly make sense to me.

What Changed My Mind?

Martin fowler specifies the microservice architecture as follows:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare mininum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

After I read that, something clicked inside my head. I realized that the microservice architecture sounds a lot like the service-oriented architecture which is specified as follows:

Service-oriented architecture (SOA) is a software design and software architecture design pattern based on discrete pieces of software providing application functionality as services to other applications. This is known as service-orientation. It is independent of any vendor, product or technology.

A service is a self-contained unit of functionality, such as retrieving an online bank statement. Services can be combined by other software applications to provide the complete functionality of a large software application.

Why didn’t I get this sooner? I think that there are two reasons for this:

  1. I am not a big fan of fancy architecture diagrams and technical gobbledygook, and these are the tools which are often used to explain service-oriented architecture. I guess you could say that I couldn’t see the forest from the trees.
  2. Most of the applications which I have created during my career have been “normal” web applications. In other words, the user interface shown to the user is rendered in the backend. Using service-oriented architecture in these applications didn’t make any sense to me because it was simpler to add everything to the same binary.

The rise of single page web applications has had a major impact to my thinking. When the backend provides a REST API to the frontend which decides how the received information should be rendered, the service-oriented architecture starts to make sense because it has the following benefits:

  • We can divide the application into discrete pieces. Each piece fulfils a specific need and have their own domain-specific language.
  • We can scale only those parts of our application that require more resources.
  • We can deploy individual services instead of deploying the whole application.
  • Different services don’t have to use the same programming language. In other words, we can use the best tool for the job.
  • Different services can be created (and maintained) by different teams.

The service-oriented architecture isn’t a silver bullet but it offers solutions to the problems caused by the monolithic architecture.

There are two problems which bothers me the most:

  • It is damn hard to organize the code into modules which don’t have dependencies with the other modules of the application. Although I think that this isn’t the fault of the monolithic architecture, it is still a problem found from most monolithic applications (if you use Spring, you have other problems too).
  • The language of the monolith is often full of compromises. I confess that I am a bit obsessed about domain-driven design and I would love to use its full power in my work. However, it is hard to do this when all code belongs to the same monolith which have to fulfill different business needs which have different vocabularies. Maybe this is one reason why enterprise applications often use very generic and confusing language.

Maybe I am a bit too enthusiastic about this but it is safe to say the service-oriented / microservice architecture has finally made its way to my toolkit.

The Name Doesn’t Really Matter

The service-oriented architecture might have a bad reputation because it sounds enterprisy, and everyone knows that enterprisy is a bad thing (at least in hipster circles). Maybe that is why some people have started to call it the microservice architecture.

Or maybe I don’t really understand the service-oriented architecture, and that is why I cannot see any difference between it and the microservice architecture (this is probably true).

Because I am not an architecture consult, I don’t really care what the name of this architecture style is. All I care about is that I found a new way to solve some of the problems caused by the monolithic architecture.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

4 Responses to "The Microservice Architecture Sounds Like Service-Oriented Architecture"

  1. Hi Petri,

    Actually, SOA is a superset of the microservice architecture in the sense that the latter is just one of the many ways to define services in your SOA. You might wanna take a look at some patterns from soapatterns.org such as Service Layers, Utility Abstraction, and Cross-Domain Utility Layer (among many others). At the core of SOA exists the concept of a Service which is a generic deployable unit. A microservice architecture focuses on low level services (usually) with independent resources and infrastructure.

    What does it even mean? A SOA is composed of many services, some of them might be defined as microservices because of governance policies and/or design decisions. Other services will just be allowed to reuse your service.

    I’m glad that Martin Fowler and James Lewis’s article has had a big impact on software developers (including myself). I believe this is a great way to begin to understand a really complex (and sometimes boring) subject as SOA.

    • Hi,

      Thank your for your comment. It helped me to get a bit better understanding about the differences of SOA and the microservice architecture. Also, I will check out soapatterns.org as well.

      I agree that one of the benefits of the original article is that software developers are rediscovering “old” things. And yes, SOA can seem a bit boring but I am pretty sure that it doesn’t necessarily have to be so.

      By the way, can you recommend a good book about SOA? I have been trying to find one (not very actively though) but so far I haven’t decided which one I should buy.

  2. Hi Petri,

    I guess it all depends on your current knowledge about SOA. I suppose an entry-level book such as Service-Oriented Architecture for Dummies could be good to establish a common set of concepts. However, SOA is so complex and intricate that you would need to read many books just to to get the hang of it.

    To me, the best thing you can do right know is just “googling” about SOA methodologies, technologies, frameworks, trends, etc. and try to put everything together.

    As for authors, I follow Jason Bloomberg and Thomas Erl whenever I want to know what’s going on in the SOA world. Maybe you could find more interesting sources and let me know about them :)

    Best of luck!

  3. cblin says:

    > SOA is so complex and intricate that you would need to read many books just to to get the hang of it.

    This is why microservices will win over SOA.

    In my humble opinion, at the core, SOA is a top-down approach : you try to plan how you can coordinate and slice your whome business capabilitties.

    Whereas MS are more bottom-up : you have a business need, you create a backend specific to that need.
    Then, the backend can reuse other services but you are not required to.

Leave a Reply


× 1 = three



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close