microservices: new frontiers -...
TRANSCRIPT
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
Matt McLarty
@mattmclartybc
www.slideshare.net/MattMcLarty
linkedin.com/in/mattmclartybc
apiacademy.co