Microservices architecture
Download as PPTX, PDF4 likes1,485 views
The document discusses microservices architecture, which is an approach to developing applications as a suite of small, independent services that communicate via lightweight mechanisms. It highlights the limitations of monolithic applications, such as challenges in scalability and frequent deployments, and outlines the characteristics, benefits, and principles of microservices, including decentralized governance, infrastructure automation, and fault isolation. Additionally, it covers various design patterns, such as API gateways and service registries, and emphasizes the importance of service independence and organization around business capabilities.
Microservices architecture
- 1. Microservices Architecture Fundamental and Practice
- 2. Fundamental
- 3. What is Microservices? An approach to developing a single application as a suite of small services, each running of its own process and communication with lightweight mechanism, often HTTP resource API. ~ Martin Fowler
- 4. Start from Monolithic Monolithic is opposite of microservices. It is a common system that nowdays used. It is application built as single unit. Applications are often built in three main parts: client-side, database, server-side. Server side handle HTTP request, execute domain logic, retrieve & update DB, select the view or respond to client. This server side application is a monolith.
- 5. The limit of monolithic Monolithic applications can be successful, but increasingly people are feeling frustrations with them, especially more applications are being deployed to the cloud. Change cycles are tied together Over time it's often hard to keep a good modular structure Scaling requires scaling of the entire application
- 7. Characteristic of Microservices Architecture Componentization via services Organized around Business Capabilities Products not Projects Smart endpoints and dumb pipes Decentralized Governance Decentralized Data Management Infrastructure Automation Design for failure
- 8. Componentization via services a component is a unit of software that is independently replaceable and upgradeable. One main reason for using services as components (rather than libraries) is that services are independently deployable.
- 9. Organized around Business Capabilities Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. -- Melvyn Conway, 1967 The microservice approach to division is different, splitting up into services organized around business capability.
- 10. Products not Projects Microservice proponents tend to avoid this model, preferring instead the notion that a team should own a product over its full lifetime. The product mentality, ties in with the linkage to business capabilities. The smaller granularity of services can make it easier to create the personal relationships between service developers and their users. “You build, You run it” - Werner Vogels - CTO of Amazon
- 11. Smart endpoints and dumb pipes Applications built from microservices aim to be as decoupled and as cohesive as possible. The two protocols used most commonly are HTTP request-response with resource API's and lightweight messaging. By using simple RESTish protocols rather than complex protocols By using messaging over a lightweight message bus. The infrastructure chosen is typically dumb. simple implementations such as RabbitMQ or ZeroMQ don't do much more than provide a reliable asynchronous fabric Be of the web, not behind the web -- Ian Robinson
- 12. Decentralized Governance One of the consequences of centralised governance is the tendency to standardise on single technology platforms. Experience shows that this approach is constricting - not every problem is a nail and not every solution a hammer. In this case microservices could be like this: You want to use Node.js to standup a simple reports page? Go for it. C++ for a particularly gnarly near- real-time component? Fine. You want to swap in a different flavour of database that better suits the read behaviour of one component? We have the technology to rebuild him.
- 13. Decentralized Data Management ( 1 ) At the most abstract level, it means that the conceptual model of the world will differ between systems. This issue is common between applications, but can also occur within applications, particular when that application is divided into separate components. A useful way of thinking about this is the Domain-Driven Design notion of Bounded Context. As well as decentralizing decisions about conceptual models, microservices also decentralize data storage decisions.
- 14. Decentralized Data Management (2)
- 15. Infrastructure Automation Teams building software this way make extensive use of infrastructure automation techniques. as much confidence as possible that our software is working, so we run lots of automated tests. Promotion of working software 'up' the pipeline means we automate deployment to each new environment.
- 16. Design for failure Any service call could fail due to unavailability of the supplier, the client has to respond to this as gracefully as possible. Since services can fail at any time, it's important to be able to detect the failures quickly and, if possible, automatically restore service. That’s why, microservices have a lot of monitoring process, real-time monitoring, business relevant metrics, log and so on.
- 17. Evolutionary Design Evolutionary Design is see service decomposition as a further tool to enable application developers to control changes in their application without slowing down change. Whenever you try to break a software system into components, you're faced with the decision of how to divide up the pieces. what are the principles? The key property of a component is the notion of independent replacement and upgradeability.
- 19. The Pattern Monolithic Architecture Microservices Architecture API Gateway Client-side discovery Server-side discovery Service Registry Self Registration 3rd party Registration Multiple service instance per host Single service instance per host Service instance per VM Service instance per Container Database per service
- 20. Monolithic Architecture (1) ● Simple to develop ● Simple to deploy ● Simple to scale However: The large monolithic code base intimidates developers, especially ones who are new to the team. The application can be difficult to understand and modify. As a result, development typically slows down. Overloaded IDE Overloaded web container
- 21. Monolithic Architecture (2) However: Continuous deployment is difficult - a large monolithic application is also an obstacle to frequent deployments. Scaling the application can be difficult - a monolithic architecture is that it can only scale in one dimension. Obstacle to scaling development - A monolithic application is also an obstacle to scaling development. Requires a long-term commitment to a technology stack - a monolithic architecture forces you to be married to the technology stack (and in some cases, to a particular version of that technology) you chose at the start of development .
- 22. Microservices Architecture (1) ● 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 scale development. It enables you to organize the development effort around multiple teams. Each (two pizza) team is responsible a single service. ● Improved fault isolation. For example, if there is a memory leak in one service then only that service will be affected. ● Eliminates any long-term commitment to a technology stack
- 23. Microservices Architecture (2) Another challenge is deciding how to partition the system into microservices. This is very much an art, but there are a number of strategies that can help. Partition services by verb or use case. Partition the system by nouns or resources.
- 24. Related Pattern
- 25. API Gateway Implement an API gateway that is the single entry point for all clients. The API gateway handles requests in one of two ways. The API Gateway must use either the Client-side Discovery pattern or Server- side Discovery Pattern to route requests to available service instances.
- 26. Client-side Discovery (1) Services typically need to call one another. In a traditional distributed system deployment, services run at fixed, well known locations (hosts and ports) and so can easily call one another using HTTP/REST. a modern microservice-based application typically runs in a virtualized or containerized environments where the number of instances of a service and their locations changes dynamically.
- 27. Client-side Discovery (2) The Benefit is fewer moving parts and network hops compared to Server-side registry. This pattern couples the client to service registry.
- 28. Server-side Discovery When making a request to a service, the client makes a request via a router (a.k.a load balancer) that runs at a well known location. The router queries a service registry. More network hops are required than when using Client-side discovery AWS provide this functionality, e.g. AWS Elastic Load Balancer
- 29. Service Registry (1) a database of services, their instances and their locations. Service instances are registered with the service registry on startup and deregistered on shutdown. Examples of service registries (or technologies that are commonly used as service registries) include: Eureka Apache Zookeeper Consul Etcd
- 30. Service Registry (2) The Service Registry is a critical system component. Although clients should cache data provided by the service registry, if the service registry fails that data will eventually become out of date. Consequently, the service registry must be highly available. You need to decide how service instances are registered with the service registry. There are two options: ● Self registration pattern - service instances register themselves ● 3rd party registration pattern - a 3rd party register the service instances with the service registry Note: Service registry instances must be deployed on fixed and well known IP addresses
- 31. Self Registration A service instance is responsible for registering itself with the service registry. On startup the service instance registers itself (host and IP address) with the service registry and makes itself available for discovery. Drawbacks: You must implement service registration logic in each programming language/framework that you use to write your services A service instance that is running yet unable to handle requests will often lack the self-awareness to unregister itself from the service registry
- 32. 3rd Party Registration A 3rd party registrar is responsible for registering and unregistering a service instance with the service registry. Examples: Netflix Prana, AWS Autoscaling Groups, Joyent's Container buddy, Registrator, Clustering frameworks such as Kubernetes and Marathon (un)register service instances with the built-in/implicit registry. Drawback: Unless the registar is part of the infrastructure it’s another component that must be installed, configured and maintained. Also, since it’s a critical system component it needs to be highly available.
- 33. Multiple Services per host Run multiple instance of services on a host (Physical or Virtual machine). There are various ways of deploying a service instance on a shared host including: Deploy each service instance as a JVM process. For example, a Tomcat or Jetty instances per service instance. Deploy multiple service instances in the same JVM. For example, as web applications or OSGI bundles. Drawbacks: Risk of conflicting resource requirements / dependency versions Difficult to limit the resources consumed by a service instance Difficult to monitor process
- 34. Single Service per host Deploy each single service instance on it’s own host. The benefits of this approach include: Services instances are isolated from one another There is no possibility of conflicting resource requirements or dependency versions A service instance can only consume at most the resources of a single host Its straightforward to monitor, manage, and redeploy each service instance Drawbacks: Potentially less efficient resource utilization
- 35. Database per service (1) Keep each microservice’s persistent data private to that service and accessible only via its API. The following of example:
- 36. Database per service (2) if you are using a relational database then the options are: Private-tables-per-service – each service owns a set of tables that must only be accessed by that service Schema-per-service – each service has a database schema that’s private to that service Database-server-per-service – each service has it’s own database server.
- 37. Additional
- 38. The Scale Cube X-axis scaling consists of running multiple copies of an application behind a load balancer. Y-axis axis scaling splits the application into multiple, different services. 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.
- 39. CAP Theorem(1) Consistency (C), Availability (A), and Partition tolerance (P) across distributed systems. Simply put, the CAP theorem demonstrates that any distributed system cannot guaranty C, A, and P simultaneously, rather, trade-offs must be made at a point-in-time to achieve the level of performance and availability required for a specific task.
- 40. CAP Theorem (2)
Editor's Notes
- #11: A common inspiration for this is Amazon's notion of "you build, you run it" where a development team takes full responsibility for the software in production.
- #17: Netflix's Simian Army induces failures of services and even datacenters during the working day to test both the application's resilience and monitoring.
- #18: The Guardian website is a good example of an application that was designed and built as a monolith, but has been evolving in a microservice direction. The monolith still is the core of the website, but they prefer to add new features by building microservices that use the monolith's API. This approach is particularly handy for features that are inherently temporary, such as specialized pages to handle a sporting event. Such a part of the website can quickly be put together using rapid development languages, and removed once the event is over. We've seen similar approaches at a financial institution where new services are added for a market opportunity and discarded after a few months or even weeks.