Availability sets on Windows Azure for an MVP | Hacker News Reader

Availability sets on Windows Azure for an MVP

cpardalis.wordpress.com

36 pointscpard44 comments

I'm wondering.. You said, build MVP on a budget... But your licensing costs are insanely high (200k pounds)...

Isn't that contradictive? (or was that the licensing costs before the current situation?)

That's not our cost, the 200k pounds are the cost pling mentioned for their case, 200k and MVP are indeed contradictory terms. We are actually participating on bizpark so we have some credits to use on the platform for free. Of course we try to keep our costs as low as possible.

What I'm saying is that your product is a fit for the platform when it is an MVP. When you grow, you're locked into an expensive platform. In the short term there is no option of escape because the cost to port it becomes increasingly more expensive.

Then before you know it, you're at that 200k.

I've seen it happen at so many companies:

"We'll build it on the MS stack because they gave us a great deal on MSDN or we used the PAP to get cheap licenses." ... after a few years ... "We got screwed by SQL 2012 and had to buy £50k of SQL licenses because the terminology between cores and CPUs changed on a whim and it's the ass-end of the SQL 2005 so we've got to make a big jump."

I'm not saying it's an invalid approach (hell I make my living out of keeping these sorts of cogs spinning) but it's not a great foundation to run a startup on. Unpredictable costs or sudden price-jacking after a partial buyout really sours the shit out of the deal. Especially when you ask for a budget you can't get from your new investors who now are worried that their short term return is going out of the window on your platform and software license costs.

that's why we try to use the Azure IaaS and avoid microsoft specific technologies. In any case as we grow we'll have to also move to other enviroments because of the nature of our product so we need to be flexible on that. But I totally agree with you that you need to be carefull on how much locked you get on a specific environment that you dont have total control over it.

Keep in mind that although availability sets can help reduce the chances that two VMs will go down at once, you do have to deal with the maintenance cycles that Azure has where they will reboot every one of your VMs over the course of x hours.

This means that with a master/slave setup, a simple failover from a master to a slave is not sufficient, you need to be able to fail back automatically as well. Depending on the exact technologies you are using and how you are using them, this can have a lot of tricky corner cases that can end up much worse.

If you don't do this, then when your master comes back up and they decide to reboot your slave next, which is a common scenario, you lose availability. This differs significantly from a scenario where VM failures/reboots aren't correlated so closely in time; if a VM failure is more random, it is more reasonable to require manual intervention to fail back to the master.

Seconded. You're lucky to get clean ACPI shutdowns, half the time Azure "pulls the plug".

The closest thing to an official explanation I've found (note date and chorus of comments): http://blogs.msdn.com/b/wats/archive/2013/09/24/windows-azur...

true, that's why we went for a master-master setup with the db.

Would a Quorum ( http://en.wikipedia.org/wiki/Quorum_(distributed_computing) ) method - like done with Ceph's monitoring system agents - be able to handle this?

I mean, you still may end up with the split-brain problem in the long run, but if that happens within a data-center would be the least of your worries. (Something like netflix's chaos army comes to mind for dealing with that).

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.

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.

Good article and particularly useful on the Galera replication - if you google replication, the tutorials that come up first are native mysql Master-Master replication which are difficult to setup and very likely to fail.

I've been on azure for almost a year now and it is essential that you use their availability sets as their emails about "planned maintenance" often come sporadically after they do the maintenance. In one upgrade they somehow managed to shutdown and not restart my instances, so i also recommend having an externally hosted monitoring server if you have mission-critical stuff on azure.

thank you! The whole point of the article was to offer a mashup of easy to follow steps to achieve replication over azure availability sets. I'm glad that you find it useful.

I'm kinda curious why you picked MariaDB instead of SQL Server ? What are the benefits?

because of cost. MariaDB helps us to reduce cost, keep in mind that our storage needs are minimal. In any case if you can afford SQL server, you should go for it.

Any downsides of using MySQL instead of SQL Server in the development stage?

I'd say that the main downside is the time/effort to setup and maintain, especially as you scale up. At the end you should always judge based on your app and its requirements.

SQL Azure starts at $5 a month. Hosting a couple linux VMs for MariaDB would be a lot more expensive. SQL Azure is extremely affordable even as you scale up and it is fully managed. For basic SQL usage it is awesome and the value is unbeatable.

if you are in the situation to need dedicaded VMs for MariaDB then you should probably go for SQL Azure. Here this is not the case, the requirements for the DB are minimal and we already have 2 VMs running for the availability set. As I said, at the end you need to judge based on the specific needs of your app/product.

Actually they are retiring the "Web and Business" pricing plans, which were charging for storage size and introducing a new pricing plan that charges for both storage size and "Database Throughput Units", which kind of obscures what they are charging for - something related to transactions volume and based on my experience with other "cloud hosted" databases, I can guarantee you that it gets pretty freaking expensive.

The smartest thing to do is to never rely on a particular service of a cloud provider. For example we once made the choice of using Amazon's DynamoDB, which is great in the beginning, but at some points along with scale issues the costs went through the roof (DynamoDB also charges for "throughput capacity") and we just switched to Cassandra - but we planned for this migration ever since the beginning.

And this is the problem with cloud providers - the pricing schemes on these services are designed to hook you with affordable prices in the beginning, but later on as your business grows they get much more expensive than hosting your own stuff. So use whatever makes you most productive, but careful about lock-in.

Unless I misunderstood, the new DTU measure is being used to gauge relative performance between the different tiers, not for usage (or billing that usage).

But in this case SQL Azure is not something you can get locked in on. You can switch to normal SQL Server at anytime away from Azure.

Have you looked into Google's managed mysql or nosql options? I'd be curious to see how they compare to what you are doing on azure.

Reply on news.ycombinator.com