Hacker News Reader

Comment by the_new_guy_29 | Hacker News Reader

He also comlpletely negates the need of rewriting all of those "scripts" in case of a change in host provider.. None of modern companies is using own hosted servers because its simply too costly. Everyone is using cloud providers - now try to switch from one cloud provider to the other - all of those "scripts" would have to be rewritten top to bottom.

I cant take this article seriously, its just some person refusing to adapt because "in my days we did it differently"

View on HN

Hello, there are a great many companies that rent mare metal servers, own their own gear in a colo, or even have DIA to their own infrastructure site.

I think you paint the whole world with the bleeding edge brush. Many fortune 500 companies are a decade behind the technology stacks described in the article and in this discussion.

Arguably containerization is one of the great hopes for Enterprise devs in the Fortune 500 space and beyond: micro investments and isolated tech stacks. It reduces a lot of the risk of innovation, while also giving a clear preservation strategy for legacy apps.

Hybrid cloud installations to leverage cloud computing resources are becoming more and more "the norm". In that context having apps and services pre-packaged for deployment in heterogenous environments is strategic power.

"The cloud" tends not to be cheap, but using cloud services to carry out jobs your dedicated site never could hope touch is something with business value.

If you’re using a cloud provider, using docker isn’t going to magically save you when switching providers cos chances are you’re using services of the cloud provider. Your code has to be rewritten.

And in regards to scripts or docker. No you wouldn’t need to rewrite everything.

Thats why you wrap them in api or rather your architect should. You can and abolutely should abstract yourself from cloud provider. Difference with Docker is that in case of such a move (already did that in my career) the amount of boilerplate you have to review and adjust is magnitudes lower than what he (OP) proposed in his article.

So you write an abstraction around the provider, and when you switch provider, you still need to implement a new implementation of that abstraction for the new provider. So in this regard, docker gave absolutely 0 benefit.

In regards to setting up a new server for a new provider, or docker, you have some boiler plate:

-> create script to attach docker to provider

New provider...

-> create new script to attach docker to provider

----

-> create script to provision server on provider

-> run generic script to configure it how I want

New provider

-> create new script to provision server on provider

-> run generic script to configure it how I want

In this regard, moving from 1 provider to another, is identical.

And this is exactly how you end up with an overbuilt system which is difficult to comprehend because some "architect" decided you need to be able to change cloud providers on a whim. You pay for that decision every day and 99.9% of you are _never_ going to switch providers.

Web development is full of engineering astronauts who think they need 8 levels of abstraction to solve relatively simple problems. Oh, and for that 0.1% that does actually switch, they soon realize they're abstractions weren't as good as they thought they were and they have to reimplement every interface anyway.

Let me ask you a question:

How do I abstract this unique idea of IOPS that AWS has?

You try, fail, and end up with a leaky, useless abstraction.

No one is using dedicated servers or colocation?

So how do Hetzner, OVH, Rackspace, and hundreds of other companies stay in business?

Hint: cloud services are in fact way more expensive on every single metric. But they are more flexible.

There's no cloud. It is just someone else's computer.

This was funny a few years ago. Parroting it any time someone mentions the cloud is just meme crap. This isn't reddit.

Reply on news.ycombinator.com