222
F. Firouzi and B. Farahani
ESB can become a single point of failure in SOA, impacting the whole
application. Because all services utilize the ESB to communicate, if one service
slows, the ESB could become obstructed with requests for that particular service. On
the contrary, microservices tolerate faults better. For example, a memory leak in one
service only affects that particular service while alternate microservices continue
managing requests.
Heterogeneous interoperability is also a large variation between the two architecture types. SOA supports the integration of many heterogeneous protocols using
a messaging middleware. The microservice architecture seeks to simplify the
architecture by reducing integration choices.
Another major difference is that unlike SOAs, microservices can both work and
be deployed independently, making it easier to push out updated versions or scale a
particular service. When it comes to deployment, SOA recreates and relaunches the
whole application while microservice architecture allows individual services to be
created and utilized separately. Therefore, microservice architecture empowers fast,
continuous, and automatic deployments.
Data storage is shared among services in SOA; however, services can store
data independently in microservices. Shared data storage has both benefits and
shortcomings. For instance, shared data storage enables data to be recycled among
all services but requires dependency and tight service connections.
Service granularity is another key difference between microservices and SOA.
The diverse services in microservice architecture each does only one thing really
well, while SOA service components can handle anything from small services to
huge enterprise services.
Finally, SOA’s approach to architecture focuses on “sharing as much as possible” while microservice architecture “shares as little as possible.” SOA is most
concerned with recycling business functionality while microservice architecture is
based on the foundation of bounded context/domain.
4.7.1 Microservice Architecture Pattern
In this section we discuss the engineering details of microservice architecture.
4.7.1.1 API Gateway
An API gateway is an application/service that serves as the system entry point. API
gateways abstracts the architecture of the internal system and then represents it via a
set of APIs. API gateways can also be responsible for authentication, load balancing,
monitoring, static response handling, caching, and request shaping or management.
Figure 4.33 illustrates the basic concept of an API gateway [30].
The API gateway manages composition and requests routing and translation of
protocols. Any client request has to pass through the API gateway where it is routed
F. Firouzi and B. Farahani
ESB can become a single point of failure in SOA, impacting the whole
application. Because all services utilize the ESB to communicate, if one service
slows, the ESB could become obstructed with requests for that particular service. On
the contrary, microservices tolerate faults better. For example, a memory leak in one
service only affects that particular service while alternate microservices continue
managing requests.
Heterogeneous interoperability is also a large variation between the two architecture types. SOA supports the integration of many heterogeneous protocols using
a messaging middleware. The microservice architecture seeks to simplify the
architecture by reducing integration choices.
Another major difference is that unlike SOAs, microservices can both work and
be deployed independently, making it easier to push out updated versions or scale a
particular service. When it comes to deployment, SOA recreates and relaunches the
whole application while microservice architecture allows individual services to be
created and utilized separately. Therefore, microservice architecture empowers fast,
continuous, and automatic deployments.
Data storage is shared among services in SOA; however, services can store
data independently in microservices. Shared data storage has both benefits and
shortcomings. For instance, shared data storage enables data to be recycled among
all services but requires dependency and tight service connections.
Service granularity is another key difference between microservices and SOA.
The diverse services in microservice architecture each does only one thing really
well, while SOA service components can handle anything from small services to
huge enterprise services.
Finally, SOA’s approach to architecture focuses on “sharing as much as possible” while microservice architecture “shares as little as possible.” SOA is most
concerned with recycling business functionality while microservice architecture is
based on the foundation of bounded context/domain.
4.7.1 Microservice Architecture Pattern
In this section we discuss the engineering details of microservice architecture.
4.7.1.1 API Gateway
An API gateway is an application/service that serves as the system entry point. API
gateways abstracts the architecture of the internal system and then represents it via a
set of APIs. API gateways can also be responsible for authentication, load balancing,
monitoring, static response handling, caching, and request shaping or management.
Figure 4.33 illustrates the basic concept of an API gateway [30].
The API gateway manages composition and requests routing and translation of
protocols. Any client request has to pass through the API gateway where it is routed