Cloud Native Architecture Patterns Tutorial

Cloud Native Architecture
Patterns Tutorial
2017 O'Reilly Software Architecture
Conference - NYC
Matt Stine ( )@mstine
http://www.mattstine.com

Your Instructor
17 years in the Enterprise IT industry
5 years as a Cloud Platform and Application
Architect
Frequent speaker on the conference circuit
Host of the Software Architecture Radio podcast

Your Instructor
http://www.oreilly.com/programming/free/migrating-cloud-native-application-
architectures.csp

Workshop Components
Lecture
Socratic Q&A Sessions
Architecture Kata Sessions

Agenda
Class Introduction
Cloud Native Architecture Fundamentals
1:30 - 2:15 PM
Socratic Q&A Session
2:15 - 2:30 PM
Cloud Native Architecture Patterns
2:30 - 3:30 PM
Socratic Q&A Session
3:30 - 3:45 PM

Agenda
Cloud Native Architecture Katas - Setup
3:45 - 4:00 PM
Cloud Native Architecture Katas - Create
4:00 - 4:30 PM
Cloud Native Architecture Katas - Present
4:30 - 5:00 PM

The Business Drivers for
Architectural Change

Agility
- Mark Andressen
Software is eating
the world.

Agility
Disruptive Characteristics
Software is primary engagement model
New and innovative business models
Fast and frequent deliveries
Hypothesis-driven development

Agility
Waterscrumfall
Consequences
Slow Delivery
Large Batch Sizes
Infrequent Feedback
Increased Waste

Agility
Digital Transformation

Resiliency
Disruptive companies are
also approaching resiliency
differently.

Resiliency
Stop trying to prevent
mistakes.

Resiliency
We need better tools and
techniques.

A High-Level Overview of
DevOps and Continuous
Delivery

DevOps
My Definition:
DevOps represents the idea of
tearing down organizational silos
and building shared toolsets,
vocabularies, and communication
structures in service of a culture
focused on a single goal: delivering
value rapidly and safely.

DevOps
The Second Way: Feedback

DevOps
The Third Way:
Continual Learning and
Experimentation

Continuous Delivery
My Definition:
Technically supporting the concept
to cash lifecycle by proving every
source code commit to be
deployable to production in an
automated fashion.

Continuous Delivery
Ingredients
Configuration Management
Continuous Integration
Automated Testing

Continuous Delivery
CI Developer Workflow

Continuous Delivery
The Deployment Pipeline

The Unique Characteristics of
Cloud Infrastructure

My Definition:
Any computing environment in
which computing, networking, and
storage resources can be
provisioned and released elastically
in an on-demand, self-service
manner.

Deployment Models
Public
Amazon Web Services
Google Cloud Platform
Microsoft Azure
Private
VMware vSphere
OpenStack
Community
Hybrid

Service Models
The *aaS Pyramid

API Driven
Automation
Audit
Authorization
Accounting

Speed
If you need a component, create it!
Load Balancers
Databases (SQL/NoSQL)
Message Queues
Private Networks
Storage Volumes

Speed
Can eliminate:
Ticket Systems
Approval Processes
Waiting Queues
Configuration Errors

Speed
As fast as you can design the system
architecture that you need, you can
usually provision and begin using it.

Elastic
Goodbye Capacity Planning!

Elastic
Capacity Planning
Peer into the crystal ball...
"What's the most capacity we'll need?"
Guess incorrectly...
Blow available capacity on Black Friday
Hundreds of idle CPUs

Elastic
As demand increases, we simply expand
capacity by provisioning more resources
to service that demand.

Elastic
As demand decreases, we simply contract
capacity by returning resources to the
pool.

Concepts

Architecting for DevOps
Modularity

Think About the Three Ways
We want a quantum of this experience.

Decomposition Strategies
What's yours?
Bounded Contexts
Value Streams
Single Responsibility Princple
Failure Domains
Anti-Corruption Layers

Strategies are not mutually exclusive!

So What About Modularity?
Loose Coupling
High Cohesion
Encapsulation
Well-Defined Interface

Gratuitous Nod to
Microservices!

If a microservice isn't giving you Three Ways Value, you probably don't need it.

Conway's Law
Any organization that designs a system
(defined broadly) will produce a design
whose structure is a copy of the
organization's communication structure.

If your architectural and and
organizational decomposition
strategies don't align well,
then CONWAY WILL FIGHT
YOU!

Observability

Think About the Three Ways
We need feedback to create a safer system of work and to (in)validate our hypotheses.

See Failure When It Happens

Measure Everything

What is Normal?
Values
Rates of Change
Mean?
P95/99/99.9?

What is Normal?
http://bravenewgeek.com/everything-you-know-about-latency-is-wrong

This is an Architectural
Responsibility
Architecture can make observability harder!
Overhead Concerns
Tools don't know your business.

