The document discusses microservice architecture as a method of developing applications as a suite of small, independently deployable services communicating through lightweight mechanisms. It highlights the advantages of microservices, such as independent scalability and polyglot persistence, where various databases can be used based on specific needs. Key components like configuration services and discovery services are essential for managing microservices effectively within a cluster.

1. Microservice Architecture
By Touraj Ebrahimi

2. Monolithic Applications
› A monolithic application is built as a single unit.
Enterprise Applications are built in three parts:
– a database (consisting of many tables usually a relational
database management system),
– a client-side user interface (consisting of HTML pages and/or
JavaScript running in a browser),
– and a server-side application.

3. Monolithic Architecture

4. What is Microservice
In short, the microservice architectural style is an approach to
developing a single application as a suite of small services,
each running in its own process and communicating with
lightweight mechanisms, often an HTTP resource API. These
services are built around business capabilities and
independently deployable by fully automated deployment
machinery. There is a bare minimum of centralized
management of these services, which may be written in different
programming languages and use different data storage
technologies.
Roots: its roots go back at least to the design principles of Unix

5. Other Features of Microservice
› services are independently deployable
› services are independently scalable
› Lightweight containers
› Polyglot programming environment
› Out-of-the-box capabilities
› Security
› Mediation and intelligent routing
› Hot swap-ability
› Monitoring and manageability

6. Complexity VS. Productivity

7. Cons and Pros

8. Granularity of Architectures

10. Microservice Architecture

11. Gartner View

12. Pivotal Cloud Foundry Architecture

13. Scalability

14. Polyglot persistence approach
To make matters worse, different microservices often use
different kinds of databases. Modern applications store
and process diverse kinds of data and a relational
database is not always the best choice. For some use
cases, a particular NoSQL database might have a more
convenient data model and offer much better performance
and scalability. For example, it makes sense for a service
that stores and queries text to use a text search engine
such as Elasticsearch. Similarly, a service that stores social
graph data should probably use a graph database, such as
Neo4j. Consequently, microservices-based applications
often use a mixture of SQL and NoSQL databases, the
so-called polyglot persistence approach.

17. Sample Spring Cloud

18. Ribbon :: Client-Side Load Balancing

19. The graphic Below illustrates a 4-microservice setup, with the connections between them indicating a
dependency.
The configuration service sits at the top, in yellow, and is depended on by the other microservices. The
discovery service sits at the bottom, in blue, and also is depended upon by the other microservices.

20. Configuration Service
› The configuration service is a vital component of any microservices
architecture. Based on the twelve-factor app methodology,
configurations for your microservice applications should be stored in the
environment and not in the project.
› The configuration service is essential because it handles the
configurations for all of the services through a simple point-to-point
service call to retrieve those configurations. The advantages of this are
multi-purpose.
› Let's assume that we have multiple deployment environments. If we have
a staging environment and a production environment, configurations for
those environments will be different. A configuration service might have a
dedicated Git repository for the configurations of that environment. None
of the other environments will be able to access this configuration, it is
available only to the configuration service running in that environment.
Note: twelve-factor :: https://12factor.net/

21. Configuration Service

22. Discovery Service
The discovery service is another vital component of our
microservice architecture. The discovery service handles
maintaining a list of service instances that are available for
work within a cluster. Within applications, service-to-service
calls are made using clients.
Spring Cloud Feign, a client-based API for RESTful microservices
that originated from the Netflix OSS project
Recommendation:,use Netflix Eureka, and the other Consul from
Hashicorp. Having multiple discovery services provides the
opportunity to use one (Consul) as a DNS provider for the
cluster, and the other (Eureka) as a proxy-based API gateway.

23. Feign

24. API Gateway
The API gateway service is another vital component if we are going to
create a cluster of services managing their own domain entities. The
green hexagons below are our data-driven services that manage their
own domain entities and even their own databases. By adding an API
gateway service, we can create a proxy of each API route that are
exposed by the green services.
Let’s assume that both the recommendation service and the movie
service expose their own REST API over the domain entities that they
manage. The API gateway will discover these services through the
discovery service and inject a proxy-based route of the API methods
from the other services. In this way, both the recommendation and
movie microservice will have a full definition of routes available
locally from all the microservices that expose a REST API. The API
Gateway will re-route the request to the service instances that own
the route being requested through HTTP.

25. API Gateway

26. Circuit Breaker

31. Why embracing Microservices

32. Container Orchestration Trends

34. Monolithic :: SOA :: Microservices

35. Frameworks Trends

36. Operation Model and Actual Component
Mapping (Spring and Netflix OSS)

37. Monolithic Frontend Vertical Decomposition Composite Frontend
• development time integration
• Runtime Integration

38. Future of the world