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
Breaking Down the Monowhat?

About Me
Senior Solutions Architect
WWPS - Australia and New Zealand
@sliedigaws
in/sliedig/
Stephen Liedig

The Monowhat

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
https://imagescart.blogspot.com.au/2013/03/ayers-rock-in-uluru-national-park.html#.Wwp1DFOFMZo

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

What microservices are not…
Defined by the number of lines of code
Services that only have subroutines (calculation or a validation) are
functions, not a service
Services that only expose CRUD operations are RPC call to a
database, not a service
REST / SOAP provide common interfaces for integration but don’t
change the logical responsivity of the implementation

“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
Top Tip!
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 SQS Amazon SNS

Amazon SQS
WHAT IT IS
Simple, flexible, fully
managed message
queuing service for
reliably and
continuously
exchanging any
volume of messages
from anywhere
USE CASE
Build decoupled,
highly scalable
microservices,
distributed systems,
and serverless
applications in the
cloud
COOL CAPABILITIES
Nearly infinite
scalability and ability
to increase message
throughput without
pre-provisioning
capacity
> 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 policy3. Lambda invoked
Lambda
function
SQS
Queue
2. Pull messages
from queue
1. Message arrives
on queue

Amazon SNS
WHAT IT IS
Simple, flexible, fully
managed
publish/subscribe
messaging and
mobile push
notification service
for high throughput,
highly reliable
message delivery
USE CASE
Push messages to a
variety of endpoints
and clients in
distributed systems,
microservices, and
serverless
applications and
enable event-driven
architecture
COOL CAPABILITIES
Highly reliable
delivery of any
volume of messages
to any number of
recipients across
multiple protocols
> aws sns create-topic --name my-topic

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

Distributed Transactions & Saga Pattern

What are Sagas?
• Pattern for dealing with “long-lived transactions” (Garcia-Molina,
Salem 1987)
• Challenges dealing with transactions in a distributed system - no
transaction coordinator!
• Time is not consistent. Time is contextual.
• Semantic consistency by providing compensating transactions for
every transaction where you have more than one collaborating
services or functions
• Failure management pattern

Applying Saga pattern with AWS Step Functions
https://theburningmonk.com/2017/07/applying-the-saga-pattern-with-aws-lambda-and-step-functions/

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 are YAGNI! Not everyone needs Microservices. If you have a well defined
domain then you don’t have to break the monolith apart entirely.
Lead your microservices strategy from strategic perspective. Model your
microservices around business capabilities.
Consider a monolith-first approach. Identify your bounded contexts first.
Don’t use a big bang approach. It’s an evolutionary journey.
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

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Breaking Down the Monowhat

Similar a Breaking Down the Monowhat (20)

Más de Amazon Web Services

Más de Amazon Web Services (20)

Breaking Down the Monowhat