Hacker News Reader

Hacker News

Comment by pling | Hacker News Reader

Full thread

pling

This could also be titled "how to enslave your MVP to increasing costs in the future".

Azure isn't cheap by any means when you need to scale up our out.

View on HN

pling sure, but if you avoid using azure specific technologies it's quite easy to move somewhere else.

Simply decouple yourself from Azure specific tech and you're good to go, no?

It is very hard to decouple yourself from the tooling and the platform specific features. The PaaS offering literally requires half of the additional services ad the basic deployment is simple and the IaaS offering is expensive and you need the latter to decouple effectively.

Either way you also hang yourself with a vendor tied product and the ball and chain of licensing. The latter of which escalates pretty quick when your business grows.

Our 8 man startup in 2005 now spends £200k a year on licensing because we're that tied to the damn platform.

pling, any chance to post/share how you are using the azure platform and what makes the migration hard? that would be really useful.

We're not using it other than for internal failovers. We tried to build version two of our product on it. The costs increased rapidly until it was cheaper to buy a 42U and stuff it with HP kit and pay for a fat pipe. The storage was expensive, the per transaction costs are expensive, the bandwidth is expensive, the IaaS machines are expensive and the support is expensive when it goes wrong which it does occasionally and violently.

This was all financial data aggregation and archival stuff.

In test it was 23% more expensive than our own kit over 3 years.

that's some nice info, thanks for sharing pling. It makes me curious to try and compare costs with other IaaS platforms.

I would do. There's a sweet spot somewhere and Azure isn't it.

Don't forget to also compare the costs to doing in-house hosting. The cost effectiveness of any platform is dependent on how you use it, and (as pling discovered) a cloud host isn't necessarily the best option.

I agree with that, although I believe that it heavily depends on where on your product roadmap you are. For early stage MVPs where you care for quick validation, I believe that in-house hosting is not a very good option, maybe a PaaS environment is more suitable for these cases, e.g. Heroku. But in any case, I think that everything is related to the product, the team and what you are trying to achieve. Of course in every iteration you should re-evaluate your strategies.

I agree completely. It's important to weigh all the options, and include issues like vender lock-in, SLA and future requirements.

Can you break down that 200k in cost? That seems pretty high unless you are a fairly popular.

In order of cost: SQL Server, MSDN, Windows Server, Office.

We got utterly raped by the SQL 2012 upgrade with the core licensing changes as we have a few 48 core machines. (enough to make us consider PostgreSQL as a serious option now)

We're not public facing either.

That makes sense -- although now I'm more interested in what a non-public facing 8 person startup with a few 48 core machines that can afford 200k in licenses is doing!!!

We're a chunk of glue that aggregates and monitors financial data. Not related to trading and not real time.

We're basically the people who say 'it was him' when someone fucks up.

Please don't use the R word, which is so deeply emotive and meaningful, in such an inappropriate context.

I think it was appropriate. We were violated forcibly without consent or warning.

yes, this is always a possible approach and personnaly preferable. But you should also look for "hidden" costs and mainly your effort/time to setup and manage things. At the end part of the value of using a cloud service is convenience. Again, everything depends on the context of your application.

We have two people who handle all our infrastructure. We still needed two people available to handle all our Azure infrastructure even though they'd spend less time doing things (N+1 failover).

Also Microsoft doesn't give a shit if you're down past a status page and profuse apologising and perhaps a pro-rata refund if you complain like a bitch and wave a big "fuck you, AWS next time" at your licensing contact. That's not how to do business.

Our guys actually get up at 2AM and drive to the DC and fix shit if it goes wrong, which it inevitably does (less often than Azure I will say).

Downtime costs you more in reputation than you can gain from the cost savings of not having your whole world under your control.

You should read up on the SLA. If you need more assurance than Azure can offer (or any cloud host, since statistically Azure has one of the best uptimes), you shouldn't have tried it in the first place.

I don't know who sold you Azure as a solution to your hosting, but whoever did it didn't take enough time to investigate your case. This comment and your others show that your requirements and architecture aren't a good match for a cloud host.

Well we were stuck in this...

http://blogs.gartner.com/kyle-hilgendorf/2012/03/09/azure-ou...

The SLA would have been fine if it was accurate, which it wasn't.

As were we, and MS has learned a lot since then. The SLA has improved and become more strict, and they've improved communications since then. There is still a ways to go, but that's true of all hosts.

It's important to note though that an SLA for any host isn't a strict guarantee. Almost all are set up on the best-effort-with-refunds-if-we-fail principle. They're promises, not hard lines. MS does not have a habit of failing to deliver on their promised number, but like any other host it can happen. These are important things to remember when considering a hosting model.

As is AWS but I suspect is easier to migrate from AWS

I would agree there. There are plenty of API compatible alternatives to AWS services.

Reply on news.ycombinator.com