Slashdot Mirror

← Back to Stories (view on slashdot.org)

Microsoft Azure vs. Amazon Web Services, For Programmers

Posted by timothy on from the equality-prison-style dept.

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."

14 of 64 comments (clear)

  1. This is a solved problem? by kwerle · · Score: 4, Informative

    Please google "Cloud Abstraction Layer".

    Here; I'll help you out:
    https://www.google.com/search?q=cloud+abstraction+layer

    1. Re:This is a solved problem? by dave562 · · Score: 4, 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"

    2. Re:This is a solved problem? by 0123456 · · Score: 3, 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).

  2. Why just those two? by bennomatic · · Score: 4, Informative

    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?
    1. Re:Why just those two? by chrb · · Score: 4, 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 or TyphoonAE. Google is not hostile to these projects - they actually sponsor AppScale development. Is Microsoft sponsoring any alternative implementations of their server-side cloud software?

  3. McDonalds or Burger King? by Hazel+Bergeron · · Score: 3, Insightful

    If you have to ask the question, you've already lost.

  4. Well by kelemvor4 · · Score: 4, Informative

    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.

  5. Summary by hawguy · · Score: 4, 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.

  6. Techwriter != Developer by Anonymous Coward · · 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.

  7. Another comparison, from programmers by leonbloy · · Score: 5, Informative

    All That Cloud: Amazon, Google App Engine, Windows Azure, Heroku, Jelastic

  8. Re:After what happened to Wikileaks? by medv4380 · · Score: 4, Insightful

    Really? You're hung-up on that little point? Your domain name could be seized by ICE and who knows what else, and you're concerned that the Amazon caved to pressure to pull Wikileaks? This kind of thing has been going on for a long time before Wikileaks and Amazon. It's apart of the risk of doing business in this world. There is no way around it.

  9. Depends by Kupfernigk · · Score: 4, Interesting
    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. The cost of hosting your own SQL Server is much higher.

    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."
  10. Re:Deal with M$ and you're screwed by larry+bagina · · Score: 3, Funny

    Amazon will sell you the lube.

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

  11. Migating Platform Lock-in by ndykman · · Score: 3, 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.