Page Comparison

(Walter - put your stuff here)

...

Introduction

In an effort to modernize our product catalog, we would like to see if we can identify common functionality that we can "wrap up" as a Web API.  This will allow us to build feature sets only once, reuse them across all products and make it easier to support all applications as changes would only need to be done in one place.  

When thinking of "functionality", we should ensure that each service follows a base microservice Architecture and Design.  Though we may not be fully microservice-based at first, we can take steps in the right direction:

• In a microservices architecture, services are small, independent, and loosely-coupled.

• Each service is a separate code base, which can be managed by a small development team.

• Services can be deployed independently: a team can update an existing service without rebuilding and redeploying the entire application.

• Services are responsible for persisting their own data or external state. This differs from the traditional model, where a separate data layer handles data persistence.

• Services communicate with each other by using well-defined APIs. Internal implementation details of each service are hidden from other services.

• Services don't need to share the same technology stack, libraries, or frameworks.

Some of the benefits of this approach are:

• Independent deployments: You can update a service without redeploying the entire application, and roll-back or roll-forward an update if something goes wrong. Bug fixes and feature releases are more manageable and less risky.

• Independent development: A single development team can build, test, and deploy a service. The result is continuous innovation and a faster release cadence.

• Small, focused teams: Teams can focus on one service. The smaller scope of each service makes the code base easier to understand - and it's easier for new team members to ramp up.

•  Fault isolation: If a service goes down, it won't take out the entire application if we build in proper resiliency in both API and client ( http://www.thepollyproject.org/  - now built in to .NET CORE https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/implement-resilient-applications/ )  

As we identify and build out these service APIs, applications can leverage preexisting functionality.  Developers can create new capabilities without reinvention or learning how to implement functions. 

Our first steps include identifying the most commonly-used features across the MSS portfolio, facilitating discussion, and prioritizing the implementation of the concepts presented above. Following the examples below, please continue to fill out the features used by the applications you develop and support.  As this list continues to grow, we'll create the services we need to help us prepare for the future instead of simply reacting to problems caused by legacy applications using obsolete technology and antiquated design methodologies.

Common Services

This figure illustrates the common services that were presented at TAC in March 2021.

...

Common Services Azure Resource Groups