ayan.poddar/eShopOnContainers
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Updated Roadmap and Milestones for future releases (markdown)

Cesar De la Torre 2017-02-08 11:07:59 -08:00
parent 06ddba30aa
commit a0b47d1a04
1 changed files with 35 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
Roadmap-and-Milestones-for-future-releases.md

@ -1,41 +1,52 @@
## Phase 1 Roadmap (By March/April 2017 timeframe)
- Migrate to .csproj and Visual Studio 2017 support, including VS Docker Tooling requirements at the docker-compose.yml files
- Migrate projects to .NET 1.1 and EF 1.1
- Implement support for Windows Containers running on Windows NanoServer using different Docker base images instead of the Linux based images (.NET Core code should be the same as it is cross-platform) - Fork or the same repo?
---
- Exception Handling - As ASP.NET middleware?
Middleware from ASP.NET Core with custom implementation which records specific exceptions depending if it is in production.
Business-Exceptions + Generic-Exception-Handler (ExceptionHandlerHandler)
- INTEGRATION EVENTS: Implement Event-Driven communication between microservices/containers based on Event-Bus interfaces and any simple inter-process communication implementation (That implementation could be swapped by any more advanced Service Bus, like Azure Service Bus using Topics)
Integration Events:
- 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.
- 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. See:
- INTEGRATION EVENTS with Event-Bus implementations: Implement Event-Driven communication between microservices/containers based on Event-Bus interfaces and two implementation:
1. Standalone Pub/Subs messaging implementation based on an out-of-proc RabbitMQ Container
2. Azure-attached implementation based on Azure Service Bus using Topics for Pub/Subs
Two scenarios to implement:
- Simple (higher priority): Change Product info in the Catalog and update that in the Orders (all, except the price)
- 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.) - Scenario to be discussed/defined
- 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.
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 a SAGA example plus integration events, so we should all those things altogether.
We should probably implement Domain Events when implementing the SAGA example plus integration events, so we implement all those things altogether.
- 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.
- 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.
- Exception Handling - As middleware
Middleware from ASP.NET Core with custom implementation which records specific exceptions depending if it is in production.
Business-Exceptions + Generic-Exception-Handler (ExceptionHandlerHandler)
- Resiliency:
- Resilient synchronous HTTP communication with retry-loops with circuit-breaker pattern implementations to avoid DDoS initiated from clients
- Resilient asynchronous communication based on queues, Service Bus, etc. (Related to the Event-Bus)
- Resilient synchronous HTTP communication with retry-loops with circuit-breaker pattern implementations to avoid DDoS initiated from clients (*** This is a priority ***)
- 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)
- Security:
- 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)
- In the Windows Containers fork, implement and add an ASP.NET WebForms application (running as a Windows Container) consuming the same microservices, as an example of "lift and shift" scenario.
For example, a simple CRUD edit WebForms app for the Catalog, consuming the Catalog microservice to add/update/delete products. As simple as possible..
- Topics to Review in current implementation:
Use a new Health Check Library (Preview) to be provided by the .NET Team. That library provided by the .NET team will provide:
o A model of healthcheckresults
o A Middleware to return ok/bad
o A polling service calling the healthchek service and publishing results (open/pluggable to orchestrators, App Insights, etc.)
The task here will be to use that new lib
- Topics to Review and document:
- API versioning Management for microservices. Techniques and things to have into account Related to Caos-Monkey, etc.
- Solid API contracts (based probably on Swagger, but interoperable with any language and explicit per paramater)
@ -47,6 +58,11 @@ Business-Exceptions + Generic-Exception-Handler (ExceptionHandlerHandler)
- Monitoring/Diagnostics of microservices based on Application Insights with custom perfkeys
- Additional topics for production-ready cloud microservices, like using an orchestrator/cluster
- Security:
- 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 example of Optimistic Concurrency updates and optimistic concurrency exceptions
- (To be Confirmed) Nancy: Add a Nancy based microservice, also with DocDB, etc.
@ -57,8 +73,6 @@ Actor model, stateful services, etc.
- (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 an ASP.NET WebForms application (running as a Windows Container) consuming the same microservices, as an example of "lift and shift" scenario.
- (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.
- (To be Confirmed) Build/compile process within an Integration Container (with a provided Docker Image with all SDK dependencies) instead of in local PC. This would greatly simplify the developer's installation requirements in a local machine. That integration container could also be used from a CI pipeline.