There is an undoubted need for a hybrid architecture for many larger corporations since migrating existing apps to the cloud is not a simple as lot of demos show and there is a perception (whether real or not) that the data is less secure on the cloud. Enter hybrids apps – maintain the data on premise or consume on-premise apps from a cloud service.
Of course it is possible to communicate between on-premise data sources or apps and cloud-based apps using SOAP/REST communication protocols, however there are two major obstacles – discovering the service endpoints (since these may change due to dynamically assigned IPs) and navigating through firewalls. These problems can be overcome by allowing apps to selectively open ports which is inherently insecure, and using relay systems that sit between the firewall and the apps and act as a bridge, thee systems tend to be very complicated and hard to implement.
The Azure Service Bus attempts to solve this issue by proving a service which allows applications which need to communicate with eachother to register with it. The requesting app is given a Service Bus endpoint to communicate with the data source/service app. Essentially the services are provided by service apps run behind the firewall, and the connection endpoints are provided by the Azure Service Bus. It should be noted that the Service Bus allows communication with non-.NET services , so Linux/UNIX hosted apps can register with the Service Bus and be consumed by .NET apps.
Security is provided by the Azure AppFabric Access Control, which applies user-defined rules to ensure security when an app claims tokens via the STS service provided by the Access Control.
Thus the Service Bus can be used to build hybrid apps which span both on-premise and cloud services.]]>
Adoption rates in future is, however, an interesting question and the answer really depends on who you talk to you. The staunchest critics seem to be DBA’s and SysAdmins who are used to the fine control they have over the hardware and the software stack. Moving to Azure surrenders most of this control to Microsoft and in truth wouldn’t leave DBA’s and SysAdmins a lot to do. In the opposing camp are small developers who have limited resources but need to deliver and maintain apps and, in common with most developers, have little idea about hardware, security or scaling applications. For these developers Azure is an ideal platform, as opposed to traditional ASP.NET Hosting since it takes most of the admin, security and application scaling chores away and lets users focus solely on building the app. A bonus for web-app start-ups is that the hurdle of persuading users to trust the app with personal data, when the app is hosted on Azure it is a powerful marketing tool to highlight the platform’s enterprise level security.
Another compelling use case are apps which are of variable scale. Typically hardware must be set up to handle the maximum load an app will be under, this can be very tricky when the max load is vastly different from the typical load. At PDC Microsoft a ticketing app was demonstrated which was suddenly under intense load when new tickets were made available for popular sports events but under minimal load thereafter. The ability of Azure to scale effortlessly up and then down makes it a very natural fit for these apps. Large apps which need a server farm are a less compelling case, Azure certainly simplifies the scale but facilitates very little in the performance fine tuning of the scaling process. In addition it is definitely cheaper to run the apps on a server farm than Azure (ignoring any saving on admin personnel that using Azure may allow).
2010 is likely to be a defacto beta year for Azure its real test is likely to come down the road.]]>
This marks a major shift in Azure’s focus, previously Azure was intended to perform all hardware configuration chores from developers. SearchCloudComputing attributes the change to easing the migration pains for existing Windows apps, however resource isolation and allocation seems a much bigger step forward. A lot of developers who are new to clouds are surprised to find that their apps are not fully isolated from other cloud apps. For this reason Azure imposes a lot of restrictions on apps – for example the execution time of a SQL Azure query is limited to 5 minutes after which the connection is terminated and must be re-established. A VM would allocate a user a finite amount of resources to use as that app wants thus removing resource throttling.
No firm release schedule or other feature details were announced.]]>
Enter the Azure cloud, now .NET developers have an arsenal of API’s to manage and scale an application. Setting up a production environment takes a few clicks and all the infrastructure is fully managed. Seems a wonderful promise, but what it the reality?
I waited until October to kick the tires of Azure, I normally only use software in Beta 2 as I’ve spent too many hours trying to figure out an issue only to find that it is a known bug (which is nevertheless undocumented) and is fixed in the next release. So here’s my first impressions:
SQL Server and SQL Azure are great products but for a lot (maybe even the vast majority) of cases they are overkill and add an unnecessary overhead and slow development. But there are almost no alternatives to persist structured data in a .NET application. XML is a good choice for small data storage tasks or for transmitting data, but it does not scale well. So for almost any structured data developers are forced to create and maintain databases, put query logic in the database and open and close database connections to read/write the data.
I recently heard Matt Mullenweg founder of WordPress.com discussing how WordPress uses MySQL simply as a dumb data store, no stored procedures, triggers etc. WordPress runs pretty much all the largest blogs and scales very well.
Clearly then, there’s a need for something a lot simpler than a full database – enter Tables, Azure’s answer to Amazon’s SimpleDB. In Tables data is stored in rows and columns but less structure is imposed than in database tables. Rules of normalization are relaxed and mixing different forms of data in a single table is now efficient. Tables don’t require connections like databases and more importantly they are blazingly fast and quick to develop.
Table storage goes some way to alleviate the biggest pain point for Azure adoption by smaller web developers – the minimum $10 per database which quickly racks up the monthly cost when several sites are added. Tables might prove a viable database alternative.
It will be very interesting to see how Tables evolve and which applications move over from SQL Server and SQL Azure.]]>