Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Let's talk about... Microservices


Published on

It's easy to say... Microservices! Reality is we need to learn and apply concepts coming from many disciplines like SOA, EDA and DDD just to name a few! Mix them with some ALM and technical processes around Packaging and Deploying... and maybe then you get a true Microservices solution.

Published in: Software
  • Login to see the comments

Let's talk about... Microservices

  1. 1. Let’s talk about… Microservices Alessandro Giorgetti
  2. 2. “If you are looking for a technical solution for what it is a business problem, you are looking the wrong way.”
  3. 3. The monolithic software - weak points oArchitecture is hard to evolve. oDifficult to Scale. oLong development pipeline (build, test, release) oAdding a feature can take time. oA lot of time between releases. oContinous Delivery is challenging.
  4. 4. What is a Microservice ? Microservice
  5. 5. 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
  6. 6. Microservices «benefits»: •Autonomy. •Independent Development: the right tools for the right job! •Independent Deployment. •Independent Scalability. •Reusability (through composition).
  7. 7. Microservices «benefits»: •A single service is entirely managed by a single team. •Teams & People scalability. •No single point of failure: the system can “degrade”, but it should never be fully down. •Promotes the adoptions of new technologies.
  8. 8. Microservices leads to Reactive Systems 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 components that have the following properties:
  9. 9. 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 ?
  10. 10. 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»: service monitoring, gateways, discovery, logging, etc... •Debugging.
  11. 11. 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.
  12. 12. The Microservices thing can become… Service 1 Service 3 Website 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
  13. 13. Is it so dramatic? The true biggest problem of Microservices is not a technical one! Many of the «problems» are caused by: misunderstanding, not knowing or not using concepts from: SOA, EDAand DDD, + some implementation & communication patterns. Before jumping the Microservices bandwagon it’s better to know some of the “fundamentals” that will help you build a proper Microservices-enabled Ecosystem.
  14. 14. Microservices fundamentals Service Oriented Architecture • Ownership of data and behavior. • Autonomy. • And more… Event Driven Architecture • Loose coupling. Domain Driven Design • Bounded Context. • Aggregate. • Events. Patterns & Practices
  15. 15. This is how we used to think about services: a layered architecture!
  16. 16. You cannot fight the «Coupling»!
  17. 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.
  18. 18. SOA Elements Web Services
  19. 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. All of this to provide the implementation for a specific Business Capability!
  20. 20. So… what is the SOA solution to this ?
  21. 21. SOA: isolate the different business capabilities… in services We might end up with something like this: slices of our layered architecture! Each slice representing a capability of the system! They are Autonomous and Loosely Coupled! Product Catalog Shopping Cart Order Management Infrastructure logging, communication, …
  22. 22. You can still have coupling!!! Shopping Cart Order Management bool placeOrder(id, items) Process 1 Shopping Cart Order Management bool placeOrder(id, items) In-Process Process 2 H T T P
  23. 23. BTW… This is coupling too!!! Process 1 Shopping Cart Order Management Process 2 The Database The Table
  24. 24. The major problems of SOA: 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).
  25. 25. Welcome «Micro-Services»: SOA 2.0 Microservices is a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices based system, services should be fine-grained and the protocols should be lightweight. Small, independent applications, loosely coupled, communicating with each other in an asynchronous manner, and can fail independently, and if one or some fails, the system as a whole still works, though the functionality might be downgraded when there are failures.
  26. 26. Why Loose Coupling? We should reduce the coupling between the services in order to: oAllow for independent evolution of each service (development / deployment). oMake it easier to scale out part of the System. oLimit the friction between the services. oExchange information between services implemented with different technologies. Design the communication protocol around «messages»: Message/Event Driven Architecture.
  27. 27. Finding out what’s inside a service Build a logical view of the system. Some practices proven to work very well (for us): oDDD (Domain Driven Design). oEvent Storming.
  28. 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. Key concepts: oUbiquitous language. oBounded contexts. oContext maps. oAggregates / Commands / Events (Messages).
  29. 29. DDD key concepts Ubiquitous Language - the language used by domain experts and developers that defines elements/processes of the business. Bounded Context - the environment in which a specific Ubiquitous Language is valid. Context-Map – shows the interactions between Bounded-Contexts. Aggregate – a cluster of domain objects that represent a single (transactional) unit, that supports the business providing behavior. Events – facts, evidences that something happened in the business.
  30. 30. Event Storming «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. 31. Bounded Contexts oUbiquitous Language: the language defined between users and developers that defines elements of the business. oAggregates: clusters of objects that can be treated as a transactional and processing unit. oBounded Context: the environment in which a specific Ubiquitous Language is valid. o Each Bounded Context defines a «business boundary»  technical boundaries and other things follows. BC 1 Aggregate(s) Cmd(s) Evt(s) BC n Aggregate(s) Cmd(s) Evt(s) Msg(s) Msg(s)
  32. 32. 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
  33. 33. Domain Driven Design DDD promotes breaking the system into autonomous pieces that collaborate to implement the business rules. We used to have a magical word for these pieces!
  34. 34. Bounded Contexts are… 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. 35. Bounded Contexts are similar to 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. 36. How do they talk ? o(SYNC) RPC and the likes. o(ASYNC) Messaging.
  37. 37. RPC and the likes: 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).
  38. 38. RPC Location Transparency: it 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.
  39. 39. Messaging Message: an immutable data structure used to exchange a piece of information.
  40. 40. 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 and delegated. •Can be broadcasted.
  41. 41. Messaging Patterns Service ServiceOne Way Service ServiceBroadcast Service Service
  42. 42. Messaging Patterns Service ServiceProxy Service ServicePub/Sub Service Service Service forward subscribe publish
  43. 43. 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.
  44. 44. DDD + EDA + SOA = Microservices SOA + EDA enables us to have a system where loosely coupled services do not directly talk to each other, but rather employ a message based style of communication. With DDD we gain greater knowledge of service boundaries (bounded contexts), business logic and data ownership and encapsulation.
  45. 45. DDD + EDA + SOA = Microservices DDD Aggregates define the transactional consistency boundary and limit the scope and size of the implementation. This is where a Microservice (or a set of Microservices) starts to surface.
  46. 46. Let’s revisit some of the MicroServices «problems» •Coupling/Undefined Service Boundaries? DDD to the rescue! (coupling between microservices that don’t belong to the same Bounded Context or DDD Aggregate? Step back and review the aggregates). •Distributed Transactions? Boundaries are wrong! The purpose of an aggregate is to provide a transactional consistency boundary. •(Distributed) State Management? Kinda the same of a distributed transaction: you need to guarantee consistency among different boundaries  boundaries are wrong (again)!
  47. 47. Time to get «physical» What is the METRIC that defines «micro» ?
  48. 48. Logical Architecture vs. Physical Architecture
  49. 49. A Microservice in a Distributed Environment 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.
  50. 50. A Service spans multiple «technologies» and «responsibilities» Product Catalog Inventory Logistics Backend ( .net / java / go / … ) Web Portal ( web api / html / javascript / …) Mobile Apps ( .net / xamarin / swift / … ) What about the Deployment Unit(s) ? Team 1 Team 1 Team 1 Team 2 Team 2 Team 2 Team 3 Team 3 Team 3
  51. 51. When it comes to the physical view… what’s inside a «Service» ? 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!
  52. 52. Microservices «Physical View»: composition of components & services Web Crawler Coordinator 1 Parser 1 Download 1 Analyzer 1 Parser n Download n Analyzer n Coordinator n Parser 1 Download 1 Analyzer 1 Parser n Download n Analyzer n Web Crawler Service
  53. 53. How do we «code» the Service ? 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).
  54. 54. Multi-Tier Layered Architecture
  55. 55. CQRS / ES (Aggregate  Domain Object)
  56. 56. Microservices + API Gateway + Monolithic UI
  57. 57. Microservices + UI Composition
  58. 58. Deployment problems - Topology oWhat services are available ? oWhat each service do ? oHow do we reach them ? oHow do we scale them ? Possible Solutions: oAPI Gateways. oService Registry / Service Discovery Platforms.
  59. 59. Diagnostics and Failure Management oHow do we know if a service is up and running ? oWhat to do when a request fail ? oHow and where do we implement retry strategies ? oWho is responsible for doing that ? Possible Solutions: oHealth Monitoring / Distributed Tracing. o(wait and) Retry X times. o(wait and) Retry forever. oCircuit Breaker (custom fallback, fail fast, autoheal….).
  60. 60. Do we have tools that can help us build a Microservices solution? Akka ( & Akka.NET ( Microsoft Orleans ( Dapr - Distributed Application Runtime (
  61. 61. So we have all our nice Microservices… How do we package them ? How do we deploy them ? How do we orchestrate & manage them ?
  62. 62. Containers: Package, Deploy, Run! A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings. It’s a true Unit of Deployment: isolate software from its environment and ensure that it works uniformly despite potential differences. Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes in user space.
  63. 63. How to «docker-ize» an application ? On a Windows OS (Windows 10 or Windows Server 2016): oSetup Docker Engine following the instructions: environment?tabs=Windows-10-Client oCreate a dockerfile with the proper directives to instruct the Docker Engine what to do. oUse the Docker CLI and the Dockerfile to: ◦ Build the image of the container. ◦ Run the container itself.
  64. 64. Container «Orchestration» Managing containers by hand is not recommended, things can become complicated quite fast. What if the number of MicroServices/Containers raises and we want to leverage the elasticity of the system scaling up and down when needed? automated container deployment, scaling, and management across a cluster of nodes.
  65. 65. What Kubernetes does It’s a set of independent, composable control processes that drive the system providing: oService discovery and load balancing. oAutomatic bin packing. oSelf-healing. oStorage orchestration. oSecret and configuration management. oHorizontal scaling. oAnd more…
  66. 66. 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 ?
  67. 67. So: Is it an «Architecture» ? Microservices is an implementation approach for distributed systems based on concepts coming from: Service Oriented Architecture, Event Driven Architecture, Domain Driven Design. Microservices also relate to the technical processes around packaging, deploying and management operations.
  68. 68. Resources - Microservices .NET Architecture Guides .NET Microservices Architecture Guidance .NET Microservices: Architecture for Containerized .NET Applications
  69. 69. Resources – DDD / Messaging Domain Driven Design Implementing Domain Driven Design Strategic Domain Driven Design with Context Mapping Reactive Design Patterns Reactive Messaging Patterns with the Actor Model
  70. 70. Resources - Docker / Kubernetes Docker Desktop for Windows (Community Edition) Containers on Windows Documentation Docker images for ASP.NET Core images?view=aspnetcore-3.0 Kubernetes Intro to Windows support in Kubernetes kubernetes/
  71. 71. Keep in touch Alessandro Giorgetti Facebook: Twitter: @a_giorgetti LinkedIn: E-mail: Blog: Alessandro Giorgetti