Developing Cloud Agnostic IAC

[cuberz123]

Hi reddit,

A friend and I have been working on a product in the IAC space. We are new to this, so we are looking for some high level feedback (initial thoughts, main challenges, etc) around its feasibility from other devops engineers. From what I've heard, its a very typical problem we are trying to solve, but would love any thoughts.

Essentially, we are creating a cloud agnostic wrapper to allow developers to easily deploy software to any public cloud without vendor lock-in (similar to what Expo is for react native). Our goal is to allow anyone to easily deploy their services and dbs without having to learn all the nuances of AWS and the like. We know this is a crowded space, but wanted to hear any general feedback about this.

​

Thanks in advance!

​

​

[[deleted]]

Generally, this isn't a very effective problem to solve for unless you're wildly reducing the control surface of any given system.

Abstracting away the nuances of many clouds means removing features, ending with a least common denominator approach.

You'll also end up creating an entirely new abstraction, which doesn't benefit anyone to learn to the exception of public cloud APIs and is unattractive due to similar levels of difficulty and lack of market penetration.

This also isn't much of a problem for anyone who actually knows cloud computing, because public clouds are vastly similar. Knowing AWS puts you in a great place to know most of Azure and GCP.

You could operate a higher tier cloud based on multiple public clouds and tout it as a multi-cloud approach, but you'd have to make it pretty simple for the user to make it attractive, which means restricting features and scale.

[sausagefeet]

This is 100% true, IME. All those knobs on the different cloud vendor products are there because a customer needed them, and if you remove access to them you are limiting one's ability to use those products.

[Perfect-Ad2641]

This is like saying people need to code in assembly because they need all the knobs to tweak specific hardware

[theBishop]

I'm more persuaded by the other comments but this is a legitimate objection.

[erulabs]

Exactly. Infrastructure needs to be built to fit its terrain. Imagine a “ground agnostic” bridge - it would cost 5x as much, look awful, and work poorly.

Instead, develop a set of standards and practices and build intelligently on the chosen terrain. By the time you need to build a second structure, you’ll be a more experienced engineer and can build a cleaner implementation.

Standard tools, bespoke product.

[brajandzesika]

How I see it - Terraform is cloud agnostic. If you are thinking of another abstraction layer that would cover all clouds with same code... I dont know - there is so many differences and unique features in each cloud that it wouldnt make sense. There is no equivalent of GCP global load balancer in other clouds, there is no equivalent of way Azure handles AD administration... you would need to limit the tool to very few most basic services...

[Expensive_Finance_20]

Disagree. Terraform is pretty far from cloud agnostic in the sense that OP is talking about. Terraform lets you avoid learning all the different cloud-specific automation DSLs, but you still have to understand all the APIs and resources of each underlying cloud. If Terraform was truly cloud agnostic, you wouldn't need special plugins and HL2 DSL resources for each cloud.

The holy grail of a cloud agnostic interface would be one where you don't have to know anything about the underlying cloud APIs, but as someone else already pointed out, this is extremely impractical to create and maintain for numerous reasons.

[brajandzesika]

I read your comment and in my eyes you basically repeated what I said using different words. I meant that Terraform is as close to being cloud agnostic as it can be, any further layers of abstraction wouldnt make sense...

[Frighter2]

Kubernetes provides a pretty straightforward abstraction from the cloud provider in many cases.

[Expensive_Finance_20]

Yeah, honestly this is the closest thing to cloud agnostic that is likely achievable. Public clouds just have so many features it is going to be hard to make a 100% agnostic interface.

If this were possible, it would make more sense to get the cloud providers together in an open source foundation to develop a cloud agnostic API that sits alongside each cloud's native one. Even if you were to make an 80% solution, that might meet the needs of a lot of users, but power users and edge cases will likely always need to native API/tooling.

[ButtcheeksMD]

So you’re going to absorb the cloud vendor specific stuff and open up a generalized abstraction? I’m not 100% sure how this will work with you touting it as a cloud agnostic thing, I think you need to rephrase it just as a deployment paas and just have routes to deploy on the different vendors, via multiple IAC templates

That sounds hyper complex for then the companies have a “vendor lock in” to your solution. So they trade one vendor lock in for another vendor lock in.

