Hacker News Reader

Comment by oriesdan | Hacker News Reader

I think the main reason they can afford pricing their services that high is because of peer pressure - probably itself the result of clever marketing, or that would be a really happy coincidence.

I've worked in many startups now, several of them where I was the first (and for a while, only) developer and had to decide on the infrastructure. Each time I was going with OVH, and each time the CEO was trying to push for moving to AWS instead, despite having no clue what the difference may be.

Their problem was that "startups are supposed to use AWS". They were having impostor syndrome. One would come to tell me every month or so how "all his friends use AWS, and they say it's very good". An other one was afraid what possible investors may say when he tells them we're not on AWS.

If people will pay overpriced services to be with the cool kids, why bother competing on price?

View on HN

Being on AWS, Azure or GPC isn't about the costs being pressured from another department at all.

The cost reflects the premium for integration into the other services.

It is after first employees bounce or the company outgrows that hustle hack everything together mentally that consultants like myself get hired and want to sob that some employee decided to board to OVH as a small startup especially if it is growing.

Every time I've dealt with this it is a disaster or things hanging together by a thread. Hanging together by a thread have sort of gotten better with kubernetes mostly keeping everything running just by turning anything back on when it dies or crashes. The thing is that only until last year did OVH offer managed k8s, those poor startups that will suffer from these choices.

OVH has it's place to be considered:

+40 engineering companies

High out going bandwidth (CDN, video streaming, etc.)

IO Latency requirements

Large enough scale of anything where the cost of AWS egress bandwidth is too costly

Your lack of punctuation and odd syntax makes me wonder, but if I understood your post correctly, you claim that building with AWS is somehow safer / more robust / more future proof than building with OVH? A technical judgement?

If so, I vehemently disagree. I've been a consultant for 10+ years too and seen 50+ companies from the inside, from startups to behemoths – including AWS itself.

Companies running a tight ship around resources were generally technically superior to those using AWS. "Hanging together by a thread" indeed, playing the AWS bingo of "use a flaky soup of 3-letter-acronym-services to cover technical inaptitude".

AFAIR the AWS versions of Spark and Elasticsearch were abysmal to the point of being unworkable. At least two years ago, maybe it's better now.

I've worked as a contractor for a CEO for two companies, in both he pushed for a full migration to AWS. Would not be surprised if he got a kickback from AWS.

Amazon is pushing AWS pretty hard in the C-level, I don't know if you've ever followed one of their certifications or landing pages, but they do their marketing really well.

Anyway, I do think a platform like App Engine / Beanstalk and other quick / easy / no setup deployment tools have a benefit, if you're not good at setting up servers.

AWS allows you to shift your costs from CapEx to OpEx. Companies with low CapEx are valued higher since "theoretically" you could remove that bill by moving to another provider. Financial Engineering is just another part of software engineering and the cloud enables it.

This is not a real saving in my experience. The DevOps time for an app is so trivial. I actually just setup a .Net core app on Linux/mysql.

My Linux experience is old and very limited. I have used AWS for years for other things (S3, cloudfront, transcribe, etc.).

Initially I setup an elastic beanstalk app/separate mysql instance on my own AWS account just so I could quickly deploy (all new to me).

Then I setup the app on my client's VM, had to configure Apache, .net core app, service, mysql, mailing.

I would say the elastic beanstalk stuff took about 3 hours (some problems with IAM and Amazon's visual studio plugin, basically ended up having to use my master key). Setting up the VM server, plus a new way to deploying .net core apps and learning/relearning much of linux took 4-5?

So no significant savings there.

Deploys are a few clicks from VS on EB, and take a little longer to the VM, but only because I haven't bothered writing a script that I estimate would take me 1/2 hour at most, in reality probably 5 minutes.

I have clients on (windows) servers that have been running for 10 years with little intervention from me (had to clear some space a couple of times as that client's app saves large files just in case, but they are all backed up on S3 as well).

TL;DR; in my experience DevOps part of running a startup/small enterprise app is basically trivial, a rounding error, compared to time spent on development.

To be fully honest, for personal work, I use Caprover for DevOps.

Edit: The move from CapEx to OpEx is not about savings, it's often about shifting the costs in your books.

I guess I phrased that wrong. Explicitly, DevOps costs are tiny in a startup, even if you do it all yourself with a bare metal server, and moving 0.5% from pot A to pot B makes no difference.

It all depends on the services you provide.

Some businesses would require huge up-front investments without the likes of AWS. DevOps costs might overwhelm you pretty quickly once stuff like compliance becomes a factor, for example.

Sometimes it's not about the technical issues, but documentation, process and qualifications. In B2B there's plenty of that and just the bus factor [1] alone might force a start-up into considering a cloud provider.

In the end it's not just shifting cost, it's also shifting risk and standards and that may or may not be a critical factor.

[1] https://en.wikipedia.org/wiki/Bus_factor

Except that nearly all companies greater than a certain size have an engagement with AWS so they shifted CapEx to CapEx.

> shifted CapEx to CapEx

or in other words, shifted nothing?

Yes, I think the CapEx argument often advanced by the marketing of AWS and C-levels and engineers of large companies moving to the Cloud is just something said to justify the decision and help everybody get on board with it, but I think the CapEx -> OpEx one is fallacious.

There is others reasons for example the flexibility, the managed services, etc. but I don't think this one makes sense.

In my mind, one of the big (but seldomly discussed) pros for using AWS and especially their high-level services (especially WRT containers) is that they allow rank-and-file developers to do a lot more of the work that was traditionally considered 'ops'. This is advantageous because developer teams don't need to coordinate with a single ops team when they need something, which allows the whole organization to be more agile. Another advantage is that you don't have to hire and develop a high functioning ops competency in your business--you can outsource much of that to AWS and focus your time/resources on more valuable opportunities (in general, I wish the on-prem side of the debate would acknowledge opportunity costs in their talking points).

Startups don't win because they save 50% on hosting costs. They win because they move fast on product development. AWS make the latter much easier due to all of the additional tooling they provide.

If the constituent employees are trying to win in the classical sense, and not the pump-my-resume-and-bail sense.

CEO changes his opinion when money runs out and a new CFO comes in to fix the costs - at least from my experience.

If you need a CFO to look at your IT bill and cut costs, your problem is likely BS title inflation crowding out real work.

Reply on news.ycombinator.com