Microservices - NYS Forum Home cb..1.pdf · Agenda Technology What are Microservices? Characteristics of Microservices Microservices and SOA Challenges Strategy Adoption –Microservices

Microservices

Eric Lehman, Chief Architect, eMedNY, CSRA

Renjith Nair, Principal Solution Architect, eMedNY, CSRA

But first, some context

New York State Medicaid System - eMedNY

100% up-time Data Center

Peak 1.7 Million

Claims per Hour

80,000 Active

Users a Month

7 Million

1 out of 3

New Yorkers$50+ Billion in 2016

Paid 31,088

Providers in 2016

117 Million Txn’s

per Month

2 Second

Response

AgendaTechnology

What are Microservices?

Characteristics of Microservices

Microservices and SOA

Challenges

Strategy

Adoption – Microservices @ eMedNY

Mircroservices and your Technology Strategy

Microservices Adoption Strategies for Government

What are Microservices?

1. Web Services without the bloat

2. An architectural pattern

3. Deployment Pattern

4. All of the above

All of the above

The Microservice architectural style is an approach to

developing a single application as a suite of small

services, each running in its own process and

communicating with lightweight mechanisms,

often an HTTP resource API.

- Martin Fowler

Traditional Monolith

Multiple functions are bundled into one

single application. Functions get

developed, tested and deployed

together!

Microservices

Multiple Independent services

Monolith Architecture

Citizen

Provider

Enrollment

HTML

Templating

Engine

Services Data Access

Layer

Load Balancer &

Other stuff

One Database to rule the world

HTML/JS Payload

Client Side Javascript MVC or

native Apps

Microservices Architecture

Citizen Services

Independent single purpose services

composed together to create apps

Provider Services

Enrollment Services

API

Gateway

Java

Nodejs

Golang

Characteristics of

Microservices

What Microservices is and is not

Is

• A Label

• Bounded Scope/Context

• Organized around Business

Capabilities

• Deployed Independently

• Smart endpoints and dumb

pipes

• Hide Implementation details

• Culture of Automation

• Design for failure

Isn’t

• A Description

• Language

• Lines of code

• Team size

• Number of API endpoints

Credit James Lewis ,Martin Fowler , Sam Newman

Bounded Context

Use Single Responsibility and Domain

Driven Design principles to design the

boundaries of your services

Business Centric

Database

Middleware

UI

Organized around business domain, not technology

Enrollment

Provider

Citizen Programming

Deploy Independently

Citizen Services Provider Services Enrollment Services

Deploy

Ability to deploy services without impacting other allows rapid

change within your organization

Scale Independently

Citizen Services Enrollment Services

Citizen Services

Citizen Services

Scale only what you need to

Provider Services

Smart Endpoints and Dumb Pipes

Mediation/Transformation/Workflow and what not?

Endpoints should have all the intelligence not the pipe

Hide Implementation Details - Service Abstraction

Service is the unit of sharing your data and capabilities for the domain

Citizen Services

Provider Services メ✔

Citizen

Datastore

Hide Implementation details - Data Architecture

Services are responsible for its own data and governance of data

Citizen Services

Provider Services

SQL

NOSQL

Culture of Automation

Exponential complexity makes automation a necessity

Culture of Automation

Automated build,test and deploy cycles

Automated consumer driven contract testing

Dynamic infrastructure

Design for failure

Distributed systems are super difficult to debug, you

need to consider resilience , visibility and network failures

in your design from the get go

Design for failure

Proactive failure testing in production

Microservices

vs

“SOA”

Microservices vs Service Oriented Architecture

Service oriented

architecture

Microservices

Credits : Martin Fowler Devoxx Talk

Microservices vs. SOA

Microservices

• Application Composition

• Fine grain

• Lightweight (HTTP)

• ESB is an anti-pattern

• Service First

• Fully Independent

Traditional SOA

• Integration problem

• Coarse grain

• Heavyweight (WS*/SOAP)

• ESB is the pattern

• Service when needed

• Interdependent

Microservices is SOA done right. It embraces the same ideas of SOA

but offers a fresh approach to architect distributed systems

What changed from SOA days?

• Extensive automation /DevOps

• Infrastructure as code

• Containerization

• Mobile• Serverless Architecture

• JavaScript MVC and Single Page

Applications

• Cloud

• SOA’s overpromise and under delivery

• Universal adoption of HTTP/Restful

That is all good!

What are the

challenges?

Any guess on the challenges with Microservices?

a) Complexity

b) Administration Overhead

c) Transaction Management

d) Logging /Error/Failure Management

e) All of the above

It can be overwhelming

Credits Youtube, njalakomboya

Death Star Architecture

Microservices Challenges

• Microservices are not for everyone

• All new tooling, mindset and process

• Security

• Infrastructure agility

• Logging (lots and lots of logging)

• Monitoring (lots and lots of monitoring)

• Transaction Management

• Automation a must

• Rapid innovation & pace

Microservices Security Challenges

• More varied attack surfaces

• Harder to track events

• Secret Management

• Dynamic transport level encryption

• Authentication and Authorization

Adoption -

Microservices @

eMedNY

Microservices Journey @ eMedNY

• 3 Patterns so far

– Extend a legacy monolith using Microservices

– JavaScript MVC and “Microservices” but single deployable

– JavaScript MVC and Microservices backend with independent deployment

• Limited separation at persistence level

• Framework - To reduce bootstrapping

• Actively Integrating software driven infrastructure components into the ecosystem

• Actively pursuing a Docker strategy

Microservices Technology Stack

Develop a MicroservicesTechnology

stack for the Enterprise. Here’s

some of key concerns we had to

address

• API Gateway

• Service Discovery

• Service Proxy

• Security

• Deployment Pattern

• Metrics & Monitoring

• Log Aggregation

Microservices

&

Technology Strategy

Conways Law

organizations which design systems ... are

constrained to produce designs which are copies of

the communication structures of these

organizations

Organizational Change

Microservices needs underlying organizational change

Application Architecture Evolution

MICROSERVICESTRADITIONAL SOAPRE-SOA (Monolithic)

Microservices and your IT Strategy

• Modernization

• Efficiencies/Reuse

• Faster Requirement/idea → Production cycles

• Increase parallelism

• Introduce modern development practices

• Performance and Scaling

• Availability

• Open Source Software

• Attract Talent

Technology innovation is driven by users

Adoption Strategies for Government

Adoption Strategies for Government

Know your security controls and risks

REST in peace

Game Changer = JavaScript MVC + Restful Service

backend

Adoption Strategies for Government

Microservices needs Automation (DevOps)

Adoption Strategies for Government

Develop a Microservices Tech Stack

Develop Bootstrap kits (Batch, Real time, Web )

Adoption Strategies for Government

Adoption Strategies for Government

Skills Retooling

(Change Manager → Build Engineer )

Not everything is a nail!

Eric Lehman,

Chief Architect, eMedNY

[email protected]

Renjith Nair,

Principal Solution Architect, eMedNY

[email protected]

Thank You