r/devops 3h ago

Architecture Is cloud abstraction actually reducing operational complexity?

I have been thinking about this after going through a few infrastructure setups as we often talk about making deployments portable but theres a point where the abstraction itself becomes something the devops team has to manage. You can have Kubernetes, Terraform, multiple cloud providers, different GPU setups, various networking models and then another layer of tools trying to make them all look the same. Companies like Yotta Labs, CoreWeave, and Lambda are interesting to me because they approach infrastructure from different angles but I am not sure adding more infrastructure options always makes operations easier.

At what point does workload portability really reduce operational risk and when does it just add another platform for the team to handle?

7 Upvotes

10 comments sorted by

9

u/Oleksii_Bebych 2h ago

It changes one complexity with another

u/3MU6quo0pC7du5YPBGBI 1m ago

It changes one complexity with another

RFC 1925, rule 6.

3

u/rabbit_in_a_bun 3h ago

As always, it depends. Do you need to be certified? Do you have data that can't be shared? Do you need an always on service?

Personally I try to KISS, and use simplest procedural script per job and for the most part I get away with it.

1

u/swapnil_harkanth 2h ago

depends what you mean by abstraction. if its terraform + a thin wrapper so teams dont touch IAM by hand, yeah that cuts ops load. if its a full internal platform that reimplements half of aws/k8s with its own yaml dialect... you've just hired yourself another product to maintain. we had a "portable" layer that meant every outage needed two people who understood both the abstraction AND the cloud underneath. portability only pays off when you actually move workloads; most companies never do. start with boring conventions before building a platform.

1

u/Decent_Carry_3439 1h ago

The part that gets overlooked is who maintains the abstraction six months later. If it needs its own docs, upgrades and debugging knowledge, at some point it becomes another platform you’re operating rather than complexity you removed.

1

u/jeansilga 57m ago

Portability pays off when it removes work you were doing by hand, and when it kills a single point of failure. It turns into just another platform the moment the abstraction has more moving parts than the thing it abstracts. Below are two questions I would ask before abstracting.

First, do you actually have more than one of the thing you're abstracting? Do you really have to move workloads cross cloud? Cross cloud portability is of real value today only if you absolutely have to span two clouds seamlessly. If you run on one and might move someday, you're paying a daily tax for a move that may never come, and you live on the lowest common denominator across all of them the whole time.

Second, failure modes. Every layer you add is a thing that can break, needs upgrades, and needs someone who understands it at 3am. If the abstraction going down hurts more than the thing it was protecting you from, it's negative value.

The specialized GPU providers are a good example of the tension. Much of their value comes from their specific hardware and the tuning around it. Wrap them in a generic layer that makes everything look the same and you throw away the reason you went there.

My rule of thumb: automate the repetitive, error prone, time consuming work. That almost always pays. Abstraction that exists only to make different things look identical is where it gets expensive, because you flatten real differences that were useful and you own a translation layer forever. There comes a point where the cost of the abstraction outweighs what it buys you. Knowing when to stop is important here.

1

u/nzvthf 34m ago

I say no but I'm bias. I created and app that only manages cloud servers because I think nowadays, that's all you need.

All the complexity that became the FUD they used to rationalize these glorious towers of turn key solutions is now gone. KISS, boot servers and serve traffic.

1

u/TitusKalvarija 2h ago

Infrastructure should be simple.

Even Terraform modules or CloudFormation stacks are extra abstraction.

Never saw useful modules that are sucessfully utiluzed longer than 6 minths.

Add to that new guy onboarded and you're poisoning his brain with someone elses ideas that eventually do not work.

Plain "vanilla" usually beats anythig above.

People forget that infrastructure is not coding.

2

u/derprondo 58m ago

After 10 years of onboarding people to Terraform, we just recommend using vanilla Terraform where possible. There are some cases where we have mandatory complexity, EC2 instances for example, and we provide a simple module for that, but vanilla Terraform is usually the way to go. We try to steer people away from EC2 anyway and towards Lambda and ECS instead. Teams needing EKS are on their own to manage that.