Microservice architecture
Download as PPTX, PDF5 likes569 views
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.
Microservice architecture
- 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.
- 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
- 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.
- 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/
- 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
- 34. Monolithic :: SOA :: Microservices
- 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