© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Constantin Gonzalez

Principal Solutions Architect, Amazon Web Servicesglez@amazon.de, @zalez

Dancing with dependencies maximizing opportunities while dealing with lock-in

AWS Software Business Leader Forum

New IT• Unlimited resources • No financial risk • Software-defined,

dynamic architecture • 100% automated • Flexible • Deployed in minutes • World-wide • Secure • Robust

New Players• Cloud vendors

• Automation tools

• Frameworks

• Components

Are We Getting Locked In?(again?)

What does it mean to be “locked-in”?

Lack of choice

Limits & Dependencies

Types of lock-in

Types of lock-in• Standardization

Types of lock-in• Standardization • Contract

Types of lock-in• Standardization • Contract • Organization

Types of lock-in• Standardization • Contract • Organization • Time

Types of lock-in• Standardization • Contract • Organization • Time • Cost $$

$

Types of lock-in• Standardization • Contract • Organization • Time • Cost • Technology $$

$

Types of lock-in• Standardization • Contract • Organization • Time • Cost • Technology • Resource

$$$

Avoiding one type of lock-in can create other lock-ins

Example: Abstraction layer

We built our own abstraction layer

on our own infrastructure

Idea Completed Project

Not possible

We don’t support thatMaybe next

year

That’s a change order

Most “lock-ins” are internal• Standardization • Contract • Organization • Time • Cost • Technology • Resource

We built our own abstraction layer

on our own infrastructure

We built our own abstraction layer

on our own infrastructure

Most “lock-ins” are internal

• Standardization • Contract • Organization • Time • Cost • Technology • Resource

FAIL

Risks when „preventing lock-in“

• High costs • High resource requirements • Long time to market, long time to react • Re-inventing uglier wheels

Two Options

Accept lock-in (and enjoy the benefits)

– or –

Eliminate lock-in

Eliminating lock-in …for good!

A simple solution

A simple solutionLack of choice,

lots of dependencies

A simple solution

Maximum choice, minimum dependencies

Lack of choice,lots of dependencies

Maximum choice, minimum dependencies

• Any standard you want • No contractual obligations • No organizational burden • At any time • Flexible cost • Any technology • Free up resources

Maximum choice, minimum dependencies

• Any standard you want • No contractual obligations • No organizational burden • At any time • Flexible cost • Any technology • Free up resources

But…

You can’t“buy”, “rent”, or “outsource”

Choice

Instead:

Increase your ability

to choose

Agility

In 2004, we had an agility problem.

Can you spot the dependency?

developers

releasetestbuild

delivery pipelineapp

Our solution:

1.Change the architecture

Service-oriented

Single-purpose

Connectedthrough APIs

Highly decoupled

“Microservices”

Our solution:

1.Change the architecture 2.Change the organization

Two-pizza teams

Full ownership

Full accountability

Aligned incentives

“DevOps”

Microservice development lifecycle

developers delivery pipelinesservices

releasetestbuild

releasetestbuild

releasetestbuild

releasetestbuild

releasetestbuild

releasetestbuild

Continuous Integration Small, frequent changes, constantly

integrating into production.

Thousands of teams

Thousands of teams × Microservice architecture

Thousands of teams × Microservice architecture

× Continuous delivery

Thousands of teams × Microservice architecture

× Continuous delivery× Multiple environments

= 50 million deployments a year

Thousands of teams × Microservice architecture

× Continuous delivery× Multiple environments

(5708 per hour, or every 0,63 second)

How do I get there?

1. Split up the monolith

1. Split up the monolith

1. Add an API

A m a z o n A P I G at e w a y

1. Split up the monolith

1. Add an API 2. Carve out services

A m a z o n A P I G at e w a y

1. Split up the monolith

1. Add an API 2. Carve out services 3. Repeat

A m a z o n A P I G at e w a y

2. Split up the organization• Small teams • Autonomous • Business + developers + ops in same team • Governance to align teams • Hierarchy for support • Introduce Lean, Agile, DevOps methods • Think: “group of startups”, not “large company”

Summary• “Lock-in” is a perception, the real problem is lack of choice. • Lack of choice has many dimensions: Standards, contracts,

organizations, time, cost, technology, resources. • Focusing on individual lock-ins can introduce other lock-ins. • A better solution is to maximize choice and minimize

dependencies by enabling technological and organizational agility.

• Microservices and the Cloud enable technological agility. • Lean, Agile and DevOps enable organizational agility.

Recommended Books

© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Constantin Gonzalez

Thank you!Use the opportunity to discuss openly with me during the break!

Principal Solutions Architect, Amazon Web Servicesglez@amazon.de, @zalez