microservices: new frontiers -...

Microservices:New Frontiers

September 25, 2017

Matt McLarty, VP, API Academy, CA Technologies, @mattmclartybc

Microservices:we’ve come a long way already

2014: Martin Fowler and James Lewis

http://martinfowler.com/articles/microservices.html

2015: Sam Newman

“Getting integration right is the single most

important aspect of the technology associated

with microservices in my opinion. Do it well,

and your microservices retain their autonomy,

allowing you to change and release them

independent of the whole. Get it wrong, and

disaster awaits.”

- Sam Newman, Building Microserviceshttp://shop.oreilly.com/product/0636920033158.do

2016: Microservice Architecture

“A microservice is an independently

deployable component of bounded scope that

supports interoperability through message-

based communication.

Microservice architecture is a style of

engineering highly-automated, evolvable

software systems made up of capability-aligned

microservices.”

http://shop.oreilly.com/product/0636920050308.do

2016: Susan Fowler

The Four Layers of Microservice Architecturehttp://shop.oreilly.com/product/0636920053675.do

Forces driving microservices

Microservice Architecture

Decentralized Organizations

Agile Methodologies

DevOps Culture

Cloud Native Technologies

API-based Integration

The common thread:complex software ecosystems

Ecosystems, not systems

“The promise is a diverse and dynamic

landscape of useful and innovative

products.”

Erik Wilde

“Don’t Let Your Microservices Garden Overgrow”

Many orgs have more than one monolith…

How can you deal with complexity?

Differentiate the Complexity

Essential vs. Accidental Complexity

Essential Complexity

• The complexity of the software’s functional scope and the problems it solves (e.g. correlating and analyzing large amounts of data in real time)

Accidental Complexity

• The complexity of the software’s implementation details (e.g. the languages, processes and messages used to do the work)

The Truth About Software Complexity

“Many of the classical problems of

developing software products derived

from this essential complexity and its

nonlinear increase with size.”

Fred Brooks

“No Silver Bullet—Essence and Accident in

Software Engineering”

Differentiating Complexity in Microservices

Essential Complexity in Microservices

• In a microservice architecture, the topology of the implemented system closely resembles the model of the system’s “essence”

Accidental Complexity in Microservices

• In a microservice architecture, accidental complexity can be minimized through automation and distribution

Modularize the system

• Herbert Simon, The

Architecture of Complexity,

1962

• Edsger Dijkstra, Structure of

the “THE”-multiprogramming

language, 1968

• David Parnas, On the

Criteria To Be Used in

Decomposing Systems into

Modules, 1972

Modularize the system

“Modularity … is to a technological

economy what the division of labor

is to a manufacturing one.”

W. Brian Arthur

The Nature of Technology

Visualize the system

“Different views of the design can

be used to manage complexity and

highlight different aspects of the

solution.”

Simon Brown

“The Art of Visualizing Software”

Visualize the system

“In distributed systems, or in any

mature, complex application of

scale built by good engineers … the

majority of your questions trend

towards the unknown-unknown”

Charity Majors

“Observability: What's in a Name?”

Focus on component interactions

“REST emphasizes evolvability to

sustain an uncontrollable system.”

Roy Fielding

“REST in AEM”

Standardize selectively

“Standardize via network protocols

and data contracts, just like the

internet.”

Ben Christensen

“Don’t Build a Distributed Monolith”

Remember the human element

“Any organization that designs a

system (defined broadly) will produce

a design whose structure is a copy of

the organization's communication

structure.”

Mel Conway

“How Do Committees Invent?”

How can you deal with complexity in a practical way

using microservice architecture?

Common Language for Microservice Systems?

Kubernetes Cloud Foundry

From https://x-team.com/blog/introduction-kubernetes-architecture/ and https://docs.cloudfoundry.org/concepts/architecture/

Common Language for Microservice Systems

Term Definition

Service (AKA Microservice) A logical application component that provides functionality via an interface.

Service Domain A defined set of services that make up the logical microservice system for a given scope (e.g. company,

organizational unit, bounded context, application).

Service Cohort A group of services services that can be deployed independently, but rely on each other to complete user

tasks. Instances of services within a service cohort are often deployed within the same service node.

Kubernetes Pods and Mesosphere Application Groups are platform-specific examples of service cohorts.

Service Instance A runtime instance of the service with a network addressable interface. Note that a service instance can

be made up of multiple containers.

Service Network The collective network through which services in the service domain communicate with one another and

with components outside the service domain. The service network can span multiple service platforms.

Service Node A single infrastructure node for hosting services. Docker hosts and AWS EC2 instances are platform-

specific examples of service nodes.

Service Zone A subsection of the service network. AWS availability zones and Kubernetes clusters are platform-

specific example of service zones.

Service Domain – Logical View

Service a

Service b Service c Service d

Service e

Service f

Service h

Service i

Service k

Service j

Service g

Service l

