Are they the same concept? Let's see the two definitions:
The term "Microservice Architecture" has sprung up over the
last few years to describe a particular way of designing software
applications as suites of independently deployable services. While
there is no precise definition of this architectural style, there
are certain common characteristics around organization around
business capability, automated deployment, intelligence in the
endpoints, and decentralized control of languages and data. (cit Martin Fowler [1]).
Service Oriented Architecture (SOA) is a paradigm for organizing and
utilizing distributed capabilities that may be under the control of
different ownership domains. (Reference Model for Service Oriented Architecture 1.0 [2]).
Comparing the two definitions seems fairly clear that although they have some similar aspects are not the same. A good article, "Microservices is SOA, for those who know what SOA is" [3] of Steve Jones, illustrates a series of points which highlight the differences between the two architectures.
Characteristics of a Microservice Architecture
Let's analyze the characteristics of a microservice architecture.
Componentization via Services
A component is a unit of software that is independently replaceable and upgradeable. Microservice architectures will use libraries, but their primary way of componentizing their own software is by breaking down into services. We define libraries as components that are linked into a program and called using in-memory function calls, while servicesare out-of-process components who communicate with a mechanism such as a web service request, or remote procedure call. One main reason for using services as components is that services are independently deployable. Another consequence of using services as components is a more explicit component interface.
Organized around Business Capabilities
The microservice approach to division is different, splitting up into services organized around business capability. Such services take a broad-stack implementation of software for that business area, including user-interface, persistant storage, and any external collaborations. Consequently the teams are cross-functional, including the full range of skills required for the development: user-experience, database, and project management.
Products not Projects
On completion the software is handed over to a maintenance organization and the project team that built it is disbanded. Microservice proponents tend to avoid this model, preferring instead the notion that a team should own a product over its full lifetime.
Smart endpoints and dumb pipes
The microservice community favours an alternative approach: smart endpoints and dumb pipes. Applications built from microservices aim to be as decoupled and as cohesive as possible - they own their own domain logic and act more as filters in the classical Unix sense - receiving a request, applying logic as appropriate and producing a response.
The two protocols used most commonly are HTTP request-response with resource API's and lightweight messaging. Microservice teams use the principles and protocols that the world wide web is built on. The second approach in common use is messaging over a lightweight message bus. The infrastructure chosen is typically dumb (dumb as in acts as a message router only) - simple implementations such as RabbitMQ or ZeroMQ don't do much more than provide a reliable asynchronous fabric - the smarts still live in the end points that are producing and consuming messages; in the services. In a monolith, the components are executing in-process and communication between them is via either method invocation or function call. The biggest issue in changing a monolith into microservices lies in changing the communication pattern.
Decentralized Governance
One of the consequences of centralised governance is the tendency to standardise on single technology platforms. Teams building microservices prefer a different approach to standards too. Rather than use a set of defined standards written down somewhere on paper they prefer the idea of producing useful tools that other developers can use to solve similar problems to the ones they are facing.
Decentralized Data Management
Decentralization of data management presents in a number of different ways. At the most abstract level, it means that the conceptual model of the world will differ between systems. This is a common issue when integrating across a large enterprise, the sales view of a customer will differ from the support view. Some things that are called customers in the sales view may not appear at all in the support view. Those that do may have different attributes and (worse) common attributes with subtly different semantics. The monolithic applications prefer a single logical database for persistant data, enterprises often prefer a single database across a range of applications. Instead microservices prefer letting each service manage its own database, either different instances of the same database technology, or entirely different database systems - an approach called Polyglot Persistence.
 |
| Monolithic vs Microservices Architecture |
Decentralizing responsibility for data across microservices has implications for managing updates.Using transactions like this helps with consistency, but imposes significant temporal coupling, which is problematic across multiple services. Distributed transactions are notoriously difficult to implement and as a consequence microservice architectures emphasize transactionless coordination between services, with explicit recognition that consistency may only be eventual consistency and problems are dealt with by compensating operations.
Infrastructure Automation
Many of the products or systems being build with microservices are being built by teams with extensive experience of Continuous Delivery and it's precursor, Continuous Integration. Teams building software this way make extensive use of infrastructure automation techniques. The following picture illustrates in the build pipeline shown below.
Another area where we see teams using extensive infrastructure automation is when managing microservices in production. In contrast to our assertion above that as long as deployment is boring there isn't that much difference between monoliths and microservices, the operational landscape for each can be strikingly different.
Design for failure
A consequence of using services as components, is that applications need to be designed so that they can tolerate the failure of services. Any service call could fail due to unavailability of the supplier, the client has to respond to this as gracefully as possible. This is a disadvantage compared to a monolithic design as it introduces additional complexity to handle it. The consequence is that microservice teams constantly reflect on how service failures affect the user experience. Since services can fail at any time, it's important to be able to detect the failures quickly and, if possible, automatically restore service. Microservice applications put a lot of emphasis on real-time monitoring of the application, checking both architectural elements and business relevant metrics. Semantic monitoring can provide an early warning system of something going wrong that triggers development teams to follow up and investigate. This is particularly important to a microservices architecture because the microservice preference towards choreography and event collaboration leads to emergent behavior.
No comments:
Post a Comment