Chưa phân loại, Microservices

Microservices vs SOA – Chap1. The World of Service-Based Architectures

This post is part of a series of posts with my personal notes about the chapters in the book “Microservices vs. Service-Oriented Architecture” by Mark Richards.

Both microservices architecture and SOA are considered service-based architectures, meaning that they are architecture patterns that place a heavy emphasis on services as the primary architecture component used to implement and perform business and nonbusiness functionality.

All service-based architectures have in common is that they are generally distributed architectures, meaning that service components are accessed remotely through some sort of remote access protocol —for example, Representational State Transfer (REST), Simple Object Access Protocol (SOAP), Advanced Message Queuing Protocol (AMQP), Java Message Service (JMS), Microsoft Message Queuing (MSMQ), Remote Method Invocation (RMI), or .NET Remoting.

Distributed architectures also lend themselves to more loosely coupled and modular applications.

Service Contracts

A service contract is an agreement between a (usually remote) service and a service consumer (client) that specifies the inbound and outbound data along with the contract format (XML, JavaScript Object Notation [JSON], Java object, etc.)

In service-based architecture you can use two basic types of service contract models: service-based contracts and consumer-driven contracts

Contract versioning allows you to roll out new service features that involve contract changes and at the same time provide backward compatibility for service consumers that are still using prior contracts

There are two basic techniques to implement your own custom contract-versioning strategy: homogeneous versioning and heterogeneous versioning

In many circumstances this may not be feasible because the number of internal and/or external service consumers is large. In this situation an integration hub (i.e., messaging middleware) can help by providing an abstraction layer to transform service contracts between services and service consumers.

Service Availability

Service availability and service responsiveness are two other considerations common to all service-based architectures

Service availability refers to the ability of a remote service to accept requests in a timely manner (e.g., establishing a connection to the remote service).

Service responsiveness refers to the ability of the service consumer to receive a timely response from the service.

Service responsiveness is much more difficult to address. A popular technique to address this issue is to use the circuit breaker pattern.

Security

Depending on your situation, service consumers may need to be both authenticated and authorized.

Authentication refers to whether the service consumer can connect to the service, usually through sign-on credentials using a username and password.

Authorization refers to whether or not a service consumer is allowed to access specific business functionality within a service.

With microservices, security becomes a challenge primarily because no middleware component handles security-based functionality.
Instead, each service must handle security on its own, or in some cases the API layer can be made more intelligent to handle the security aspects of the application.

Transactions

Transaction management is a big challenge in service-based architectures. Most of the time when we talk about transactions we are referring to the ACID (atomicity, consistency, isolation, and durability). Given that service-based architectures are generally distributed architectures, it is extremely difficult to propagate and maintain a transaction context across multiple remote services

Transaction issues are much more prevalent in SOA because, unlike in microservices architecture, multiple services are typically used to perform a single business request.

Rather than use ACID transactions, service-based architectures rely on BASE transactions. BASE is a family of styles that include basic availability, soft state, and eventual consistency.

In situations in which you simply cannot rely on eventual consistency and soft state and require transactional consistency, you can make your services more coarse-grained to encapsulate the business logic into a single service, allowing the use of ACID transactions to achieve consistency at the transaction level.

Too Much Complexity?

Service-based architectures are a significant improvement over monolithic applications, but as you can see they involve many considerations—including service contracts, availability, security, and transactions, …

In chapter 2, we will compare Service Characteristics of Microservices and SOA

edwardthienhoang

1 thought on “Microservices vs SOA – Chap1. The World of Service-Based Architectures”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.