Amazon Web Services adds support for Windows 8/WP8 apps

Microsoft's Windows Azure cloud service has a huge rival in Amazon Web Services. This week, AWS announced it has released a new version of its .NET SDK that for the first time offers Windows 8 and Windows Phone 8 app developers some of the same features as Microsoft does with Windows Azure.

In a post on the company's blog, AWS states:

With the new SDK, you can connect your Windows Phone or Windows Store apps to AWS services and you can build a cross-targeted application that's backed by AWS.  With this release, we add Windows Phone support to our growing SDK support for different mobile operating systems including our SDK for iOS and SDK for Android.

Specifically, AWS is now allowing Windows 8 and Windows Phone 8 apps to connect to S3, EC2 and other services; developers can also pick which specific AWS region the SDK calls to in this new update.

Microsoft has offered similar features for Windows 8 and Windows Phone 8 developers via its Windows Azure Mobile Services for some time. It also has cloud app support for the iOS platform and in March it added Android app support. It will be interesting to see how Microsoft and Amazon's cloud server rivalry will proceed now that both services offer similar features for the majority of mobile app developers.

Source: Amazon Web Services via ZDNet.com | Image via Amazon

Report a problem with article
Previous Story

Nokia reveals more info on its ZEISS camera partnership

Next Story

The perfect accessory for your Lumia 1020, a UAV

8 Comments

Commenting is disabled on this article.

This is neat, but I doubt anyone really wants to use any AWS SDKs for non-enterprise use because you would have to embed the username and password into the app to make use of most features that you would want.

And I don't know about you, but I'm not too fond of the idea of a semi-advanced user easily gaining access to my S3 buckets or EC2 instances.

Where this is most useful, perhaps beyond enterprise development (as even there, I wouldn't embed the username and password), is actually the previously existing SDKs that existed to allow you have some web service that can receive a request and do the work for the phone, likely hosted on an EC2 instance.

It would be different if normal users had AWS accounts akin to Skydrive or Dropbox because then it would make sense to use their credentials, but I have not seen that. Still, there will be a few cases where I could see AWS administrative apps appearing for WP as long as the user types in their account info.

Uhh, what developer-facing backend web service uses usernames and passwords instead of API keys that can easily be revoked should they be compromised?

Why would you give the client, itself, direct access to your buckets? Create a session mechanism, have code that receives chunks authenticated by that session mechanism, and have your server side code access and maintain writes to the bucket, it can even do reads if security requires.

dagamer34 said,
Uhh, what developer-facing backend web service uses usernames and passwords instead of API keys that can easily be revoked should they be compromised?

AWS uses a token/password scheme that is identical to a username/password scheme (there's even two of them), except that it is explicitly meant for revoking (whereas username's at least tend to be less frequently revoked/changed). Beyond token, I forget the other name that they use, but the meaning and usage are identical.

With that in mind: having your credentials embedded in the executable (a compiled resource, or a loaded one from an XAP or Jar for instance) represents a failed design because they are instantly compromisable, and revoking will stop use of the resource only until you deploy the next version whose credentials will be grabbed, and they need to be similarly revoked. It's an unwinnable situation, and it is the entire reason I pointed out that the AWS SDK is largely useless on the client side beyond AWS management software where the user supplies their own credentials.

MrHumpty said,
Why would you give the client, itself, direct access to your buckets? Create a session mechanism, have code that receives chunks authenticated by that session mechanism, and have your server side code access and maintain writes to the bucket, it can even do reads if security requires.

That's exactly what my third paragraph was getting at, with my ending paragraph getting at the concept of public buckets, which are not really used commonly by regular users. The client side of it is largely meaningless beyond management software.

pickypg said,

AWS uses a token/password scheme that is identical to a username/password scheme (there's even two of them), except that it is explicitly meant for revoking (whereas username's at least tend to be less frequently revoked/changed). Beyond token, I forget the other name that they use, but the meaning and usage are identical.

With that in mind: having your credentials embedded in the executable (a compiled resource, or a loaded one from an XAP or Jar for instance) represents a failed design because they are instantly compromisable, and revoking will stop use of the resource only until you deploy the next version whose credentials will be grabbed, and they need to be similarly revoked. It's an unwinnable situation, and it is the entire reason I pointed out that the AWS SDK is largely useless on the client side beyond AWS management software where the user supplies their own credentials.

That's exactly what my third paragraph was getting at, with my ending paragraph getting at the concept of public buckets, which are not really used commonly by regular users. The client side of it is largely meaningless beyond management software.

I'm curious, why do you make the distinction between Enterprise and Non-Enterprise? Your issue is from poor coding habits at any level. If you're publicly distributing an application why would you ever embed the user/password. That is your issue and it's a non-issue unless you're just not very good at designing whatever level of application you are distributing.

MrHumpty said,
I'm curious, why do you make the distinction between Enterprise and Non-Enterprise? Your issue is from poor coding habits at any level. If you're publicly distributing an application why would you ever embed the user/password. That is your issue and it's a non-issue unless you're just not very good at designing whatever level of application you are distributing.
Because many enterprise applications ignore best practice, as they tend to be an in-house tool that would never even enter the app store.

Furthermore, I even called out that exact point: "(as even there, I wouldn't embed the username and password)".

My entire point is still that the AWS SDK is largely pointless for client side development.