Page Comparison

Introduction

In an effort to modernize our product catalog we  would , we would like to see if we can identify common functionality that we can then "wrap up" as a Web API.  This will allow us to build the feature set sets only once, reuse it 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 services service follows a base microservice Architecture and Design, .  Though we may not be full fully microservice-based at first but will , we can take steps in the right direction:

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

• Each service is a separate

  codebase

  code base, which can be managed by a small development team.

• Services can be deployed independently

. A

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

  , assuming

  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 API APIs, applications can then leverage pre-existing functionality so developers preexisting functionality.  Developers can create new capabilities and not have reinvent the or learn without reinvention or learning how to implement functions.  Hopefully we will be able to determine what features are used the most across our entire product portfolio, facilitate discussion, and prioritize implementation of this concept.  

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