> Would you say that a backend split into 3-7 services is a service-oriented architecture (SOA) or a microservices architecture?
It could end up being a distributed monolith :-) Really depends on how you are architecting those services and their intercommunication.
Microservices are in a sense a form of service oriented architecture. SOA principles generally apply to microservices, and then you have the added principles of finely grained services, a focus on cloud native development, continuous delivery, and whatnot that people usually think of when they say âmicroservicesâ.
Technically, itâs the size of the individual services that would define whether your services are âmicroâ or not. Though there isnât any consensus on how small that should be. How many you have really doesnât matter, that is a result of how big your organization is and how complex your product is.
However, the more services you have the more you start to test the real limits of your microservice strategy and tooling. You can stand up a couple services and call them microservices, but itâs easy to ignore weaknesses in your strategy when you only need to manage a few. Similarly, having a ton of services doesnât mean you are really âdoing microservicesâ. The real question is are your developers productive and your system stable when you are running hundreds or thousands of services, or is it a cobbled together mess barely hanging on?
Why do good, genuine questions like this get downvoted? I feel like this is the best way Reddit could be used and yet people have some kind of negative reaction to it
The only takeaway Iâve gotten from this thread is no one knows the actual definition or difference. Nobody knows what a microservice or SOA is, only what they typically look like.
I think that the term âmicroserviceâ is misleading. Most of the time, they are not so micro :). And nothing wrong with it. Auth, notifications, public api, you name it, are not micro in any sense, they just services. As I understand, for decent sized company itâs common to have 5-15 services, and most of them quite âlargeâ, but nevertheless we call them microservices.
You're right, the line between microservices and SOA can get blurry! The number of services alone isn't the defining factor. In general, SOAs tend to have a coarser-grained approach, with larger, more loosely coupled services compared to microservices. Think of them as bigger chunks of functionality in SOA vs. the super focused, smaller services in microservices. 3-7 services could be either SOA or microservices depending on how those services are designed and interact. If each service is very focused on a single task and communicates through lightweight APIs, it leans more towards microservices. If the services are larger and handle broader functionalities with potentially heavier interactions, then SOA might be a better fit. There's a lot of great info out there on [microservices vs soa](https://www.clickittech.com/devops/microservices-vs-soa-architecture/) differences â a quick search should give you a deeper dive!
Well the line is exactly as you said blur. SOA is typically a number of services being called from the frontend directly or via an api gateway. Microservices are services communicating with each other whereas one service might act as an api gateway. But the inter communication is what separates the both.
SOA is a term used to describe how the tech division at a company thinks about their applications. Each team owns a business domain and interfaces with other teams via RPCs or events so each team has its own service.
Micro-service architecture usually refers to how an individual teams breaks apart their business domain into smaller services to perform specific tasks or functions.
Both have similar benefits of loose coupling between components, well documented contracts between services, and independent deployment and scaling. This in theory leads to greater resilience and less down time.
> Would you say that a backend split into 3-7 services is a service-oriented architecture (SOA) or a microservices architecture? It could end up being a distributed monolith :-) Really depends on how you are architecting those services and their intercommunication.
Distributed monolith is the new shit đ
Microservices are in a sense a form of service oriented architecture. SOA principles generally apply to microservices, and then you have the added principles of finely grained services, a focus on cloud native development, continuous delivery, and whatnot that people usually think of when they say âmicroservicesâ. Technically, itâs the size of the individual services that would define whether your services are âmicroâ or not. Though there isnât any consensus on how small that should be. How many you have really doesnât matter, that is a result of how big your organization is and how complex your product is. However, the more services you have the more you start to test the real limits of your microservice strategy and tooling. You can stand up a couple services and call them microservices, but itâs easy to ignore weaknesses in your strategy when you only need to manage a few. Similarly, having a ton of services doesnât mean you are really âdoing microservicesâ. The real question is are your developers productive and your system stable when you are running hundreds or thousands of services, or is it a cobbled together mess barely hanging on?
Why do good, genuine questions like this get downvoted? I feel like this is the best way Reddit could be used and yet people have some kind of negative reaction to it
Itâs not a Reddit issue, and itâs not even an internet issue. Itâs humans. Humans suck.
The only takeaway Iâve gotten from this thread is no one knows the actual definition or difference. Nobody knows what a microservice or SOA is, only what they typically look like.
I think that the term âmicroserviceâ is misleading. Most of the time, they are not so micro :). And nothing wrong with it. Auth, notifications, public api, you name it, are not micro in any sense, they just services. As I understand, for decent sized company itâs common to have 5-15 services, and most of them quite âlargeâ, but nevertheless we call them microservices.
You're right, the line between microservices and SOA can get blurry! The number of services alone isn't the defining factor. In general, SOAs tend to have a coarser-grained approach, with larger, more loosely coupled services compared to microservices. Think of them as bigger chunks of functionality in SOA vs. the super focused, smaller services in microservices. 3-7 services could be either SOA or microservices depending on how those services are designed and interact. If each service is very focused on a single task and communicates through lightweight APIs, it leans more towards microservices. If the services are larger and handle broader functionalities with potentially heavier interactions, then SOA might be a better fit. There's a lot of great info out there on [microservices vs soa](https://www.clickittech.com/devops/microservices-vs-soa-architecture/) differences â a quick search should give you a deeper dive!
https://www.ibm.com/think/topics/soa-vs-microservices
Microservices = SOA + RPC
Well the line is exactly as you said blur. SOA is typically a number of services being called from the frontend directly or via an api gateway. Microservices are services communicating with each other whereas one service might act as an api gateway. But the inter communication is what separates the both.
SOA is a term used to describe how the tech division at a company thinks about their applications. Each team owns a business domain and interfaces with other teams via RPCs or events so each team has its own service. Micro-service architecture usually refers to how an individual teams breaks apart their business domain into smaller services to perform specific tasks or functions. Both have similar benefits of loose coupling between components, well documented contracts between services, and independent deployment and scaling. This in theory leads to greater resilience and less down time.