undefined | Better HN

0 pointsarbie7y ago0 comments

Have you considered a cloud abstraction that let's you change providers with less effort?

0 comments

6 comments · 3 top-level

This is like those database abstractions that get made under the premise that someday at some point you'll switch DB's. But yet, 10 years later you are still chugging along on the same database you started with. You would have been far better off to just completely "move in" with the DB you decided to use in the first place and leverage all it has to offer.

The problem with these kinds of abstractions is in order to avoid "vendor lock in" they are forced into a "lowest common denominator" deal where you don't get to leverage any vendor-specific awesomeness. For example, in DB land you would avoid certain kinds of database fields (Postgres's structured datatypes like JSON, for example). Instead of leveraging the DB to do certain kinds of JSON queries you now have to write the infrastructure your self "just in case we switch DB's".

The irony is, in my experience to avoid the dreaded vendor lock in "problem", teams and organizations wind up locking themselves into their own homebrew nightmare that does nothing but recreate (often poorly) what they could have gotten by allowing themselves to get locked in to a third party. It goes without saying that in almost all cases, this homebrew nightmare has zero to do with the actual value generating functions of the business. Storing and querying on structured JSON in a database has nothing to do with the core values of 99.999% of all organizations--these things should be locked into third parties.

My point is, most teams should embrace all their cloud providers can offer. Settling for the lowest common denominator shared between cloud providers leaves money on the table and runs a very high risk of what is, in my experience, a worse form of vendor lock in--getting locked into your own stinking pile of rubble.

I could go on and on about the "vendor lock in" boogyman--it is one of the biggest, most annoying anti-patterns I see. It creates huge political and technical hurdles as the business grows. I believe it stems from a poor understanding of actual business risks, not understanding the true lifetime costs of inhouse engineering projects, resume-driven design, and a very healthy dose of premature optimization. (also toss in some Stallmanesque mistrust of proprietary systems for good measure)

tracker17y ago

+1 to the above... There's HUGE costs in trying to create abstraction... Generally layers of crap code that is all repetitive and adds no value, making it so much more costly to maintain even. You're often better off writing a second version and transition scripts than trying to maintain an abstracted code base or application platform.

Though a lot of the docker tooling, k8s and other options do make it quite a bit easier as an option of you want to self-host. But that has other issues, advantages and disadvantages.

mnutt7y ago

I will say that the majority of Rails apps can just use the Rails abstractions and they sit reasonably well on top of whatever database you choose to use. Rails 5 maps just fine to most common database types and patterns.

On the other hand, in the past I’ve used Fog to abstract our cloud provider and that was nothing but pain. SQL is well-specced with some vendor-specific extensions, while there really isn’t any actual common denominator for cloud services.

whorleater7y ago· 1 in thread

Have you been using the same cloud abstraction tools I have? Terraform and Kubernetes all require more effort in dealing with cloud providers, not less.

gaius7y ago

Yes the myth of Terraform is that it abstracts sufficiently to be cross platform. You can use it on multiple platforms but that’s all.

ryrobes7y ago

ORMs all the way down? Please no.

j / k navigate · click thread line to collapse