Microsoft Azure vs. Amazon Web Services, For Programmers 64
Nerval's Lobster writes "Tech writer and programmer Jeff Cogswell does a head-to-head comparison of Microsoft Azure and Amazon Web Services from a pure programming perspective, examining the respective sides' vendor lock-in and vendor-specific APIs (among other issues). 'If you're not using any vendor-specific APIs, then it's safe to say the experience you get on either Amazon or Microsoft will be roughly the same,' he writes. 'But that means you're also not developing an app that necessarily takes advantage of all possible cloud capabilities—not just add-ons, but scalability. Your app might need to expand and grow as your user base grows.' He suggests it's ultimately a tie between the two companies. 'From a strict programming perspective, both companies have their own RESTful API, and their own libraries for using the API.'"
The problem with both of these services, though, that RMS could have told you about: "The moment you start using either, you're locked in for the most part."
This is a solved problem? (Score:5, Informative)
Please google "Cloud Abstraction Layer".
Here; I'll help you out:
https://www.google.com/search?q=cloud+abstraction+layer [google.com]
Re:This is a solved problem? (Score:5, Informative)
Now I know we don't actually READ the articles around here, but did you even skim the summary?
"If you're not using any vendor-specific APIs, then it's safe to say the experience you get on either Amazon or Microsoft will be roughly the same,' he writes. 'But that means you're also not developing an app that necessarily takes advantage of all possible cloud capabilities—not just add-ons, but scalability"
Re:This is a solved problem? (Score:4, Insightful)
Which means either:
1. You end up with a lowest-common-denominator API.
2. You move most of the smarts into the 'abstraction layer', which then decides how to implement them on different 'cloud' providers, and then you're tied to it instead.
3. You start using APIs wihch are only properly supported on one system so you're doubly screwed (your software only runs on the abstraction layer using features only supported by one 'cloud' provider).
Re: (Score:1)
2. You move most of the smarts into the 'abstraction layer', which then decides how to implement them on different 'cloud' providers, and then you're tied to it instead.
p>
It seems like you are listing that as a negative....why would you be worse off being tied to the abstraction layer instead of the cloud vendor?
Re: (Score:2)
This is why we write our own Abstraction layer and make sure none of our site code directly references any of the API calls directly.
We just roll our own functions for whatever we need to do and while yes, if we need to switch cloud service it relies on, then we deal with when and if we come to it.
If you write for both services - or use an abstraction that covers both - *now*, yet only use one of them, then you're giving yourself redundancy that may or may not still be compatible 1, 5, 10 years down the lin
Re: (Score:2)
time wasted on maintaining both, or switching your abstraction layer to one that supports all the new things, will probably take about as much time as if you'd just programmed it against the Native API
That's highly debatable. There's a reason why adapters or "abstraction layers" if you will are popular with software developers. It's not the right answer in every case, but the collective experience of millions of developers working over many decades has proven the concept to be useful. At the very least, it's something that ought to be considered whenever a third party service or library is introduced into your system. A good developer learns to keep their options open and adapters or abstraction layers h
Re: (Score:2)
Now I know we don't actually READ the articles around here, but did you even skim the summary?
"If you're not using any vendor-specific APIs, then it's safe to say the experience you get on either Amazon or Microsoft will be roughly the same,' he writes. 'But that means you're also not developing an app that necessarily takes advantage of all possible cloud capabilities—not just add-ons, but scalability"
Not only that, but I have some experience with the amazon cloud. We're talking about virtual MACHINES, right? At some point it's just some [virtual] intel box that loads up some OS and fires up whatever software you've installed. One intel box is a whole lot like another - or it should be. Performance of various systems is gonna vary, but that's what you choose a vendor and a config for.
The company I got the amazon experience with had no real intention of leaving, but we went to some effort to abstract
screw that! (Score:2)
Cumulonimbus or GTFO.
Why just those two? (Score:5, Informative)
Funny, though, that out of the three of them, if I were to choose the least "evil" one, it'd be Microsoft.
Last, but not least, if you're using Azure, I'm pretty sure that New Relic has an agent that's compatible, for performance monitoring.
Re: (Score:3)
Re: (Score:2)
Has anyone here tried AppHarbor? https://appharbor.com/ [appharbor.com]
For a while they were going on about being "Azure done right" ;).
http://trycatchfail.com/blog/post/AppHarbor-Rocks-Seriously.aspx [trycatchfail.com]
http://www.aaronstannard.com/post/2011/01/14/Getting-Started-with-AppHarbor-e28093-Heroku-for-NET.aspx [aaronstannard.com]
Wondering how it compares with the latest Azure now...
Re: (Score:2)
I use AppHarbor, and they do a lot of things right, but they also don't have a lot of the flexibility of Azure or AWS - for most of the addons, it's either a free offering, a small offering for some money 10GB SQL DB for $10 a month) or a dedicated offering for a lot of money. Very little granularity.
Re: (Score:2)
Re: (Score:3)
Funny, though, that out of the three of them, if I were to choose the least "evil" one, it'd be Microsoft.
Why? That's a fascinating assertion, and yet you just left it there, alone, without any backup. Poor thing.
Re:Why just those two? (Score:5, Informative)
Funny, though, that out of the three of them, if I were to choose the least "evil" one, it'd be Microsoft.
Why? Serious question. App Engine doesn't even lock you in that hard - there are APIs for exporting all of your data, and you can run your own App Engine cloud with an open source implementation like AppScale [google.com] or TyphoonAE [google.com]. Google is not hostile to these projects - they actually sponsor AppScale development. Is Microsoft sponsoring any alternative implementations of their server-side cloud software?
Re: (Score:1)
I think the distaste for App Engine came
Re: (Score:2)
There are, of course, other players, including some big ones. Oracle's got a Java-based cloud offering. SalesForce.com has a cloud platform offering as well, although I think it's based on their own proprietary technologies.
Re: (Score:3)
Google has just extended their tendrils too f
McDonalds or Burger King? (Score:4, Insightful)
If you have to ask the question, you've already lost.
Re: (Score:2)
Are we talking fries or burgers? Because the answer is different depending...
Re: (Score:3, Funny)
Re: (Score:1)
Obligatory link:
http://www.amazon.com/Passion-Natural-Water-Based-Lubricant-Gallon/dp/B005MR3IVO [amazon.com]
Well (Score:5, Informative)
For what I would am doing, the cost is unreasonable. I've never really looked at amazon; so I can't compare them.
Depends (Score:5, Interesting)
I'm also not so convinced that the VM cost is that way out of line. The performance we get, both in and outbound, is high, and we pay considerably less than we used to for our hosting. I guess you have to compare like with like taking into account bandwidth, scalability and SLA, and the flexibility to dial cost up and down as the machines are scaled, which you do not have with a true hosted server and database.
Re: (Score:2)
For what we are doing, the principal benefit of Azure is the scalable SQL Server.The ability to fap around with little 1Gbyte databases and then scale them all the way to 150Gbytes (and beyond with sharding) is what sold me on it.
Is 150GB supposed to be a big database? Or do you mean 150TB?
Re: (Score:3)
I think he does mean 150GB: http://msdn.microsoft.com/en-us/library/windowsazure/ee336245.aspx#dcasl [microsoft.com]
Windows Azure SQL Database provides two database editions: Web Edition and Business Edition. Web Edition databases can grow up to a size of 5 GB and Business Edition databases can grow up to a size of 150 GB.
Here are some benchmarks - which might be out of date:
http://blogs.microsoft.co.il/blogs/applisec/archive/2012/02/02/windows-azure-benchmarks-part-13-sql-azure-read-throughput.aspx [microsoft.co.il]
http://blogs.microsoft.co.il/blogs/applisec/archive/2012/02/08/windows-azure-benchmarks-part-14-sql-azure-write-throughput.aspx [microsoft.co.il]
http://blogs.microsoft.co.il/blogs/applisec/archive/2012/02/13/windows-azure-benchmarks-part-15-sql-azur [microsoft.co.il]
Re: (Score:2)
So Azure only makes sense financially if you have sudden spikes in load. Isn't this the case with any cloud provider?
After what happened to Wikileaks? (Score:2)
No thanks. Sure, 99% of us aren't going to be in the business of publishing military docs, but the point was made pretty clear that you don't own The Cloud and any time they have a problem with you, you're subject to having your entire infrastructure and all your data shut off like a light switch.
Re: (Score:2, Insightful)
As if your ISP or colo wouldn't give you the boot "any time they have a problem with you" either. LOL
Re:After what happened to Wikileaks? (Score:5, Insightful)
Re: (Score:2)
You'll have that same problem pretty much no matter what you do, unless you go whole-hog and set up a hidden server on Tor. Yeah, the Cloud will cut you off if somebody with enough pull leans on them. Switch to running your own leased server, and the leasing company will pull your plug. Run your own servers in your own home/office/lair, and either your ISP will pull the plug, or you'll get raided directly. Or both. Run or lease servers in some other country, and they'll pressure that country and try to take
Summary (Score:5, Informative)
Briefer summary of linked article:
Amazon and Azure use different API's, if you use one vendor's API, you're locked into that vendor. There might be libraries available that hide the vendor specific API's but that's outside the scope of the article.
Dismissing third-party API implementations (Score:3)
Of course, TFA acknowledges that there are several (both public cloud and open-source software for private-cloud implementations) alternatives that support Amazon APIs, but dismisses them as unlikely to actually work with real apps no substantive reasoning presented.
It really looks like the author had a conclusion in mind before even beginning to look at the facts.
Techwriter != Developer (Score:5, Informative)
You're never forced into using AWS APIs. They are there if you want to use them. If you don't want to use S3, you stand up a storage server as an instance. No vendor lock-in. If you don't want to use RDS, you build your own DB instance. No vendor lock-in. If you don't want to use ELB, you build your own load balancer instances. AWS offers shortcuts for those developers who want big features and don't want to build them. It doesn't force them on you.
Re: (Score:2)
The difference being that you have to manually configure those instead of programmatically using their API.
Someone manually configuring load balancers isn't being a developer. They are being a system administrator.
Another comparison, from programmers (Score:5, Informative)
Re: (Score:2)
All That Cloud: Amazon, Google App Engine, Windows Azure, Heroku, Jelastic [bozho.net]
Unfortunately there's more missing in that article than info its actually providing. For example, it glosses over all the other services that Azure and Amazon's cloud services offer. It also mentions Google is a PaaS provider, without mentioning that Azure is both IaaS and PaaS.
When it comes to cloud platforms, the capabilities surrounding them are more important than the "dumb" VM hosting and whatever management "polish" they may provide. Google, for example, does't play particularly well with a lot of inf
Google Compute Engine: IaaS (Score:2)
Google is also both IaaS and PaaS: Compute Engine (currently in limited preview) is Google's IaaS offering.
I'm not sure ... (Score:1)
Re: (Score:2)
Niether! (Score:2)
Rackspace (Score:3)
It's worth noting that rackspace's cloud system is pretty slick and easy to use now as well. Nowhere near as big as those two monsters, but it's a very well done system that is very easy to use, and pretty cheap on top of it.
Re: (Score:2)
Huh? I've been using the RS cloud for a couple months. I like it. What's wrong with saying so?
Migating Platform Lock-in (Score:4, Insightful)
The article seems to bemoan the lack of standards and APIs for relatively new technologies like blob storage, message queuing and the like.
In short, it's the same situtation everyone deals with when choosing a platform. Take full advantage of the specific platform and lose portablity, or code to a portable subset and tradeoff ease of implementation for platform independence.
You can minimize your dependency on a third-party API if you use an API of your own to code against. Creating a set of interfaces that provide the blob, queuing and other cloud features for your project not only isolates the cloud-specifc code to one place, but it makes it more testable (using test-doubles, fakes, etc).
This is a problem, but it is a well understood one with a time tested solution.
I love both but I think Azure has taken the lead (Score:2)
Direct hardware access.. (Score:2)
I like Azure for the SQL (as somebody else mentioned) but my biggest beef with them is no ability to talk to the hardware. We are doing some CUDA development, and with Amazon I have the ability to talk direct to the hardware in a VM... not so with Azure. It's a niche need but something I'd like to see.
It's time to give REST a rest. (Score:2)
The IDEA of REST is a laudable goal. Most implementations of it using HTTP as the vechicle for REST with a limited supply of verbs spits in the idea of RESTs face.
You don't get to reuse crap or do anything cross domain with a "restful" API. I've implemented dozens of vendors restful APIs and each one is its own country.
The multi-inheritance issues with the URL path alone are never ending and annoying. Everyone makes up paths adhoc which are not reusable, rarely consistant or coherent.
Then we have a sever
Azure: 24/7, 365 days a year, but ... (Score:2)
With a lack of attention to detail like that it really doesn't bode well for anything else on that system.