Service Domain

Service Cohort A

Service Cohort B

Service Cohort C

Service Cohort D

Service Network – Physical View

Service a –Instance 1

Service b –Instance 2

Service c –Instance 2

Service d –Instance 2

Service e –Instance 1

Service f –Instance 1

Service h –Instance 1

Service i –Instance 1

Service k –Instance 1

Service j –Instance 1

Service g –Instance 1

Service l –Instance 1

Service Network

Service Zone 1

Service b –Instance 2

Service c –Instance 2

Service d –Instance 2

Service a –Instance 1

Service Node 1-1

Service Node 1-2

Service Zone 2

Service Node 2-1

Service Node 2-2

Service e –Instance 2

Service f –Instance 2

Service h –Instance 2

Service i –Instance 2

Service k –Instance 2

Service j –Instance 2

Service g –Instance 2

Service l –Instance 2

Service Zone 3

Service Node 3-1

Service Node 3-2

DDD for Modeling Service Boundaries

• Effectively modeling essential complexity reduces

the need for coordination

• Eric Evans’ Domain-Driven Design provides a

framework for defining and modeling the essential

capabilities of complex software systems

Image credit: http://martinfowler.com/bliki/BoundedContext.html

Sample Microservices Context Map

More here: http://www.apiacademy.co/designing-a-system-of-microservices/

Subdomain SubdomainSubdomain

Subdomain

Subdomain

Subdomain

Bounded Context

Bounded Context

Bounded Context

Bounded Context

Bounded Context

Bounded Context

Bounded Context

Bounded Context

Bounded

Context

Bounded

Context

Service

Service

Service

Service

Service

Service

ServiceService

Service

ServiceService

Consumer

Service

Consumer

Service

Consumer

Service

AC

LA

CL

AC

L

Interaction

Interaction

Interaction

Interaction Interaction

Interaction

Multi-Cloud Access Control Model

Network-based controls

• TLS/SSL, ACL’s

Trust-based controls

• PKI

Token-based controls

• OAuth, JWT, OpenID Connect

Platform-based controls

• Kubernetes, Cloud Foundry, AWS

Microservice Interaction Patterns

Query Only

Request-Response

CQRS/Event-sourced

Reactive

Microservices Technological Capabilities

Incentive-based Governance

Selective Standards

Abundant Guidelines

Tools and Toolmaking

Cross-Team Collaboration

Empowered Dev Teams

Centralized Supports

APIs vs. Microservices

API• An application interface

exposed on a network

• Many styles– RPC, CRUD, REST

• Many protocols– HTTP, Kafka, gRPC

• Many data formats– JSON, XML, protobuf

• Many implementations– standalone microservice, monolithic

application, API gateway, ESB

Microservice• Independently deployable

application component

• Often self-contained– Interface, logic, and data

• Exposes functionality to other

services and external clients via

APIs

APIs for Microservices

APIs describe the functional capabilities of the system

• They allow architects to view and model the system without diving into the weeds

• They facilitate conversation between business and technology people

APIs offer a transition path to microservices

• Monolithic application services can be offered through APIs as a stepping stone

• This insulates service consumers from changes on the back end

APIs provide a normalized access point for system functions

• They provide interoperability between components

• Single point in the system to address security, composition, monitoring, and SLAs

Microservice Design Canvas

Consumer Tasks Dependencies

Qualities

Interface

DataLogic/Rules

Queries Commands Event

Subscriptions

Event

PublicationsConsumer …

• Task list…

Consumer …

• Task list…

.

.

.

Service …

• Task list…

Service …

• Task list…

.

.

.

Service Name: Description:

Service Name: Description:

Microservice Design Canvas

Dependencies

Qualities

Interface

DataLogic/Rules

Queries Commands Event

Subscriptions

Event

PublicationsService …

• Task list…

Service …

• Task list…

.

.

.

Consumer Tasks

Consumer …

• Task list…

Consumer …

• Task list…

.

.

.

Enumerating the consumers of the service along with the

tasks they need to perform helps to crystallize the purpose of

the service and provides the material inputs needed to design

the interface.

Service Name: Description:

Microservice Design Canvas

Consumer Tasks Dependencies

Qualities DataLogic/Rules

Consumer …

• Task list…

Consumer …

• Task list…

.

.

.

Service …

• Task list…

Service …

• Task list…

.

.

.

Interface

Queries Commands Event

Subscriptions

Event

Publications

Consumer tasks can be broken down into interactions with the

service interface. Classifying interactions according to

patterns—queries, commands, events—will help shape the

underlying service implementation

Service Name: Description:

Microservice Design Canvas

Consumer Tasks DependenciesInterface

DataLogic/Rules

Queries Commands Event

Subscriptions

Event

PublicationsConsumer …

• Task list…

Consumer …

• Task list…

.

.

.

Service …

• Task list…

Service …

• Task list…

.

.

.

