Microservices Architecture
Download as PPTX, PDF0 likes287 views
The document discusses microservices as an architectural style for building distributed applications using loosely coupled services, highlighting their autonomy, scalability, and resilience. It addresses the pain points associated with microservices, such as increased complexity and challenges in state management and communication. Additionally, it contrasts microservices with traditional service-oriented architecture (SOA) and emphasizes the importance of domain-driven design in identifying and managing business capabilities within microservices.
Microservices Architecture
- 2. Microservices “If you are looking for a technical solution for what it is a business problem, you are looking the wrong way.”
- 3. The monolithic software weak points oArchitecture/Solution is hard to evolve. oDifficult to Scale. oLong development pipeline (build, test, release). oAdding a feature takes time. oA lot of time between releases. oContinous Delivery is challenging.
- 4. Microservices definition Microservices is an architectural design for building a distributed application using containers.
- 5. Microservices a «better» definition Microservices is an “architectural style” for building a distributed application as a collection of small and loosely coupled services (each service implementing a business capability). Services should have the following properties…
- 6. Microservices «properties»: •Autonomy. •Small and Focused on a single «thing». •Independent Development: the right tools for the right job! •Independent Deployment. •Independent Scalability.
- 7. Microservices «properties»: •Reusable (through composition). •Owned by a small team. •Designed for Failure / No single point of failure: the system can “degrade”, but it should never be fully down. •Promotes the adoptions of new technologies.
- 8. Microservices promise to be like: The Monolith (the big ball of mud) Service 1 Service 3 Website Service 4 APP Service 7 Service 6 Service 5 Service 8 Service 10 Service 2 Service 9
- 9. Microservices leads to Reactive Systems https://www.reactivemanifesto.org/ Loosely Coupled Loose coupling through async message passing Resilient Error containment Fault tolerance and recovery Elastic Scalability React to workload change Responsive Rapid and consistent response times A Reactive System is made of services and components that have the following properties:
- 10. Microservices «pain points» •Increased complexity for developers. •Increased complexity for operators. •Increased complexity for devops (ALM madness!). •It requires serious expertise. •Unclear or not well defined Service Boundaries. •(Distributed) State management ?
- 11. Microservices «pain points» •Versioning. •Communications issues. •Distributed Transactions: Can they be avoided? At which cost? •Performances: many services with many «dependencies» = many network calls! •Managing and «orchestration»: logging, monitoring, discovery, etc... •Debugging.
- 12. Distributed computing is hard! The fallacies of distributed computing: 1. The network is reliable. 2. Latency is zero. 3. Bandwidth is infinite. 4. The network is secure. 5. Topology doesn't change. 6. There is one administrator. 7. Transport cost is zero. 8. The network is homogeneous. And we always underestimate: 1. Error Handling, Failures and Recovery. 2. Performance and Bottlenecks. 3. Blocking operations. 4. Concurrency. 5. Consistency. 6. State Management / Locks / Threads. 7. Parallelism. 8. Availability.
- 13. The Microservices thing can become… Service 3 Service 4 APP Service 7 Service 6 Service 5 Service 8 Service 10 Service 9 Service 1 Service 3 Website Service 4 APP Service 7 Service 6 Service 5 Service 8 Service 10 Service 11 Service 9
- 14. Microservices fundamentals Service Oriented Architecture • Ownership of data and behavior. • Autonomy. • And more… Domain Driven Design • Bounded Context. • Aggregate. • Events. Event Driven Architecture • Loose coupling. Patterns & Practices
- 15. The first thing that comes in mind when thinking about «architecture»!
- 16. You cannot fight the «Coupling»!
- 17. A long time ago in a galaxy far, far away…. SOA Service Oriented Architecture A service is a technical authority for a business capability. Any piece of data or rule must be owned by only one service. http://www.soa-manifesto.org/ https://www.infoq.com/articles/tilkov-10-soa-principles https://en.wikipedia.org/wiki/Service-orientation_design_principles
- 19. SOA Service: a definition (sort of) We can define a service by its fundamentals / principles (the four tenets): oServices are autonomous. oServices have well defined boundaries. oServices share contracts and schema. oServices interactions are controlled by policies. A Service provide the implementation for a specific Business Capability! http://www.dbizinstitute.org/resources/articles/four-tenets-service-orientation
- 20. SOA: «decouple» the different business capabilities… in «services»! We might end up with something like this: slices of a layered architecture! Each slice representing a capability of the system! They are Autonomous and Loosely Coupled! Product Catalog Sales Shipping Infrastructure logging, communication, …
- 21. The major problems of SOA: oServices could be «very big» (monolithic services). oToo much tied to a specific technology (Web Services, ESB). oIf done wrong we’ll end up having tight coupling with one service directly calling into another. (welcome the distributed monolith… with latency and reliability problems).
- 22. MicroServices: SOA vNext Microservices is a variant of SOA that structures an application as a collection of loosely coupled services. Services should be fine-grained and the communication protocols should be lightweight. Another Microservices Definition: Microservices is an “architectural style” for building a distributed application as a collection of small and loosely coupled services. A service is a technical authority for a business capability. Any piece of data or rule must be owned by only one service.
- 23. MicroServices: SOA vNext From an “operative” standpoint: Small, independent applications, loosely coupled, communicating (asynchronously) with each other, and can fail independently, and if one or some fails, the system as a whole still works (the functionality might be downgraded).
- 24. How is it different from SOA ? •Tries to reduce the size of services: Small services with a single focus. •Promotes the usage of technology agnostic APIs. • Services can be consumed by other services written in different technologies. •Promotes the usage of independent data storage (for each service). •Promotes the usage of lightweight communication protocols. •Puts the emphasis on loose coupling even more. •Improves the scalability. •Improve the flexibility.
- 25. Microservices goes further! Product Catalog Sales Shipping Infrastructure P.C. Service 1 P.C. Service 3 P.C. Service 4 P.C. Service 5 P.C. Service N P.C. Service 2 S. Service 1 S. Service 2 S. Service 5 S. Service N S. Service 3 S. Service 4 Sales Service 1 Sales Service 2 Sales Service 3 Sales Service 4 Sales Service 5 Sales Service N
- 26. How to «discover» the Services? DDD TO THE RESCUE
- 27. Finding out what’s inside a service We need logical view of the system. Some practices worked very well (for us): oDDD (Domain Driven Design). oEvent Storming.
- 28. Domain Driven Design An approach to software development for «complex systems» that works promoting the adoption of an evolving domain model, that derives from a collaboration between developers and domain experts to iteratively refine a conceptual model that addresses particular domain problems.
- 29. DDD key concepts Ubiquitous Language - the language used by domain experts and developers that defines elements/processes of the business. Events (and Commands) – facts, evidences that something happened in the business. Aggregate – a cluster of domain objects that represent a single (transactional) unit, it supports the business providing behavior and rules. Bounded Context - the “environment” in which a specific Ubiquitous Language is valid. Context-Map – shows the interactions between Bounded-Contexts.
- 30. Event Storming – talk the (ubiquitous) language of the business! «Tool / Workshop» that allows to quickly explore complex business domains. You can figure out how the system works (how much in detail it is up to you); you’ll also get an overrall idea of the «shape» of the system.
- 31. Aggregate An Aggregate encapsulates state and behavior. An Aggregate guarantees that Business Rules are satisfied. An Aggregate is a «Transactional» and «Computational» Unit. An aggregate accepts Commands and emits Events, Event represents Business Transactions outcome. A DDD aggregate is a cluster of domain objects that can be treated as a single unit. Aggregate Cmd(s) Evt(s) Cmd(s) Evt(s) Evt(s)
- 32. Bounded Contexts Catalog Aggregate(s) Cmd(s) Evt(s) Catalog Aggregate(s) Cmd(s) Evt(s) Catalog Aggregate(s) Cmd(s) Evt(s) Sales Aggregate(s) Cmd(s) Evt(s) Catalog Aggregate(s) Cmd(s) Evt(s) Shipping Aggregate(s) Cmd(s) Evt(s) Catalog Bounded Context Sales Bounded Context Shipping Bounded Context
- 33. Context Map Context Maps draw the relationships between the Bounded Contexts, they are: oConformist relationship: the downstream context might follow and adapt to what the upstream context says. oPartnership relationships (both context work towards a common goal; the same term might exists in multiple contexts with different behaviors). oTechnical relationships (how they talk). A system will almost never be made of a single bounded context, BCs operate toghether to fulfill the system requirements and implement business capabilities. BC 1 BC 3 BC 4 BC 2 External System https://www.infoq.com/articles/ddd-contextmapping
- 34. Bounded Contexts oThey are Autonomous / have Explicit Boundaries: encapsulation, they «contain» everything that’s needed to implement a business capability. oThey share contract and schema: that’s a «communication protocol». BC 1 BC 3 BC 4 BC 2 External SystemBC 1 BC 3 BC 4 BC 2 External System
- 35. Bounded Contexts SOA Services oThey are Autonomous / have Explicit Boundaries: encapsulation, they «contain» everything that’s needed to implement a business capability. oThey share contract and schema: that’s a «communication protocol». BC 1 BC 3 BC 4 BC 2 External System Service 1 Service 3 Service 4 Service 2 External System
- 36. How do Services talk? REDUCING COUPLING IS THE KEY!
- 37. How do these Services communicate? You can still have coupling!!! Shopping Cart Sales bool placeOrder(id, items) Process 1 Shopping Cart Sales bool placeOrder(id, items) In-Process Process 2 H T T P
- 38. BTW… This is coupling too!!! Process 1 Shopping Cart Sales Process 2 The Database The Table
- 39. How do services talk ? o(SYNC) RPC and the likes. o(ASYNC) Messaging.
- 40. RPC and the likes: gRPC, Web Services, anything over TCP, HTTP and so on… In distributed computing, a remote procedure call (RPC) is an Inter-process communication technology that allows a computer program to causes a procedure (subroutine) to execute in a different address space (commonly another process on another computer on a shared network). https://en.wikipedia.org/wiki/Remote_procedure_call
- 41. RPC (underlying concepts) Location Transparency: the function call is coded as if it were a normal (local) procedure call, without the programmer explicitly coding the details for the remote interaction. RPC is typically implemented via a (blocking) request – response message- passing system. Remote calls are usually slower and less reliable than local calls.
- 42. Messaging Message: an immutable data structure used to exchange a piece of information.
- 43. Why Messages are so important? They have properties that open up many scenarios: •Asynchronous Communication. •Can be serialized and stored (debugging, event sourcing). •Can be ordered (priority, deferred elaboration). •Carry metadata / context information (like a reply-to). •Can be forwarded. •Can be broadcasted.
- 44. Messaging Patterns Service ServiceOne Way Service ServiceBroadcast Service Service
- 45. Messaging Patterns Service ServiceProxy Service ServicePub/Sub Service Service Service forward subscribe publish
- 46. Message Delivery Patterns •at-most-once: for each message handed to the mechanism, that message is delivered zero or one times; the messages may be lost. •at-least-once: for each message handed to the mechanism potentially multiple attempts are made at delivering it, until at least one succeeds; the messages may be duplicated but not lost. •exactly-once: for each message handed to the mechanism exactly one delivery is made to the recipient; the message can neither be lost nor duplicated.
- 47. Event Driven Architecture •Event Producers: generate streams of events. •Event Consumers: listen to events. Producers are decoupled from consumers: a producer doesn't know which consumers are listening. Consumers are also decoupled from each other. Every Consumer can potentially see all the events / messages. Event Producer Event Consumer Event Consumer Event Streaming Infrastructure
- 48. Event Driven Architecture Can use two communication models: •Pub/sub: the messaging infrastructure keeps track of subscriptions. After an event is received, it cannot be replayed, and new subscribers do not see past events. •Event streaming: events are written to a durable log. Events are strictly ordered within a partition. Consumers don't subscribe to the stream, instead a consumer can read from any part of the stream. The consumer is responsible for advancing its position in the stream.
- 50. A Microservice in a Distributed App. OWNS and PROTECTS data and behavior… it’s responsible for their exposure to the rest of the system. Ideally, everything that «belongs» to a service is managed by the service itself: oFrom the Databases to the Backend to the UI components (widgets). oThe Team responsible for the service should have expertise in all the areas.
- 51. A Service spans multiple «technologies» and «responsibilities» Product Catalog Sales Logistics Backend ( .net / java / go / … ) Web Portal ( web api / html / javascript / …) Mobile Apps ( .net / xamarin / swift / … ) Microservices is also for scaling People! Not only the Deployment Unit(s)! Team 1 Team 1 Team 1 Team 2 Team 2 Team 2 Team 3 Team 3 Team 3
- 52. When it comes to the physical view… A service is a composition of components and smaller «services»… that collaborate to implement a specific business capability!! The term service is «overloaded» and has slightly different properties: oA service, in this context, is a support entity for other components in order to fulfill very specific tasks. oMight not be fully autonomous. oThere will be coupling, a lot of coupling… there will be cohesion!
- 53. Microservices «Physical View»: composition of components & services Web Crawler (stateful) Crawling Job Coordinator 1 (stateful) Parser 1 (stateless) Downloader 1 (stateless) Analyzer 1 (stateless) Parser n (stateless) Downloader n (stateless) Analyzer n (stateless) Crawling Job Coordinator n (stateful) Parser 1 (stateless) Downloader 1 (stateless) Analyzer 1 (stateless) Parser n (stateless) Downloader n (stateless) Analyzer n (stateless)
- 54. How do we «code» each Service / Bounded Context? Inside a Microservice we can follow any architectural style we want! They are «small» and «autonomous» and «easily replaceable»! (Given we respect the communication protocol contracts).
- 56. CQRS / ES (Aggregate Domain Object)
- 57. We can also consider tools designed to help us build distributed applications Akka (https://akka.io) & Akka.NET (https://getakka.net/) Microsoft Orleans (https://dotnet.github.io/orleans/) Dapr - Distributed Application Runtime (https://dapr.io/)
- 58. Chosing the «communication protocols» at the highest level of the system Product Catalog Service Inventory Service Account Service Sales Service Shipping Service Whatever Service My favorites: • Event Streams. • Enterprise Service Bus. • Independent Queues. Less favorites: • Lightweight RPC (gRPC / WebServices). Event Streams / ESB
- 59. Communications «within» a Microservice If our Microservice can be made of a subset of cohesive sub-services: •Few stateful services. •Many stateless services. We can deploy them on several machines (cluster), how do they communicate? My Favorites: •RPC. •Async Messaging. Crawling Job Coordinator 1 (stateful) Parser 1 (stateless) Downloader 1 (stateless) Analyzer 1 (stateless) Parser n (stateless) Downloader n (stateless) Analyzer n (stateless)
- 60. Microservices + API Gateway + Monolithic UI https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout
- 61. Microservices + UI Composition https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout
- 62. Microservices Lifecycle Management ? Microservices are biased towards organizations with multiple teams. oBest practices as Continous Integration / Continous Deployment should be encouraged. oMultiple backlogs (Agile, SCRUM, Kanban, etc…) ? oMultiple Repositories ? oMultiple Deployment tools & Deployment Strategies ?
- 63. So we have all our nice Microservices… How do we package them? How do we deploy them? How do we orchestrate & manage them? How do we monitor them? How do we handle failing microservices?
- 64. Resources – Distributed Applications •Designing Data-Intensive Applications https://www.amazon.it/Designing-Data-Intensive-Applications-Reliable- Maintainable/dp/1449373321 •Designing Distributed Systems https://www.amazon.it/Designing-Distributed-Systems-Patterns-Paradigms/dp/1491983647
- 65. Resources - Microservices •Microservices.io https://microservices.io/ •Building Microservices https://www.amazon.it/Building-Microservices-Sam-Newman/dp/1491950358 •.NET Architecture Guides https://dotnet.microsoft.com/learn/dotnet/architecture-guides •.NET Microservices Architecture Guidance https://dotnet.microsoft.com/learn/aspnet/microservices-architecture •.NET Microservices: Architecture for Containerized .NET Applications https://docs.microsoft.com/en-us/dotnet/architecture/microservices/
- 66. Resources – DDD •Domain Driven Design https://www.amazon.it/Domain-Driven-Design-Tackling-Complexity-Software- ebook/dp/B00794TAUG/ •Implementing Domain Driven Design https://www.amazon.it/Implementing-Domain-Driven-Design-English-Vaughn- ebook/dp/B00BCLEBN8 •Strategic Domain Driven Design with Context Mapping https://www.infoq.com/articles/ddd-contextmapping/
- 67. Resources – Reactive Applications •Reactive Design Patterns https://www.amazon.it/Reactive-Design-Patterns-Roland-Kuhn/dp/1617291803/ •Reactive Messaging Patterns with the Actor Model https://www.amazon.it/dp/B011S8YC5G
- 68. Keep in touch Dott.ing. Alessandro Giorgetti Facebook: https://www.facebook.com/giorgetti.alessandro Twitter: @a_giorgetti LinkedIn: https://it.linkedin.com/in/giorgettialessandro E-mail: alessandro.giorgetti@live.com Blog: www.primordialcode.com Alessandro Giorgetti www.primordialcode.com