In this article, we'll explain the basics of service-oriented architecture (SOA) and microservices, touch on their key differences and look at which approach would be best for your situation.
If you work in IT or thecloud computingfield, you're probably well aware of theservice-oriented architecture(SOA) vs. microservices debate. After all, everyone is talking about microservices andagileapplications these days.
At first glance, the two approaches sound very similar, and in some ways, they are. Both involve cloud or hybrid cloud environments for agileapplication developmentand deployment, and both can scale to meet the speed and operational demands of big data. Both break large,complex applicationsinto small, flexible components that are easier to work with. And both differ from a traditional,monolithicarchitecturein that every service has its own responsibility.
However, even with these key commonalities, a closer examination of the two approaches reveals important differences.
What isservice-oriented architecture(SOA)?
Service-oriented architecture(SOA)is an enterprise-wide approach tosoftware development of application components that takes advantage of reusablesoftware components, or services. InSOAsoftware architecture, 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 into 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,development teamscan save time by reusing components in other applications across the enterprise. This is both a benefit and a risk. As a result of the shared access to theenterprise service bus (ESB), if issues arise, it can also affect the other connected services.
XMLdata is a key ingredient for solutions that are based onSOAarchitecture.XML-basedSOAapplications can be used to buildweb services, for example.
SOAemerged in the late 1990s and represents an important stage in the evolution ofapplication developmentand integration. BeforeSOAwas an option, connecting amonolithicapplicationto data orfunctionalityin another system required complex point-to-point integration that developers had to recreate for each new development project. Exposing those functions throughSOAeliminates the need to recreate the deep integration every time.
- Functional services (i.e., business services), which are critical for business applications.
- Enterprise services, which serve to implementfunctionality.
- Application services, which are used to develop and deploy apps.
- Infrastructure services, which are instrumental for backend processes like security andauthentication.
Each service consists of three components:
- The interface, which defines how aservice providerwill execute requests from aservice consumer.
- The contract, which defines how theservice providerandservice consumershould interact.
- The implementation, which is the service code.
SOAservicescan be combined to create higher-level services and applications.
What are microservices?
LikeSOA,microservices architecturesare made up of loosely coupled, reusable, and specialized components that often work independently of one another. Microservices also use a high degree of cohesion, otherwise known asbounded context.Bounded contextrefers to the relationship between a component and its data as a standalone entity or unit with very fewdependencies. Rather than being adopted enterprise-wide, microservices typically communicate viaapplication programming interfaces (APIs)to build individual applications that perform a specificbusinessfunctionality (or functionalityfor specific areas of the business) in a way that makes them more agile, scalable and resilient. Typically,Javais theprogramming languageof choice to develop Microservices. Otherprogramming languagesmay also be used, such as Golang and Python.
Microservices are a truecloud-nativearchitectural approach, often operating in containers, which make them more scalable and portable for the creation ofindependent services. Teams can use microservices to update code more easily, use different stacks for different components and scale the components independently of one another, reducing the waste and cost associated with having to scaleentire applicationsbecause a single feature might be facing too much load. Because of their independence, microservices produce services that are more fault-tolerant than the alternatives.
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 toscope. To put it simply,service-oriented architecture(SOA) has an enterprise scope, while themicroservices architecturehas 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 fewusecaseswhere this distinction comes into play:
InSOA,reusabilityof integrations is the primary goal, and at an enterprise level, striving for some level ofreuseis essential.Reusabilityandcomponent sharingin anSOAarchitectureincreasesscalabilityand efficiency.
Inmicroservices architecture, creating a microservices component that is reused at runtime throughout an application results independenciesthat reduce agility and resilience. Microservices components generally prefer toreusecode by copying and accepting data duplication to help improvedecoupling.
The reusable services inSOAare available across the enterprise using predominantly synchronous protocols likeRESTfulAPIs.
However,withina microservice application, synchronous calls introduce real-timedependencies, resulting in a loss of resilience. These dependencies 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.
A clear aim of providing services in anSOAis for all applications to synchronously obtain and alter data directly at its primary source, which reduces the need to maintain complex data synchronization patterns.
In microservices applications, ideally, each microservice 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.
Otherkey differencesbetweenSOAand microservices
- Communication:In amicroservices architecture, each service is developed independently, with its own communication protocol. WithSOA, each service must share a common communication mechanism called anenterprise service bus(ESB).SOAmanages and coordinates the services it delivers through theESB. However, theESBcan become asingle point of failurefor the whole enterprise, and if a single service slows down, the entire system can be affected.
- Interoperability:In the interest of keeping things simple, microservices use lightweightmessagingprotocols likeHTTP/REST (Representational State Transfers) and JMS (JavaMessagingService).SOAsare more open toheterogeneousmessagingprotocols such as SOAP (Simple Object Access Protocol),AMQP(AdvancedMessagingQueuing Protocol) and MSMQ (MicrosoftMessagingQueuing).
- Servicegranularity:Microservices architecturesare made up of highly specialized services, each of which is designed to do one thing very well. The services that make upSOAs, on the other hand, can range from small, specialized services to enterprise-wide services.
- Speed:By leveraging the advantages of sharing a common architecture,SOAssimplify development and troubleshooting. However, this also tends to makeSOAsoperate more slowly thanmicroservices architectures, which minimize sharing in favor of duplication.
- Governance:The nature ofSOA, involving shared resources, enable the implementation of common data governance standards across all services. The independent nature of microservices does not enable consistent data governance. This provides greater flexibility for each service, which can encourage greater collaboration across the organization.
- Storage:SOAand microservices also differ in terms of how storage resources are allocated.SOAarchitecturetypically includes a singledata storagelayer shared by all services within a given application, whereas microservices will dedicate a server or database fordata storagefor any service that needs it.
Migration fromSOAto microservices
For some organizations, SOAarchitectureis a steppingstone to replace themonolith, providing a more flexible and agile environment.SOAservicescan be developed and utilized in a large environment, but they do not address specific needs of individual businesses that wish to addressbusiness processeswithin their purview.DevOpscan be used to help an organization transition from SOAarchitectureto microservices to address specific needs.
SOAvs. microservices: Which is best for you?
Architectural styleshave their advantages, so how can you determine which one will work best for your purposes? In general, it depends on how large and diverse your application environment is.
BothSOAand microservices can useautomationto speed upbusiness processes. Larger, more diverse environments tend to lean towardsservice-oriented architecture(SOA), which supports integration between heterogenous applications andmessagingprotocols via anenterprise-service bus(ESB). Smaller environments, including web and mobile applications, do not require such a robust communication layer and are easier to develop using amicroservices architecture.
Learn more aboutSOAand microservices
Some will point out that theSOAvs. microservices debate is much more complicated, and that’s true. There is a great deal more to it. For a more detailed technical explanation of these nuances, we encourage you to delve into theSOAand microservices Learn Hub articles, which provide a great deal of in-depth information. From a business perspective, however, scope is the crucial distinction.
- What are Microservices?
- What isSOA(Service-Oriented Architecture)?
- Agile vs. Waterfall
To learn more about how to build agile applications, download your free copy of theAgile Applications Architecture ebook.