Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Microsoft Azure vs. Amazon Web Services, For Programmers

timothy posted more than 2 years ago | from the equality-prison-style dept.

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

Sorry! There are no comments related to the filter you selected.

Lardass Fatties Are Not Sane (-1)

Anonymous Coward | more than 2 years ago | (#41012499)

My Lord do fat people suck. They suck so hard and so bad that I do not even know how to describe it. This is only a partial attempt.

You know what's worse than the rolls of fat and general ugliness of obesity? You know what's worse than saying "hey I smoke but I don't smoke right next to you and I don't blow smoke in your face and I don't in any way make MY smoking into YOUR problem ... so y'think maybe you could I don't know, waddle your big fat ass out of my path that it's blocking with its immenseness? You know what's worse than the emotional trainwreck all fatties secretly are on the inside? You want to hear the very worst part of it all?

The excuses. The thing where they try to convince you "yeah I daily decide to eat too much, several times every day, but but but ummm yeah you're some kind of bigot if you question that and connect two whole dots and say things like maybe this is why you are overweight! I mean how dare you try to tell me something I am too gutless to admit myself?! All this damn truth and shit, fuck you it's your fault! Not my fault! Your fault! See that means I am not doing anything wrong so hah! That's what matters to you psychos, right? Blame? Not solving the problem, of course, but avoiding blame, yeah that's what counts. Thinking like that is why America's economy is so hopelessly fucked and its waistline with it.

For fuck's sake. Don't eat more calories than you burn. If you're a dullard I'll explain: that means either get more exercise, eat less food, or eat less calorie-rich food. Ideally, all of the above at the same time. The most important thing is, fix the one that's in excess or not happening enough. You know you fixed it when you can do it this way the rest of your life and remain at a healthy weight. No crash-course diets. Permanent change, change back to how you should have been all along.

God dammit, America, is that really so hard to understand? Seems like basic, obvious, can't beleive people don't get this, so many adults should never fail to implement something so self-evident, why the fuck would this ever be so hard, type of shit. Seriously,. You fucking lard-asses, get a clue. Stop with the goddamned excuses, grow a pair, and get some personal responsibility. It's so much easier than what you're already doing.

This is a solved problem? (4, Informative)

kwerle (39371) | more than 2 years ago | (#41012507)

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? (4, Informative)

dave562 (969951) | more than 2 years ago | (#41012645)

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? (0)

Anonymous Coward | more than 2 years ago | (#41013201)

I don't think you understand the "Cloud Abstraction Layer" concept.

The programmer codes for the abstraction layer's API instead of the cloud vendor's API. The abstraction layer converts the API calls into the vendor specific API calls.

Re:This is a solved problem? (3, Insightful)

0123456 (636235) | more than 2 years ago | (#41013393)

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:This is a solved problem? (1)

Anonymous Coward | more than 2 years ago | (#41013897)

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:This is a solved problem? (0)

Anonymous Coward | more than 2 years ago | (#41015549)

Because unless you're writing that code yourself, you're still relying on a third party API which may disappear tomorrow?

Re:This is a solved problem? (1)

Canazza (1428553) | more than 2 years ago | (#41016449)

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 line when it comes to move. If you move to the other (or, indeed, if you choose a third option) then the 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, and created it to be replaceable in the first place.

Re:This is a solved problem? (1)

CodeBuster (516420) | more than 2 years ago | (#41019947)

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 help to preserve the flexibility necessary to achieve that. In software development, few things are worse than the case of "coincidental" coupling or "accidental" complexity. Instead, be deliberate in your decisions as a developer and understand the choices that you're making. It's alright to make a trade-off but make sure that you're getting more in return for whatever you're giving up in exchange. That's my advice anyway.

Re:This is a solved problem? (1)

kwerle (39371) | more than 2 years ago | (#41017311)

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 out their particulars, anyway - it's just the right thing to do.

Seems to me that if configuring your VMs and setting up your cloud are really complex and/or hard, then you have either:
* Selected the wrong cloud provider
* Failed to hire the right IT folks
* Got some really boring custom software (because that's what you should probably be spending your time on)
* More than one of those...

screw that! (1)

Gravis Zero (934156) | more than 2 years ago | (#41018553)

Cumulonimbus or GTFO.

Why just those two? (4, Informative)

bennomatic (691188) | more than 2 years ago | (#41012525)

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:Why just those two? (2)

bennomatic (691188) | more than 2 years ago | (#41012551)

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

Re:Why just those two? (1)

TheLink (130905) | more than 2 years ago | (#41013529)

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:Why just those two? (1)

Richard_at_work (517087) | more than 2 years ago | (#41013873)

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:Why just those two? (1)

TheLink (130905) | more than 2 years ago | (#41013999)

I just noticed that they actually run on Amazon Web Services... Wonder if that affects their granularity.

Re:Why just those two? (0)

Anonymous Coward | more than 2 years ago | (#41013059)

And then there's Ubuntu:

http://www.ubuntu.com/cloud [ubuntu.com]

Re:Why just those two? (2)

phantomfive (622387) | more than 2 years ago | (#41013441)

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? (4, Informative)

chrb (1083577) | more than 2 years ago | (#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?

Re:Why just those two? (0)

DuckDodgers (541817) | more than 2 years ago | (#41015657)

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 when Google bumped the prices. Everyone knew it was coming, but they still expected their favorite tech company to let them have peace and butterflies forever.

I'm not sure about the distaste for Amazon, though - I've heard from friends who work at their warehouses that they run you ragged and generally treat you poorly ( do a web search on all the hospitalizations for heat exhaustion at the Amazon warehouse in Allentown, Pennsylvania ). But to my knowledge, AWS customers are generally satisfied.

Re:Why just those two? (1)

bennomatic (691188) | more than 2 years ago | (#41019891)

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.

Re:Why just those two? (2)

bennomatic (691188) | more than 2 years ago | (#41019785)

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 far, and I'm a little creeped out by them. I used to be an avid defender, but I don't believe the "don't be evil" credo quite so much anymore.

And Amazon, well again, I think their cloud service is awesome. Brilliant innovation to take their datacenter expertise and sell off those resources as a service. But their overall business model is, I think, predatory and shameful. They're like the Walmart of the on-line world. I've stopped shopping there, and I've asked my wife to do the same. If there's any way to support our local economy, even if it costs a bit more and requires driving and parking and going out of the house and stuff, I think it's important to do so. There's a high cost for convenience and low prices, and we just won't know what it is until it's too late.

Re:Why just those two? (0)

Anonymous Coward | more than 2 years ago | (#41015919)

Google aren't offering IaaS. He did however ignore OpenStack (RackSpace, HP etc.).

McDonalds or Burger King? (3, Insightful)

Hazel Bergeron (2015538) | more than 2 years ago | (#41012537)

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

Re:McDonalds or Burger King? (2)

_Stryker (15742) | more than 2 years ago | (#41013409)

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

Re:McDonalds or Burger King? (0)

Anonymous Coward | more than 2 years ago | (#41013527)

Wendy's?

Deal with M$ and you're screwed (-1, Troll)

Anonymous Coward | more than 2 years ago | (#41012549)

You deal with M$ and you're screwed.

Deal with Amazon, and they'll at least use some lube and give you a reach around.

Re:Deal with M$ and you're screwed (3, Funny)

larry bagina (561269) | more than 2 years ago | (#41013209)

Amazon will sell you the lube.

Re:Deal with M$ and you're screwed (0)

Anonymous Coward | more than 2 years ago | (#41013265)

And if you have Prime membership, they were get it to you in just two days for no extra charge.

Well (4, Informative)

kelemvor4 (1980226) | more than 2 years ago | (#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.

Depends (4, Interesting)

Kupfernigk (1190345) | more than 2 years ago | (#41012895)

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.

Re:Depends (0)

Anonymous Coward | more than 2 years ago | (#41013381)

Doesn't the Azure SQL Server get throttled?
http://stackoverflow.com/questions/10420721/sql-azure-throttling-the-effect-of-indexes [stackoverflow.com]
http://social.technet.microsoft.com/wiki/contents/articles/3507.windows-azure-sql-database-performance-and-elasticity-guide.aspx#SQL_Azure_Engine_Throttling [microsoft.com]

So basically it's nice till you really have to use it then you get throttled- the last I checked it didn't take that many rps to get throttled, has that changed already? If you could shard things so easily with federation you might as well use the azure table and blob stuff. Many people like to use SQL DBs for stuff that doesn't shard well, and "NOSQL" for the shard stuff.

From what I see they are still playing catch up with Amazon. The service isn't that stable yet. Don't bet your job/project on it, unless Microsoft is paying you $$$$$$ for it. AND you don't mind spending hours publishing, redeploying your stuff and hoping for the best. Even Microsoft doesn't know why their stuff sometimes doesn't work.

Maybe in 2 or 3 years time, they'd be a serious contender. They are trying very hard to add features and improve things.

p.s. And Azure only works 365 days a year, so beware of leap years... I guess when they said 24 x 365 they weren't joking ;).

Re:Depends (1)

0123456 (636235) | more than 2 years ago | (#41013433)

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:Depends (2)

TheLink (130905) | more than 2 years ago | (#41013927)

Re:Well (1)

Eirenarch (1099517) | more than 2 years ago | (#41013305)

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? (1)

GodfatherofSoul (174979) | more than 2 years ago | (#41012581)

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:After what happened to Wikileaks? (2, Insightful)

Anonymous Coward | more than 2 years ago | (#41012639)

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? (4, Insightful)

medv4380 (1604309) | more than 2 years ago | (#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.

Re:After what happened to Wikileaks? (1)

downhole (831621) | more than 2 years ago | (#41013573)

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 your domain name too.

But then, why worry so much? Publishing top-secret info from major countries is always risky. Don't do that if you aren't prepared to take the heat. It's kinda like asking how to hide from the police after you've killed somebody - yeah it's hard, because it's supposed to be, so don't do that.

Summary (4, Informative)

hawguy (1600213) | more than 2 years ago | (#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.

Dismissing third-party API implementations (2)

DragonWriter (970822) | more than 2 years ago | (#41013585)

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.

Techwriter != Developer (5, Informative)

Anonymous Coward | more than 2 years ago | (#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.

Re:Techwriter != Developer (1)

casings (257363) | more than 2 years ago | (#41014227)

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 (5, Informative)

leonbloy (812294) | more than 2 years ago | (#41012619)

Re:Another comparison, from programmers (1)

tgd (2822) | more than 2 years ago | (#41013167)

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 infrastructure that isn't Google. It'd be a bizarre choice for 90% of cloud applications, but its dramatically better than any others if you happen to hit the sweet spot of services Google provides.

Google Compute Engine: IaaS (1)

DragonWriter (970822) | more than 2 years ago | (#41013645)

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'm not sure ... (0)

PPH (736903) | more than 2 years ago | (#41012793)

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

Re:I'm not sure ... (1)

courteaudotbiz (1191083) | more than 2 years ago | (#41012897)

Yeah, instead of a blue SCREEN, you'd encounter a blue SKY, which means no more CLOUD.

Niether! (2)

Otter_79 (2709507) | more than 2 years ago | (#41012795)

use Skytap! So Much Better ;)

Choices? (0)

Anonymous Coward | more than 2 years ago | (#41012865)

He want us to choose between two evil empires?

No shit, Sherlock? (-1, Troll)

Desler (1608317) | more than 2 years ago | (#41012949)

This just in: timothy informs us that using platform-specific APIs ties you to that platform. Apparently timothy is playing Captain Obvious today.

co3k (-1)

Anonymous Coward | more than 2 years ago | (#41012971)

To keep up as downward spiral. beyond the scope of completely before say I'm packing been the best, between ea^ch BSD Since then. More WASTE OF BITS AND NetBSD user to foster a gay and share, this news

Rackspace (2)

rwven (663186) | more than 2 years ago | (#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.

Re:Rackspace (0)

Anonymous Coward | more than 2 years ago | (#41013225)

yet another Rackspace astroturfer

Re:Rackspace (1)

rwven (663186) | more than 2 years ago | (#41025797)

Huh? I've been using the RS cloud for a couple months. I like it. What's wrong with saying so?

Get shitty performance developers (0)

Anonymous Coward | more than 2 years ago | (#41013205)

Go "Cloud"! It's sure to run slow as frozen honey, and crash.

Migating Platform Lock-in (3, Insightful)

ndykman (659315) | more than 2 years ago | (#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 love both but I think Azure has taken the lead (2)

elabs (2539572) | more than 2 years ago | (#41014179)

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.

Direct hardware access.. (2)

HerculesMO (693085) | more than 2 years ago | (#41014391)

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.

Re:Microsoft Azure vs. Amazon Web Services, For Pr (0)

Anonymous Coward | more than 2 years ago | (#41015097)

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.

It's time to give REST a rest. (1)

WaffleMonster (969671) | more than 2 years ago | (#41017739)

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.

Azure: 24/7, 365 days a year, but ... (1)

dbIII (701233) | more than 2 years ago | (#41019827)

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.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?