Qualities

In addition to the tasks and interactions for the service—what

it does—we must also consider the non-functional aspects of

the service—what it is. Identifying qualities such as availability

and performance levels, extensibility approaches, and

security expectations help further consumers’ understanding

of the service and also influence its implementation.

Service Name: Description:

Microservice Design Canvas

Consumer Tasks Dependencies

Qualities

Interface

DataLogic/Rules

Queries Commands Event

Subscriptions

Event

PublicationsConsumer …

• Task list…

Consumer …

• Task list…

.

.

.

Service …

• Task list…

Service …

• Task list…

.

.

.Taken together, the consumer

tasks, interface and qualities define

the “surface” of the service

Service Name: Description:

Microservice Design Canvas

Consumer Tasks Dependencies

Qualities

Interface

DataLogic/Rules

Queries Commands Event

Subscriptions

Event

PublicationsConsumer …

• Task list…

Consumer …

• Task list…

.

.

.

Service …

• Task list…

Service …

• Task list…

.

.

.

The “Logic/Rules” and

“Data” boxes provide a

place for service

designers to document

key considerations in

these areas. Resist the

temptation to go too deep

at this stage.

Service Name: Description:

Microservice Design Canvas

Consumer Tasks

Qualities

Interface

DataLogic/Rules

Queries Commands Event

Subscriptions

Event

PublicationsConsumer …

• Task list…

Consumer …

• Task list…

.

.

.

Dependencies

Service …

• Task list…

Service …

• Task list…

.

.

.

Finally, service dependencies are listed in

order to call out what tasks the service

requires. For task-heavy microservices

featuring a fair amount of business logic, it is

natural to require interactions with more

data-oriented services. However, in the spirit

of microservice architecture, the goal is to

minimize these dependencies.

Sample Microservice Design Canvas

Consumer Tasks Dependencies

Qualities• Mostly read only, except

for transaction removal

• Medium volume service ,

not mission critical

• Direct customer and

delegated authentication

• Not transactional

Interface

Data• Aggregated transaction

store

Logic/Rules• Populate aggregated

transaction store through

event listening (event

sourcing)

• Filter or adjust data query

based on input parameters

• Offer idempotent

transaction removal

command

Queries• Query customer

transactions

• Get transaction

details

Commands

• Remove

transaction

Event

Subscriptions• Add transaction

• Add transaction set

Event

PublicationsProduct-specific

Transaction Service

• Query transactions

Banking Customer

using Online Banking

Web or Mobile App

• Search transactions

• Get transaction

details

Banking CSR using

Branch Banking or

Call Center App

• Search transactions

• Get transaction

details

Service Name: Transaction Search Service Description: The Transaction Search Service allows consumers to find specific

transactions that fit a set of specified criteria. This criteria can range from date/time, to

spending category, to amounts, and more.

More here: http://www.apiacademy.co/the-microservice-design-canvas/

API World Microservices Conference

MONDAY – Workshop Room 1

12:00 – 12:50 PM

New Frontiers for Microservices

Matt McLarty, API Academy

1:00 – 1:50 PM

The Hardest Part About

Microservices – Your Data

Christian Posta, RedHat

2:00 – 2:50 PM

Master of the Domain – API Access

Control in a Microservice Architecture

Rob Wilson, CA Technologies

Alan Marion, CIBC

3:00 – 3:25 PM

REST vs. Reactive – Interaction

patterns in microservice architecture

Mark Makary, Logic Keepers

TUESDAY – Main Stage

9:00 – 9:25

Monolith Strikes Back – Forces

Challenging a Transition to Microservices

Snezana Sahter, eBay

9:25 – 9:50 AM

Lifecycles – APIs and Microservices

Pete Clare, Vanick Digital

10:00 – 10:50 AM

PANEL: Microservices in Practice

Moderated by Lou Powell, Vanick

Jen Leech, Truss

Bill Monkman, Hootsuite

Bhanu Vegi, Beachbody

11:00 – 11:50 AM

Implementing Microservices at Capital One

Mark Donovan, Capital One

Irakli Nadareishvili, Capital One

MONDAY – Workshop Room 1

3:25 – 3:50 PM

Overcoming Obstacles to Success with

Microservices

Eric Roch, Perficient

4:00 – 4:50 PM

PANEL: The Evolution of Microservices

Protocols

Moderated by Matt McLarty

Fran Mendez, Hitch

Ryan Blain, Arvata

Mike Sample, Hootsuite

Varun Talwar, Google

5:00 – 5:50 PM

Low Code Microservices – Accelerating

Ideas to Implementation

Renu Motwani, CA Technologies

Geoff Duck, CA Technologies

Thank You!

Vice President, API Academy, CA Technologies

matthew.mclarty@ca.com

Matt McLarty

@mattmclartybc

www.slideshare.net/MattMcLarty

linkedin.com/in/mattmclartybc

apiacademy.co