Member-only story
Service-Oriented Architecture (SOA)
Evolving from monolith toward a distributed system
In the first years of my career, Service-Oriented Architecture (SOA) rang my bells, as many seniors and architects were talking very much about it. And the buzz was quite strong, but not as strong as microservices which is also promoted by the DevOps movement. At that time, I understood very little about this topic as I was still a junior developer, trying just to sort out some delivery problems on a project while preparing for my certification in Java. One thing I’m sure about is that N-Tiers were intensively used at that time.
Even though many architects were trying to move some system’s architecture toward SOA style, the term “monolith” was not known yet, as far as I can record from my memory, so the move was to transit from N-Tiers to SOA, by breaking down the system into components and compose them as services to be served through network calls.
Let’s describe what is a monolith and what is N-Tiers architecture before going into the details of SOA.
Related articles:
- Software Architecture — principles, rules and styles
- Microservices Architecture — a step further than just SOA
Monolithic Architecture
The term “monolith” had probably emerged when people talking about microservices for the need to distinguish between them. The Monolithic Architecture style describes the way we build an entire application as a single cohesive unit. That means all components (UI, data access, business logic) are bundled together and in the same process.
Back to the 2000s, all code of an application sits within the same repository, including the script to build, test and deploy the application. Before the rise of microservices, applications relied heavily on multi-threading to serve other client applications and web pages. The way to scale up in case of traffic increase is to add more resources on servers so that the applications can consume more RAMs and CPUs. That is exactly what we call vertical scaling.
