Microsoft Microservices

Using Microsoft for MicroservicesPresenter: Chase Q. Aucoin

PRESENTATION MAPOur hope is that at the end of this your mind will be racing with questions and ideas

2

What Is a Microservice

Business Domains

Business Agility

Teams & Organization

Building Services

Health & Monitoring

Questions & Answers

Where Does UI Fit?

Testing & Deployment

Failure as a Service

Simply put: It’s a self contained, domain specific, service

What is a Microservice

Using Microsoft for Microservices 4

When you hear the term cloud you probably think a place. When we say cloud we mean a set of patterns and practices. These patterns

and practices work regardless of hosted providers or on premises deployments.

What Does Cloud mean?

Cloud Services are available on demand. Whether that is VMs, File Storage, or Data Processing

On Demand

Cloud services are distributed across many fault zones to ensure high uptime.

Distributed

In a cloud scenario building applications that can scale horizontally is favored to the traditional approach of increasing the size of compute resources. This allows for “infinite” scalability.

Horizontal Scale

Because of the transient nature of resources in a cloud environment services assume that

they will fail instead of assuming they will always exist.

Built To Fail

Lose coupling between components allows easy transitions between implementations and

locality of a given resource.

Loosely Coupled

Where possible use existing built technical resources to provide the highest levels of

productivity and reduce operations complexity.

Favor Existing Technical Solutions


Traditional when we think of a service we think of an in process body of code that has methods. Sometimes we mean the actual deployable “windows service”. Sometimes we think of it as a worker process that is servicing something on a continuous loop.

During this presentation we mean an application that does the “heavy lifting” of responding to a clients request.

What is a service

Using Microsoft for Microservices

Traditional 3-Tier Architecture

Client - Presentation

Service – Business Logic

Data - Database


The monolith is ancient. It contains all knowledge. It succeeds as one. It fails as one.

The MonolithMost monolithic application start from a need to get business value out quickly. They are typically feature driven and more often than not built in an environment of tight deadlines and high expectations. It is only in hindsight as productivity slows, and the pace of innovation declines that we question its nature. Most times at this point it has become so engrained into its place within a business that changing its nature seems like an impossible task.

It is not impossible, but it does take work.


You only have to deploy and manage one application

Single Deployable

Cloud services are distributed across many fault zones to ensure high uptime.

Initial Agility Is High

You can change large amounts of the source all in one place. This could also be considered a con in most scenarios.

Simplifies Make Broad Changes

Feature A that is part of one domain may be ready to go but other features in other

domains may have committed code that are not ready for deployment into a production

environment

Inconsistent State

As you move the application through the delivery pipeline you have to test the entire

surface area of the application.

Testing

You cannot scale the areas of the application that are creating “hot zones” independently making for difficult management scenarios

both technically and also with your consumers.

Scale

Deployable Service or Data

Feature A

Feature B

Feature C

Feature D

Feature E

Feature F

Monolithic ApplicationAdvantages Challenges


“I don’t need to know everything. I just need to know where to find it when I need it.” Albert Einstein

MicroservicesMicroservices instead of being solely focused on features. Are focused on a given business or technical domain or “bounded context” that they operate in. This nature allows us to have laser focus on business need. It also allows us to speak the same language as the business and delivery applications in a more meaningful and rapid way in a large scale application set.


If one service fails it does not bring down the entire application stack. Worst case scenario loss of a single set of functionality is lost until recovered.

Physically Decoupled

You only have to test one domain. This does require an adherence to some SOLID principals for best results.

Testing

Easily scale a specific potion of the application that needs to scale. Likewise you can scale delivery teams more reliably providing more types of functionality going out in parallel.

Scale

Embracing a Microservice paradigm for software delivery usually means shift

mentality within the organization about how to deliver software.

Requires Culture Shift

Since there are more moving parts that means there is ultimately more to have to keep track

of. This is where automation is important.

Large Footprint

It is usually slow initially for the organization to shift culture and get it’s processes in place

Initial Agility Is Slower

Deployable Do-main

Service A

Data A

Microservice ApplicationAdvantages Challenges

Deployable Do-main

Service B

Data B

Deployable Do-main

Service C

Data C

Deployable Do-main

Service D

Data D


Advocates fewer services but doesn’t suggest what the bounding of those service are. Services are typically very “smart”

Fewer Components

The logic for a feature may be scattered across many domains.

Logic Across Many Domains

Mulesoft, Biztalk, Corba, EJBMiddleware Required

Service a scoped within the bounds of a given domain.

Many Small Components

Typically the business logic for doing an atomic body of work lives within a single

service.

Business Logic Per Service

Service are exposed via simple wire protocols such as HTTP with JSON with API gateways

creating high levels of interoperability across BU’s

API Driven

Isn’t This Just SOA?SOA Microservices

Sort of..Conceptually the 2 are similar, but SOA tends to be a loaded term that may be defined drastically different form one

person to the next.In our experience SOA becomes a vehicle for:

• Selling expensive over-complicated software (ESBs, BPM tools, ERP, Service Registries Etc..),

• Long business process modeling initiatives

• Large checks with little to no tangible ROI

How do we think about services in relation to the business

Business Domains


What is a Business Domain?An area of the business that tends to use similar taxonomy/terminology to

describe a business/technical need or value proposition.

1 Focuses on the management and information retrieval of Employees

Employees2 Focuses on the tracking and

management of projects

Projects

3 Focuses on the logging of events in the system

Logging4 Focuses on the

authentication of users into the system (Identity management)

Authentication


Why we organize Microservices by domain?It does a few things for us.

• Enables us to speak in a common language with the business alleviating miscommunication• Allows us to create end to end ownership for a team• The business and engineers work closer allowing for rapid ideation, validation, and iteration• Create highly concurrent deployment scenarios• Create isolation. Services only have to care about what is happening within their domain

