Getting from Here to There: A Journey from On-premises to Serverless Architecture - ARC316 - re:Invent 2017

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
AWS re:INVENT
Getting from Here to There: A Journey from
On-Premises to Serverless Architecture
A R C 3 1 6
N o v e m b e r 2 9 , 2 0 1 7

Introductions
Timothy Patterson is a sr. technical account manager at Amazon Web Services (AWS). Having
earned all 7 publically available AWS Certifications, Timothy loves to share his in-depth
knowledge of AWS and illustrate the transformative power that the platform can have on
organizations of all sizes. Timothy not only believes in the AWS message, he has lived it.
Timothy came to AWS after having served his previous employer as a principal cloud architect
for three and a half years. During this tenure, the organization underwent a dramatic
transformation as a cloud-first, and all-in AWS strategy was adopted. Timothy’s main areas of
focus revolve around infrastructure automation, optimization, and migration towards
serverless architectures.
Ryan Wassa is a technical account manager at Amazon Web Services (AWS), who specializes in
AWS Serverless technologies such as Lambda and Amazon API Gateway. With his propensity to
keep all things agile, he works with customers to streamline their development processes while
maintaining scale and saving costs. Prior to joining AWS, Ryan worked on many large-scale
projects in both the public and private sectors. His background includes everything from
systems administration and application development to project management. These skills help
balance between the fine line of technology costs and business needs.

Agenda
This session takes you on a journey from traditional, on-premises applications and architecture to pure
serverless environments.
This transformative approach highlights the steps required to incrementally move into AWS technologies
while increasing resiliency, efficiency, and reducing operational overhead.
We will challenge traditional understanding and show you how different types of workloads can be migrated,
using real-world examples. Additionally, we will demonstrate how you can assemble and utilize the AWS
building blocks available today to bolster your success and position you to inherit the power of our managed
services.
You will leave armed with the knowledge you need to begin your own voyage towards
serverless architecture!

The journey
Every cloud adoption journey is unique!
There is no one-size-fits-all way that companies are moving to the cloud.
There are some common migration patterns that have emerged with enterprise customers:
• Development and test workloads
• Brand new applications
• Websites, analytics, and mobile applications
• Business critical applications
• Entire datacenter migrations
• All-in on AWS

The journey—continued
The technological journey is also unique!
There is no one-size-fits-all approach to getting into a true serverless solution.
We are going to walk you through the most common phases of application migration using two different
applications as our guide. We will take you through the following architectures:
• Completely self-hosted on-premises
• Hybrid
• All-in on AWS
• Pure serverless
In order to move from one phase to the next, there are many obstacles that need to be overcome.

Serverless? Definition please!
Serverless computing allows you to build and run applications and services without thinking about servers.
You are not required to provision, scale, or manage any servers.
Serverless applications provide four main benefits:
No server management
Flexible scaling
High availability
No idle capacity
If your idea of serverless fits this pattern,
“Deploying serverless on…” includes:
- Containers
- Virtual machines
- And so on…
Think again!
(Credit to Mark Nunnikhoven, Twitter: @marknca)

The business Pegasus Pickups:
A world-class, premier transportation service that gets
people get to their destination in elegant style.
Pegasus Pickups was the first successful worldwide exotic
ride service. Users simply request a ride, and a Pegasus
swoops down from the sky and picks them up!
Pegasus Pickups has enjoyed a monopoly in their market
for many years.
Pegasus Pickups is currently hosting their set of
applications in their on-premises datacenters.
NOTE: This is a completely fictitious example. Names, characters, businesses, places, creatures, events and
incidents are either the products of the author's imagination or used in a fictitious manner.
Any resemblance to actual events is purely coincidental.

The problem
Meet Wild Rydes…
Wild Rydes completely disrupted the exotic ride market.
Their unmatched agility and pace of innovation has
allowed them to overtake Pegasus Pickups within six
months of their inception.
Wild Rydes offers end-users rides on unicorns, and offers
more features and a better user experience.
Their sudden success has been directly attributed to the
fact that they were born on the cloud. Using a pure
serverless architecture, their development teams can focus
more on innovation and less on infrastructure.
NOTE: This is a completely fictitious example. Names, characters, businesses, places, creatures, events and
incidents are either the products of the author's imagination or used in a fictitious manner.
Any resemblance to actual events is purely coincidental.

The applications
Web/Mobile application:
Users can request a Pegasus ride from anywhere, anytime.
Batch processing:
Churns through various incoming data sources for business analytics,
user features, and fleet management.

