Hacker Newsnew | comments | show | ask | jobs | submit login

Windows Azure is a collection of services managed by Microsoft that, together with software development tools and SDKs (for popular languages such as C#, Java, Ruby, Python, Node.js, or over plain REST), comprise a computing platform.

It includes services for on-demand computing, storage (in No-SQL form and Blob form), message queueing, service bus, secure connection, identity management, horizontably-scalable relational database, big data computing (Hadoop), media encoding and streaming, content distribution network, reporting, business intelligence, a data marketplace.

The list goes on and on and is increasing rapidly. The gist is, you consume those services, Microsoft hosts and manages them (with high availability, geographic redundancy, etc.) and you pay for what you use.




I want to add that you can remotely debug your applications there using your desktop Visual Studio. I think this is an excellent addition.

-----


Well.... I wont pretend I understand all of it, but it seems their offering is pretty big.

So it doesn't have to do much with "Windows" OS in any sense, it's just a little confusing name for their SaaS.

Thanks!

-----


The virtualization platform they are using for all this stuff is Hyper-V which runs on Windows, so the name is still relevant.

-----


Originally Windows was the only OS in this platform, but I iirc they are planning to change the name also.

-----


Correct. They are dropping the Windows bit. Details here:

http://www.neowin.net/news/microsoft-renames-azure-services

-----


Not really.

https://twitter.com/WindowsAzure/status/199918250652475393

-----


There's no brand change.

-----


so it's like App Engine has a bigger brother :)

I hate Google App Engine, I hope Azure is better

-----


Care to explain why you hate App Engine so much?

-----


Yep sure.

- It's speed is very unpredictable. Sometimes it'll be lighting fast, other times requests will hang for up to 8 seconds. We've used nodes in data centers across the world to measure this and have confirmed 100% that the delay is happening at App Engine and not our machines :)

- There's been several times where I have used Google Python libraries (for other Google products) and found them incompatible with the version of Python on app engine. I've had to write several dummy modules that replace googles ones that attempt to open a file on the disk in write mode (not allowed) when they're not even writing to the file! I cant be specific, under NDA. I have contributed the fixes back to the Google API team.

- The last 3 SDK upgrades has broken something in the core modules, or Django. App Engine SDK upgrades are now a running joke at my workplace

- It's insanely expensive for the CPU / DB power that you get

-----


Hows this for nasty:

Part of Python [removed] core module on App Engine has a bug in it. Including this module will terminate your application with an exception.

Nobody notices it in development or testing, because the dev system was including the python distributions [removed] module, which is apparently different to the one on App Engine.

Site makes it through testing. push live and crunch, falls over.

Now we have a test app engine account, and have to deploy to that first, because we cant rely on the installation of Python on App Engine matching the installation of python on our dev machines, even though the versions are exactly the same

-----


I'm not following. Why is the name of the module "[removed]". Was that an edit? Why? Surely a bug in a core python module (whether it be AppEngine-specific or not) is a matter worthy of public discussion.

-----


> Now we have a test app engine account

That's good practice. You test locally, then test on a real deployment environment, then deploy to production. You should also use app versions and test new ideas on new versions and always plan for rolling back.

-----


PaaS is a tough thing to do. You have to automatically deploy new instances of your applications, distribute those instances according to the load on individual nodes of its clusters. Also, they have to do more or less the same with the datastore. If you have loads that experience sharp peaks, new instances will have to be spun up and that may take some time. Some seemingly random variations on response time are to be expected when you consider it's not only your application that's running there. You can somehow mitigate that by setting up warmup requests (https://developers.google.com/appengine/docs/python/config/a...) and tuning the minimum pending latency (https://developers.google.com/appengine/docs/adminconsole/pe...). If you build a fixed size cluster to run a single application, you'll experience much more predictable response times.

As for the price, you should consider what would it cost running your application on IaaS, rented or co-lo hardware. As always, YMMV.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: