Microsoft Azure is a cloud service that allows you to build, test or manage your services. But before you can do this cool stuff with your applications, you need to put your application onto it. We have MVC app with few microservices and one Windows Service operating Hangfire. Like many other creators, we want it in the cloud!
At first, we need to transfer our database to SQL Azure. We can divide this task into two: recreating schema and transferring data.
The schema can be created in few ways. First one – executing every migration in the project – was too ambitious in our example. When we inherited the solution, there were more than 2500 migrations. It’s a lot. SQL Azure has some limitations like dealing with TempDB – they aren’t very problematic, but every not compatible line must be changed by hand. And because of this, we abandoned that idea and we have chosen the second method.
Every table, procedure etc. can be easily exported from SSMS. There is a task called Generate Scripts where we can choose to export only schema of our database. In the result, we have SQL script with all CREATE statements. It’s effortless and efficient because all statements are in the correct order, so we have connections between tables which we wanted.
Generating script tasks in SSMS
After having all elements of our database in the new location, we can now move data between destinations. Like in the first case, we had few ideas to solve it. In the beginning, we tried to manage data transfer by generating INSERT scripts from the old database.
It can be quickly done in SQL Server Management Studio. Generating script is one of many available database tasks. After scripting our data, we had more than five gigabytes of text! We also tried to generate one file per table. Each table had own file, and the biggest file was more than three gigabytes large! It’s not acceptable for any tool.
The path that we have chosen is using Export Data task in SSMS. It allows you to copy data between databases. You can transfer one or many tables at the same time. Every table data movement requires changing default mapping settings. Option ‘Enable identity insert’ must be set on. It allows putting values in identity columns like primary keys.
‘Enable identity insert’ is on
This solution has one minor disadvantage – you must run export in the correct order. Any dependant tables must be exported after the main table. It took few hours for us to transport all tables. Biggest table, with more than three millions of rows, has been processed for about 5 hours.
Export data progress
Now, we have all tables and all data that we wanted, and we can proceed to put our services into the cloud.
At first, we wanted to upload our microservices to the server. To do that, we needed two web apps. Creating web app in Microsoft Azure Portal is easy and intuitive. You need to choose Web App option in New App Service view.
New App Service view
In next step, Azure portal requires a name for your app. It must be unique in Azure Websites. You also need to select what form of subscription you choose. Every available subscription can be selected. Next, you must choose or create a resource group and choose App Service Plan.
New Web App
Choosing the best plan for you is necessary but not critical. Besides region where your services will be put, you must pick up pricing. It’s tough to guess which plan your application will need. We recommend selecting one of lowest and then progressively increase if there is such a need. The lowest plan is free, and it provides 1 Gb of storage and only shared infrastructure.
Every plan price depends on the region which we choose. The most expensive plan with the region in South Korea costs more than 1100 euro per month, in West Europe more then 750 euro per month and for example in East Australia more than 1200 euro per month. This plan allows us to use 1 TB of storage, four cores, 14 Gb of ram etc. It also uses faster discs and CPUs. After you realise that selected plan is not suitable for your application, it can be changed without any repercussions.
Choosing plan for our services
At this point, we had two services for our microservices. Then we’ve put all needed files through FTP. Configuration file needed changes in the connection strings section. It was a quick job and everything was working fine. In the next step, we wanted to have our MVC application on Azure. The way to deploy it into the cloud is identical to previous one. In this case, we had some problems with third-party packages. Not every internal library has been correctly embedded in our project. After short analysis and cleaning, every problem was gone and we could log into our system.
The last thing to move was our Hangfire service. For this task, we needed to create Web Job. Every WebJob runs under Web App. We’ve created app service similar to this above. Then in the settings section of our app, we’ve selected WebJobs.
Creating WebJob in the app settings
After that, we could create new WebJob. It requires typing name for this item. Also, you must select the file that will be executed in the process. At the picture below you can see that Scale option is disabled. Our service plan allows only for using single instance but it’s enough for us because our flow doesn’t allow more than one instance of Hangfire service. And at the last type of Web Job, execution can be chosen.
New WebJob
We want our job to work all the time like Windows Service is. There are two operating modes for the Web Job. First one is triggered. In this type, the job can be started manually or at the time set in the schedule. The second mode and the mode we’ve chosen is working continuously. WebJob starts once it’s created. It stops when the job process finishes his work. Then it can be restarted at any moment.
Because we want our Hangfire process to work all the time, we must set a proper option in corresponding app service. Normally service is put in the sleep after few minutes of the inactivity, so we have enabled ‘Always On’ option in the settings. This option is not available on the cheapest service plan. Everything equal to Basic plan or above is suitable for our expectations.
After creating WebJob and checking if everything works fine, we can honestly say that we have our system in the cloud. Two microservices are being used to handle mobile application requests. MVC application fulfils the requirements of the end users. WebJob with Hangfire service is responsible for data integration and executing scheduled tasks.
