Decomposing the Monolith (Riga Dev Days 2019)
•Als PPTX, PDF herunterladen•
3 gefällt mir•443 views
A micro-service architecture is a great strategy for decomposing a monolith. In this talk, I’ll show you some of the pros and cons of micro-services and how you can leverage OWIN, .NET, Event Sourcing and the Onion Architecture to gradually move your monolith into a bright new future. If I have to name a single hype in software architecture land then I would have to mention the micro-service architecture. Micro-services are supposed to be small, have a very focused purpose, can be deployed independently, are completely self-supporting and loosely coupled. Ideally, micro-services 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 micro-service architecture has many benefits and are a great strategy for decomposing a monolith. So how do you build a micro-service? 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 micro-services and how you can leverage OWIN, .NET, Event Sourcing and the Onion Architecture to gradually move your monolith into a bright new future.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Decomposing the Monolith (Riga Dev Days 2019)
Ähnlich wie Decomposing the Monolith (Riga Dev Days 2019) (20)
Mehr von Dennis Doomen
Mehr von Dennis Doomen (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Decomposing the Monolith (Riga Dev Days 2019)
- 1. Dennis Doomen | @ddoomen | Aviva Solutions | The Continuous Improver
- 5. Hybrid of 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.
- 8. What is a microservice? From https://martinfowler.com/articles/microservices.html
- 9. Very scalable, very reliable Very difficult to debug distributed problems Unreliable network requires resiliency techniques Requires message bus/broker/ gateway End-to-end testing very unpractical Very mature DevOps culture is a prerequisite Advanced monitoring and visualization is a must High operational maintenance Can be deployed/upgraded independently Explosion of network activity.
- 10. The First Law of Distributed Computing
- 12. Monolith Micro “service” Micro “service” Micro “service” 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
- 14. 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> >
- 15. Monolith Micro “service” HTTP API Service Registry Contract documented through OpenAPI Webhook Micro “service” Micro “service” Provides HTTP abstraction to connect to service Event payload exposed as OpenAPI Subscribers register HTTP abstraction API/payload consumers use liberal JSON interpretation Subcribers can request resending history. Payload includes unique ID to help idempotency Each request requires correlation ID that flows through all APIs, webhooks and services
- 17. Dennis Doomen | @ddoomen | The Continuous Improver Application Domain NoSQL / RDBMS OR/M / DAL Web UI, HTTP API, etc Lucene Index Document Projector Web UI, HTTP API, etc Web UI, HTTP API, etc Domain Commands Events Event StoreProjections Projectors Uses Event Sourcing Uses traditional CRUD architecture Indexing-based architecture Subcribe to webhooks Coarse- grained HTTP requests. Bus Subscribe Publish coarse- grained event
- 18. Aggregates Command Handlers 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 independently 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
- 19. Application Command Service Correct Customer Email Handler Customer Unit of Work Projector Data Access Layer Read Database. Write Database CorrectCustomerEmailCommand HTTP API / In-process invocation Get<Customer>(identity) Correct Email Event Store Load(events) Apply Get changes CustomerEmailCorrectedEvent Submit changes History Dennis Doomen | @ddoomen | The Continuous Improver
- 20. Monolith Micro “service” HTTP API Event Store Events Payload Projector Subscription Request Payload ‘event store’ Have their own checkpoints Projects fine-grained events into payload projections Projector Projector Projector Webhook Projectors Separate instance per subscription Subscriber Callback API ‘Project’ payload ‘events’ into HTTP calls Projected Data Uses the incoming payloads as an ‘event store’. Payload SQL DB Schema changes using code or using NoSQL Subscription Request
- 22. - Micro “service” owns ‘schema’ - Supports upgrading and downgrading - NoSQL preferred, but RDBMS can work too.
- 23. Event Store Projector Application Version 2 Owns schema (e.g. FluentMigrator) Version 1 X Involves down-time until projections are rebuild Dennis Doomen | @ddoomen | The Continuous Improver
- 24. Event Store Projector Application Application Network Load Balancer Event Store Version 1 Version 2 events Projection ProjectorProjection bring off-line Returns HTTP 503 (Service Unavailable) Dennis Doomen | @ddoomen | The Continuous Improver Returns HTTP 503 (Service Unavailable)
- 26. 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 Handelier 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. Prerequisites Projac
- 28. Dennis Doomen | @ddoomen | The Continuous Improver
- 30. Monolith Micro “service” Micro “service” Micro “service” 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
- 32. 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 Evaluate status-quo on micro-services (products, platforms, etc) 6 Slide-and-dice microservices one-by- one 7 Break-up delivery teams and code.
- 33. Dennis Doomen @ddoomen Dennis Doomen | @ddoomen | The Continuous Improver
- 34. • Liquid Projections https://www.liquidprojections.net • 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 https://www.continuousimprover.com/search/label/OWIN%20Reci pes • The good, the bad and the ugly of Event Sourcing https://www.continuousimprover.com/search/label/event%20sourc ing
- 37. 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
- 38. 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
- 39. 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
- 40. 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
- 41. 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
- 42. Events Aggregate Root Entity Entity Value Object Aggregate Root Aggregate Root Aggregate Root Entity Value Object Value Object Dennis Doomen | @ddoomen | The Continuous Improver
- 44. Designing your domain based on ownership
- 45. Relying on eventual consistent projections
- 46. Bad choice in functional keys (e.g. username vs ID)
- 47. Running business logic after an domain event is raised
- 48. Domain-specific value types in events
- 50. Ask questions about consistency Understand the real world
- 51. Driven by invariants, not composition Only consistent within aggregate Small aggregates Reference by identity
- 53. • Column constraints (e.g. data truncation) • Changes in data invariants (null vs non- null in event versions) • Unexpected projection dependencies • Partial replays.
- 54. • Causing duplicate child records • Causing large event streams • Incorrect caching strategy (e.g. on lookups) • Identity case-sensitivity • Incomplete SQL-backed event store reads.
- 55. • Side by side rebuilding • Functional archivability and archiving • Projection tracking and ETAs • Prioritization • Partitioning.
- 56. • After bugs, schema changes, etc • Manual or automatic (e.g. hashes)
- 58. 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
- 61. 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);
- 62. e.g. LibLog, TinyIoc, FluidCaching
- 65. • 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