without being bogged down by having to know everything all the time• Alleviates paralysis by analysis

Scaling teams is just as important as scaling software

Teams & Organization


Conways Laworganizations which design systems ... are constrained to produce designs which are copies of the communication

structures of these organizations.

“

“Melvin Edward Conway PhD | Rockwell Semiconductor

Business TeamUI TeamService TeamData Team


Inverse Conways LawOrganizations which design systems ... Are encouraged to create communication structures that produce the desired

designs for the systems.

“

“David Pitt | Keyhole Software

Domain A TeamDomain B TeamDomain C TeamDomain D Team


Siloed teams leads to siloed application architecture. Limiting holistic knowledge of a give domain within the business.

Siloed Teams

Difficult to scale teams to meet the demands of the business.

Limited Scalability

Too much time is spent transferring knowledge between the layers so everyone has to know everything all the time. This hinders the effectiveness of delivery.

Productivity

Each delivery team knows exactly what it needs in order to get it’s products into

production end to end.

Cross Functional Teams

Teams can easily be distributed across BU’s and as new domains are required new teams can be on-boarded to meet demand without

limiting existing teams.

Highly Scalable

Once the cross functional team hits it’s stride new features can be production ready in days

not months.

Highly Productive

Conways LawSOA/Monolith Microservices

organizations which design systems ... are constrained to produce designs which are copies of the communication structures of

these organizations.

“

“Melvin Edward Conway PhD | Rockwell Semiconductor

Delivering more, faster, with automation and collaboration

Business Agility


How Can We Create More Value Across Our Organization?Reuse applications that we have already built value in to create value across

all of our business units.

Microservice facilitate this because at their heart they are just APIs.


“I think of novels in architectural terms. You have to enter at the gate, and this gate must be constructed in such a way that the reader has immediate confidence in the strength of the building.”” Ian Mcewan

API GatewaysA strong gateway is incredibly valuable within an organization. It allows your work to be self documenting and creates scenarios for pull instead of push during cross collaboration. It enables us to leverage our existing code over and over in new and novel ways.

Beyond Conceptual: how do we put it together?

Building Services


What are the pieces that enable us to create Microservices in our

organization?

Technical Components


Since our services are so widely distributed we need to know when one is failing and pull it out of load to alleviate stress during peak load.

Circuit Breaker

Service Fabric – Built In Polly

Service Fabric - Name ServiceWCF – Discovery Service

Azure – Service Bus

The service registry lets services find each other at run time without having to know in advance where service are located.

Service Registry

Using JavaScript/HTML and frameworks like backbone or angular powered by services requested via AJAX through the API gateway

SPA Front-End

Angular Backbone

EmberReact

Web API with Swagger Azure – API Gateway

Mashery Mulesoft

The gateway is the entry point to serve up client requests via an HTTP based API for maximum interoperability

API gateway


TFS – Release Management Jenkins

TeamCityService Fabric

Docker

The biggest key to the successful implementation of the Microservice paradigm is to automate as much of the delivery cycle.

Continuous Delivery

Messaging increases asynchrony across the system and enables patterns such as CQRS, Pipes & Filters, and Subscription Based Extension

Messaging

Azure – Service Bus RabbitMQ

Service Fabric – Built In

Azure - Application Insights Operations Management Suite

ELK Stack

Log aggregation allows you to see what’s going on across your services at a glance.

Log Aggregation

Nuget lets us manage the packaging and delivery of shared libraries within the enterprise

NuGet

ProGet MyGet

Nuget.Server


SPA SPA SPA SPA

API Gateway API Gateway API Gateway API Gateway

Auth Primary Auth Secondary Auth Secondary Employee Primary

Employee SecondaryEmployee Secondary Project Primary Project Secondary

Project Secondary


Project DAL

Project Service

Project API

[Project]

Appointment DAL

Appointment Service

Appointment API

[Appointment]

Employee DAL

Employee Service

Employee API

[Employee]

SQL Server Mongo/3Rd Party API

Sample Architecture

Authorization

Authentication

Service Fabric

Application Insights

TFS/ Release Management

Moving away from rendered views

How Does UI Fit?


How do we think differently about UI in this paradigm?

• The UI is just another consumer of services• The UI should go on a separate cadence as the services as it wil be the slowest to move

through the business process and the least impactful to system stability• Favor simple HTML and Javascript modules

Best practices to make launching the most boring part of the cycle

Testing & Deployment


What should we keep in mind for testing?

• Automate service testing and make it part of the CI/CD process• Keep the testing surface area limited to the domain that is being published.• Isolate a domain specific automated integration testing environment for regression that can

be drop and recreated during the delivery process.


Containers

• Instead of delivering “code” deliver containers. • Docker and Service Fabric are excellent choices for containerization.• Have an automated rollback strategy as part of deployment. This is built into Service Fabric• Configuration should be injected at runtime or via container configuration

• Storage mechanisms should be durable and movable in case of failure. Good choices include vSphere disk virtualization or Azure File Storage mounted as a drive at application startup.

Keeping your system healthy after launch

Health & Monitoring


How do we keep services healthy?

• Leverage tools like Application Insights and ELK stack• Use your hosting platforms built in health tools. Service Fabric, IIS, Azure all have

customizable health metrics.

Dealing with mission critical failure before it ever happens

Failure As A Service


What is failure as a service?

• Use tools like Keyhole Trouble Maker or Built in Service Fabric tools to randomly stop applications in production

• If your apps are able to handle this continual shutting off of parts of the system you can sleep easy at night knowing that the system is stable.

Failure As A ServiceDealing with mission critical failure before it happens

Question & Answers