Examples of microservice architecture.
The objective of this lesson is to show
examples of breaking monolithic application into microservices.
The airline example.
Here's a fictitious example of an application with a microservice architecture.
From the red book,
Microservices from Theory to Practice.
This example is in Chapter 8, Scenario 3,
Modifying the ACBI error application and adding full terminus capabilities.
Notice that the main organization means something to business users.
For an application for booking airline tickets,
you need multiple components.
Each is a fairly independent business task that can
be developed separately and in priority order.
Each service has quality of service targets.
In addition, each service has login, metrics,
health check, service endpoint,
service registry, and service management.
The initial task is to book a flight.
That service uses related services to find out when flights are available,
the cost of the flight, and which seats are available.
After booking the flight,
the inventory needs to be adjusted.
The customer's record needs to be updated and the rewards program needs to change.
The number of instances for service can be
increased as shown here with the booking service.
With a monolithic application,
the entire application would have to scale.
Finally, all these services are loosely coupled with well defined interfaces.
The sample airline architecture.
In the past, three-tier architectures were common.
Typically, the three layers were the user interface layer,
the business logic layer,
and the back-end persisted data layer.
Well, you can still see that structure is different in that
each layer is divided into separate services.
Notice in this diagram showing the microservice architecture,
that the data storage, proceeding charts,
fair rules, flight schedules,
and sales are separate and closely associated only with a single related service.
Different business channels, specifically travel aggregator,
and the airline mobile app,
and the airline website,
all have access to the various business functions.
But if one of those channels failed,
the other channels could continue.
Now, you have an app model for each client type,
not a single app model layer that spans the entire application.
Monolith first: peeling away services.
This next example shows the strategy of beginning with
a monolithic application and peeling away
some services to begin the transformation into microservices.
The example is a stock trading application.
The monolithic version was known as Day Trader,
and the vision is called Cloud Trader.
See scenario one, transforming
a monolithic application to use microservices cloud trader,
in the red book, Microservices from Theory to Practice, for more information.
In the monolithic version,
the trade direct class contains the bulk of the business operations: orders,
quotes, accounts, and holdings.
This structure is common in monolithic applications.
A single class is responsible for all the main business functions.
Using this strategy of decomposing a monolith by peeling away services,
two services were separated out: quotes and accounts.
Microservices. Using different services can be written in different languages.
The quote service was written using NodeJS to demonstrate this point.
The quote service uses a new IBM cloud database.
But in production, it would use a live feed.
They can't service reused existing Java code
still running on the IBM WebSphere Application server Liberty.