A practical approach to microservices.

1. Some Q/A on Microservices
Architecture in Enterprise
Applications Context
Pranab Das

2. What are Some of the Characteristics of
Enterprise Applications?
Run Information System (IS) of large businesses e.g., banking,
insurance, etc.
Have large user bases for their transactional systems with heavy
concurrent loads.
Store data in polyglot systems e.g., Mainframe, RDBMS, Document
DB, (K, V) pairs, Graph DB, etc.
Have integrated Data Warehouse and Business Intelligence (DW/BI)
systems to put information to strategic use.
Require high performance, low meantime-between-failures (MTBF),
high security, high maintainability, perfect scalability, and low latency.

3. Why/What is cloud-deployment?
Computing—data processing, storing, and networking—has become a utility such
as electricity, gas, or water that can be switched on or off as required.
Collocating computing resources betters economy of scale and utilization of
energy, helping a greener planet.
Infra as a Service (IaaS) provides only infrastructure or the metal and maximizes freedom to
choose platforms or software.
In addition to the above, Platform as a Service (PaaS) also provides a platform such as
Windows 2012, allowing freedom to select software that is compatible with such platform;
hence, providing reasonable flexibility.
Often, are Virtual Machines (VM) that use the hypervisor to host selected platforms.
 Such VMs may, optionally, be managed—scaled and secured—by the cloud-provider.
 A variation—Container as a Service (CaaS)—is a soft-VM cf. Docker, which is, generally, managed by
the provider.
In addition to the above, Software as a Service (SaaS) also provides a programming
environment that may be limited.
 A type of SaaS, Function as a Service (FaaS) provides standalone functions facilitating microservices.
 FaaS is often fortified with requisite patterns e.g., Façade, Service Registry, and Fail Fast.

4. What is the Optimum Denomination of
Microservices?
Some talk about microservices as entities.
Microservices as classes or components (when contained) provide easy conceptual
migration from Object-Oriented Analysis and Design (OOAD).
 However, classes provide only a static view—insufficient to represent—of a System under
Development (SuD).
 Rather, an SuD is described by what it does: its APIs.
Some other conceive micro services as a method or function—like a one-
method API.
The functional decomposition of the system could be a way to denominate
microservices.
The atomicity of microservices may encourage reusability through generality.
 A do-something business service may be broken down into microservices such as form-filling,
form-saving, and form-submitting that can be reused for do-something-else business service.

5. What are Best Practices with
Microservices?
 Microservices being individually maintained and versioned should be indirected through a registry.
 The business services’ clients need not know which microservices need be called to fulfill their requirements.
 An instrumentality should check health of microservices periodically: if a microservice has failed, it should fail fast
the business services that use it.
 The ‘talkative’ REST protocol may cause avoidable strain on computing resources: consider HATEOS.

6. What/Why is Service Registry
Business services would refer to the registry, instead of a particular
microservice.
Anew version of a microservice needs to be registered (or the
previous version rolled back, in case of a failure) without making any
change in the business processes that use them.
Netflix ‘Eureka’ provides a ready-to-use implementation of Service
Registry via Spring Cloud.

7. What/Why is Façade?
The Gang of Four pattern Façade is known as API Gateway in
microservices parlance.
It decouples clients from the microservices by providing a business
service abstraction layer in-between.
Amazon Web Service has API Gateway. So has Netflix Zuul, NGiNX,
Spring Cloud Gateway, etc.
The link to a comparative study can be found here.

8. What/Why Fail Fast?
Sometimes, a microservice may fail or
become slow—any calls to the
corresponding business services would be
wasteful.
A periodic health-check of microservices
should be instituted.
 If a microservice passes the health-check, it is
deemed to be working normally; otherwise
abnormally.
For all abnormal microservices, all
dependent business services should fail fast.
 They should be failed by the façade, without
the façade calling any of the microservices
corresponding to the business service that
associates a failed microservice.
 If the client has a stub of the façade, it may not
even make a request to the façade in the first
place.
Refer to Spring Cloud Circuit Breaker.
Normal Abnormal
Performing
health-check
States (boxes)/Transitions (arrows)

9. Why Microservices Should
Not Use Talkative REST?

10. What is Talkative REST?
Is a protocol that returns everything, often unnecessary.
The SOAP is bounded by the WSDL, whereas REST isn’t.
A REST call may beget data that is not required.
Or, not required immediately.
Puts unnecessary demand on computing resources.
Network bandwidth.
Processor.
Memory.
A way to get data on demand could be useful.
Cf. lazy loading.
Especially suitable for microservices that aims for resource-optimization.

11. What is Hypermedia as the Engine of
Application State (HATEOS)?
Works only with matching data repositories/entity objects.
Such repositories are used in a REST object to create hyperlinks to other
REST objects.
Much like how HTTP uses links within a document to refer to other documents.
Thus, a complex object can be loaded progressively and as required.
Works best if such objects are designed hierarchically.
Optimizes use of computational resources—a great way to improve
performance of enterprise applications.
HATEOS is built atop the REST protocol.
Spring Boot can easily be integrated with HATEOS