Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Avoiding lock-in without avoiding managed services

Avoiding lock-in without avoiding managed services

How to think clearer about managed services and avoid lock-in

Stian Øvrevåge

January 29, 2020
Tweet

More Decks by Stian Øvrevåge

Other Decks in Programming

Transcript

  1. Avoiding lock-in without
    avoiding managed services
    Correcting the myth:
    Stian Øvrevåge
    Cloud evangelist @ K30
    29. January 2019
    Stavanger Software Developers Meetup

    View Slide

  2. > whoami
    Cloud evangelist at K30, currently working on two Kubernetes platform
    teams in Equinor.
    I used to be in operations, setting up and managing “internet and
    infrastructure plumbing” but have moved towards DevOps, SRE and
    development.

    View Slide

  3. and why am I giving this talk *?
    I meet quite a few teams who resist when I advice them to use managed
    services for their “undifferentiated heavy lifting”.
    That is, they don’t want to use a cloud provided managed service when
    they for example need hosting, a database or some storage.
    Some are creatures of habit, some lack the experience and mindset and
    some have legitimate objections.

    View Slide

  4. View Slide

  5. Managed service
    Managed service lets you build faster by outsourcing operating and
    learning a “commodity” subsystem (database, storage, queue, hosting
    platform).
    You create the service via command-line, API or a web interface.
    You get some connection information and start using it.

    View Slide

  6. Benefits of managed services
    You don’t need to monitor it closely.
    You don’t need operations experience.
    You don’t need to spend time updating and troubleshooting.
    You don’t need to spend time setting up
    highly-available and fault-tolerant setup.

    View Slide

  7. Downsides / risks / objections / fears
    Going from development to production:
    Compliance
    Price
    Feature freeze
    Scaling

    View Slide

  8. Can we get the best of both worlds?
    The critical decision is not which vendor to use, or even which software to
    use, but the interface between the systems.
    If you build on an open standardized interface you have the freedom to *:
    ● Switch vendors for price, compliance or any other reason
    ● Run a mix of environments with different trade offs
    ● Adapt deployment strategy to project phase

    View Slide

  9. Hypothetical project phases - 1
    Let’s imagine you start working on a new project doing Lean & Agile and
    you quickly want to get going. It’s a simple web-app that needs to store
    some data.
    Phase 1 - You develop it locally. You spin up a PostgreSQL container on
    your machine in 2 minutes and start using it.

    View Slide

  10. Hypothetical project phases - 2
    Phase 2 - Pilot users. They accept downtime so you spin up the same
    PostgreSQL container in the cloud (Azure App Service, AWS Fargate, AWS
    ElasticBeanstalk, an existing Kubernetes cluster with available resources).
    Phase 3 - Production. Now we need stability, durability and security. Create
    a managed PostgreSQL on AWS/GCP/Azure.
    Phase 4 - (Web)Scale. Cloud costs have run amok. But you have resources
    and competence to operate PostgreSQL yourself in the cloud or
    on-premise. You switch back to managing the database yourself.

    View Slide

  11. * open standardized interface
    Caveat: An open standardized interface is an indication, but not a
    guarantee, that you have freedom and flexibility. Example:
    2014: Kubernetes (K8s) released as open source. But it’s so complicated to
    set up and operate that you should really think long and hard before
    considering doing that! (K8s failure stories: www.k8s.af)
    Google Cloud was the only provider of managed K8s = open and
    standardized but still locked in.

    View Slide

  12. * open standardized interface
    2017-2020: AWS, Azure, DigitalOcean, Oracle, IBM, RedHat and 50 other
    providers offer managed Kubernetes at competitive prices. Dozens of
    providers of tools to set up and manage on-premise and hybrid
    installations.
    Kubernetes interface introduced on top of software not actually running
    Kubernetes: Docker Desktop. Azure App Service. AWS Fargate.

    View Slide

  13. * open standardized interface
    MongoDB & ElasticSearch - Open source with standard interfaces
    Very easy to set up for development, but they are a pain to set up and
    operate reliably at scale.
    In the past there were few providers of managed services resulting in a
    3-5-10x cost premium.
    Now: Azure’s proprietary Cosmos DB has API compatibility for MongoDB
    AWS Document DB has API compatibility for MongoDB

    View Slide

  14. Lesson: Inhibitors and drivers of commodification
    The higher complexity to run yourself, the higher the cost premium of
    buying as a managed service.
    ...unless it is something extremely popular making the big dogs compete
    the prices down.

    View Slide

  15. Warning
    The cloud providers still try to lure you in by having addons, plugins,
    proprietary services that work well with the open standardized software.
    They are usually just a click away!
    But do step back and analyze if the benefits are worth it. Because you
    might just have locked yourself in again. Woops!

    View Slide


  16. It’s the interface. Not the
    software.
    &
    Beware the lure of proprietary
    vendor add-ons

    View Slide

  17. We specialize in design and
    development using the
    modernest of technology
    & we are hiring ;-)
    www.k30.no/careers
    Mandatory
    company plug

    View Slide

  18. Thank you!
    github.com/StianOvrevage
    stian.tech

    View Slide