Forgot your password?
typodupeerror
Cloud Microsoft Programming

Microsoft Azure vs. Amazon Web Services, For Programmers 64

Posted by timothy
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."
This discussion has been archived. No new comments can be posted.

Microsoft Azure vs. Amazon Web Services, For Programmers

Comments Filter:
  • by kwerle (39371) <kurt@CircleW.org> on Thursday August 16, 2012 @12:23PM (#41012507) Homepage Journal

    Please google "Cloud Abstraction Layer".

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

    • by dave562 (969951) on Thursday August 16, 2012 @12:32PM (#41012645) Journal

      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"

      • by kwerle (39371)

        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

    • Cumulonimbus or GTFO.

  • Why just those two? (Score:5, Informative)

    by bennomatic (691188) on Thursday August 16, 2012 @12:25PM (#41012525) Homepage
    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.
    • (re: the New Relic stuff, I'm referring to .NET server-side monitoring. I'm pretty sure their client-side RUM system works regardless of the hosted platform.)
    • 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.

    • by chrb (1083577) on Thursday August 16, 2012 @01:35PM (#41013501)

      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?

      • Azure now offers the ability to rent Linux servers. Obviously that means you would be using Windows Azure as an "Infrastrustructure As A Service" instead of "Platform As A Service", but that would stop you from being locked in. Plus I like the idea of giving Microsoft money for offering free software virtual servers. I don't like it as much as the idea of Microsoft going out of business, but if that happens it won't be soon (even with Windows 8 on the horizon).

        I think the distaste for App Engine came
        • Yeah, I wasn't complaining about AWS or GAE, more the overall companies.

          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.
      • It's not so much AppEngine that I think is evil--I actually love it and use it for protoyping web app ideas because it's cheap and easy to use for that purpose. Rather, it's Google and Amazon the companies that I've soured on. Where Microsoft was once the evil empire, they're kind of beaten down and sad. I mean, they're still making bazillions of dollars, but I can't help but think that unless something crazy happens, they'll always be the company that was.

        Google has just extended their tendrils too f
  • by Hazel Bergeron (2015538) on Thursday August 16, 2012 @12:26PM (#41012537) Journal

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

    • by _Stryker (15742)

      Are we talking fries or burgers? Because the answer is different depending...

  • Well (Score:5, Informative)

    by kelemvor4 (1980226) on Thursday August 16, 2012 @12:27PM (#41012561)
    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.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      As if your ISP or colo wouldn't give you the boot "any time they have a problem with you" either. LOL

    • by medv4380 (1604309) on Thursday August 16, 2012 @12:48PM (#41012871)
      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.
    • by downhole (831621)

      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)

    by hawguy (1600213) on Thursday August 16, 2012 @12:29PM (#41012585)

    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.

    • Amazon and Azure use different API's, if you use one vendor's API, you're locked into that vendor.

      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.

  • by Anonymous Coward on Thursday August 16, 2012 @12:30PM (#41012611)

    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.

    • by casings (257363)

      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.

    • by tgd (2822)

      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

      • It also mentions Google is a PaaS provider, without mentioning that Azure is both IaaS and PaaS.

        Google is also both IaaS and PaaS: Compute Engine (currently in limited preview) is Google's IaaS offering.

  • ... I'd use any Microsoft product with a name synonymous with 'Blue'.

  • use Skytap! So Much Better ;)
  • by rwven (663186) on Thursday August 16, 2012 @01:05PM (#41013115)

    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.

  • by ndykman (659315) on Thursday August 16, 2012 @01:14PM (#41013243)

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

"If a computer can't directly address all the RAM you can use, it's just a toy." -- anonymous comp.sys.amiga posting, non-sequitir

Working...