Architecting for Continuous Delivery
NOTE: Architecting for
DevOps aids in Continuous
Delivery!

Adding some layers...

Think About Full Lifecycle
Architecture

Neal Ford
Architecture is abstract until it is
operationalized.

Architectures that aren't
operationalized exist only on
whiteboards!

Deployability
Testability
We'll examine these qualities by asking questions of
our architectures.

Deployability

Have you automated ALL of
your deployment tasks?

Can you transform a brand
new deployment environment
into your running
architecture without manual
work?

Can you vary configuration
across environments without
rebuilding code?

Do you deploy like this
EVERYWHERE?

Can you do this without your
users noticing?

Testability

Have you automated ALL
testing tasks that you
possibly can?

Do you have to deploy all the
things to test anything?

If testing is an experiment,
can you control everything
except your experimental
variable?

Can you run the same tests
against any environment
(including production)?

Can you verify that you
continue to meet your
contractual obligations?

Architecting for Cloud Infrastructure
Cloud Capabilities
API-driven
Speed
Elasticity
Geography
Specialized Services

Exploiting the capabilities of
Cloud can enhance our ability
to practice DevOps and
Continuous Delivery!

Disposability
Replaceability
We'll examine these qualities by asking questions of
our architectures.

Disposable
adjective
1. designed for or capable of being thrown away after
being used or used up:
disposable plastic spoons; a disposable cigarette lighter.
2. free for use; available:
Every disposable vehicle was sent.
http://www.dictionary.com/browse/disposable

Replace
verb
1. to assume the former role, position, or function of;
substitute for (a person or thing):
Electricity has replaced gas in lighting.
2. to provide a substitute or equivalent in the place of:
to replace a broken dish.
http://www.dictionary.com/browse/replace

Consequence
noun
1. an act or instance of following something as an
effect, result, or outcome.
2. importance or significance:
a matter of no consequence.
http://www.dictionary.com/browse/consequence

Disposability
Can I destroy a service
instance at any time without
consequence?

Disposability
Can I repave the entire
architecture at any time
without consequence?

Disposability
Can I respond to changes in demand by
adding or removing instances of a
service without consequence?

Replaceability
Can I replace a sick service
instance with a brand new
copy without consequence?

Replaceability
Can I route traffic to any
available service instance

Replaceability
If I lose an AZ or Region, can
I route traffic to another

Replaceability
Can I swap between multiple
implementations of the same
service contract without
consequence?

Replaceability
Can I swap between multiple
running versions of a service

These are Architectural
Responsibilities
Architecture can make disposability impossible.
Architecture can make replaceability impossible.
Architecture must take charge of removing the
consequences of disposing and replacing service
instances.

Summary
Architectural Decision
Making Can:
Enhance or Detract from Our Ability to Practice
DevOps
Enhance or Detract from Our Ability to Practice
Continuous Delivery
Exploit or Waste the Characteristics of Cloud
Infrastructure

Summary
We could have called this
"DevOps Native" or
"Continuous Delivery Native"
Architecture!

Summary
DevOps Native Architecture

Summary
Balancing:
Agility and Resilience

Summary
Supported By:
DevOps and Continuous Delivery

Summary
On a Foundation of:
Cloud and Architecture

Patterns

Overview
Pattern-Oriented Software Architecture, Volume 1: A System of Patterns
Patterns should...be described uniformly.
This helps us to compare one pattern
with another...

Overview
Design Patterns: Elements of Reusable Object-Oriented Software
We describe design patterns using a
consistent format...making design
patterns easier to learn, compare, and
use.

Overview
Brick and Mortar Pattern Template
Context
The basic situation in which we find ourselves working.
Problem
Presents the problem as a system forces which must be balanced.
Solution
Describes the components that make up the general solution, how they relate to one another,
and their runtime interactions.

Overview
Brick and Mortar Language Structure
Brick Patterns
Patterns for constructing individual (micro)services.
Mortar Patterns
Patterns for composing bricks into complete distributed systems.

Overview
Brick Patterns
Externalization Patterns
Structural patterns for creating deployable, disposable, and replaceable bricks.
Externalized Configuration
Externalized State
Externalized Channels
Runtime Patterns
Behavioral patterns for creating deployable, replaceable, and observable bricks.
Runtime Reconfiguration
Concurrent Execution
Brick Telemetry

Overview
Mortar Patterns
Distributed Systems Patterns
Composition patterns addressing common distributed systems challenges.
Service Discovery
Edge Gateway
Fault Tolerance
Integration Patterns
Composition patterns addressing integration and observability challenges.
Event-Driven System
Contract Management
Integration Telemetry

Overview
Brick and Mortar Language Relationships

Brick Patterns
Externalized Configuration
Externalized State
Brick Telemetry

Context and Problem
Context
An application's configuration will vary
independently from its code throughout
its lifecycle.

