Slashdot Mirror
Microsoft Azure vs. Amazon Web Services, For Programmers
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."
Please google "Cloud Abstraction Layer".
Here; I'll help you out:
https://www.google.com/search?q=cloud+abstraction+layer
I wonder why Cogswell ignored Google's cloud services. They've got the Python- or Java-based AppEngine, and they've got a full virtual server service. There are a lot of other platforms, too, but as far as size and industry impact, I'd put Google on a similar level.
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.
The CB App. What's your 20?
If you have to ask the question, you've already lost.
I've got an azure account with MSDN and TechNET subscription (I don't remember which of the two came with the azure). Processor time on their service is very expensive if you go beyond the allotment of free time given to you by those subs. The service works well, although getting your code to the servers is a little kludgy. Given the high cost, I think you'd be hard pressed to find value when weighed against leasing a full server or even multiple servers from a regular hosting provider. The exception to that would be if you had a simply massive load requirement and just couldn't muster enough horsepower out of a few traditional servers.
For what I would am doing, the cost is unreasonable. I've never really looked at amazon; so I can't compare them.
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.
I swear to God...I swear to God! That is NOT how you treat your human!
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.
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.
All That Cloud: Amazon, Google App Engine, Windows Azure, Heroku, Jelastic
Have gnu, will travel.
use Skytap! So Much Better ;)
He want us to choose between two evil empires?
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.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
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.
Go "Cloud"! It's sure to run slow as frozen honey, and crash.
Amazon will sell you the lube.
Do you even lift?
These aren't the 'roids you're looking for.
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.
And if you have Prime membership, they were get it to you in just two days for no extra charge.
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.
Google is also both IaaS and PaaS: Compute Engine (currently in limited preview) is Google's IaaS offering.
I've used both cloud platforms for the past few years and I really enjoy both of them. I do think that in the past few months the Azure tools have gotten a lot better and easier to use.
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.
The price is always right if someone else is paying.
I see from Cogswells article that he programmed on both platforms. However, I am not certain why he rates them as approximately equal. I was tasks to evaluate Azure and AWS for a 1bn revenue company with 100s of servers to migrate. And, I focused on PaaS as well as IaaS. My findings?: Azure is bug prone with usability issues. AWS on the other hand is a dream to work with. Now, pass the cool aid.
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 severly limited supply of verbs (HTTP) which are not particularly useful for anything non-trivial. This limitation ususally accompanies an "action" field hidden in the path or as a separate parameter to make up for the limited vocabulary.
There are no templating, transactions, registries of fields or data to promote any reuse of any horizontally useful information or concepts.
Next up is retardulous idea it is a good thing to collapse response layer so http response codes mean something to the API. I've lost track of the number of times this has ended in disaster. Systems that report a 500 error due to some issue way down in the stack get interpreted to mean the API command failed when no such thing has occured. The same results have occured due to fat-fingered URLs or middle boxes providing invalid responses while API only examines the fucking HTTP response codes.
Viral propogation of nonsensical memes without comensurate technical merit are harmful to the industry.
Cumulonimbus or GTFO.
Anons need not reply. Questions end with a question mark.
Azure: 24/7, 365 days a year, but leap years really suck.
With a lack of attention to detail like that it really doesn't bode well for anything else on that system.
Obligatory link:
http://www.amazon.com/Passion-Natural-Water-Based-Lubricant-Gallon/dp/B005MR3IVO