Introduction
SOA and microservices share common goals around reuse, encapsulation, and interoperability. But they represent distinct architectural styles optimized for different needs:
- SOA focuses on enterprise-wide reuse and standardization. It decomposes applications into an interconnected set of enterprise services built on standards like SOAP and WSDL.
- Microservices emphasize decentralized ownership and lightweight protocols. Applications are segmented into independently deployable microservices owned by small teams.
While similarities exist, the architectures, tooling, and applicable use cases diverge in important aspects. Understanding the contrasts helps architects select the right approach.
Key Differences Between SOA and Microservices
Several fundamental differences characterize SOA and microservices:
- Size and granularity – SOA services are larger grained focused on enterprise reuse. Microservices emphasize finer grained, focused services.
- Standardization – SOA leverages standards like SOAP, WS-Security, and UDDI registry for universal interoperability. Microservices favor simpler REST/JSON APIs with minimal standardization.
- Governance – SOA governance is centralized with uniform policies and reuse strategies. Microservices are decentralized where each service can use unique technology stacks.
- Inter-service communication – SOA uses enterprise service buses while microservices favor simple APIs and message brokering.
- State management – SOA focuses on stateless services. Stateful data lives in datastores. Microservices allow state to be kept locally within services.
- Scalability model – SOA services may support different scaling needs across the enterprise portfolio. Microservices scale each service independently.
These core differences lead to divergent architectures, development workflows, and usage scenarios.
Comparing SOA and Microservices Architectures
SOA and microservices take architectural approaches optimized for their respective goals and contexts:
SOA Architecture
- Enterprise Service Bus (ESB) centrally routes all inter-service communication and handles translation between protocols.
- Services register with a Universal Description Discovery and Integration (UDDI) registry so they can be discovered enterprise-wide.
- Web Services Definition Language (WSDL) and XML Schema describe service contracts. SOAP used for message encoding.
- Services designed for reuse across the enterprise portfolio to simplify integration.
- Layered architecture consisting of presentation, services, business process and integration tiers.
Microservices Architecture
- Simple APIs (often REST over HTTP) used for direct service-to-service interaction without a central hub.
- Decentralized architecture – services are independent units that manage their own dependencies.
- Lightweight protocols like REST prefered over SOAP and ESBs to minimize overhead.
- Fine-grained services with bounded contexts focused on specific capabilities.
- Decentralized data management with each service responsible for its own data persistence.
- Dynamically discover services using simple service registry or DNS versus UDDI registry.
These contrasting styles optimize for their different priorities. SOA creates an enterprise ecosystem through standardization. Microservices empower decentralized teams through autonomy and simplicity.
Comparing Governance Models
SOA and microservices take divergent approaches to governance:
SOA Governance
- Centralized governance over all services and integration to ensure consistency and compliance.
- Formal reuse policies, review processes and design standards enable enterprise integration.
- Services managed by a central IT group though various teams may build services.
- Focus on maximizing reuse, reducing redundancy, and rationalization.
Microservices Governance
- Decentralized governance owned at the team level. No central oversight.
- Individual teams have autonomy over service interfaces, technology choices, and standards.
- Loose guidelines may suggest consistency across teams but no enforcement.
- Services managed by the teams that build and use them.
- Focus on developer freedom and velocity over standardization.
SOA applies strong top-down governance for system integrity. Microservices use bottom-up governance emphasizing team ownership.
Contrasting Scalability Models
SOA and microservices scale services to meet different needs:
SOA Scalability
- Individual services may need to be scaled differently based on enterprise usage patterns.
- Some services act as enterprise APIs reused across applications. Others are unique to single apps.
- Scaling decisions are made centrally by IT considering needs across the portfolio.
- Services scaled using typical patterns like load balancing and database sharding.
Microservices Scalability
- Services are scaled based only on the specific workload and resource needs.
- Teams make scaling decisions independently for the services they own.
- Services likely scaled uniformly as part of an application since tightly coupled.
- Individual services and entire applications can be replicated horizontally for scale.
SOA considers broader enterprise service consumption, while microservices focus on specific applications and workloads.
Decomposing Monoliths
Both SOA and microservices aim to componentize monolithic applications. Their approaches reflect different end goals:
SOA Decomposition
- Identify enterprise subsystems and extract as services for reuse opportunities.
- Refactor backend systems and databases for service-compatibility.
- Expose APIs through ESB using SOAP/WSDL following enterprise standards.
- Make incremental progress abstracting monolith into services while maintaining existing system.
Microservices Decomposition
- Segment monolith by business domains into bounded contexts. Model as microservices.
- Shift organization towards decentralized service teams owning domains.
- Incrementally re-architect legacy using strangler pattern while building new microservices.
- Once core domains are microservices, remaining monolith can potentially be retired.
SOA decomposes monoliths for reuse while microservices target decentralized ownership and independent lifecycles.
Microservices – Advantages vs. Disadvantages
The microservices approach offers certain benefits but also new complexities:
Microservices Advantages
- Team autonomy and rapid development velocity
- Independent scaling per service
- Fault isolation – failures are localized
- Polyglot tech stacks using optimal languages
- Incremental modernization of legacy monoliths
Microservices Disadvantages
- Distributed complexity to manage
- Integration and testing across services
- Increased overhead from service communication
- Repeated logic across services
- Data consistency challenges from decentralization
SOA vs. Microservices – When to Use Each
With very different architectures and models, SOA and microservices each excel in different scenarios:
When to use SOA:
- Need to integrate across enterprise systems using standards
- Priority is maximizing reuse across portfolio
- Require centralized management of APIs and architecture
- Prefer stability and universal interoperability over speed
When to use microservices:
- Fast evolution of software is critical
- Decentralized team autonomy is beneficial
- Independent scaling needed per component
- Modernizing large legacy monolithic apps
- Optimizing for organizational alignment over reuse
Some systems may benefit from a combination, using SOA principles internally and microservices externally. But in general one architectural style tends to dominate.
Conclusion
SOA and microservices both improve agility and velocity by decomposing applications into services. But they represent two distinct styles optimized for different strategies.
SOA enables enterprise-wide reuse through standardization. Microservices accelerate autonomous team speed through decentralization.
Factors like governance, scale, protocols, and existing systems determine the best choice for a given organization. Evaluating priorities and trade-offs allows selecting an approach that aligns architectural style with business values and culture.
Frequently Asked Questions
What are the main differences between SOA and microservices?
The main differences are scope, governance, protocols, standards use and granularity. SOA focuses on enterprise-wide integration while microservices emphasize decentralized team autonomy.
Which style has led to modern serverless architectures?
The microservices emphasis on decentralization, autonomy and loosely coupled services has strongly influenced modern serverless architectures. SOA provides useful distributed patterns but many find it too centralized and standardized for current needs.
What role do APIs play in SOA vs. microservices?
SOA APIs tend to be centrally managed enterprise services consolidated in an ESB. Microservices expose lightweight HTTP/REST APIs owned by each service team.
How are microservices adopted from a monolith?
Microservices should be incrementally extracted from monoliths over time based on domain boundaries. Adopting a strangler pattern slowly modernizes while building new microservices.
When might combining both SOA and microservices make sense?
In large enterprises with legacy systems, using SOA internally and microservices on the edge can be beneficial. SOA integrates backends while microservices deliver agile customer experiences.