Microservices architecture
•Download as PPTX, PDF•
1 like•408 views
This document discusses microservices architecture as an alternative to monolithic architecture. It outlines the objectives of microservices such as allowing independent scalability, continuous deployment, and productivity for new developers. The key aspects covered include scaling approaches, advantages of microservices like independent deployability and fault tolerance, potential drawbacks around complexity, and strategies for partitioning monolithic applications into microservices.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to Microservices architecture
Similar to Microservices architecture (20)
Recently uploaded
Recently uploaded (20)
Microservices architecture
- 3. Monolithic Architecture All functionality is coupled in single process The application is either layered or hexagonal Presentation layer Business layer Data layer Integration layer
- 5. Objectives There is a team of developers working on the application New team members must quickly become productive The application must be easy to understand and modify Ensure continuous deployment of the application
- 6. Objectives Must satisfy scalability and availability requirements Introducing technologies
- 7. Scale Cube
- 10. Z axis scaling
- 11. Microservices
- 12. Advantages Each microservice is small Each service can be deployed independently Easier to scale development Increases faultorance Eliminate long term association with technology stack
- 13. Drawbacks Complexity of creating distributed system Deployment complexity Additional memory consumption
- 14. How to partition By verb or use case By nouns or resources
- 15. Which one to choose At the early stage of the application when challenge is how to rapidly adapt business model At stage when scale is important
Editor's Notes
- The book, The Art of Scalability, describes a really useful, three dimensional scalability model: the scale cube.
- X-axis scaling consists of running multiple copies of an application behind a load balancer. If there are N copies then each copy handles 1/N of the load. This is a simple, commonly used approach of scaling an application. One drawback of this approach is that because each copy potentially accesses all of the data, caches require more memory to be effective. Another problem with this approach is that it does not tackle the problems of increasing development and application complexity.
- Unlike X-axis and Z-axis, which consist of running multiple, identical copies of the application, Y-axis axis scaling splits the application into multiple, different services. Each service is responsible for one or more closely related functions. There are a couple of different ways of decomposing the application into services. One approach is to use verb-based decomposition and define services that implement a single use case such as checkout. The other option is to decompose the application by noun and create services responsible for all operations related to a particular entity such as customer management. An application might use a combination of verb-based and noun-based decomposition.
- When using Z-axis scaling each server runs an identical copy of the code. In this respect, it’s similar to X-axis scaling. The big difference is that each server is responsible for only a subset of the data. Some component of the system is responsible for routing each request to the appropriate server. One commonly used routing criteria is an attribute of the request such as the primary key of the entity being accessed. Another common routing criteria is the customer type. For example, an application might provide paying customers with a higher SLA than free customers by routing their requests to a different set of servers with more capacity. Z-axis splits are commonly used to scale databases. Data is partitioned (a.k.a. sharded) across a set of servers based on an attribute of each record. In this example, the primary key of the RESTAURANT table is used to partition the rows between two different database servers. Note that X-axis cloning might be applied to each partition by deploying one or more servers as replicas/slaves. Z-axis scaling can also be applied to applications. In this example, the search service consists of a number of partitions. A router sends each content item to the appropriate partition, where it is indexed and stored. A query aggregator sends each query to all of the partitions, and combines the results from each of them. Z-axis scaling has a number of benefits. Each server only deals with a subset of the data. This improves cache utilization and reduces memory usage and I/O traffic. It also improves transaction scalability since requests are typically distributed across multiple servers. Also, Z-axis scaling improves fault isolation since a failure only makes part of the data in accessible. Z-axis scaling has some drawbacks. One drawback is increased application complexity. We need to implement a partitioning scheme, which can be tricky especially if we ever need to repartition the data. Another drawback of Z-axis scaling is that doesn’t solve the problems of increasing development and application complexity. To solve those problems we need to apply Y-axis scaling.
- Each microservice is relatively small Easier for a developer to understand The IDE is faster making developers more productive The web container starts faster, which makes developers more productive, and speeds up deployments Each service can be deployed independently of other services - easier to deploy new versions of services frequently Easier to scale development. It enables you to organize the development effort around multiple teams. Each (two pizza) team is responsible a single service. Each team can develop, deploy and scale their service independently of all of the other teams. Improved fault isolation. For example, if there is a memory leak in one service then only that service will be affected. The other services will continue to handle requests. In comparison, one misbehaving component of a monolithic architecture can bring down the entire system. Each service can be developed and deployed independently Eliminates any long-term commitment to a technology stack
- Developers must deal with the additional complexity of creating a distributed system. Developer tools/IDEs are oriented on building monolithic applications and don't provide explicit support for developing distributed applications. Testing is more difficult Developers must implement the inter-service communication mechanism. Implementing use cases that span multiple services without using distributed transactions is difficult Implementing use cases that span multiple services requires careful coordination between the teams Deployment complexity. In production, there is also the operational complexity of deploying and managing a system comprised of many different service types. Increased memory consumption. The microservices architecture replaces N monolithic application instances with NxM services instances. If each service runs in its own JVM (or equivalent), which is usually necessary to isolate the instances, then there is the overhead of M times as many JVM runtimes. Moreover, if each service runs on its own VM (e.g. EC2 instance), as is the case at Netflix, the overhead is even higher.
- This is very much an art, but there are a number of strategies that can help. One approach is to partition services by verb or use case. For example, later on you will see that the partitioned e-commerce application has a Shipping service that’s responsible for shipping complete orders. Another common example of partitioning by verb is a login service that implements the login use case. Another partitioning approach is to partition the system by nouns or resources. This kind of service is responsible for all operations that operate on entities/resources of a given type. For example, later on you will see how it makes sense for the e-commerce system to have an Inventory service that keeps track of whether products are in stock. Ideally, each service should have only a small set of responsibilities. (Uncle) Bob Martin talks about designing classes using the Single Responsibility Principle (SRP). The SRP defines a responsibility of a class as a reason to change, and states that a class should only have one reason to change. It make sense to apply the SRP to service design as well. Another analogy that helps with service design is the design of Unix utilities. Unix provides a large number of utilities such as grep, cat and find. Each utility does exactly one thing, often exceptionally well, and can be combined with other utilities using a shell script to perform complex tasks.