[scarface74]

You won't get 4 folders with 26 files handling simple tasks like uploading images to an S3 bucket (saw this huge mess just last week and guess what?! It's broken. I know, surprising right?)

You can see right here on HN anytime a post comes up about using a cloud provider someone advocating putting a layer of abstraction over the provider’s SDK to prevent “lock-in”. As if the CTO is going to one day move their entire infrastructure because a developer promises them they’ve abstracted their code perfectly.

So instead of just being able to read the docs of the SDK, you have a custom QueueManagerFactory that gives you an AWSQueueManager that wraps the Boto3 AWS SDK just so one day if the company decides to move to GCP, someone can write a GCPQueueManager.

See also, developers who think they can effortlessly move from their company’s six figure Oracle installation to Postgres because they used the repository pattern.

[kristopolous]

Suggesting to just manually go in and change the touchpoints over if the time comes is seen as uncouth, as if we're in an Oscar Wilde play and I'm some unwashed ruffian from the alley.

This is despite the fact that if you do it it'll take 40 minutes manually versus 10 minutes if the Rube Goldberg abstraction machine works as planned (it won't).

Since there's only about a 5% chance (max) that going from say S3 to Azure will ever happen, the extra cathedral of abstraction saves an actuarial 1.5min of dev time.

All that only for 2-4 days of development to make it and the added runtime at every request for the convenience. Genius!

[hderms]

I think it depends on whether the library you're using is well designed and doesn't require contorting code around it. If it's a simple integration I don't see much of a point in abstracting it but if dealing with the library is painful on some level you'd maybe get some benefit from doing so. That being said this is somewhat orthogonal to the issue you're describing

[scarface74]

I do have a *Utils module to wrap some calls to the AWS SDK but it’s not to protect from “lock-in” it’s a classic DRY principal of putting a code snippet in a function so I don’t have to remember how to do it every time.

[admax88q]

A poor abstraction is always a poor abstraction, but a good abstraction can not only isolate your components from change but also provide a better interface.

I'm not going to write raw HTTP requests to S3 in every place in my code that I need to read/write objects from there. What I'd rather have is a simple abstraction with methods like get(id) -> obj and put(obj) -> id.

[scarface74]

Seeing that you can still use the same SQS API from 2006 and that in 2018 AWS still supports SOAP of all things for S3 (https://docs.aws.amazon.com/AmazonS3/latest/API/APISoap.html) , I would much rather be able to just look at the SDK to see how something is used than having to try to debug through an abstraction that the “architect” who was at the company years ago, put in a custom Nuget package trying to abstract the API and imposed s “standard”.

Yeah I have been through that before where the architect of the company wrote his own bespoke ORM, logging framework, etc. and he was the only one who knew how it worked.