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.
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.
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.
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.
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
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.
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.
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.
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.
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
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.
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!