Migrate-Critical-Workload-to-AWS-From-Domain-Driven-Design-perspective

© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Ice Breaking & On Boarding

Migrate Critical Workload to AWS
From Domain Driven Design perspective
Kim Kao, Solutions Architect
yikaikao@amazon.com
@Yikaikao
Domain Driven Design(DDD Taiwan)
Kim Kao

Enterprise face a challenging environment
?
High customer
expectations, fickleness
Low barriers
to entry
Constant, rapid change
and uncertainty

It’s all about change
• Product
• Operational Excellence
• Client Experience
• Business Model

1. Rapid series innovation
2. Product teams
3. Relentless training
4. Application modernization
5. Embedded security
6. IT as a partner of the business
1. The big bang
2. Project approach - siloed
3. Don’t have time for training
4. Non-agile approach
5. Bolt on security
6. IT as a contracted service
Enterprise challenges Enterprise opportunity

2.0
• Build on
• Everything gets put on
• End date for improvement
The big bang

• Endless agile MVP market experiments
• Platforms that rapidly scale best results
• Compete again and again to win and
retain customers
• Start with small teams, small slices of
value, and small investments
“Nail it before you scale it”
Rapid series innovation

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

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

How or why should I migrate my
monolith?

Common migration strategies
There is no one size fits all approach to migrating your applications

Methodical migration process
Visualize the cloud adoption effort from planning to operating on AWS
Evaluate Plan Design Migrate Optimize
• Discovery
• Migration
patterns
• Well Architected
• Tool selection
• Test planning
• Cutover planning
• Migration
workloads
• Migration tools
• Validation &
cutover
• Operation
• Optimization
• Migration
Readiness
Assessment
• On-boarding
• Planning and SOW
• Portfolio
discovery
• Requirements
collection
• Landing Zone
• People - skills and
organization
• Business case, TCO

Portfolio discovery
Goals:
• Determine resource allocation in the AWS environment
• Develop a prioritized backlog of applications to feed migration
• Assess project migration costs and run costs
Evaluate
Discover
& Plan
Design Migrate Optimize

Questions & challenges on the Journey
• Where to start?
• What to break out?
• Dependencies?
• Works as expected?
• Users happy?
• Does it scale?
• Does it perform?
• How to automate?
• Works as expected?
• Users happy?
• How to optimize?
Does it perform?
• How to automate?
?
? ?
?
?
?
?
?
?
?
?
?
?
?
?
?
?
? ?
?
?
?
? ? ?
?
?
?
?
From
On-Premises Monolith
Via
Containerized Services
To
Functions & Cloud Services

How can you discuss with
stakeholders for key
workload?

We are all in the
business of innovation.

Rapid innovation is an imperative
Exploit existing
capabilities
Make your
numbers
Explore new
opportunities
Incubate
new ideas

Rapid innovation is digital at its core
Strategy
Culture
Technology
Talent

Rapid innovation evolves the business
New markets
New customer outcomesNew economics
New digital products & services

What it takes to enable rapid innovation
Quality Agility Velocity
Rapid
innovation

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
“Any organization that designs a system…
will inevitably produce a design whose
structure is a copy of the organization’s
communication structure.”
—
Melvin Conway
a.k.a  Silo

Way to deal with Complexity
problem Domain

An Engineer promised his boss to develop an app.
Now what?
Step 0: Requirement analysis, high level design…
Step 1: Design decisions - what to use?
Serverless web app with
…an API ???
…access to existing data stored in ???
…static content served by ???
…dynamic content/business logic encoded as ???
What we need

Problem Solving

Domain Driven Design
Eric Evans
Ubiquitous Language
Bounded Context

User Registered
User
Authenticated
Shipping info Filled
Goods Selected
Order Placed
Time
Variety business events

Divide Complexity problem by Event Storming
“ All the key Stakeholders in the same room
with an unlimited modelling space
Using stickies as Domain Events ”
~ Alberto Brandolini

Traditional Meeting

Leave Space for Storming

Immutable Truth

Explain Most Valuable Chances and Risks

Way to collaborate
• Point out the events
• Who send the command
• Find the Noun(s)
• Have all team voices
Commands
Events
Aggregate

Form up Domain Boundary

Approach
• Collect the “Aggregates” which stand for similar concept
in the “Bounded Context”, draw a circle shape.
• Prioritize the “Domains”, which one is Core Domain, rest
for Sub Domain, even Utility Domain.
• Get Consensus, not Compromise
• Focus on Core Domain

Challenge
New development
Hard to net new
Branding
Hotel amount
growth high
Segmentation
Specific customer
obssessed

New Business operation attempt
Keep travelers safety in
Clean environment for
Variety Pillow
Refund when Not Satisfied
Easy to fall asleep
Stay like home
During the stay

Free WIFI
Power
Station
Agile
Solution
Architecture
Industrialized
Patterns &
Solutions
Comfortable
Pillow
Choices
Customized
Service
Cross hotel Vending
Machine
Self
Checkout
POS
Digital
Door-lock
360º
Customer
Persona
IT operation response in time
New Technology required
Business Driven Evolution
Super Hotel Operation

What’s the major concern for
Super Hotel transformation?

Crunch Domain(Business)
events flow

Scenario : Guest Check in & out flow
Confirmed
Booking
Presented
E-Keys
Verified
Booking guest
Took
elevator
Filled up
Guest Info
Opened
Room Door
Delivered
Stay policies
Acted
In Room

Scenario : Guest Check in & out flow
Shower
took
Asleep
fallen
Raised
A morning call
Checked
Out

Form up Boundary by Aggregate concept

UX Consideration

Face all the risks

Domain Boundary confirmed
Super
Hotel
How to implement ?
Multiple RDS ?

There is no One-size-fits-all

Relational
Referential
integrity, ACID
transactions,
schema-
on-write
Lift and shift, ERP,
CRM, finance
Key-value
High
throughput, low-
latency reads
and writes,
endless scale
Real-time bidding,
shopping cart,
social, product
catalog, customer
preferences
Document
Store
documents and
quickly access
querying on any
attribute
Content
management,
personalization,
mobile
In-memory
Query by key
with
microsecond
latency
Leaderboards,
real-time analytics,
caching
Graph
Quickly and
easily create
and navigate
relationships
between
data
Fraud detection,
social networking,
recommendation
engine
Time-series
Collect, store,
and process
data sequenced
by time
IoT applications,
event tracking
Ledger
Complete,
immutable, and
verifiable history
of all changes to
application data
Systems
of record, supply
chain, health care,
registrations,
financial
Amazon
QLDB
Amazon Aurora
Amazon RDS
Amazon
DynamoDB
Amazon
DocumentDB
Amazon
ElastiCache
Amazon
Neptune
Amazon
Timestream
Booking Guest 360 E-Door LockPromotion
Advertise
Digital
Assets
PaymentPillow
Staff

https://qrgo.page.link/x19n

• Circle Study group
• Implementing Domain Driven Design
• Volunteer reader lead
• Hands-on workshop
• Try Pair programming

Fill Survey  Earn credit

Thank You!

Migrate-Critical-Workload-to-AWS-From-Domain-Driven-Design-perspective

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Migrate-Critical-Workload-to-AWS-From-Domain-Driven-Design-perspective

Ähnlich wie Migrate-Critical-Workload-to-AWS-From-Domain-Driven-Design-perspective (20)

Mehr von Amazon Web Services

Mehr von Amazon Web Services (20)

Migrate-Critical-Workload-to-AWS-From-Domain-Driven-Design-perspective