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

11a1dfabcaa545e169a4728dd14d9375?s=128

Stian Øvrevåge

January 29, 2020
Tweet

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
  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.
  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.
  4. None
  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.
  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.
  7. Downsides / risks / objections / fears Going from development

    to production: Compliance Price Feature freeze Scaling
  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
  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.
  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.
  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.
  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.
  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
  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.
  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!
  16. “ It’s the interface. Not the software. & Beware the

    lure of proprietary vendor add-ons
  17. We specialize in design and development using the modernest of

    technology & we are hiring ;-) www.k30.no/careers Mandatory company plug
  18. Thank you! github.com/StianOvrevage stian.tech