If you work in IT or the cloud computing field, you’re probably well aware of the service-oriented architecture (SOA) vs. microservices debate. After all, everyone is talking about microservices and agile applications these days.
At first glance, the two approaches sound very similar. In some ways, they are—both are different from a traditional, monolithic architecture in that every service will have its own responsibility; both are scalable, agile approaches. However, even with these key commonalities, a closer examination of the two approaches reveals important differences.
In this article, we’ll explain the basics of SOA and microservices, touch on their key differences, and look at which approach would be best for your situation.
What is service-oriented architecture (SOA)?
Service-oriented architecture (SOA) is an enterprise-wide approach to software development that takes advantage of reusable software components, or services. Each service is comprised of the code and data integrations required to execute a specific business function—for example, checking a customer’s credit, signing in to a website, or processing a mortgage application.
The service interfaces provide loose coupling, which means that they can be called with little or no knowledge of how the integration is implemented underneath. Because of this loose coupling and the way the services are published, developers can save time by reusing components in other applications across the enterprise.
SOA emerged in the late 1990s and represents an important stage in the evolution of application development and integration. Before SOA was an option, connecting an application to data or functionality in another system required complex point-to-point integration that developers had to recreate for each new development project. Exposing those functions through SOA eliminates the need to recreate the deep integration every time.
What are microservices?
Like SOA, microservices architectures are made up of loosely coupled, reusable, and specialized components. However, rather than being adopted enterprise-wide, microservices are typically used to build individual applications in a way that makes them more agile, scalable, and resilient.
Microservices are a true cloud native architectural approach, and by using them, teams can update code more easily, use different stacks for different components, and scale the component independently of one another, reducing the waste and cost associated with having to scale entire applications because a single feature might be facing too much load.
Check out the following video for more info on microservices architecture:
The main difference between SOA and microservices: Scope
The main distinction between the two approaches comes down to scope. To put it simply, service-oriented architecture (SOA) has an enterprise scope, while the microservices architecture has an application scope.
Many of the core principles of each approach become incompatible when you neglect this difference. If you accept the difference in scope, you may quickly realize that the two can potentially complement each other, rather than compete.
Here are a few cases where this distinction comes into play:
Reuse
In SOA, reuse of integrations is the primary goal, and at an enterprise level, striving for some level of reuse is essential.
In microservices architecture, creating a microservices component that is reused at runtime throughout an application results in dependencies that reduce agility and resilience. Microservices components generally prefer to reuse code by copy and accept data duplication to help improve decoupling.
Synchronous calls
The reusable services in SOA are available across the enterprise using predominantly synchronous protocols such as RESTful APIs.
However, within a microservice application, synchronous calls introduce real-time dependencies, resulting in a loss of resilience. It may also cause latency, which impacts performance. Within a microservices application, interaction patterns based on asynchronous communication are preferred, such as event sourcing, in which a publish/subscribe model is used to enable a microservices component to remain up to date on changes happening to the data in another component.
Data duplication
A clear aim of providing services in an SOA is for all applications to synchronously get hold of and make changes to data directly at its primary source, which reduces the need to maintain complex data synchronization patterns.
In microservices applications, each microservice ideally has local access to all the data it needs to ensure its independence from other microservices, and indeed from other applications, even if this means some duplication of data in other systems. Of course, this duplication adds complexity, so it must be balanced against the gains in agility and performance, but this is accepted as a reality of microservices design.
Microservices vs. SOA – Is There Any Difference at All?
Learn the real differences between microservices and SOA architecture, their focus, and most frequent uses in development.
Lately, there has been a lot of fuss about the differences between these two types of architectures, or whether there is any difference at all. In order to delve deeper into this question that raised hundreds of debates, I will first briefly define both SOA and microservices architecture and their origins, and then we’ll compare them and see how we can best distinguish them.
Service-Oriented Architecture (SOA)
Service Oriented Architecture is a software architecture where distinct components of the application provide services to other components via a communications protocol over a network. The communication can involve either simple data passing, or two or more services coordinating connecting services to each other. These distinct services carry out some small functions such as validating payment, creating a user account, or providing social log-in.
Service Oriented Architecture is less about how to modularize an application, and more about how to compose an application by integration of distributed, separately-maintained and deployed software components. It is enabled by technologies and standards that make it easier for components to communicate and cooperate over a network, especially an IP network.
There are two main roles in SOA: a service provider, and a service consumer. A software agent may play both roles. The Consumer Layer is the point where users (human, other components of the app, or third parties) interact with the SOA, and the Provider Layer consists of all the services within the SOA.
SOA first got its name in the mid 90s, when a corporation called Gartner Group recognized this emerging trend in software architectures, adopted it, and popularized it worldwide. By doing this, they managed to greatly speed up the adoption and further evolution of this architecture pattern. However, the first records of using distributed services as software architecture date back to the early 80s.
Microservices
Microservices, in a way, are the next step in the evolution of Service Oriented Architectures. Basically, this architecture type is a particular way of developing software, web, or mobile applications as suites of independent services – a.k.a microservices. These services are created to serve only one specific business function, such as User Management, User Roles, E-commerce Cart, Search Engine, Social Media Logins, etc. Furthermore, they are completely independent of each other, meaning they can be written in different programming languages and use different databases. Centralized services management is almost non-existent and the microservices use lightweight HTTP, REST, or Thrift APIs for communicating among themselves.
The word itself originates from a workshop of software architects held near Venice in May 2011. They used the term "microservice" for the first time, to describe what the participants saw as a common architectural style that many of them had been recently exploring. In May 2012, the same group decided on "microservices" as the most appropriate name. However, major tech companies such as Microsoft, Amazon, Netflix, and Facebook, have been working with microservices for more than a decade. Other people have called them “Micro Web-Services” or “fine-grained SOA” before coming up with the commonly accepted name.
Yes, at first glance, it might seem that we are talking about the same thing as SOA. However, I will call upon the words of Martin Flower, a pioneer in the world of microservices, who once said that we should think about SOA as a superset of microservices.
So, Where’s the Difference?
We could say that both architectures have more similarities than differences, however, at the end of the day, they are two different types of architecture. To support my claim, first, I will go through particular segments of the architectures which differentiate them, in table form. Later, I will elaborate on some of them in greater detail. Here we go!
| SERVICE-ORIENTED ARCHITECTURE | MICROSERVICES ARCHITECTURE |
| Maximizes application service reusability | Focused on decoupling |
| A systematic change requires modifying the monolith | A systematic change is to create a new service |
| DevOps and Continuous Delivery are becoming popular, but are not mainstream | Strong focus on DevOps and Continuous Delivery |
| Focused on business functionality reuse | More importance on the concept of “bounded context” |
| For communication it uses Enterprise Service Bus (ESB) | For communication uses less elaborate and simple messaging systems |
| Supports multiple message protocols | Uses lightweight protocols such as HTTP, REST or Thrift APIs |
| Use of a common platform for all services deployed to it | Application Servers are not really used, it’s common to use cloud platforms |
| Use of containers (such as Docker) is less popular | Containers work very well with microservices |
| SOA services share the data storage | Each microservice can have an independent data storage |
| Common governance and standards | Relaxed governance, with greater focus on teams collaboration and freedom of choice |
I’ll get into more detail in some of the aspects shown in the table above and further explain the differences:
- Development – In both architectures, services can be developed in different programming languages and tools, which brings technology diversity into the development team. The development can be organized within multiple teams, however, in SOA, each team needs to know about the common communication mechanism. On the other hand, with microservices, the services can operate and be deployed independently of other services. So, it is easier to deploy new versions of microservices frequently or scale a service independently. You can read further about these benefits of microservices here.
- “Bounded Context” - SOA encourages sharing of components, whereas microservices try to minimize on sharing through “bounded context.” A bounded context refers to the coupling of a component and its data as a single unit with minimal dependencies. As SOA relies on multiple services to fulfill a business request, systems built on SOA are likely to be slower than microservices.
- Communication - In SOA, the ESB could become a single point of failure which impacts the entire system. Since every service is communicating through the ESB, if one of the services slows down, it could clog up the ESB with requests for that service. On the other hand, microservices are much better in error tolerance. For example, if one microservice has a memory fault, then only that microservice will be affected. All the other microservices will continue to handle requests regularly.
-
Interoperability - SOA promotes the use of multiple heterogeneous protocols through its messaging middleware component. Microservices attempt to simplify the architecture pattern by reducing the number of choices for integration. So, if you want to integrate several systems using different protocols in a heterogeneous environment, you need to consider SOA. If all your services could be accessed through the same remote access protocol, then microservices are a better option for you.
-
Size - Last but not least, the main difference between SOA and microservices lies in the size and scope. The prefix “micro” in microservices refers to the granularity of the internal components, meaning they have to be significantly smaller than what SOA tends to be. Service components within microservices generally have a single purpose and they do that one thing really well. On the other hand, in SOA services usually include much more business functionality, and they are often implemented as complete subsystems.
Conclusion
One cannot simply say that one architecture is better than the other. It mainly depends on the purpose of the application you are building. SOA is better suited for larger, complex enterprise application environments that require integration with many other applications. That being said, smaller applications are not a good fit for SOA as they don’t need a messaging middleware component. Microservices, on the other hand, are better suited for smaller and well-partitioned, web-based systems. Also, if you are developing a mobile or web application, then microservices give you much greater control as a developer. Finally, we can conclude that since they serve different purposes – microservices and SOA are indeed distinct types of architectures.
扫一扫
9594
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
