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.

Een andere kijk op Microservices


Published on

Heb je ook een onderbuik gevoel dat er iets mis is als mensen praten over microservices? Alsof je verplicht bent services te bouwen van hooguit enkele regels code, die expliciet autonoom en los inzetbaar zijn, en altijd via REST moeten communiceren? Iedereen zegt dat je deployment goed op orde moet hebben, omdat dit anders een nachtmerrie wordt, maar niemand geeft een oplossing. In deze sessie geven we je een andere kijk op microservices en hoe je dit ook kunt implementeren binnen je bestaande architectuur.

Published in: Technology
  • Be the first to comment

Een andere kijk op Microservices

  1. 1. in a Microservices Architecture Dennis van der Stelt Software Architect
  2. 2. v a n d e r s t e l t 2 Your presenter Dennis van der Stelt Software Architect About Dennis Innovative software architect Almost 20 years of experience in development of distributed systems. Has a continuous drive to learn and improve knowledge in different architectural styles, including quality in software development. Highly motivated to share his knowledge via articles, presentations and his blog. Awards NServiceBus Champ Typemock MVP Certified Trainer Professional Services Provides coaching & training • Presentations • Software & Architecture audits • SOA & Microservices advice • Unit Testing training • NServiceBus training Presentations October 15th at Blaak Selectie / Betabit Reliable systems using messaging
  3. 3. v a n d e r s t e l t 3 Agenda In a polyglot architectural landscape with a lot of business logic, data and information, how can we build solid loosely coupled systems? Let’s have a look at the differences between those opposites Monolithic vs Microservices Dividing your system’s business logic over logical boundaries Service Boundaries Why duplicating data is a bad practice, but replicating data is perfectly fine Replicating vs Duplicating
  4. 4. v a n d e r s t e l t Monolithic application Wikipedia : large, powerful, and intractably indivisible and uniform. A monolithic application is build and deployed as a single unit. WordPress is a successful & scalable monolithic application used by millions! Monolith is therefor not by default a badly designed system 4
  5. 5. v a n d e r s t e l t 5 Microservices a software architectural style for complex applications of small, independent processes. services are small, highly decoupled and focus on a single task communicate via language agnostic APIs boundaries are explicit services are autonomous share schema & contract, not classes compatibility is based on policy
  6. 6. v a n d e r s t e l t Monolithic application 6 single deployment unit
  7. 7. v a n d e r s t e l t Microservices 7 multiple deployable services
  8. 8. v a n d e r s t e l t Authentication 8 Coupling OSS ViewModel Change Product Database Razor
  9. 9. v a n d e r s t e l t 9 First law “My First Law of Distributed Object Design: Don't distribute your objects” Martin Fowler in Patterns of Enterprise Application Architecture
  10. 10. v a n d e r s t e l t 10 Monolithic application problems Problem Analysis of all monolithic systems are build with high time constraints, resulting in big balls of mud in which no developer can find their way. 42% Maintenance The coupling makes it hard to change anything Documentation Cost to add new features Building the 100th feature as fast as the 1st Project Ownership
  11. 11. v a n d e r s t e l t Monolithic application 11
  12. 12. v a n d e r s t e l t 12
  13. 13. v a n d e r s t e l t 13 Microservices “don't even consider microservices unless you have a system that's too complex to manage as a monolith” Martin Fowler
  14. 14. BOUNDED CONTEXTDividing your system’s business logic over logical boundaries
  15. 15. v a n d e r s t e l t 15 Microservices architecture Deployment Don’t necessarily need to separately deploy every single service Bounded Context Define boundaries around logical business processes Monitoring Document message flows and monitor them with great tools Messaging Asynchronous communication via messaging & publish/subscribe
  16. 16. v a n d e r s t e l t Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure. “ ”Conway’s law – 1968
  17. 17. v a n d e r s t e l t Service boundaries 17 Shipping FinanceSales Marketing
  18. 18. v a n d e r s t e l t Deployment 18 Shipping FinanceSales Marketing SQL SQL { }
  19. 19. v a n d e r s t e l t Architectural style 19 Shipping FinanceSales Marketing CQRS Event Sourcing CRUD there is no top level architecture
  20. 20. v a n d e r s t e l t Coupling aspects 20 SpatialTemporalPlatform
  21. 21. v a n d e r s t e l t 21 -Alan Kay- Creator of SmallTalk, Adjunct Professor at MIT & University of California At Utah sometime after Nov 66 when, influenced by Sketchpad, Simula, the design for the ARPAnet, the Burroughs B5000, and my background in Biology and Mathematics, I thought of an architecture for programming. It was probably in 1967 when someone asked me what I was doing, and I said: "It's object-oriented programming".
  22. 22. v a n d e r s t e l t 22
  23. 23. v a n d e r s t e l t Messaging 23 Shipping FinanceSales Marketing SQL
  24. 24. v a n d e r s t e l t Messaging 24 Shipping FinanceSales Marketing SQL
  25. 25. v a n d e r s t e l t Messaging 25 Shipping FinanceSales Marketing SQL Publish / Subscribe
  26. 26. v a n d e r s t e l t 26 Messaging Handle business events through Inversion of communication by supplementing SOA with EDA “ ”
  27. 27. v a n d e r s t e l t 27 Resume Service Boundaries Try to see if your organizational communication structure can be the model for your logical service boundaries. Messaging Avoid RPC style communication between services. Use messaging with an event driven architecture. Deployment Don’t necessarily see every microservice as a deployable unit. Do keep an eye out for coupling. Avoid joins in your database between entities.
  28. 28. DUPLICATION vs REPLICATIONWhy you shouldn’t duplicate, but replicate data
  29. 29. v a n d e r s t e l t 29 Do not duplicate across service boundaries You can share… some information Publish / Subscribe to notify in advance
  30. 30. v a n d e r s t e l t 30 Duplicating data What event just took place business process related events that other services require to properly function and take action on Status changes Identifiers Date Time Info Who was the subject the triggered event has a specific subject in our domain When does the status expire when status updates expire or are no longer relevant at a point in time, we provide expiration information
  31. 31. v a n d e r s t e l t Sales Messaging 31 Taxi Customers TaxiRequested TaxiRequested RequestTaxi
  32. 32. v a n d e r s t e l t Sales Messaging 32 Taxi TaxiRequested RequestTaxi Finance TaxiAssigned Customers
  33. 33. v a n d e r s t e l t Sales Messaging 33 Taxi RequestCancelled Finance RequestCancelled CancelRequest
  34. 34. v a n d e r s t e l t 34 Replicating vs Duplicating data So duplication of data is not good But what about this replicating data?
  35. 35. v a n d e r s t e l t 35 Replicating vs Duplicating data So duplication of data is not good But what about this replicating data? Replicating within a service boundary is okay for performance or connectivity issues
  36. 36. v a n d e r s t e l t 36 Replicating data options Performance optimization Suitable for all categories business and personal presentation In memory cache Prepare for optimal querying Prepare data for querying, for example into a specific readmodel / viewmodel Resolve latency issues Replicating data across physical machines does not break service boundaries Resolve network issues Different sites across the globe, or a moving site without connection, like a large container ship Viewmodels Different machines Different sites
  37. 37. v a n d e r s t e l t 37 Composite UI; little micro views Sales Lists requests made by customer Customer Displays customer information such as name and current location Taxi Shows where taxi drivers are and at what time they arrive at your location Finance Displays status of all financial transactions and outstanding bills
  38. 38. IMPLEMENTINGinto your own system
  39. 39. 39 Implementation Find edge cases New features that are added (not integrated) into your system Publish messages to it Start using messaging and publish/subscribe for communication Add small databases Do not integrate into your big ball of mud database; keep it seperate Pay attention to logical boundaries A service is the technical authority of a specific business capability
  40. 40. MONITORINGyour services
  41. 41. v a n d e r s t e l t 41 Monitoring
  42. 42. v a n d e r s t e l t 42 Monitoring
  43. 43. v a n d e r s t e l t 43 Monitoring
  44. 44. v a n d e r s t e l t 44 Resume; how we build microservices Define Boundaries Define boundaries of your services. Your organizational structure may help. Do not duplicate data across services. Share status changes, identifiers and date-times. Implement Implement your microservices that handle a single task. Use publish/subscribe to notify other services with status changes. Composite UI Everything from data up until the user interface should belong in a service, resulting in a composite ui that retrieves data based on the mentioned identifiers. Deploy Deploy your microservices, but not necessarily as single units. A possibility is a deployment unit per service boundary.
  45. 45. v a n d e r s t e l t 45 Microservices can be hard to build, deploy & monitor. Get help from people with experience Think about temporal coupling between services and how to solve this, possibly with messaging Do not duplicate data between services, as at some point business logic will follow Conclusion
  46. 46. v a n d e r s t e l t 46
  47. 47. v a n d e r s t e l t 48 Contact Me Address Rotterdam, The Netherlands Email Twitter @dvdstelt Website Thank you for your time…