Breaking Down the 'Monowhat'

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Stephen Liedig
Senior Solutions Architect, WWPS (ANZ), Amazon Web Services
Session #194304
Breaking Down the Monowhat?

About Me
Senior Solutions Architect
WWPS - Australia and New Zealand
Email: sliedig@amazon.com
Twitter: @sliedigaws
Stephen Liedig

The Monowhat

https://imagescart.blogspot.com.au/2013/03/ayers-rock-in-uluru-national-park.html#.Wwp1DFOFMZo

https://farm3.static.flickr.com/2874/13827796634_3b70a2f3ba_b.jpg

The Monolith
“…a single-tiered software application in which the user interface and
data access code are combined into a single program from a single
platform. A monolithic application is self-contained, and independent
from other computing applications.”
- Wikipedia

Where did they all come from?

Monolith = “Traditional” Applications
• Applications developed to “best practices” and standards of the time
• Monolith <> poorly designed
• Applications didn’t need to be or weren’t designed to be distributed
• Application design constrained by resources

Monolith = “Traditional” Applications
Pros:
• At first…
o Simple
o No over-engineering
• In-process latencies
• Single codebase
• Resource efficient at small scale
Cons:
• Modularity is hard to enforce as
app grows
• Can only scale up!
• All or nothing deployment
• Database dependencies
• Long release cycles
• Slow to react to customer demand

2001
Development transformation at Amazon: 2001+
2001+
monolithic
application + teams
microservices + 2 pizza teams

Monolith development lifecycle
developers
releasetestbuild
delivery pipelineapp

Single-purpose
Connect only through APIs
Connect over HTTPS
Largely “black boxes” to each other
Microservices

Microservice development lifecycle
developers delivery pipelinesservices
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild

> 60 million deployments a year*
Thousands of teams
× Microservice architecture
× Continuous delivery
× Multiple environments
*2016 number

Conway’s Law
“…organizations which design systems ... are
constrained to produce designs which are copies of
the communication structures of these
organizations…”
— M. Conway

Microservices

What microservices are…
“…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

“Independently deployable services that work together, modelled around
a business domain…”
-Sam Newman

“The technical authority for a business capability”
- Udi Dahan

Shipping
Inventory
Customer
Service
Accounts
Returns
Invoicing

How?
Shipping
Inventory
Customer
Service
?

Domain Driven Design

Domain Driven Design
“Ubiquitous language” –Modelling the language of the
business
Provides guidance about model domains with
entities, value objects, repositories and services
Start reading from Chapter 11: Strategic
Design vs Tactical Design

Bounded Contexts
• Bounded Contexts are an essential
modeling tool in DDD and microservices
• Identify explicit boundaries around our
understanding of the ubiquitous language
and the things people care about
• Multiple models for a business concept
https://www.martinfowler.com/bliki/BoundedContext.html
Customer
Ticket
Product
Product
Version
Customer
Product
Territory
Opportunity
Pipeline
Sales
Person
Defect
Sales Context Support Context

Multiple Bounded Contexts
Concept
Contracting with
authors
Managing the
book’s authorship
and editorial
process
Designing the book
layout, including
illustrations
Source: Implementing Domain-Driven Design, Vaughn Vernon
Publishing Example: Book model
Translating the
book into other
languages
Producing the
physical print and/
or electronic
editions
Marketing the book
Selling the book to
resellers and/ or
directly to
consumers
Shipping a physical
book to resellers
and consumer

Context Maps
Bounded contexts alone don’t provide a global view of your
domain
Context maps deal with mapping different, but related,
Ubiquitous Languages by integrating their Bounded Contexts
Evans and Vernon describe 7 patterns for integrating
bounded contexts
• Shared Kernel
• Customer / Supplier
• Conformist
• Anticorruption Layer
• Separate Ways
• Open / Host Service
• Published Language
Sales Context Support Context
Marketing Context

Domain Events
• Objects in a domain that represent that something has happened
• Immutable – cannot change the past
• Should be represented as verbs in the past tense, e.g. “customer_created”
• Light weight, correlated by properties that are common across bounded contexts
“customer_id”
• Pattern for bounded context integration - Publish / Subscribe

Coupling

Managing Dependencies
Loose Coupling / High Cohesion
Encapsulation

Types of coupling
• Afferent (Ca) and Efferent (Ce)
Measurement units of the degree of coupling
Who depends on you?… Who do you depend on?
• Platform Coupling
May be introduced by things like proprietary protocols or components
that are platform specific
• Temporal Coupling
Dealing with time-based dependencies between collaborating system
components, e.g. waiting operations or sequential processing
• Spatial Coupling
Not having to know the location of your collaborating services on the
network and providing failover mechanisms, e.g. Amazon Elastic Load
Balancer
A B
A B

There is no loose coupling…

There is no loose coupling…
• Coupling is a function of multiple
dimensions
• No loose or tight
• Need to make tradeoffs
Platform
Spatial
TemporalAfferent
Efferent

Messaging & Messaging Patterns

Amazon Simple Queue Service (Amazon SQS)
• Simple enough to get started in minutes
• Highly reliable, always available, and durable
• Continuous scale allows burst loads with no excess
capacity
• Integrated with AWS platform with monitoring and queue
management
• Comprehensive security and compliance
“Worry-free managed
queues - simply and reliably
distribute any volume of
messages between
endpoints"

