Azure Websites vs. Azure Mobile Services

Since I decided to go with Microsoft technologies for my new app, the next question I asked myself was related to hosting. With the growing prevalence of cloud services, it was obvious to go with Microsoft Azure to host my platform. With the benefits of Microsoft BizSpark, this was a no-brainer decision.

As I researched into what Azure offers, I learned there are currently two solutions for hosting mobile app platforms on Azure: Azure Websites and Azure Mobile Services. I spent some time researching both and the differences seem to come down to whether you’re a developer familiar with server-side coding or not. Mobile Services is great for client-side developers who don’t know much about server-side development. Mobile Websites will spin up the tables and the CRUD API’s in one step. You can even customize the logic using node.js. Websites, on the other hand, require that you manually create your own website and service, create your own database, and make sure everything is working properly without deadlocking. This is for the server-side developer.

I eventually decided to go with Azure Websites because the simplicity of Mobile Services was causing more problems than the time savings gained. I liked that Mobile Services provided client-side libraries to interact with the service on multiple platforms, but it wasn’t too hard to learn Alamofire to call my API code from my iOS app. My relational data model was also sufficiently complex such that the default implementation of Mobile Services created more of a road-block than made things easier. Since I’m familiar with server-side development, using technologies such as ASP.NET MVC, ASP.NET Web API, and Entity Framework for the database made more sense than trying to learn node.js. Websites also have many more scalability options than Mobile Services.

Cloud infrastructure is great. Not having to worry about the machine, the DLL’s, the system libraries feel so liberating than the old days when I had to respond to system alerts at 3am in the morning. Azure provides all of these benefits no matter which solution you choose. If you’re on the fence on selecting Websites or Mobile Services for your app, hopefully this helps clarify things.

Picking Technologies for a Startup

When you’re starting from scratch, one of the first questions you have to ask yourself is “what technology?” Sometimes it’s clear – content accessible anywhere in any format: responsive web, creating dynamic web content: use Javascript. Unfortunately, most times it’s very ambiguous: what server technology? what mobile platform?

This was one of the first questions I asked myself when launching my new startup. I eventually realized the following are the key questions to ask in my situation.

  1. What are you familiar with?
  2. Which platform do your customers use?
  3. How much time do you have?

What are you familiar with?

I’ve established my career on the Microsoft stack: C#, .NET, ASP.NET, LINQ, SQL Server, IIS, … Therefore, you would think this is a slam dunk right? Choose the Microsoft stack. However, I’ve always wanted to learn and play around with the open source stack: Linux, Apache, MySQL, and more recently Ruby and Ruby on Rails.

I figured building a new platform is a great opportunity for me to learn a new technology and apply the learnings to a real project. In the process of making this decision, I spent a few weeks learning Ruby on Rails, reading tutorials, and going through a few online videos in an effort to get the basics down before writing any production code.

Besides asking myself what I’m familiar with, I also debated with myself on many other factors not specifically related to programming. Which platform has more local developers we can hire? Which platform do I have more friends I can call upon? How much would it cost to hire contractors? How much does hosting cost? What’s the maintenance and support process? Are there software licensing fees to consider? Who do I turn to if I need support? When you just write code, you don’t think about these topics. However, when you run a technology department or start your own business, these are issues just as important, if not more important, than how clean your code is, how much code does your unit tests cover, how efficient is your code, …

In the end, I picked Microsoft for two main reasons: (1) that’s my background and that’s what I’m familiar and (2) see question 3.

Which platform do your customers use?

Obviously if you’re building a mobile app, you’d need to pick a platform. If you asked me 10 years ago, I would have told you I’m building a Pocket PC app. That would be an easy choice since there weren’t many smartphones back then and my background is in Microsoft. Alas, those days are long gone and today’s world is very different.

Mobile platform’s today revolve around iOS or Android. iOS spurred the “modern” smartphone and has Apple backing the platform. Android has the biggest market share with Google supporting the platform. Each platform is attractive to different customer segments with different demographics. Development on iOS is on a Mac, using Xcode, and either Objective-C or Swift programming languages. Development for Android is on PC or Mac, using Android Studio, and uses Java.

In the end, I picked iOS. There were technical and business reasons for this selection. On the technology side, it’s much easier for me to develop and test with a smaller set of device types and screen sizes to worry about. I’m also familiar with iOS development having played around with it in the past. On the business side, which is the more important reason, the type of customer we’re trying to reach with our initial version is more likely to have an iPhone than an Android device. We didn’t consider the other mobile platforms (Windows Phone, Blackberry, …) at this point because not enough of our target users use those platforms.

We also considered building a responsive web and going the route of using a Web View on the mobile app side. However, UX is critical for our app so we decided to invest in the native app for the initial release to ensure our customers get the best first impression. Of course this decision means we would forgo customers on the other platforms. This is a risk we were willing to accept since our goal is to prove out the concept with our first version before moving ahead onto other platforms. Lean Startup anyone?

How much time do you have?

The last, and possibly the most important, question I asked myself was regarding time. Just like any corporate project, time is always a big consideration. This is just as important if not more important for a startup since we’re trying to launch fast with limited resources (me essentially), get feedback on our product, and either fail fast or pivot so we’re not wasting time and resources on a concept that isn’t working.

My partner and I set out with an aggressive timeline to get our app launched early in the year so we can learn from the release and iterate quickly on the product until we find something that works. If you’re familiar with the project management triangle, then you know something has to give when you have limited resources and limited time.

Therefore, we needed to cut out everything else that wasn’t core to developing the product, which ultimately means delivering the most value to our customers in the least amount of time. In the end, going back to question 1, I realized I didn’t have time to waste learning new technologies. That’s why I realized the technology decision simplifies down to: the platform that allows me to be the most efficient and quick with development. For me, that means the Microsoft stack on the server-side of things and iOS on the client-side of things.