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:
- 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.
- 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.
| Reference: | The Microservice Architecture Sounds Like Service-Oriented Architecture from our JCG partner Petri Kainulainen at the Petri Kainulainen blog. |
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… Read more »
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… Read more »
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… Read more »
> 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.
SOA and Microservices could not be farther apart. The essence of SOA is the layering, which is centered around Common Domain Model. You partition your Common Domain Model and structure it according to DDD, and you layer (domain) services accordingly, and you build application services, while applying SOA patterns. If an organization had 100 LOBs, under this approach they would all be exposed externally as a single harmonized thing. Remember that each of these LOBs run in its own separate process. This silo-like applications evolution was one of the reasons SOA came into existence. Contrast that with Microservices, which essentially… Read more »