COMPOSITE

MICROSERVICE
AND
FUTURE OF
MICROSERVICE
 COMPOSITE MICROSERVICE
 A composite microservice makes calls to all the required
microservices, consolidate the data, and transform the data
before sending back.
 A composite UI is precisely generated and composed by the
microservices themselves. Some of the microservices drive the visual
shape of specific areas of the UI. The key difference is that there is
client UI components based on templates, and the data-shaping-UI
ViewModel for those templates comes from each microservice.
 At client application start-up time, each of the client UI components
registers itself with an infrastructure microservice capable of
providing ViewModels for a given scenario. If the microservice
changes the shape, the UI changes also.
 This approach is simplified as there might be other microservices that
are aggregating granular parts that are based on different
techniques. It depends on whether you're building a traditional web
approach (ASP.NET MVC) or an SPA (Single Page Application).
 Each of those UI composition microservices would be similar to a
small API Gateway. But in this case, each one is responsible for a
small UI area.
Aggregator Pattern
 A simple web module will act as a load balancer, which means it
will call different services as per requirements.
 The "Aggregator" is responsible for calling different services one
by one. If we need to apply any business logic over the results of
the service A, B and C, then we can implement the business logic
in the aggregator itself.
Proxy Pattern
 Proxy service may call different services individually.
 In Proxy pattern, we can build one level of extra security by
providing a dump proxy layer. This layer acts similar to the
interface.
Chained Pattern
 As the name suggests, this type of composition pattern will
follow the chain structure. Here, we will not be using anything
in between the client and service layer.
 Instead, we will allow the client to communicate directly with
the services and all the services will be chained up in a such a
manner that the output of one service will be the input of the
next service.
Branch Microservice Pattern
 This is extended version of aggregator pattern and chain
pattern. In this design pattern, the client can directly
communicate with the service.
 Also, one service can communicate with more than one
services at a time. Following is the diagrammatic
representation of Branch Microservice.
Shared Resource Pattern
 Shared resource pattern is actually a conglomerate of all types of
patterns mentioned earlier. In this pattern, the client or the load balancer
will directly communicate with each service whenever necessary. This is
the most effective designing pattern followed widely in most
organizations.
 The Future of Microservices
 Severless/Function as a Service
• We’re already seeing it with serverless and function as a
service. The entire application stack will be commoditized.
More decentralization. More towards real-time for data
science and analytics. Intelligence-driven microservices
with in-memory computer doing real-time analytics with
Spark versus big analytics solutions.
• The move to on-demand compute resources and
serverless architectures will strengthen. Better tooling
for rapidly building and deploying microservices will eliminate
the need for a large upfront investment. Richer third party
microservices that are easy to integrate into a
microservice ecosystem allowing companies to offer more
advanced capabilities more quickly. 
 Cloud
• The immediate future will likely be a deeper integration of
microservice offerings in Google Cloud, AWS, and Azure as it
can help them with their bottom line and make their resource usage
in a more predictable manner. Also taking a large bite out of
commercial virtualization software, and maybe even taking them out
of business since containers offer much of the same end-result and
you can use them on free and open source software.
• Microservices provide a good starting point for the scalability of
the cloud and the other benefits offered by the cloud.
However, moving to the cloud is not simply “lift and shift.”
Microservices are particularly beneficial when building a platform
that many things plug into – it makes a complex problem much
easier.
 Other
• More improvement in service discovery and load routing. Service
to service communications. Shared libraries.
• Making it easy to manage, deploy and connect microservices will
change the way applications will be built. If a microservice is easily
set up and deployed, there’s no reason to start with the monolith.
• Microservices is a big player driving strategic growth for the
organization. In the API economy, microservices are a by-product.
More open and inclined for a microservices architecture.
Applications are built in a fluid way. There will be new languages
and new architectures to transition to.
• Deliver greater business value. Provide greater support for
business functions. Accelerate from containers to container
orchestration. More rapid adoption of the cloud. Fill the gap
between the overall solution for orchestration delivery pipeline.
Support an overarching view of what the process looks like.
THANK YOU!