Eliminating Busywork at the Organizational Level · 6/23/2020 · © 2020, Amazon Web Services, Inc. or its Affiliates. © 2020, Amazon Web Services, Inc. or its Affiliates. David

© 2020, Amazon Web Services, Inc. or its Affiliates. © 2020, Amazon Web Services, Inc. or its Affiliates.

David Yanacek, Sr. Principal Engineer, AWS Lambda

@dyanacek

Eliminating Busywork at the

Organizational LevelTips for using serverless to its fullest potential

© 2020, Amazon Web Services, Inc. or its Affiliates.

Table of contents

• Removing roadblocks to serverless

• Finding the right path(s) to serverless

• Leveraging trailblazers: A how-to guide


Removing Roadblocks to Serverless


LE

VE

L O

F A

BS

TR

AC

TIO

N

FOCUS ON BUSINESS LOGIC

PHYSICAL MACHINES

Requires “guess” planning

Lives for years on-premises

Heavy investments (capex)

Low innovation factor

Deploy in months

Computing evolution – A paradigm shift


LE

VE

L O

F A

BS

TR

AC

TIO

N


VIRTUAL MACHINES

Hardware independence

Faster provisioning speed (minutes/hours)

Trade capex for opex

More scale

Elastic resources

Faster speed and agility

Reduced maintenance



LE

VE

L O

F A

BS

TR

AC

TIO

N


CONTAINERIZATION

Platform independence

Consistent runtime environment

Higher resource utilization

Easier and faster deployments

Isolation and sandboxing

Start speed (deploy in seconds)



AWS Lambda

AWS Fargate

LE

VE

L O

F A

BS

TR

AC

TIO

N


Continuous scaling

Fault tolerance built-in

Pay for value

Zero maintenance

SERVERLESS



Laziness


Laziness

Productivity

Developer efficiency


Law of Laziness:

Developers choose tools that get the

job done using the least amount of effort

(Productivity)


LE

VE

L O

F A

BS

TR

AC

TIO

N

SERVERLESS

AWS Lambda AWS Fargate

The path(s) to serverless

CONTAINERS

VIRTUAL MACHINES

PHYSICAL MACHINES



𝑠




The invisible hand



LE

VE

L O

F A

BS

TR

AC

TIO

N

SERVERLESS


Which path to serverless?

CONTAINERS

VIRTUAL MACHINES

PHYSICAL MACHINES



(Productivity)

Law of Laziness:





(less effort with serverless)


Removing Barriers to Change


Development transformation at Amazon: 2001-2002


2-tier architecture


The cost of coordination


Release train: build, test, deploy, monitor


Lots of coordination

developers

delivery pipeline

monolith


Lots that can go wrong

developers

delivery pipeline

monolith


Bottlenecked processes


“[A system’s speed and throughput is

limited by the speed of its serialized tasks]”

Amdahl’s law:


parallelization

serialization

Amdahl’s law:


The cost of coordination


parallelization

serialization

coordination

Universal scalability law:


The teams behind the monolith


The cost of consensus building


Reduced consensus building through abstraction

API

API

API

API


Reduced coordination


The hidden cost of coordination

(coupling makes change harder)


Breaking down activation energy


Breaking down the blockers

Coordination / coupling

Existing release tools

Existing monitoring tools

Existing security practices



Where can I look for good

opportunities to use

serverless?


SERVERLESS


“The road less traveled”

SERVERFULL


SERVERLESS


All roads lead to serverless!


What new development effort are

we about to take on?


InstanceLambda function

Using Lambda within Lambda

?

AWS Lambda


Lambda triggers

Amazon Kinesis

Amazon Simple Queue Service

Amazon DynamoDB

AWS Lambda Your Lambda Function


Configuring Lambda triggers

CreateEventSourceMapping()

Amazon Kinesis

AWS Lambda Your Lambda FunctionAmazon Simple Queue Service

Amazon DynamoDB


A fork in the road

Is the decision reversable?

How much coupling is there to

existing systems?


AWS Lambda

InstanceLambda function

?




AWS Lambda

Lambda function


What part of the monolith is

causing scale problems?


