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

McDonalds or Burger King?

[Hazel Bergeron]

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

Re:After what happened to Wikileaks?

[Anonymous Coward]

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?

[medv4380]

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.

Migating Platform Lock-in

[ndykman]

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.

Re:This is a solved problem?

[0123456]

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