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.

Decomposing the monolith into embeddable microservices using OWIN, WebHooks, Event Sourcing and the Onion Architecture

751 views

Published on

If I have to name a single hype in software architecture land then I would have to mention the micro-service architecture. Microservices are supposed to be small, have a very focused purpose, can be deployed independently, are completely self-supporting and loosely coupled. Ideally, microservices are technology agnostic, but hey, we're in the .NET space, aren't we? And they are not a goal, but a means to an end. In fact, a microservice architecture has many benefits and are a great strategy for decomposing a monolith. So how do you build a microservice? What technologies does the .NET realm offer for us? And what if you don't want to deploy them independently? In this talk, I'll show you some of the pros and cons of microservices and how you can leverage Event Sourcing, OWIN and .NET to move your monolith into a bright new future.

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Decomposing the monolith into embeddable microservices using OWIN, WebHooks, Event Sourcing and the Onion Architecture

  1. 1. Dennis Doomen | @ddoomen | Aviva Solutions | The Continuous Improver
  2. 2. Also known as the Microservices Premium
  3. 3. Hybrid of Front-end Technologies Multiple patterns for the same problems Long compile time Large source control repositories Long-running unit tests Too much coupling Limited team scalability Devs need to know everything NoIsolationProductivity drops over time.
  4. 4. • The network is reliable • Latency is zero • Bandwidth is infinite • The network is secure • Topology doesn't change • There is one administrator • Transport cost is zero • The network is homogeneous. https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
  5. 5. The First Law of Distributed Computing
  6. 6. Very scalable, very reliable Very difficult to debug distributed problems Unreliable network requires complicated techniques Requires message bus/broker End-to-end testing very unpractical Very mature DevOps culture is a prerequisite Advanced monitoring and visualization is a must Security can not be an afterthought High operational maintenance. Can be deployed/upgraded independently. Explosion of network activity
  7. 7. Monolith Microservice Microservice Microservice HTTP API HTTP API HTTP API OWIN component released through MyGet/Nuget No network I/O at all Can have its own database instance, shared with monolith, or shared storage service Microservice owns the schema Separate repos with distinct owners. Runs in-process, thus easier debugging New version requires redeployment of the monolith. Loose coupling through HTTP Less scalability options HTTP is not the fastest serialization format Designed for minimum dependencies
  8. 8. Client IIS Console WinSvc Unit Test HTTP request HTTP response Middleware environment handler next Middleware IDictionary<string, object> Func<IDictionary<string, object>, Task> Task Func< Func<IDictionary<string, object>, Task>, Func<IDictionary<string, object>, Task> >
  9. 9. Monolith Microservice HTTP API Service Registry Contract documented through Swagger Webhooks Microservice Microservice Provides OWIN- aware HttpClient to connect to service Event payload exposed as Swagger (e.g. SwaggerHub) Subscribers register URLs or in-process OWIN message handler API/payload consumers use liberal JSON interpretation Circuit Breaking to handle unreliable (future) consumers At-least-once payload delivery Subcribers can request replays. Payload includes ID to help idempotency Each request requires correlation ID that flows through all APIs, webhooks and services
  10. 10. Aggregates Command Handlers Queries Commands Events Upconverters Value Objects Query Handlers Schema Migrations Projectors Data Importers Query API Projections HTML CSS JS API Controllers Projectors Projections Registrations Webhook API Command API Event Storage Domain Services Payload Definitions Outer layers depend on inner layers Domain is persistency ignorant Can be tested independentlyFor eventual consistent business rules Master data For microservices that provide a (partial) UI or management screen Based on Domain Driven Design To persist the domain To support domain queries
  11. 11. UI / HTTP API Command Service CorrectUser EmailHandler User User Projector DAL Read DB Write DB CorrectUserEmailCommand Execute query Get<User>(identity) CorrectEmail Event Store Load(events) Apply Changes Get changes Dispatcher Events Handle(UserEmailCorrectedEvent) Submit changes Dennis Doomen | @ddoomen | The Continuous Improver History
  12. 12. Monolith Microservice HTTP API Event Store Events Payload Projector Subscription Request Payload ‘event store’ Have their own checkpoints Projects fine-grained events into payload projections Projector Payload schema is documented using Swagger Projector Projector Webhook Projectors Separate instance per subscription Subscriber HTTP API ‘Project’ payload ‘events’ into HTTP calls Projected Data Uses the incoming payloads as an ‘event store’ Payload Use Circuit Breakers to handle slow/unavailable subscribers SQL DB Schema changes using FluentMigrator or using NoSQL DB Subscription Request
  13. 13. Domain Event Store Events App RDBMS Events Projection EventsProjection Projection Projector Optimized for specific queries Separate projections database NoSQL Projector Projection-specific storage Projector HTML Raw SQL or Dapper Run asynchronously Great for sharding Dennis Doomen | @ddoomen | The Continuous Improver
  14. 14. Events Transaction 6 Transaction 5 Transaction 4 Transaction 3 Transaction 2 Transaction 1 Temporal Projector Read Store Time Projected until this point Immutable, thus auditable and SOX compliance Dennis Doomen | @ddoomen | The Continuous Improver
  15. 15. Domain Event Store Events App Events Projection EventsProjection Projection Projector Application projections RDBMS Reporting Projector Traditional reporting model Asynchronous OLAP Dennis Doomen | @ddoomen | The Continuous Improver
  16. 16. Dennis (v4) Persisted State Changes Dennis (v3) Role Granted PasswordChangedEvent Dennis (v4) Dennis (v3) User Created Role Granted Phone Number Added Password Changed Dennis (v5) Role Revoked Dennis (v6) Role Granted Time Dennis (v7) Password Changed Dennis Doomen | @ddoomen | The Continuous Improver
  17. 17. Events 1 2 3 6297 6298 6298 Projections Documents Groups Users Objects Folders Microservice V2 Changes Queries Events 1 2 3 6299 6300 6301 Projections Documents Groups Users Objects Folders Microservice V1 ChangesQueries Migration Process Dennis Doomen | @ddoomen | The Continuous Improver
  18. 18. Events Aggregate Root Entity Entity Value Object Aggregate Root Aggregate Root Aggregate Root Entity Value Object Value Object Dennis Doomen | @ddoomen | The Continuous Improver
  19. 19. Designing your domain based on ownership
  20. 20. Relying on eventual consistent projections
  21. 21. Bad choice in functional keys (e.g. username vs ID)
  22. 22. Running business logic after an domain event is raised
  23. 23. Domain-specific value types in events
  24. 24. Ask questions about consistency Understand the real world
  25. 25. Driven by invariants, not composition Only consistent within aggregate Small aggregates Reference by identity
  26. 26. • Column constraints (e.g. data truncation) • Changes in data invariants (null vs non- null in event versions) • Unexpected projection dependencies • Partial replays.
  27. 27. • Causing duplicate child records • Causing large event streams • Incorrect caching strategy (e.g. on lookups) • Identity case-sensitivity • Incomplete SQL-backed event store reads.
  28. 28. • Side by side rebuilding • Functional archivability and archiving • Projection tracking and ETAs • Prioritization • Partitioning.
  29. 29. • After bugs, schema changes, etc • Manual or automatic (e.g. hashes)
  30. 30. Prerequisites - Microservice owns ‘schema’ - Supports upgrading and downgrading - NoSQL preferred, but RDBMS can work too.
  31. 31. Rebuild schema in-place – Rebuilding using event store – Requires tracking API – Involves down-time.
  32. 32. Disallow breaking changes – Only new ‘columns’ and ‘tables’ – Partial rebuilding using event store – Requires forwards compatibility.
  33. 33. Rebuild side-by-side – Rebuilding using event store – Requires tracking API – Requires compatibility with previous ‘schema’ – Previous ‘schema’ is removed in the next release.
  34. 34. Microservice Bunch of classes that should be used directly X No inheritance Uses composition over inheritance internally Convenience classes that don’t hide the magic Library Abstract Package Interfaces Delegates DTOs Only depend on abstract packages… Stable Package …or depend on more stable packages Auxiliary Package Classes that are not used together do not belong togetherOptional Dependency Dependency Package Consumers should not be faced with optional dependencies
  35. 35. public interface IEventStore { IDisposable Subscribe( long? lastCheckpoint, Func<Transaction[]>, Task> handler, string subscriptionId); } public delegate IDisposable CreateSubscription( long? lastCheckpoint, Func<Transaction[]>, Task> handler, string subscriptionId);
  36. 36. e.g. LibLog, TinyIoc, FluidCaching
  37. 37. Aggregates Command Handlers Queries Commands Events Upconverters Value Objects Query Handlers Schema Migrations Projectors Data Importers Query API Projections HTML CSS JS API Controllers Projectors Projections Registrations Webhook API Command API Event Storage Domain Services Payload Definitions Liquid Projections RavenDB + LiquidProjections.RavenDB NHibernate + LiquidProjections.NHibernate WebAPI / Nancy Swashbuckle / Nancy.Swagger Logging w/ Liblog Composition w/ TinyIocNEventStore + LiquidProjections.NEventStore EventStore / SqlStreamStore Fluent Migrator JSFOTD + Embedded Resources OWIN Middleware.
  38. 38. Library Consumer LiquidProjections LiquidProjections.Abstractions Transaction Delegates LiquidProjections. NEventStore NHibernate LiquidProjections NHibernate RavenDB LiquidProjections RavenDB LiquidProjections. Testing
  39. 39. Monolith Microservice Microservice Microservice HTTP API HTTP API HTTP API Apply routing conventions Versioning using Accept Headers, Response Headers or Routes Optimize body using AVRO or Protobuf Cross-service tracing using OpenTracing Replace OWIN with (upcoming) in- process gRPC Common contracts for diagnostics, monitoring Add KPI dashboards, e.g. Sumologic
  40. 40. 1 Build a (container-based) cloud capability. 2 Deploy monolith to the cloud. 3 Automate your delivery pipeline. 4 Full end-to-end responsibility 5 Break-up delivery teams and code 6 Evaluate status-quo on micro-services (products, platforms, etc) 7 Slide-and-dice microservices one-by- one.
  41. 41. • Liquid Projections – The Example https://github.com/liquidprojections • Bliki: MonolithFirst https://dzone.com/articles/martin-fowler%E2%80%94bliki • In-process gRPC https://github.com/grpc/grpc-go/issues/906 • Protobuf in WebAPI http://www.infoworld.com/article/2982579/application- architecture/working-with-protocol-buffers-in-web-api.html • Ingredients for well-design OWIN components http://www.continuousimprover.com/search/label/OWIN%20Recip es • The good, the bad and the ugly of Event Sourcing http://www.continuousimprover.com/search/label/event%20sourci ng

×