AWS Initiate Day Dublin 2019 – Breaking down the Monoliths

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Breaking Down the Monoliths?

The Monolith

© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
The Monolith
“…a 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

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
microservices

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

= Millions of deployments per year
Thousands of teams
× Microservice architecture
× Continuous delivery
× Multiple environments
Amazon transformation

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

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 Create, Read, Update and Delete (CRUD)
operations are Remote Procedure calls (RPC) to a database, not a
service
• REST / SOAP provide common interfaces for integration but don’t
change the logical responsivity of the implementation

Shipping
Inventory
Customer
Service
Accounts
Returns
Invoicing

How?
Shipping
Inventory
Customer
Service
?

Designing Microservices with the Domain Driven Design
Framework - Bounded Contexts
• Domain Driven Design is a broad
framework to making design decisions
• Bounded Contexts are an essential
modeling tool in DDD and microservices
• DDD deals with large models by dividing
them into different Bounded Contexts
and being explicit about their
interrelationships.
• A model acts as a Ubiquitous Language
to help communication between
software developers and domain experts
• Ubiquitous Language is the practice of
building up a common, rigorous
language between developers and users.
https://www.martinfowler.com/bliki/BoundedContext.html
Customer
Ticket
Product
Product
Version
Customer
Product
Territory
Opportunity
Pipeline
Sales
Person
Defect
Sales Context Support Context

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
7 patterns for integrating bounded
contexts
• Shared Kernel
• Customer / Supplier
• Conformist
• Anti-corruption Layer
• Separate Ways
• Open Host
• Published Language
Sales Context Support Context
Marketing Context

Coupling Bounded Context - Types of coupling
• Afferent (Ca - Incoming) and Efferent (Ce - Outgoing)
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
Coupling is a measure that defines the level of inter-dependability
between modules or components

AWS Serverless Services for
implementing Microservices

Serverless tenets
No server management Flexible scaling
No idle capacity
$
High availability

Managed services as building blocks
AWS Lambda
Amazon API Gateway
Orchestration
API proxy
Compute
AWS Step Functions
Amazon SNS
Amazon SQS
Amazon S3
Messaging
Monitoring and debugging
Storage
AWS X-Ray
Amazon DynamoDB
Amazon Kinesis
Analytics
Database
Edge compute
AWS Greengrass
Lambda@Edge
Amazon Athena
Amazon Aurora Serverless
Application Frameworks
AWS Amplify

• Platform to run code without thinking about servers
• Our definition
• No servers to provision or manage
• Scales with usage
• Never pay for idle
• High availability built in, fault tolerance made easier
• Native integration with other AWS services
• Benefits
• Event-driven framework
• Multiple invocation models
Serverless: AWS Lambda

AWS serverless web architecture
AWS Cloud
Amazon
DynamoDB
AWS
Lambda
Amazon
API Gateway

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
in all AWS
regions
Continuous and
unlimited scaling
Simplified
troubleshooting
with a Dead
Letter Queue
Integrated with
other AWS
services as a
destination

Amazon SQS as an Event Source
• 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
2. Pull messages
from queue
1. Message arrives on
queue
Queue
Lambda function

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”

Amazon SNS Key Features
High durability
with messages
persisted across
multiple AZs
High availability
in all AWS
regions
Continuous and
unlimited scaling
Simplify
development with
filtered message
delivery
Easy monitoring
with CloudWatch,
with alarming

Publish / Subscribe
• 1 to many (fan out) between publisher and subscribers
• 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

Amazon SNS 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"}]}
{"sport": [{"prefix": "bas"}]}
matches message attributes
{"balance": 301.500}
and
{"balance": 3.015e2}
matches negative numbers only, and
{"balance": [{"numeric":
[">", 0, "<=", 150]}]}
matches any positive number up to 150.

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, uses a JSON based
specification called States Language
• Out of the box on the AWS Console
• 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

Don’t forget about the user interface!
• Microviews (user interfaces
matching microservices)
• 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
frameworks (like AWS Amplify)
B
A
C D
E
A B C D E

Summary
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 the whole solution in it’s entirety first and identify your bounded
contexts to break it down into microservices.
Lead your microservices approach from a 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.

AWS Initiate Day Dublin 2019 – Breaking down the Monoliths

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a AWS Initiate Day Dublin 2019 – Breaking down the Monoliths

Semelhante a AWS Initiate Day Dublin 2019 – Breaking down the Monoliths (20)

Mais de Amazon Web Services

Mais de Amazon Web Services (20)

AWS Initiate Day Dublin 2019 – Breaking down the Monoliths