Today’s infrastructure: On-premises
Pegasus DC 1 (Las Vegas) Pegasus DC 2 (Ann Arbor)
Storage Replication
VPN Connectivity

Today’s problems
• Things are moving too slowly: It takes 10 to 18 weeks to
provision hardware
• Datacenters are expensive: facility, cooling, electricity,
ongoing maintenance, so on…
• Pegasus Pickups is fully responsible for both physical and
logical security
• Staff is spending their time just “keeping the lights on”
Too much undifferentiated heavy lifting!
• Increasing competitive pressure
• Frustrated C-Level executives
• No time for innovation
• Agility is non-existent
• Revenue is dramatically reduced
The heat is on!
”How can we possibly recover from this?”
Hybrid to the rescue!

Why hybrid?
“Wait now, hold up! Isn’t AWS a public cloud provider?”
A hybrid environment offers many benefits for companies who currently own, maintain, and deploy their own
assets…
• Can take advantage of existing resources before they reach their shelf life
• Business will still realize results
• Gain the advantages that the AWS platform has to offer
AWS has been enabling hybrid architectures from the start!

Hybrid web transition steps
1. Create VPC
2. Create Public Subnets
3. Establish VPN Connectivity
4. Swing DNS over to Amazon
Route 53
5. Create Application Load
Balancer (ALB)
6. Create ALB Target Group
(target type: ‘ip’)
7. Create Network Load
Balancer (NLB)
8. Create NLB Target Group
(target type: ‘instance’)

Hybrid web transition steps—continued
9. Create Launch
Configuration
10. Create multi-AZ Auto-
Scaling Group (ASG)
[min=2]
11. Register ASG with NLB’s
Target Group
12. Lookup NLB’s IP addresses
(private) and add them as
IP targets in the ALB’s
Target Group
13. Enter on-premises load
balancer IP addresses in
the ALB’s Target Group
14. Change Amazon Route 53
DNS to point to ALB

Hybrid next steps
Database tier:
• MySQL can be migrated to run on Amazon Elastic Compute Cloud (Amazon EC2) or even
the Amazon Relational Database Service (Amazon RDS)
• Can either use MySQL’s own native replication mechanisms or the AWS Database
Migration Service (AWS DMS)
• When using native replication, the MySQL instance external to RDS must be
running the same version as the Amazon RDS instance, or a later version
• AWS DMS is useful for moving across DB engine versions, amongst other things
Amazon RDSAmazon EC2
AWS DMS
Other improvements:
• Networking: Consider using AWS Direct Connect to add high-speed connectivity into the
AWS region you have deployed into
• Dedicated connections of 1Gbps and 10 Gbps ports are available
• Shared connections with speeds of 50 Mbps, 100 Mbps, 200 Mbps, 300 Mbps,
400 Mbps, and 500 Mbps can be ordered from any APN partners supporting
AWS Direct Connect
• Availability: Consider deploying into additional Availability Zones or Regions
Direct
Connect

Hybrid next steps—continued
Batch processing application:
• If you have established higher speed connectivity (via Direct Connect), consider
migrating away from the on-premises NFS storage in favor of the Amazon Elastic File
System (Amazon EFS)
• Amazon EFS shares can be mounted on-premises across Direct Connect links
• Amazon EFS shares can be mounted across multiple Availability Zones within a
single Region
• With Amazon EFS, you only pay for what you use—no sunk storage costs
• Migrating the storage to Amazon EFS will allow you to migrate the batch processing
application to AWS
• This empowers you to take advantage of Auto-Scaling groups for the batch processing
workload(s)
Amazon EFS
Direct
Connect
• Increased elasticity = reduced costs
• Less infrastructure to manage = increased agility
• Increased agility = more innovation!

Awesome! Where to now?
While it is true that a hybrid computing model adds many benefits to an organization that has traditionally
been hosted entirely in an on-premises fashion, hybrid is just one step in our transformational journey.
Points to ponder:
• What happens when my hardware is up for a refresh?
• Do I really want to renew the lease on my datacenter facilities?
• What additional benefits could I get from pushing further into the cloud?
How about all-in on AWS?

That’s a bold move! …Isn’t it?
Let’s crank up the volume!
Even more agility.
Even more elasticity.
Increased cost savings.
Looking back five years or so ago, sure, but today? Cloud has become the new normal, and all-in migrations
are an accelerating trend.
Think about it—the hybrid stop on our journey has already laid the framework for the remaining migration
activities…
By moving to an all-in on AWS model, you are amplifying the benefits that you realized in the hybrid state.
Increased operational velocity!

