Introduction to Microservices
Download as PPTX, PDF0 likes142 views
The document discusses microservices, providing examples and characteristics. Microservices are small, independent services that each perform a specific task and communicate through lightweight protocols. They allow for scalability, flexibility and organic development. However, microservices also introduce more complexity, communication issues and challenges in management and testing across distributed systems. When designing microservices, the appropriate level of granularity must be determined to balance functionality and performance. [/SUMMARY]
Introduction to Microservices
- 1. Microservices TECH9810 - System Architectures
- 2. Microservices ● Microservices are small-scale, stateless, services that have a single responsibility. They are combined to create applications. ● They are completely independent with their own database and UI management code.
- 3. Microservices ● Software products that use micro services have a microservices architecture. ● If you need to create cloud-based software products that are adaptable, scaleable and resilient then design them around a microservices architecture.
- 4. Microservices (Example) ● Let’s look at an example: ● TU Dublin registration, where users provide information about their identity, security information, mobile phone number and email address.
- 5. Microservices (Example) ● Authentication using UID/password. ● Two-factor authentication using code sent to mobile phone. ● User information management e.g. change password or mobile phone number. ● Reset forgotten password.
- 6. Microservices (Example) ● Each of these features could be implemented as a separate service that uses a central shared database to hold authentication information.
- 7. Microservices (Example) ● However, these features are too large to be microservices. To identify the microservices that might be used in the authentication system, you need to break down the coarse-grain features into more detailed functions.
- 10. Microservices Characteristics ● Self-Contained ● Microservices do not have external dependencies. They manage their own data and implement their own user interface.
- 11. Microservices Characteristics ● Lightweight ● Microservices communicate using lightweight protocols, so that service communication overheads are low.
- 12. Microservices Characteristics ● Implementation Independent ● Microservices may be implemented using different programming languages and may use different technologies (e.g., different types of database) in their implementation.
- 13. Microservices Characteristics ● Independently Deployable ● Each microservice runs in its own process and is independently deployable, using automated systems.
- 14. Microservices Characteristics ● Business-oriented ● Microservices should implement business capabilities and needs, rather than simply provide a technical service.
- 16. Microservices Guidelines ● Balance fine-grain functionality and system performance ○ Single-function services mean that changes are limited to fewer services but require service communications to implement user functionality. This slows down a system because of the need for each service to bundle and unbundle messages sent from other services.
- 17. Microservices Guidelines ● Follow the ‘common closure principle’ ○ Elements of a system that are likely to be changed at the same time should be located within the same service. Most new and changed requirements should therefore only affect a single service.
- 18. Microservices Guidelines ● Associate services with business capabilities ○ A business capability is a discrete area of business functionality that is the responsibility of an individual or a group. You should identify the services that are required to support each business capability.
- 19. Microservices Guidelines ● Design services so that they only have access to the data that they need ○ If there is an overlap between the data used by different services, you need a mechanism to propagate data changes to all services using the same data.
- 20. The Good, the Bad, and the Interesting of Microservices
- 21. THE GOOD
- 22. Microservices: Benefits ● Self-Contained ● Microservices are self-contained and run in separate processes. 22
- 23. Microservices: Benefits ● Independence ● In cloud-based systems, each microservice may be deployed in its own container. This means a microservice can be stopped and restarted without affecting other parts of the system. 23
- 24. Microservices: Benefits ● Scalable ● If the demand on a service increases, service replicas can be quickly created and deployed. These do not require a more powerful server so ‘scaling-out’ is, typically, cheaper than ‘scaling up’. 24
- 25. Microservices: Benefits ● Non-monolithic ● It is possible to change or upgrade each service individually rather than upgrading in the entire application. 25
- 26. Microservices: Benefits ● Organic Development ● Microservices allows us to develop an application which is organic (an application which latterly upgrades by adding more functions or modules) in nature. 26
- 27. THE BAD
- 28. Microservices: Weaknesses ● Complexity ● Microservices has all the associated complexities of the distributed system. 28
- 29. Microservices: Weaknesses ● Communication Issues ● There is a higher chance of failure during communication between different services. 29
- 30. Microservices: Weaknesses ● Management ● Difficult to manage a large number of services. 30
- 31. Microservices: Weaknesses ● Network Issues ● The developer needs to solve the problem, such as network latency and load balancing. 31
- 32. Microservices: Weaknesses ● Distributed Testing ● Complex testing over a distributed environment. 32
- 33. THE INTERESTING
- 34. Microservices: Interesting ● How small is too small? ● It's received wisdom that if you are an enterprise, then microservices means breaking up your large, monolithic applications into smaller, discrete functions and technical services. How small? A microservice should have been architected to focus on doing one task, and doing it well. How long would it take to re-implement if you tore it down? A few days or weeks? If the idea of starting again scares you, then your microservice is too big. 34
- 35. Microservices: Interesting ● It’s a distributed architecture! ● Microservices are a distributed architecture and, as such, must be able to communicate over a larger area—across data centers, servers, clusters, and meshes. They must run across networks of varying quality and across different hardware. This will inevitably mean challenges in terms of performance, availability, concurrence, latency, and reliability. 35
- 36. Microservices: Interesting ● “Bounded Context” ● Breaking up monolithic applications into smaller sets of services will require communications between those services to operate in a federated way. This will breed increased network traffic and necessitate more detailed management. You can reduce communications and complexity by grouping services around a problem domain. 36
- 37. Microservices: Interesting ● Autonomy ● Microservices should be architected to be autonomous, able to operate and be maintained without relying on other microservices. If they can operate independently of each other, they will neither be derailed by problems or performance issues in another microservice nor act as a point of failure. All this adds up to performance, scalability, and elasticity. 37
Editor's Notes
- #36: Distributed, therefore, means building an architecture for an application or service that caters to the kinds of variables that can slow performance, reduce availability, and introduce latency. For example, it might mean building an architecture that relies on smaller volumes of data being transported during a transaction, that sees data cached locally, or that relies on stateless transactions. It might mean streamlining the number of service calls needed to complete a transaction. It could entail load balancing, especially if workloads fluctuate according to demand at given times of a day or during an event. On top of architecture comes the need for monitoring and management—using tools to ensure your application or service hits the required service levels and provides warnings when it doesn't.
- #37: This is an idea from Eric Evans, defined as "bounded context," in his book Domain Driven Design. In this approach, particular terms, definitions, and rules related to each other are applied consistently. Lack of consistency is an issue that can, and has, frustrated IT projects long before cloud. It can, for example, be a lack of consistency in project definitions or data in different systems that mean the same thing but are described differently and must be translated or required a schema registry. In the cloud, microservices that are aligned around a problem—within that bounded context—will mean fewer interfaces and chatty interactions.