01. Roadmap and Milestones for future releases

Miguel Veloso edited this page Jun 26, 2018 · 59 revisions

Related readme files (use them for more information after reading this)

Version 2.1 (Current version based on .NET Core 2.1)

eShopOnContainers v2.1 is evolving at the DEV and MASTER branch. Features supported on eShopOnContainers v2.1 are the features supported on v2.0 listed below, plus the following added features:

  • Use of HttpClientFactory with Polly integration for resilient Http communication (Retries with exponential backoff and Circuit Breakers)

  • Real time communication: SignalR Hub microservice/container for real-time communication. Scenario: Notification of Order's status changes. This is new since SignalR is provided in ASP.NET Core 2.1.

Version 2 (Based on .NET Core 2.0)

  • Docker containers with .NET Core, Linux images and Windows containers supported and tested.

  • .NET Core 2.0 and EF Core 2.0 support

  • Visual Studio 2017, including VS Docker Tooling based on docker-compose.yml files supporting multi-container debugging, etc. CLI and VS Code environments are also supported.

  • 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.

  • Microservice oriented architecture, easy to get started, described in this Guide/eBook .

  • Implementation of the API Gateway and BFF (Backend-For-Front) patterns so you can filter and publish simplified APIs and URIs and apply additional security in that tier while hiding/securing the internal microservices to the client apps or outside consumers. These sample API Gateways in eShopOnContainers are based on Ocelot, an OSS lightweight API Gateway solution explained here.

  • 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. (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:
    3. 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)
    4. (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.)
  • 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.
  • 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.

  • 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)

  • Command Validations with MediatR Decorator - FluentValidation https://github.com/JeremySkinner/FluentValidation

  • 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.)

  • 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.

  • 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

  • Additional microservice (Marketing and Location microservices) with data stored in MongoDB containers or Azure CosmosDB

Deploying to Azure

  • Deployment/support into Kubernetes in ACS (Linux containers tested)

  • Deployment/support into Azure Service Fabric (Windows Containers and Linux Containers).

  • Azure Storage Blob: Using Azure Blobs to store the Product Images instead of plain files in folders

  • Azure Functions: Azure Function microservice (The Marketing feature has an Azure function returning the Marketing Campaign content)

  • DevOps: eShopOnContainers scripts/procedures of CI/CD pipelines in Visual Studio Team Services

Previous version 1.0 (Based on .NET Core 1.1)

This is an older version supporting .NET Core 1.1, tagged as v1.0 and available here: https://github.com/dotnet-architecture/eShopOnContainers/releases/tag/netcore1.1

VNext

Other possible features, to be evaluated for the backlog:

  • Helm support for Kubernetes deployment and Azure Dev Spaces compatibility

  • Support for Service Fabric Mesh (codename "SeaBreeze")

  • Manage Secrets with Azure KeyVault

  • Split Unit Test projects and distribute across microservices, so each microservice "owns" its own tests.

  • Implement a more advanced versioning system based on aspnet-api-versioning or comparable system. Current API versioning is very basic, simply based on the URLs.

https://github.com/Microsoft/aspnet-api-versioning

  • Implement more advanced logging suchs as using Serilog: https://serilog.net/ or the selected approach.

  • Azure Event Grid: Implement an additional Event Bus implementation based on Azure Event Grid.

  • Azure Functions integrated with Azure Event Grid: Additional event-driven Azure Function microservice (i.e. grabbing uploaded images and adding a watermark and putting it into Azure blobs) - The notification would come from Azure Event Grid when any image is uploaded into a BLOB storage.

  • Monitoring/Diagnostics of microservices based on Application Insights with custom perfkeys

  • Service Fabric Stateful Service implementation in the SF branch

  • 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.

  • (To be Confirmed) Support for .NET Core 2.0 Razor Pages as additional client app.

  • 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 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/
  • Create a building block to handle Idempotency in a generic way (Issue 143)

  • Implement example of Optimistic Concurrency updates and optimistic concurrency exceptions

  • (To be Confirmed) Nancy: Add a Nancy based microservice, also with DocDB, etc.

  • (To be Confirmed) Support other DataProtection providers such as AspNetCore.DataProtection.ServiceFabric

  • (To be Confirmed) Guide on Kubernetes • Possible "Getting started guide w/ local dev Kubernetes integrated to Docker for Windows and Mac"

  • (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) Semantic log - Semantic logic - Related to the Azure app version and Application Insight usage Monitor what microservices are up/down, etc. related to App Insights, but the events are custom ETW events and "Semantic Application Log" from P&P Multiple implementations for the storage of the events, Azure Diagnostics, Elastic Search. Using EventSource base class, etc.

  • (To be Confirmed) Composite UI based on microservices. Including the “UI per microservice”. References on Composite UI with microservices:

    Composite UI using ASP.NET (Particular’s Workshop) http://bit.ly/particular-microservices

    The Monolithic Frontend in the Microservices Architecture http://blog.xebia.com/the-monolithic-frontend-in-the-microservices-architecture/

    The secret of better UI composition https://particular.net/blog/secret-of-better-ui-composition

    Including Front-End Web Components Into Microservices https://technologyconversations.com/2015/08/09/including-front-end-web-components-into-microservices/

    Managing Frontend in the Microservices Architecture http://allegro.tech/2016/03/Managing-Frontend-in-the-microservices-architecture.html

  • Enhance the domain logic for Order Root-Aggregate.

    Already implemented item stock validation (cancels order when quantity is not enough), but could add additional features, check issue #5.

  • Support "multiple redirect urls" for the STS container based on Identity Server 4, check issue #113.

  • Add proper handling of Authentication Token lifetime, check issue #118 for details.

  • Refactor/Improve Polly's resilient code, check issue #177 for details.

  • Add a Jitter strategy to the Retry policy, check issue #188 for details.

  • Increase the resilience of the RequestProvider class in the mobile app, check issue #206 for details.

  • Investigate using the OIDC library to communicate with IdentityServer from the Xamarin client, check issue #215 for details.

  • Replace the WebView in the Xamarin client with device web browsers, check issue #216 for details.

  • Consider using Bash instead of Powershell scripts, check issue #228 for details.

  • Improve app startup time of Xamarin client, check issue #231 for details.

  • Add social login to MVC and SPA apps, check issue #475 for details.

  • Create a new "ServerProblemDetails" response that conforms with RFC 7807, check issue #602 for details.

  • Include some guidance on testing in CI/CD pipelines, check issue #549 for details.

Sending feedback and pull requests

We'd appreciate to your feedback, improvements and ideas. You can create new issues at the issues section, do pull requests and/or send emails to eshop_feedback@service.microsoft.com

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.