I met with a medium sized ISV the other week. They make a software application for service companies. Some of their customers are one guy and a van, and others are giant companies. Their software helps manage the service appointments from the customer’s central office. They also have a mobile app that runs on an iPad. The idea is that the home office makes an appointment, and the data is sync’d to the iPad for the service personnel to use. The system does a lot more than this, but that is the basic use case.
Some customers rent a server from them to host their application, while others (the larger ones) run their own servers. All customers sync their data to a central web server/SQL Server, which the iPad app uses as a data source. We’ll call these servers the ‘mobile backend.’
The customer servers are constantly sync’ing with the mobile backend, even during the evening when there is a lot less new data to move around.
The ISV wanted to move the mobile backend related infrastructure to the cloud, and wanted to ask me some questions about it.
It turns out their web services are running on IIS (written in .NET). This is a single web server running four cores. It uses a dedicated SQL Server for data storage. This SQL Server also runs four cores. The servers are almost always at 70% CPU utilization. Both servers are actually virtual servers. Their database runs evenly at 10GB in size. The system only keeps a certain window of data online for the mobile users, so their primary data growth vector is the number of customers using the service. The rest of the data is stored in the product db of the tenant.
After some discussion, these are the options we came up with for them. All of these approaches are for their production environment. I won’t be outlining their options for dev/test, but they would be very similar. The benefits would be in pricing, with their MSDN subscriptions.
Also, since all scenarios would have the same outbound bandwidth usage, we didn’t factor that into these costs.
1> Lift & Shift
They could simply upload their current virtual servers into Windows Azure using the new Virtual Machines capability. This would be the fastest into the cloud. There would be little to no engineering required. This is usually the least threatening and easiest step into the cloud, but it results in the least cloud benefits. They will gain easy recoverability of their servers, and geo-redundancy on the VHDs the servers are running.
This would save them the Windows licenses on the servers, but they would still pay for the SQL Server license. They would save on having to manage the physical infrastructure, but they would still have to manage the virtual servers (patches, etc.)
Their rough monthly Azure bill would be something like the following, using the WindowsAzure.com pricing calculator.
- Two Large (four core) servers: $460.80 / month
- Storage of their VHDs for the servers (estimated 50GB) : $4.75 / month
- Storage transactions for VHDs (estimated 10 million) : $1.00 / month
Total: About $466.55 / month
2> Lift & Shift with SQL Database
This second scenario is very similar to the first, but instead of shifting both servers, we are only shifting the web server. The SQL Server will be replaced with SQL Database. We discussed their data needs, and SQL Database will meet it nicely. In this scenario, they will now get three replicas of their SQL data.
This scenario will require a few more days of engineering work, to migrate the schema and data to SQL Database.
- One Large (four core) servers: $230.40 / month
- Storage of their VHDs for the servers (estimated 25GB) : $2.38 / month
- Storage transactions for VHDs (estimated 5 million) : $0.50 / month
- SQL Database – 10GB : $45.96 / month
Total: About $279.23 / month
3> Move to Cloud Services
The biggest lack of ‘cloudiness’ in VM’s is that you still have to manage VM’s. If they kept their data in SQL Database (as in scenario 2) and moved their web service code into a cloud service (as a web role) they would reduce their management costs a lot, and reduce their operating costs a bit.
The biggest benefit to moving to cloud services for them will be to simplify rolling out new versions, the ability to scale when things get busy, and to have easy redundancy in the servers. In this scenario they will start using single core servers (small), and scale as needed. While we expect the number of core hours per month would be lower, we estimated with four full time small servers.
It would take their team a few days to a week to move over the code, mostly because they haven’t worked with web role instance and cloud services before. Other than that, the code will mostly move over just fine.
If they tune how the tenants (in house and at the customer site) sync with the mobile backend, they could dramatically reduce the amount of horsepower needed. Right now the service is synced/polled everything three minutes (I am simplifying a bit here). We discussed a truncated exponential back off polling algorithm where the rate of polling would slow down as the tenant had less and less new data to sync. The truncated part comes into play when there is new data to sync, the polling interval immediately speeds back up to normal instead of slowly ramping back up.
You can see a service company that only does jobs during normal business hours would not need to poll at all after 6pm, but would need rapid polling through the day. For a service company that had 24 hour service, they might need some polling at night, so the system can handle that as well.
With this change in polling behavior, they could easily adjust the number of small instances handling the web service servers based on the immediate and expected load. Perhaps a simple plan of four during the day, and only two at night.
- Four small (single core) servers: $230.40 / month
- SQL Database – 10GB : $45.96 / month
Total: About $276.36 / month
4> Extreme Cloud Unicorns Riding Rainbows!
Lets take it one step further for fun. What if they hosted their web service front end in Web Sites, and moved their data into Mobile Services Data? Crazy! What if they get really crazy, and dump the web service front end altogether, and use the Mobile Services Data REST service endpoint in their mobile app?
This would take a week or two to move their data into Mobile Services, and to update the iPad app with the Mobile Services iOS SDK.
The REST façade into the data service runs in a free hosting model. The free model does have some limitations. When your service bumps into these you can scale up to dedicated hosts. This price estimate will range based on how often they scale up to four dedicated small instances, and how long they stay at the free tier.
- Mobile Service instances (ranging from the free tier to four small instances) : $0 – $230.40 / month
- SQL Database – 10GB : $45.96 / month
Total: About $45.96 – $276.36 / month
Which way did they go?
They chose to go with option 3. They thought the small investment in time to migrate their code to a cloud service was worth costs savings and agility they would gain. They considered moving to scenario 1 first, and then migrating to scenario 3. They decided that that would just drag the process out, cost them more money in the long run, and not provide any benefits for them.
They didn’t go with scenario 4 because Mobile Services is still in preview, and they wanted to control the web service, and be able to include more intelligence in the service. With the data service, it’s just a REST CRUD façade. They did like the idea of this in the long term however.
Since I am an engineer, and not a sales person, I didn’t go into the commitment pricing options available to them. That would reduce their costs even more.
I hope this helped you gain some insight into what some of the thinking goes on when a company is looking to move some of their infrastructure to the cloud. Please keep in mind that every customer and situation is different, and you need to use the human superpower ofCritical Thought to make the right decision for you and your company.
In this case they wanted to balance both soft and hard costs, gain some big IT features they didn’t want to buy for themselves, and gain some agility they couldn’t get while keeping the small dev and IT Pro team that have in place.