From f141b7f5518d1db3ecc3d9bda25ae8c8ee30f0c9 Mon Sep 17 00:00:00 2001 From: Cesar De la Torre Date: Wed, 19 Apr 2017 16:20:58 -0700 Subject: [PATCH] Updated 01. Roadmap and Milestones for future releases (markdown) --- ...dmap-and-Milestones-for-future-releases.md | 84 ++++++++----------- 1 file changed, 34 insertions(+), 50 deletions(-) diff --git a/01.-Roadmap-and-Milestones-for-future-releases.md b/01.-Roadmap-and-Milestones-for-future-releases.md index 024c21c..2360424 100644 --- a/01.-Roadmap-and-Milestones-for-future-releases.md +++ b/01.-Roadmap-and-Milestones-for-future-releases.md @@ -7,77 +7,56 @@ - CLI build process using a Docker ASPNETCore build-image (microsoft/aspnetcore-build) with all the needed SDKs so the compilation takes place in the same container recommended to be used in your CI pipeline (Continuous Integration). No need to have all dependencies in the dev machine when using this method. [Using this CI docker-compose file](https://github.com/dotnet/eShopOnContainers/blob/master/docker-compose.ci.build.yml). - Initial basic foundational microservice oriented architecture, easy to get started, described in this **Guide/eBook** (Early DRAFT, still work in progress). -- Support for Windows Containers running on Windows NanoServer using different Docker base images instead of the Linux based images +- Support for Windows Containers running on Windows Server Nano using different Docker base images instead of the Linux based images - INTEGRATION EVENTS with Event Bus implementations: Implement Event-Driven communication between microservices/containers based on Event Bus interfaces and two implementations: - 1. (PRIORITY) Standalone Pub/Subs messaging implementation based on an out-of-proc RabbitMQ Container + 1. (Implemented as PoC) Standalone Pub/Subs messaging implementation based on an out-of-proc RabbitMQ Container 2. (Future version) Azure-attached implementation based on Azure Service Bus using Topics for Pub/Subs Two integration event scenarios to implement in the app: 1. Simple (higher priority): Change Product info (name, image URL, etc.) in the Catalog and update that in the existing Orders and Baskets (all, except the price) 2. (Future version) Complex: Events propagating Order's states changes related to the Order-Process SAGA (InProcess, Paid, Handling, Shipped, Canceled if timeout because it was not paid, etc.) -- Monolithic ASP.NET MVC app (just web app, no containers) with public area of the eShop (Home page with catalog-view functionality, basically). As segregated project available at: https://github.com/dotnet/eShopOnWeb +- DOMAIN EVENTS: Implement Domain Events which is related but not the same as integration events for inter-microservice-communication. Domain Events are initially intended to be used within a single microservice's Domain, like communicating state-changes between Aggregates, although they could derive to Integration Events if what happened in a microservice's domain should impact other additional microservices. +SCENARIOS IMPLEMENTED: + 1. Check price change basket vs. catalog when converting to Order: https://github.com/dotnet/eShopOnContainers/issues/38 + 2. Multiple AGGREGATE changes within the same Command-Handler, decoupled by domain events. -- Legacy ASP.NET WebForms client running on a Windows Container (Catalog Manager/Simple CRUD maintenance). Consuming the same Catalog microservice. This is an example of a "lift and shift" scenario. +- Resiliency Communication: Resilient synchronous HTTP communication with retry-loops with exponential backoff and circuit-breaker pattern implementations to avoid DDoS initiated by clients. Implementation with Polly: https://github.com/App-vNext/Polly/ OSS lib. -## Version 0.3 Roadmap (BETA, by May 2017 timeframe) - - - -- INTEGRATION EVENTS / Advanced: Prrof of concept of a Order-Process SAGA (InProcess, Paid, Handling, Shipped, Canceled if timeout because it was not paid, etc.) as a long running process. - -- Implement security best practices about app's secrets (conn-strings, env vars, etc.) - (However, this subject depends on the chosen orchestrator...) - See when using Swarm: https://blog.docker.com/2017/02/docker-secrets-management/ +- Idempotent updates at microservices, so the same update (like OrderCreation) cannot be executed multiple times. Server must implement operations idempotently. An operation is idempotent if it gets the same result when performed multiple times. Implementing idempotency is domain-specific. - Exception Handling - ASP.NET middleware extension: Business-Exceptions + Generic-Exception-Handler (ExceptionHandlerHandler) -- Validations with MediatR Decorator - FluentValidation +- Command Validations with MediatR Decorator - FluentValidation https://github.com/JeremySkinner/FluentValidation -- Resiliency: - 1. Resilient synchronous HTTP communication with retry-loops with circuit-breaker pattern implementations to avoid DDoS initiated from clients (*** This is a priority ***) - Initial implementation with Polly: https://github.com/App-vNext/Polly/ OSS lib. - 2. - Implement "Idempotent" updates at microservices, so the same update (like a Payment or OrderCreation) cannot be executed multiple times. Server must implement operations idempotently. An operation is idempotent if it gets the same result when performed multiple times. Implementing idempotency is domain-specific. - 3. Gracefully stopping or shutting down microservice instances – Use the new library implemented as an ASP.NET Core middleware, to be provided by the .NET Team (Need to wait for that library) +- HEALTHCHECKS / Health Check Library (Preview) from the ASP.NET team. It provides: A model of healthcheckresults, A Middleware to return ok/bad, A polling service calling the healthchek service and publishing results (open/pluggable to orchestrators, App Insights, etc.) -- DOMAIN EVENTS: Implement Domain Events which is related but not the same as integration events for inter-microservice-communication. Domain Events are initially intended to be used within a specific microservice's Domain, as communicating state changes between Aggregates, although they could derive to Integration Events if what happened in a microservice's domain should impact other additional microservices. -SCENARIOS TO IMPLEMENT: - 1. Check price change basket vs. catalog when converting to Order: https://github.com/dotnet/eShopOnContainers/issues/38 - 2. Multiple AGGREGATE changes within the same Command-Handler, decoupled by domain events. - 3. Might need Domain events related to the SAGA implementation -See discussion: -https://blogs.msdn.microsoft.com/cesardelatorre/2017/02/07/domain-events-vs-integration-events-in-domain-driven-design-and-microservices-architectures/ -Preferred method: Two-phase Domain events (a la Jimmy Bogard): -https://lostechies.com/jimmybogard/2014/05/13/a-better-domain-events-pattern/ -Other insights: -Domain Events – https://docs.spine3.org/biz-model/event.html -Take 2: http://udidahan.com/2008/08/25/domain-events-take-2/ -http://www.tonytruong.net/domain-events-pattern-example/ -Reactive Extensions might be useful for events: -http://channelsis.com/IntroToRx.pdf -http://www.slideshare.net/EPAMSystems/reactive-extensions-39691960 -We should probably implement Domain Events when implementing the SAGA example plus integration events, so we implement all those things altogether. +- Legacy ASP.NET WebForms client running on a Windows Container (Catalog Manager/Simple CRUD maintenance). Consuming the same Catalog microservice. This is an example of a "lift and shift" scenario. -- Implement a SAGA example of a long running instance of a business process (similar to a workflow but implemented as a class with state persistence). The business process would be the "Order-Process-Saga" workflow, involving multiple mock services like PaymentGateway, StockChecking, etc. while changing the Order's state until the order is shipped. Then a background job which fakes ordre delivery and changes order states to delivered. +- Monolithic ASP.NET MVC app (just web app, no microservices) with public area of the eShop (Home page with catalog-view functionality, basically). + . Running as a container: https://github.com/dotnet/eShopOnContainers/tree/master/src/Web/WebMonolithic + . More advanced layered web app: As segregated project available at: https://github.com/dotnet/eShopOnWeb This app is not using Docker containers, just plain web -- Resiliency 2: -- Use a new Health Check Library (Preview) to be provided by the .NET Team. That library provided by the .NET team will provide: A model of healthcheckresults, A Middleware to return ok/bad, A polling service calling the healthchek service and publishing results (open/pluggable to orchestrators, App Insights, etc.) -Our task here will be to use that new lib. + +## Version 0.3 Roadmap (BETA, by May 2017 timeframe) + +- INTEGRATION EVENTS (Advanced scenario): Proof of concept of an Order-Process SAGA (Pending, Paid, Handling, Shipped, Canceled if timeout because it was not paid, etc.) as a long running process. It is a of a long running instance of a business process (similar to a workflow but implemented as a class with state persistence). The business process would be the "Order-Process-Saga" workflow, involving multiple mock services like PaymentGateway, StockChecking, etc. while changing the Order's state until the order is shipped. Then a background job which fakes ordre delivery and changes order states to delivered. - Create a building block to handle Idempotency in a generic way ([Issue 143](https://github.com/dotnet/eShopOnContainers/issues/143)) -- Topics to Review and document: - - API versioning Management for microservices. Techniques and things to have into account Related to Chaos Monkey, etc. - - Solid API contracts (based probably on Swagger, but interoperable with any language and explicit per paramater) -## Future versions - Roadmap (After April 2017) + + +## Future versions - Roadmap (After May 2017) -- Production-Ready Cloud application with Resilient microservices' design and implementation - - Gracefully stopping or shutting down microservice instances - Implemented as an ASP.NET Core middleware in the ASP.NET Core pipeline. Drain in-flight requests before stopping the microservice/container process. - - Implement messaging communication to ensure Commands/Updates' communication success, using queues, etc. plus providing better scalability capabilities. +- Production-Ready Cloud application with resilient microservices' design and implementation + - Deployment to Orchestrators: Kubernetes, Service Fabric, DCOS, Swarm, etc. - Monitoring/Diagnostics of microservices based on Application Insights with custom perfkeys - - Service Fabric Stateful Service implementation in the SF branch - - Additional microservice with data stored in a No-SQL database like Azure Document DB + +- Service Fabric Stateful Service implementation in the SF branch +- Additional microservice with data stored in a No-SQL database like Azure Document DB +- Gracefully stopping or shutting down microservice instances - Implemented as an ASP.NET Core middleware in the ASP.NET Core pipeline. Drain in-flight requests before stopping the microservice/container process. - Additional Azure cloud scenarios 1. Azure Functions: Implement an event-driven Azure Function microservice (i.e. grabbing uploaded images and adding a watermark and putting it into Azure blobs) @@ -90,6 +69,9 @@ Our task here will be to use that new lib. - Encrypt secrets at configuration files (like in docker-compose.yml). Multiple possibilities, Azure Key Vault or using simple Certificates at container level, Consul, etc. - Other "secure-code" practices - Encrypt communication with SSL (related to the specific cloud infrastructure being used) + - Implement security best practices about app's secrets (conn-strings, env vars, etc.) + (However, this subject depends on the chosen orchestrator...) + See when using Swarm: https://blog.docker.com/2017/02/docker-secrets-management/ - Implement example of Optimistic Concurrency updates and optimistic concurrency exceptions @@ -97,11 +79,11 @@ Our task here will be to use that new lib. - (To be Confirmed) Service Fabric and Azure version Actor model, stateful services, etc. -- (To be Confirmed) Docker Swarm version (on Azure Container Service) +- (To be Confirmed) Guide on Kubernetes • Possible "Getting started guide w/ using minikube and eShopOnContainers" -- For MAC dev machine most of all: [Requirements](https://kubernetes.io/docs/getting-started-guides/minikube/#requirements) • Possible "Examples using https://github.com/kubernetes/helm" + - (To be Confirmed) Mesos DC/OS version (on Azure Container Service) -- (To be Confirmed) Kubernetes version (on Azure Container Service) - (To be Confirmed) In the Windows Containers fork, implement and add a simple WCF microservice/container implementing any logic like a simulated legacy Payment Gateway, as an example of "lift and shift" scenario. @@ -129,6 +111,8 @@ References on Composite UI with microservices: Managing Frontend in the Microservices Architecture http://allegro.tech/2016/03/Managing-Frontend-in-the-microservices-architecture.html + + ## Sending feedback and pull requests We'd appreciate to your feedback, improvements and ideas.