Context and Problem
Problem
Traditional techniques for managing
configuration tightly couple these two
orthogonal concepts.

Context and Problem
Forces
Different environments will have different
configuration settings:
resource handles to the database (e.g. a JDBC
URL)
credentials to external services (e.g. Amazon S3)
per-deploy values such as the canonical hostname
(e.g. blog-test.example.com vs. blog-
prod.example.com)
features that are toggled on or off

Context and Problem
Forces
Configuration is often bundled within deployment
artifacts (e.g. Java properties files).
Build processes often modify configuration based on
arguments.
The Deployment Pipeline should only build each
deployment artifact once, and deploy the same
artifact to multiple environments.

Context and Problem
Context
Disposability and Replaceability require
the elimination of "snowflake
deployments" from the architecture.

Context and Problem
Problem
Traditional state management
techniques prevent us from achieving
"phoenix deployments."

Context and Problem
Forces
Early web architectures emphasized server-side
state management:
Fat Clients to Thin Clients
Vertically Scaled Cache Management
Stateful Scaffolding on Stateless Protocol (HTTP)

Context and Problem
Forces
Cloud Infrastructure:
Resource Limited Horizontal Scale
Limited Load Balancer Support for Sessions
Limited (No) Support for Persistent Local Disk

Context and Problem
Context
Realizing the DevOps Way of Feedback
requires that we have visibility into both
the business value and technical
behavior generated by our services.

Context and Problem
Problem
Common approaches to service visibility
fall short of the architectural qualities
that we need.

Context and Problem
Forces
Visibility is often accomplished via post facto
application of agent-based monitoring tools.
Agent-based monitoring tools don't understand
business value.
Determining an application's health often requires
complex logic.
Traceability of an application is difficult (or
impossible) to accomplish with OTS solutions.

Mortar Patterns
Service Discovery
Edge Gateway
Fault Tolerance

Context and Problem
Context
Decomposition of architecture into
services leads to increasingly more
distributed systems.

Context and Problem
Problem
As systems become distributed, and as
service instance lifecycles become more
dynamic and independent, location of
and communication with dependencies
becomes more challenging.

Context and Problem
Forces
Cloud platforms often assign auto-generated,
internal hostnames or private IP's to service
instances.
As services are scaled and unhealthy instances are
replaced, the addresses of a service's instances are
constantly changing.
Binding a service to anything other than logical
names for its dependencies leads to friction in the
architectural lifecycle.

Context and Problem
Forces
Applying Concurrent Execution is made more
difficult (or impossible) when binding services to
fixed addresses for their dependencies.
We may want to remove a service instance from the
available pool but keep it running to troubleshoot a
problem.

Context and Problem
Context
Decomposed architectures must always
be recomposed. This recomposition often
happens within the user interface layer of
an application.

Context and Problem
Problem
Recomposing an architecture within the
User Interface layer presents significant
complexities that can lead to decreased
agility and degraded user experience.

Context and Problem
Forces
Systems often must support multiple user
experience options (web/mobile/AVR).
Recomposing architectures as the UI layer can
require exposing the architecture to the public
network.
API needs for a mobile device are often quite
different from a web UI.

Context and Problem
Forces
Exposing a network graph to mobile devices can
increase latency, increase data usage, and degrade
battery life.
UI platforms may not support the integration
architecture used for all services.
Native apps often have longer upgrade cycles.
Recomposing the architecture there can lead to
friction in the architectural lifecycle.

Context and Problem
Context
In order to accomplish its assigned tasks,
each brick will need to communicate with
other bricks, and with external systems,
to which we'll collectively refer as
dependencies.

Context and Problem
Problem
When a brick's dependencies become
unhealthy, unreachable, or slower than
normal to respond, that brick's own
performance is degraded, and such
degredation can potentially cascade
across the entire architecture.

Context and Problem
Forces
The network is not reliable.
Latency is non-zero and unpredictable.
Service availability is a product of its dependencies'
availabilities.

Context and Problem
Forces
Failures can be transient.
Failures can cascade.
An incorrect or stale response is often preferable to
no response.

Katas
Setup

What are Architecture Katas?
Take me to the rules!

To Cloud Native
Add the following to your requirements:
Day 1 as a company we're agreeing to guide
ourselves by DevOps principles and practice
Continuous Delivery.
We have no infrastructure; we'll use one or more
public cloud providers to deliver our software.
Think deeply about your decomposition strategy and
what advantages it will bring you.
Use the CNA Patterns you know so far in order to
enable your architectures to these ends.

Kata Choices
http://bit.ly/cna-kata-choices

Cloud Native Architecture Patterns Tutorial

More Related Content

What's hot (20)

Similar to Cloud Native Architecture Patterns Tutorial (20)

More from Matt Stine (20)

Recently uploaded (20)

Cloud Native Architecture Patterns Tutorial