SOA vs Microservices architecture

I see a little bit confused about microservices and how they are compared with the old friend SOA (Service Oriented Architecture). I strongly believe the root cause of this confusion is related to misconceptions about SOA.

SOA is a logical concept like OOP(Object Oriented Programming) and should be considered apart from the tools that we use to implement it. SOA has a bad reputation, mostly because of the famous tool that we used to use implementing SOA discipline for IT services which is ESB(Enterprise Service Bus).

ESBs are themselves developed as monolith applications and they became a single point of failure in enterprises. We tried some workarounds like creating federated ESBs etc., but we couldn’t get a robust solution.

To make it more clear, I will give an example from programming languages. When you choose a programming language that has OOP support, like Java, does it guarantee that the output will be a software that is developed with OOP concepts and easy to maintain and extend? Can you develop an application in a totally structural way with Java? Can you develop an OOP application using C programming language which doesn’t support OOP at first glance? Yes, you can develop a terribly designed application using Java and Yes, you can create applications with OOP principles using C. Those totally depend on developers’ expertise who are coding with those programming languages.

If we go back to the topic of this article, SOA is a discipline that guides you on how you need to structure your organization. It is definitely not just the IT services that you are running. “Service” word mentioned means services that your company provides. After you start thinking like; What are my goals? What I’m trying to provide? What is needed for achieving those goals? You will figure out what your services are.

When you create a business, mostly you have an idea that you think other people will find interesting and ask for it from you. That’s the service we’re talking about. And that service will contain some building blocks that create the service. We can call them sub-services. Some of those sub-services can be automized using IT tools, and some are not. When we start implementing some of them in an autonomous way, we start using IT tools.

How we were doing that?

Let me remind you of our legacy infrastructure with a simple example. A company that sells products to its customers needs Billing services and CRM services. Those services implemented in giant systems. Billing services are provided from one billing system and CRM services are provided from one CRM system. But are our customers aware of those systems? Of course No. Mostly we provide direct customer touching services like Web/mobile apps or indirect services through sale stores or call-centers. Then we provide web apps to those people working in stores and call-centers so that they can provide services needed by customers.

In time, we decided to create a middleware layer to apply SOA principles, like the implementation of recurring business logic, rather than implementing it several times individually in customer-facing applications or creating new services by orchestrating existing ones. To make our life easier, we developed some middleware layer applications, ESB’s BPM’s. I don’t want to go into details for those products, but mostly they were being used for the orchestration of underlying systems, as I mentioned like Billing and CRM. We also used middleware systems for some cross-cutting concerns like security, monitoring.

Long story short, while we changed our infrastructure architecture by adding those tools in the middle of existing systems, we created a huge single point of failure. If Billing system has failure Billing services don’t work if CRM system struggles with a problem than CRM services got affected. When it comes to middleware tools, having monolith applications like other Billing and CRM systems but in the middle of the stage causes a total downtime for all services that an enterprise provides. You can think of them as a network switch with star topology. Even though all computers attached are up and running if switch fails nothing works.

That’s why people start hating from ESB and BPM tools. Even with a little confusion(“thanks” to the naming of products by vendors), their name referred as SOA. But actually they are middleware tools that help us to implement SOA principles. SOA principles caused the creation of an abstraction layer, what we call as “middleware layer’ in enterprises, but SOA principles don’t have any role in designing the applications as monolith and placing them like a bomb in the middle of an enterprise.

How we are doing now?

With evolving technologies nowadays, the middleware layer has different products/tools. Like other monolith systems, new tools are implemented in a microservices manner and can run containerized in the Kubernetes platform. Now we have Service Mesh for internal interaction of services, we have API gateway for providing our services to the outer world. We implement our BPM needs as microservices with Saga design pattern. Sidecar concept evolved after containerizing stuff. So that cross-cutting concerns can be implemented without being a single point of failure. They remind me of the agent applications that we were installing on machines to talk to monolith apps like monitoring etc.

In the end, the need, how we should be thinking of building and structuring our organization is still the same and valid. So, we are still in need of those service-oriented principles while we are designing our services. Microservices are the way how we breakdown monolith applications so that we build, maintain, and scale applications much more easily, but they don’t come with alternatives to SOA principles. We keep implementing SOA principles with different tools for IT services nowadays and it doesn’t seem they will be discarded in the near future.

Long story short, I find so irrelevant to compare microservices architecture with SOA.

I’m planning to share my opinions on how old things are rebranded and serviced as new concepts/products like DDD(Domain-driven design) etc. in another article.

Thanks for your time and attention.

--

--

--

I love to spend time with tech

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

An Article Stating My Goals for HNGi8 X 14G And What I Want To Achieve By The End Of 8 weeks.

Linux Privilege Escalation exploiting Sudo Rights — Part I

MicroZed Chronicles: A Look at the Ultra96 Board

Simple implementation of Dijkstra using heap in Go

The usual website building platforms are like push-buttons phones in 2018

Developing an original API function with doorkeeper and oauth2.

Mobile Frontendless photo sharing app using Figma and Backendless

How to Refine your Engineering Process | SitePen

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Burak Tartan

Burak Tartan

I love to spend time with tech

More from Medium

Monolith to Micro Services — Key Takeaways

Command and Query Responsibility Segregation (CQRS) Architecture

Today we are focus on what are micro-services architecture.

Scale Applications by optimizing DNS Configuration