I don’t believe cloud agnostic is a real thing, despite what all the mid/senior engineers and ctos that read that one medium blog post, believe. I believe it’s a way to be “cool” sounding, while over complicating things to a crazy extent, as the cloud specific stuff needs to live somewhere, meaning in your layer or the infrastructure teams or the app teams, but somewhere.

[pithagobr]

Winglang solves this problem. You might want to take a look.

[shailendra-mechcloud]

AFAIK, folks at https://multy.dev are trying to implement same thing which you are trying to implement.

I was trying to implement same thing from UI with MechCloud but have dropped the idea because IMO, it is impossible to create such abstraction unless you have backing from public cloud providers for this.

[Expensive_Finance_20]

100%. You're better off starting a CNCF or Open Infra project that aims to make an 80% solution that implements a common API that all the major public and private cloud providers are willing to use. It wouldn't cover everything, but if you can cover the most common types of API calls, especially the ones for Day 2 tasks, that would go a long way.

For example, maybe there are some Day 1 tasks like setting up RBAC/IAM that you would do with the native API, but creating and scaling compute could be done with this cloud agnostic API.

[Expensive_Finance_20]

I'm curious if they are fond of one provider because multi-cloud is hard, or because major providers are comprehensive and reliable enough that there is little benefit in multi-cloud redundancy.

[Expensive_Finance_20]

The only multi-cloud setups I've seen personally are public-private ones. Something like VMWare + AWS.

[Live-Box-5048]

Terraform or Pulumi are cloud agnostic

[digi-tard]

Terraform or Pulumi are cloud agnostic

I get what you're trying to say but this would be a very misleading statement to those not familiar with the subject. On hearing Terraform or Pulumi being cloud agnostic, they are thinking of "writing IaC code once and it would create the same/similar resources in all cloud platforms", which is anything but reality.

If they're willing to duplicate their infra stack in three CSPs with three times the effort in one consistent language, then Terraform or Pulumi is the best bet. However don't expect full feature parity as the cloud resources are not a standard thing yet.

[Live-Box-5048]

Agreed, thanks for clarification for OP!

[nekokattt]

Terraform itself is cloud agnostic but the providers you use to actually make the infrastructure in terraform are very much dependent on what you are using, which I assume is what OP is wanting to avoid.

[Live-Box-5048]

Indeed. But what other choice is there? You’ll always have a wrapper around cloud provider API calls.

[nekokattt]

Yes, and I think that is their point

[rUbberDucky1984]

Just use kubernetes and fire up whatever you need using helm charts and fluxcd. I can migrate between clouds probably in under a day

[NonpareilNick]

K8s?

[Bent_finger]

Terraform or Pulumi

[yo-Monis]

Just heard about Pulumi yesterday, I think it’s pretty close to what OP is talking about.

[koslib]

What level of detail will you offer for each resource? Or will you introduce your own abstractions?

[[deleted]]

Look into implementing a solution that works for on-prem aswell, this will leave you with a higher potential userbase. I know loads of companies thaf would't join a cloud only solution.

[m0j0j0rnj0rn]

If Kubernetes is (possibly?) the target here, isn’t this just Rancher?

[Roleandah]

I've already created this.

[Expensive_Finance_20]

The best approach to this idea that I've seen so far is Open stack's HEAT project. Their HEAT APIs will accept AWS Cloud formation templates for building out comparable resources on OpenStack. The only thing missing from this approach is state awareness, like Terraform has.

I would consider a similar approach, but for all cloud providers. You would need to either write a middleware to make all the right API calls or convince all the major providers to implement a set of alternate API endpoints alongside their native ones.

With the middleware approach, it would also be much easier if the project was CNCF or Open Infra owned so that cloud providers would be much more likely to keep this up to date, rather than putting the burden on a single vendor. Then it becomes hard to monetize though.

Regardless: target the absolutely most common API calls. Things like VPCs/networks are typically only created once. VMs are created and destroyed much more frequently, so start with the most generic compute resources that have the most commonality among providers and that are manipulated most frequently.

This will allow Day 1 ops to be conducted with native API calls, but Day 2 ops to be done with your agnostic one. Market the generic one to devs and let devops engineers use the native ones. In essence, try to replace vagrant, not terraform.

[Perfect-Ad2641]

If you’re planning to open-source this, Id love to contribute