Microservices architecture
•Download as PPTX, PDF•
3 likes•146 views
The document discusses the key concepts of microservices architecture including domain analysis, data management, communication between services, monitoring, and security. It describes techniques for handling data across multiple microservices like using separate databases per service or event sourcing. Communication methods like API gateways, message queues, and service registration/discovery are also outlined. The presentation provides examples of implementing microservices for a reference application and discusses important considerations for moving microservices to production.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Microservices architecture
Similar to Microservices architecture (20)
Recently uploaded
Recently uploaded (20)
Microservices architecture
- 1. Microservices Architecture Presented by: Muhammad Zeeshan December 12,2018
- 2. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. Microservices
- 3. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. 3 Domain Analysis
- 5. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. Data
- 6. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. Bounded Context (boundaries of each microservice)
- 7. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. • Shared Database • Anti-pattern • Database per service • Different service can use different storage • SQL, Elastic Search (SOLR) or NO-SQL • More databases to maintain • API Composition • Event Sourcing 7 Data techniques
- 8. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. 8 • Database per service • Different service can use different storage • SQL, Elastic Search (SOLR) or NO-SQL • More databases to maintain Consistency across multiple microservices
- 9. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. Service subscribe to related events in order to keep an updated view of the required data whilst avoiding bulk data transfers that are both time consuming and also resource inefficient. 9 Event Sourcing
- 10. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. 10 Query data from multiple microservices
- 11. Communication 11
- 12. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. 12 Service Registration - Self
- 13. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. 13 Service Registration -Third party registration
- 14. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. 14 Service Discovery
- 15. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. Client-to-microservice communication
- 16. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. Open Source .NET Core API Gateway Products with API Gateway features Azure API Gateway
- 17. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. 17 API Gateway pattern
- 18. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. • Authentication and authorization • Service discovery integration • Response caching • Retry policies, circuit breaker and QoS • Rate limiting and throttling • Load balancing • Logging, tracing, correlation • Headers, query strings and claims transformation • IP whitelisting Disadvantages • Coupling that tier with the internal microservices • Single point of failure • API Gateway can introduce increased response time API Gateway pattern
- 19. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. Communication (Across Microservices) • Protocol • Synchronous • Asynchronous • AMQP • Receiver • Single receiver • Multiple receivers
- 20. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. 20 Message-based communication – Single Receiver
- 21. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. 21 Message-based communication – Multiple Receivers
- 22. Monitoring 22
- 23. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. • Failover Mechanism • Circutbreaker • Health-check API Fault tolerance
- 24. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. Distributed Logging Logging with correlation IDs
- 25. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. • Application Insights • InfluxDB Pull based • Prometheus Push based • Dashboard tool such as Kibana or Grafana • Fluentd with Elasticsearch 25 Logging and auditing
- 27. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. • User identity & access control • Use automatic security updates • Use a distributed firewall with centralized control • Use security scanners • Monitor everything Best Practices
- 28. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. 28 Defence in depth Antivirus software Authentication Biometrics Demilitarized zones (DMZ) Data-centric security Encryption Key Firewalls (hardware or software) Hashing passwords Intrusion detection systems (IDS) Logging and auditing Multi-factor authentication Vulnerability scanners Timed access control Virtual private network (VPN) Sandboxing Intrusion Protection System (IPS)
- 29. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. Azure KeyVault • Generate RSA key • Rotation of encryption keys used • Cancellation of a compromised communication channel • Retrying the message on a different channel or to a different node without worrying about a breach. 29 Encryption Key
- 31. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. 31 ReferenceApplication
- 32. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. 32
- 33. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. 33 Composite UI
- 34. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. Going into production with a Microservices-based system: • Monitoring and health checks of the services and infrastructure. • Scalable infrastructure for the services (that is, cloud and orchestrators). • Security design and implementation at multiple levels: authentication, authorization, secrets management, secure communication, etc. • Rapid application delivery, usually with different teams focusing on different Microservices. • DevOps and CI/CD practices and infrastructure. Important aspects
- 35. © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. Next… Orchestrators
- 36. Sitecore Confidential © 2001-2017 Sitecore Corporation A/S. All rights reserved. Sitecore® and Own the Experience® are registered trademarksof Sitecore Corporation A/S. All other brand and product names are the property of their respective owners. Q & A
Editor's Notes
- As the name implies, a microservices architecture is an approach to building a server application as a set of small services. That means a microservices architecture is mainly oriented to the back-end, although the approach is also being used for the front-end. Each service runs in its own process and communicates with other processes using protocols such as HTTP/HTTPS, WebSockets, or AMQP. Each microservice implements a specific end-to-end domain or business capability within a certain context boundary, and each must be developed autonomously and be deployable independently. Finally, each microservice should own its related domain data model and domain logic (sovereignty and decentralized data management) and could be based on different data storage technologies (SQL, NoSQL) and different programming languages.
- Start with a bounded context. In general, the functionality in a microservice should not span more than one bounded context. By definition, a bounded context marks the boundary of a particular domain model. If you find that a microservice mixes different domain models together, that's a sign that you may need to go back and refine your domain analysis. Next, look at the aggregates in your domain model. Aggregates are often good candidates for microservices. A well-designed aggregate exhibits many of the characteristics of a well-designed microservice, such as: An aggregate is derived from business requirements, rather than technical concerns such as data access or messaging. An aggregate should have high functional cohesion. An aggregate is a boundary of persistence. Aggregates should be loosely coupled. Domain services are also good candidates for microservices. Domain services are stateless operations across multiple aggregates. A typical example is a workflow that involves several microservices. We'll see an example of this in the Drone Delivery application. Finally, consider non-functional requirements. Look at factors such as team size, data types, technologies, scalability requirements, availability requirements, and security requirements. These factors may lead you to further decompose a microservice into two or more smaller services, or do the opposite and combine several microservices into one.
- Approaches to managing data There is no single approach that's correct in all cases, but here are some general guidelines for managing data in a microservices architecture. Embrace eventual consistency where possible. Understand the places in the system where you need strong consistency or ACID transactions, and the places where eventual consistency is acceptable. When you need strong consistency guarantees, one service may represent the source of truth for a given entity, which is exposed through an API. Other services might hold their own copy of the data, or a subset of the data, that is eventually consistent with the master data but not considered the source of truth. For example, imagine an e-commerce system with a customer order service and a recommendation service. The recommendation service might listen to events from the order service, but if a customer requests a refund, it is the order service, not the recommendation service, that has the complete transaction history. For transactions, use patterns such as Scheduler Agent Supervisor and Compensating Transaction to keep data consistent across several services. You may need to store an additional piece of data that captures the state of a unit of work that spans multiple services, to avoid partial failure among multiple services. For example, keep a work item on a durable queue while a multi-step transaction is in progress. Store only the data that a service needs. A service might only need a subset of information about a domain entity. For example, in the Shipping bounded context, we need to know which customer is associated to a particular delivery. But we don't need the customer's billing address — that's managed by the Accounts bounded context. Thinking carefully about the domain, and using a DDD approach, can help here. Consider whether your services are coherent and loosely coupled. If two services are continually exchanging information with each other, resulting in chatty APIs, you may need to redraw your service boundaries, by merging two services or refactoring their functionality. Use an event driven architecture style. In this architecture style, a service publishes an event when there are changes to its public models or entities. Interested services can subscribe to these events. For example, another service could use the events to construct a materialized view of the data that is more suitable for querying. A service that owns events should publish a schema that can be used to automate serializing and deserializing the events, to avoid tight coupling between publishers and subscribers. Consider JSON schema or a framework like Microsoft Bond, Protobuf, or Avro. At high scale, events can become a bottleneck on the system, so consider using aggregation or batching to reduce the total load.
- An important rule for microservices architecture is that each microservice must own its domain data and logic. Just as a full application owns its logic and data, so must each microservice own its logic and data under an autonomous lifecycle, with independent deployment per microservice. This means that the conceptual model of the domain will differ between subsystems or microservices. Consider enterprise applications, where customer relationship management (CRM) applications, transactional purchase subsystems, and customer support subsystems each call on unique customer entity attributes and data, and where each employs a different Bounded Context (BC). This principle is similar in Domain-driven design (DDD), where each Bounded Context or autonomous subsystem or service must own its domain model (data plus logic and behavior). Each DDD Bounded Context correlates to one business microservice (one or several services). (We expand on this point about the Bounded Context pattern in the next section.)
- Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships. This principle is similar in Domain-driven design (DDD), where each Bounded Context or autonomous subsystem or service must own its domain model (data plus logic and behavior). Each DDD Bounded Context correlates to one business microservice (one or several services). (We expand on this point about the Bounded Context pattern in the next section.)
- Define a view database, which is a read-only replica that is designed to support that query. The application keeps the replica up to data by subscribing to Domain events published by the service that own the data.
- Consider the following questions when developing a large application based on microservices: • How can client apps minimize the number of requests to the backend and reduce chatty communication to multiple microservices? Interacting with multiple microservices to build a single UI screen increases the number of roundtrips across the Internet. This increases latency and complexity on the UI side. Ideally, responses should be efficiently aggregated in the server side—this reduces latency, since multiple pieces of data come back in parallel and some UI can show data as soon as it is ready. • How can you handle cross-cutting concerns such as authorization, data transformations, and dynamic request dispatching? Implementing security and cross-cutting concerns like security and authorization on every microservice can require significant development effort. A possible approach is to have those services within the Docker host or internal cluster, in order to restrict direct access to them from the outside, and to implement those cross-cutting concerns in a centralized place, like an API Gateway. • How can client apps communicate with services that use non-Internet-friendly protocols? Protocols used on the server side (like AMQP or binary protocols) are usually not supported in client apps. Therefore, requests must be performed through protocols like HTTP/HTTPS and translated to the other protocols afterwards. A man-in-the-middle approach can help in this situation. • How can you shape a façade especially made for mobile apps? The API of multiple microservices might not be well designed for the needs of different client applications. For instance, the needs of a mobile app might be different than the needs of a web app. For mobile apps, you might need to optimize even further so that data responses can be more efficient. You might do this by aggregating data from multiple microservices and returning a single set of data, and sometimes eliminating any data in the response that is not needed by the mobile app. And, of course, you might compress that data. Again, a façade or API in between the mobile app and the microservices can be convenient for this scenario.
- Cross-cutting concerns or gateway offloading. Depending on the features offered by each API Gateway product, you can offload functionality from individual microservices to the gateway which will simplify the implementation of each microservice by consolidating cross-cutting concerns into one tier. This is especially convenient for specialized features that can be complex to implement properly in every internal microservice such as the following functionality. • Authentication and authorization • Service discovery integration • Response caching • Retry policies, circuit breaker and QoS • Rate limiting and throttling • Load balancing • Logging, tracing, correlation • Headers, query strings and claims transformation • IP whitelisting
- Communication types Client and services can communicate through many different types of communication, each one targeting a different scenario and goals. Initially, those types of communications can be classified in two axes. The first axis is defining if the protocol is synchronous or asynchronous: Synchronous protocol. HTTP is a synchronous protocol. The client sends a request and waits for a response from the service. That is independent of the client code execution that could be synchronous (thread is blocked) or asynchronous (thread is not blocked, and the response will reach a callback eventually). The important point here is that the protocol (HTTP/HTTPS) is synchronous and the client code can only continue its task when it receives the HTTP server response. Asynchronous protocol. Other protocols like AMQP (a protocol supported by many operating systems and cloud environments) use asynchronous messages. The client code or message sender usually does not wait for a response. It just sends the message as when sending a message to a RabbitMQ queue or any other message broker. The second axis is defining if the communication has a single receiver or multiple receivers: Single receiver. Each request must be processed by exactly one receiver or service. An example of this communication is the Command pattern. Multiple receivers. Each request can be processed by zero to multiple receivers. This type of communication must be asynchronous. An example is the publish/subscribe mechanism used in patterns like Event-driven architecture. This is based on an event-bus interface or message broker when propagating data updates between multiple microservices through events; it is usually implemented through a service bus or similar artifact like Azure Service Bus by using topics and subscriptions.
- An important point is that you might want to communicate to multiple microservices that are subscribed to the same event. To do so, you can use publish/subscribe messaging based on event-driven communication. This publish/subscribe mechanism is not exclusive to the microservice architecture. It is similar to the way Bounded Contexts in DDD should communicate, or to the way you propagate updates from the write database to the read database in the Command and Query Responsibility Segregation (CQRS) architecture pattern. The goal is to have eventual consistency between multiple data sources across your distributed system. Your implementation will determine what protocol to use for event-driven, message-based communications. AMQP can help achieve reliable queued communication. When you use an event bus, you might want to use an abstraction level (like an event bus interface) based on a related implementation in classes with code using the API from a message broker like RabbitMQ or a service bus like Azure Service Bus with Topics. Alternatively, you might want to use a higher-level service bus like NServiceBus, MassTransit, or Brighter to articulate your event bus and publish/subscribe system.
- In microservices architecture when a request come in, it will go through a series microservies What if the middle of services break down.
- We are going to use Eg like Sitecore, we forced to change our password after 3 months. This allows the cancellation of a compromised communication channel, rotation of the encryption keys used and retrying the message on a different channel or to a different node without worrying about a breach. https://devops.com/building-a-solid-foundation-for-microservices-security/ I couldn’t find any famework to do this, is like key management services that sole purpose to serve the key
- Easy to get started sample reference microservice and container based application. Cross-platform on Linux and Windows Docker Containers, powered by .NET Core 2.1, Docker engine and optionally Azure, Kubernetes or Service Fabric. Supports Visual Studio 2017, VS for Mac and CLI based environments with Docker CLI, dotnet CLI, VS Code or any other … https://github.com/dotnet-architecture/eShopOnContainers