Serverless is more than compute

COMPUTE

DATA STORES

INTEGRATION

Amazon

DynamoDB

Amazon Aurora

Serverless

Amazon

S3

AWS

Lambda

AWS

Fargate

Amazon

EventBridge

Amazon

API Gateway

Amazon

SQS

Amazon

SNS

AWS

AppSync

AWS

Step Functions


Example: website session data

Users

Relational Database

Web Server

(browser session data) (application data)


Example: website session data

Users

Relational Database

Web Server

(browser session data) (application data)


Example: Website session data

Sharded databasesAmazon DynamoDB

(session data)

(application data)

?

Users

Web Server Existing database



Amazon DynamoDB

(session data)

(application data)

Users

Web Server Existing database



Web Server

Amazon DynamoDB

Amazon API Gateway

Amazon DynamoDB

Accelerator (DAX) Amazon Aurora Amazon Managed

Apache Cassandra

Service

Amazon

ElastiCache


What part of the monolith is

causing (human) scale problems?


A different kind of scaling bottleneck


Yesterday’s microservice, tomorrow’s monolith


AWS Lambda

Control plane serviceLambda function

?

43 APIs (and counting!)


Mono to Micro

Moving monolithic applications to

microservices by gradually

creating events and APIs for

various components on of the

legacy application

The Strangler Pattern


Tools for branching out

Amazon API Gateway

Monolith

Foo()

Bar()

Baz()

Bar()

Baz()

Foo()Bar()

Foo()


What operational paper cuts could

we automate if automation was

easy?


Automating with an “ops bot”

Nightly scaling

Root cause analysis

Automated actions

Automated backups


Who operates the operations automation?


What new project do we need to

build especially quickly?


Infrequently used web tools?


Virtual Choir video uploader

Amazon Simple

Storage Service

Amazon Cognito Amazon Simple

Notification Service

Email

notification

Choir Choir

director


What might someone build during a

hackathon using serverless?


Serverless is huge in hackathons

Experiment with

big ideas

Science!

Build new tools

Drive data analytics

Sandboxed prototyping


Which systems utilize hardware

especially poorly?


Low utilization workloads

(waste)

(problem)

(no provisioning)


Leveraging Serverless

Trailblazers


Opportunistic adoption

(low adoption cost)

(large payoff)


Using a catalyst

(catalyst reduces energy)


What did you do to adopt serverless

that you could avoid doing next time?


Story: Bridging sign-in systems

Operators

Existing operational

tools



Operators

Existing operational

tools

Corporate Sign-In

(verify)



Operators

New Lambda-based

web tool

Amazon API GatewayCorporate Sign-In

?



Operators

New Lambda-based

web tool

Corporate Sign-In Authorizer



Operators

New Lambda-based

web tool

Corporate Sign-In Amazon Cognito Amazon

API Gateway



New tool!

(other developers)


In conclusion…


(Productivity)

Law of Laziness:




LE

VE

L O

F A

BS

TR

AC

TIO

N

SERVERLESS


More abstraction, less busywork

CONTAINERS

VIRTUAL MACHINES

PHYSICAL MACHINES



LE

VE

L O

F A

BS

TR

AC

TIO

N

SERVERLESS


Many starting points, many paths

CONTAINERS

VIRTUAL MACHINES

PHYSICAL MACHINES



Identifying opportunities and catalysts

(low adoption cost)

(large payoff)(catalysts)


Many paths, many questions

• New development?

• System scale problems?

• Human scale problems?

• Missing operational tools?

• Urgent new project?

• Poor utilization?

• Hackathon ideas?

• Adoption papercuts?


SERVERLESS




SOA: Service-oriented architecture

API

API

API

API


Conway’s law:

The structure of any system designed by an organization

is isomorphic to the structure of the organization.


SOA:

Service-oriented architecture


The new SOA:

Serverless organizational architecture


Thank you!@dyanacek

Documents

Eliminating Busywork at the Organizational Level · 6/23/2020 · © 2020, Amazon Web Services, Inc. or its Affiliates. © 2020, Amazon Web Services, Inc. or its Affiliates. David