09 2016-05-31 Dancing with Dependencies - Amazon Web Servicesaws-de-media.s3. 2016-05-31_Danciآ  Summary

  • View
    0

  • Download
    0

Embed Size (px)

Text of 09 2016-05-31 Dancing with Dependencies - Amazon Web Servicesaws-de-media.s3. 2016-05-31_Danciآ ...

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

    Constantin Gonzalez

    Principal Solutions Architect, Amazon Web Services
 glez@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 solution Lack 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

    Connected
 through 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 Services
 glez@amazon.de, @zalez