All-in on AWS

That looks… complicated
While an all-in architecture diagram may seem daunting at first, allow me to walk you through each of the
moving parts and discuss how we assembled various AWS building blocks in order to arrive at this point in
our journey.

All-in web transition
What has changed?
1. Web servers now sit directly behind the
ALB
• NLB no longer necessary
• Simply attach web servers
Target Group to new ALB and
update DNS
2. Static web assets (ex: images, CSS files)
moved into an Amazon Simple Storage
Service (AmazonS3) bucket
3. Amazon CloudFront CDN introduced to
cache static and dynamic content
(where applicable)
4. Route 53 updated to remove on-
premises entries
5. VPN no longer necessary*

All-in batch
processing transition
What has changed?
1. Batch processing nodes have been fully
migrated to AWS
2. SQS introduced: intended to replace
NFS polling mechanism
• Allows Auto Scaling based
upon actual number of jobs
in queue versus system CPU
• Also enables for faster
parallel processing
3. Operates in private subnet
environment
4. Utilizes NAT Gateway for internet
connectivity for SQS access, as well as
OS and application updates

All-in database transition
What has changed?
1. Entirely migrated to RDS
• Fully managed
• Automated patching and
backups
• Can vertically scale if
necessary
2. Automatic read replica available for
use—increased redundancy and could
be used to speed up read-only batch
and web operations
3. The read replica can also take over as
the database master in case of a
primary node failure

• Git Repository
• Jenkins Project
• Deploy to AWS account(s)
Hybrid & All-in CI/CD tools
CloudFormation is your best friend!
https://jenkins.io/https://git-scm.com/

Hybrid & All-in blockers
COST? RE-TRAINING EFFORTS B U S I N E S S
D E A D L I N E S
C O M P L I A N C E /
R E G U L A T I O N S

All-in next steps
Congratulations!
You have now completed your journey into an all-in on AWS architecture!
It’s time to sit back and reap the rewards of your labor. Your organization is now realizing much more
operational velocity, thanks to the completion of this project.
There is no more undifferentiated heavy lifting. Managing bare metal is a thing of the past.
Now we can sleep well at night knowing that we are as fully optimized and watch as our development groups
release innovative new features, allowing us to catch up to those pesky Wild Rydes folks!
Hold up! Why stop here?
It can’t be that easy! Let’s keep the velocity…

Serverless architecture

FEAR OF UNKNOWN LEGACY CODE OTHER PRIORITIES HANDCUFFED
Serverless blockers

First web transition steps
Amazon S3
+ CloudFront
API Gateway

Web authentication
Authenticates every API call
Flexibility with Amazon Cognito
Pass authentication information to Lambda for finer grained
authorization
API Gateway custom authorizers

Web logic and batch processing
Events:
ReadFromQueue:
Type: Schedule
Properties:
Schedule: rate(1 minute)
BATCH SCHEDULE
API EVENT
Events:
UpdateResource:
Type: Api
Properties:
RestApiId: !Ref MyApi
Path: /user/update
Method: post
Events:
PhotoUpload:
Type: S3
Properties:
Bucket: !Ref Bucket
Events: s3:objectCreated:*
S3 EVENT

Additional thoughts
Familiar languages
Only pay for what you use
De-provision without risks

Serverless CI/CD Tools
AWS
CodeCommit
AWS
CodePipeline
AWS
CodeStar
https://jenkins.io/https://git-scm.com/
AWS
CodeBuild AWS SAM
(Serverless Application Model)

• Git Repository
• Jenkins Project
• Project Build
• Deploy to AWS account
• CodeCommit
• CodePipeline
• CodeBuild
• Runs within AWS account
Serverless CI/CD Tools

Conclusion
Eliminated need for hardware
Reduced costs
Can focus on development and innovation
Serverless is already in your toolbox

Thank you!

Getting from Here to There: A Journey from On-premises to Serverless Architecture - ARC316 - re:Invent 2017

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Getting from Here to There: A Journey from On-premises to Serverless Architecture - ARC316 - re:Invent 2017

Similar to Getting from Here to There: A Journey from On-premises to Serverless Architecture - ARC316 - re:Invent 2017 (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Getting from Here to There: A Journey from On-premises to Serverless Architecture - ARC316 - re:Invent 2017