Greetings Habrazhiteley! This is my first post here, I hope you will like it, and someone will be useful. In the post I will describe our practice of using Windows Azure as a hosting for a SaaS project. The article will be useful to those working with .NET and thinking about moving to the "cloud".
UPD: the article describes the technical issues, the financial issue will be discussed in the next article.
About service and team
In the beginning I will say a few words about the service itself. SportFort automates the process of creating the official website of a sports team. Our platform is used by both amateurs and professionals. Perhaps, SportFort will be useful for small studios and freelancers for making a team or league site. Our project is the first of its kind in the CIS market.
team site appearance')
As is often the case, we run into funding, so our team is small and each member is “a reaper, a successor, and a igrets on a dude”. There are three of us: I develop the product, I program, we also have a person who is looking for funding and administrative issues, and a sales manager. We are helped by other guys, paint on the design, set up an advertising campaign, make a video, etc.
Technical details of the service
Windows Azure really helped us out. Especially considering that at first we used it through the BizSpark program. Before the transition to WA, we had regular hosting, which often let us down. No one in the team has any server administration skills, and there was no opportunity to allocate a budget for a new specialist. Sometimes our hoster fell for a whole day and absolutely nothing could be done, the support service simply ignored all incoming messages and it remained only to spoil their twitter. I considered the option to organize your own servers, but it is expensive both in finance and in time. WA allowed not to be distracted by the hardware infrastructure, but to focus on the product. It works much more comfortably when you know that everything is reliable and that no major changes are required for scaling.
In the Azure architecture, functional components are roles, these can be Web Roles serving external requests or Worker Role for internal tasks. Each role can be allocated corresponding to the computing power. For example, a video processing site other than Web Role, which will be directly responsible for the site, will contain one Worker Role for video processing. And if there are many requests at once, WA will be able to add the power of this Worker Role.
In our case, the service used to be a regular ASP.NET MVC 3 website with an MS SQL database and the storage of user files (mainly pictures) in the file system. Respectively, this is now Web Role on ASP.NET MVC 3 with SQL Azure database and image storage in Blob Storage, a special cloud storage for binary files. In addition to Blob Storage, there are two more types of storage in WA - Table Storage and Queue Storage. Table Storage is a non-relational database, we use it to store logs, and Queue Storage is a built-in mechanism for working with message queues, which we are not using yet.
To manage all the services in Windows Azure, there is a browser-based control panel. Here you can configure both technical parameters and view usage statistics.
Azure admin panel, here is hosted service, and storages and databasesDeploy on Windows Azure is different from deploying to regular hosting. To post a new version, you need to create a special package and download it through the administration panel. In this case, the update will occur automatically - all servers will be updated in turn, the service will not go offline. It is not possible to replace a separate file. But working with SQL Azure is the same as with ordinary SQL Server, through Management Studio. There are some minor differences with the keys, but they have not touched me.
In addition to differences in the Deploy, we have changed the testing process. In Azure, this is more convenient: we first lay out the new version in the preliminary environment, the so-called “Staging Environment”, then we test and, if everything is fine, then we change the current version to the new one. It happens very quickly in one click. I have not yet explored other Azure features, but I know that there is an automatic allocation of new resources when the load increases. In the future, we need it. We can say that for the time being we mainly use WA as usual hosting, except for deployment and testing, nothing has changed.
Recently, with the development of service and the emergence of new features, there is a need to use other features of Azure. In particular, for non-urgent and long-term tasks in WA, Queue Storage is great in conjunction with Worker Role. I plan to send a separate Worker Role to send notifications and use Queue Storage queues to send messages to this role. In general, many functions related to remote services need to be reworked to work using queues, but their hands have not yet reached.
Going to WA was pretty easy, because Initially, the service was programmed using the “correct” patterns, albeit in haste. First of all, I mean Dependency Injection, the use of which allowed, for example, only in one place to replace FileSystemPictureStorage with AzurePictureStorage as an implementation of the IPictureStorage interface. Well, write a migration script, of course. Thus, instead of a file system that cannot be used as permanent storage in WA, we switched to using cloud storage.
On the local developer’s machine, Windows Azure emulation and the SDK are pretty straightforward, and the database is local (in our case, SQL Server 2008 R2).
My conclusion
The most important advantage for me is reliability. No need to blush in front of users when the hoster is something wrong. Users of stability, of course, also like. Pleases the speed of innovation for the development environment. When in MS they make SQL Azure support in Database Project it will be generally super). Also, a huge advantage was the fact that it was possible to simply move to the “cloud”: I didn’t have to redo anything capital and managed to figure everything out myself. And we did not need to hire a highly qualified specialist to build a scalable architecture.
If there is interest in the article, I will describe the financial side of the question.
Thanks for attention!