Amazon SQS Features
High durability
with messages
persisted across
multiple AZs
High availability
all AWS regions
Continuous and
unlimited scaling
Simplified
troubleshooting
with a Dead
Queue
Integrated with
other AWS
as a destination
> aws sqs create-queue --queue-name MyQueue

Amazon SQS as an Event Source (SQSaaES)
• Lambda polls the queue and when it detects new messages,
it invokes your Lambda function by passing the messages as
an event
• Full control over the queue processing settings such as
visibility timeouts, delay queues, redrive policy, etc. Supports
batch processing
• Lambda will gradually increase the queue polling rate as long
as queue polling results in fetching of new messages
• Supports Identity and Resource based policy
3. Lambda invoked
Lambda
function
SQS
Queue
2. Pull messages
from queue
1. Message arrives
on queue

Amazon Simple Notification Service (Amazon SNS)
• Highly reliable, available, and durable pub-sub service
that delivers messages to multiple destinations,
including system and mobile endpoints
• Continuous scale allows burst loads with no excess
capacity
• Integrated with AWS platform delivering messages
from services to subscribing endpoints
• Comprehensive monitoring, security, and compliance
“Simply and reliably distribute
any volume of messages and
event notifications anywhere”

> aws sns create-topic --name my-topic
Amazon SNS Key Features
High durability
with messages
persisted across
multiple AZs
High availability
all AWS regions
Continuous and
unlimited scaling
Simplify
development with
filtered message
delivery
Easy monitoring
with CloudWatch,
with alarming

Publish / Subscribe
• One logical publisher for a given domain event
• Fully enforces a consistent boundary
• Addresses multiple types of coupling
SNS
Topic
Service B
Service C
Service D
Service A
• Each subscriber can react to
domain events in their own
bounded context
• SNS supports multiple
subscription channels – Lambda,
SQS, HTTP/S, Email, SMS,
Mobile Push

Mapping events to topics
Grey
Topic
Attr=
Blue
Grey
Publisher
Blue
Topic
Blue
Grey
Blue
Blue
Grey
Subscribers
Service C
Service D
Service E
Service F
Message type mapped to logical destination

Amazon SNS Message Filters
• Publishers do not need to route message
• Subscribers do not need to filter for message of interest
• Lowers cost
SNS
Topic
Attr=
Grey
Attr=
Blue
Attr=
Blue
Attr=
Grey
Attr=
Blue
Attr=
Grey
Filter Policy
Attr=Grey
Filter Policy
Attr=Blue
Publisher

Message Filtering Operators
Subscription filter policy
{"sport": ["rugby"]}
matches message attribute
{"sport": "rugby"}
Exact matching on string
values (Whitelisting)
Anything-but matching on
string values (Blacklisting)
Prefix matching on
string values
Exact matching on
numeric values
Range matching on
numeric values
{"sport": [{"anything-but":
"rugby"}]}
matches message attributes such as
{"sport": "baseball"}
and
{"sport": "basketball"}
and
{"sport": "football"}
but not
{"sport": "rugby"}
{"sport": [{"prefix": "bas"}]}
matches message attributes such as
{"sport": "baseball"}
and
{"sport": "basketball"}
{"balance": [{"numeric":
["=", 301.5]}]}
matches message attributes
{"balance": 301.500}
and
{"balance": 3.015e2}
["<", 0]}]}
matches negative numbers only, and
[">", 0, "<=", 150]}]}
matches any positive number up to 150.

Long Running Processes

Coordination by Function Chaining

“I want
try/catch/finally”
“I want to
select tasks based on data”
“I want to
retry failed tasks”
A
B C
A
?
“I want to
sequence tasks”
BA
“I want to
run tasks in parallel”
CBA

AWS Step Functions
…makes it easy to coordinate the
components of distributed
applications using visual workflows

AWS Step Functions
“Serverless” workflow management with zero
administration
• Coordinate the components of distributed
applications and microservices using visual
workflows
• Keeps the orchestration out of the code!
• State management
• Automatically triggers and tracks each step,
and retries when there are errors
• Logs the state of each step, so when things do
go wrong, you can diagnose and debug
problems quickly
Task
Choice
Fail
Parallel

Microservices messaging patterns
One-Way
Lambda
function
SQS Queue
Return Address
SQS QueueLambda
function
Request / Response
Lambda
function
SQS Queue
SNS
Topic
Service B
Service C
Service D
Service A
Publish / Subscribe
request
response
request
response

Final thoughts

Microviews
• Don’t forget about the user interface!
• If a microservice is the technical
authority for a business capability
then it is also the authority on how
interacts with the user
• Leverage composite user interfaces
B
A
C D
E
A B C D E

https://imagescart.blogspot.com.au/2013/03/ayers-rock-in-uluru-national-park.html#.Wwp1DFOFMZo
Summary
Chances areYAGNI! Not everyone needs Microservices. If you have a well defined domain
then you don’t have to break the monolith apart entirely.
Don’t use a big bang approach. It’s an evolutionary journey.
Consider a monolith-first approach. Identify your bounded contexts first.
Lead your microservices strategy from strategic perspective. Model your microservices
around business capabilities.
Leverage messaging services and publish subscribe patterns to provide strict boundaries
around your bounded contexts and use them to manage coupling inside your application.

Thank you

Breaking Down the 'Monowhat'

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Breaking Down the 'Monowhat'

Semelhante a Breaking Down the 'Monowhat' (20)

Mais de Amazon Web Services

Mais de Amazon Web Services (20)

Breaking Down the 'Monowhat'

Notas do Editor