On paper, the Microsoft Azure App Service looks great and seems the most viable solution. The service has been built and configured to enable you to create and deploy powerful cloud apps using a fully managed platform. You won’t need to worry about installing .NET, .NET Core, Java, Ruby, Node.js, PHP or Python. It’s all been done for you, and can be enabled with a click of a button. I’m really selling this to you aren’t I?
When first getting started with the Azure App Service, everything ran as one would expect. I was excited, apps were easy to set-up, quick to deploy. Things ran smoothly without a hick-up for months. This was effortless and worry free, what a solution. Or was it.
I started to set-up the Azure App Service for clients of all sizes, because I thought it was fantastic. But as time passed, I started to notice small random outages on a number of the clients App Services, which I have monitored and managed 24/7, 365 days a year. I acknowledged these outages, but before I could jump onto Azure to look into resolving them, the apps would come back online. After a few week of researching the events, I noticed that the outages started to have an ‘off-peak hours’ pattern and would never fail during the day. So for that reason I acknowledged but turned a blind eye, assuming that the outages were caused by Microsoft’s internal maintenance and would soon be a thing of the past.
For monitoring platforms I use Pingdom. With a network of 60+ probe servers, Pingdom tests are available from all over the world, as often as every minute. And if there is an outage, Pingdom can alert you within milliseconds, ensuring you’re the first to know via SMS, Email or via the Pingdom App.
Outages started occurring about twice a month, then increasing to once a week, finally growing to become a very concerning issue by stepping up to multiple outages throughout every evening and night. I couldn’t ignore this, and the outages were happening for longer periods showing an error of “The page cannot be displayed because an internal server error has occurred” when trying to load the page within browsers. From a hosting service which is costing my clients £60+ a month is (NOT including the additional costs of Scale-Out’s), without doubt, not standard. In fact, this was more unreliable than a hosting package which could cost as little as £4 a month. I’ve done my fair rounds with hosting providers over the years, so I know.
Working towards resolving the never-ending growing issues with the App Services, I needed to resolve these outages. And the only way was to report them to the Microsoft Azure support team. I was asked to enable logging in the hope that this would capture what the cause of the outages. But it didn’t, in fact it didn’t pick up anything which I found hard to believe. All we found was a few PHP errors, pages not found or stale sessions — nothing out of the ordinary and nothing relating to the internal server error browser notice that was being shown. I was receiving endless App Service outages throughout the evenings and nights, on multiple separate subscriptions, with no regional Health Issues showing and Microsoft support engineers saying that the outages are caused by "storage migrations” - I’ll let you evaluate in your head what my thoughts of that were.
Outages continued, “PING”… “PING”… “PING”… “PING”… “PING”… every evening and night. Which I don’t like to admit, really pisses me off!
The hunt continues…
When a managed service is being offered, it needs to be stable and reliable. Clients shouldn’t feel helpless and completely out of control, which is exactly how I felt every time the App Service fails. When an App Service goes offline, or unresponsive, as it had been, you are helpless with no access at host level or even force a reboot. Probably because you don’t have an accessible “host” with App Services. The ONLY option you have, is to submit a support call to Microsoft (if you have a support SLA in place).
Which leads me onto why I would recommend anyone weighting up the options of the App Service vs. Virtual Machine. Comparing the pros and cons between these two options, I can’t help but feel the only con for the Virtual Machine would be that you’ll need basic Ubuntu (unless you choose Windows, of course) terminal experience to build and configure your host. But even then, you could hire an expert to do this for you. At the time of my service choice, honestly, I only choose to build a Virtual Machine because the Ubuntu (or Linux) App Services were fresh Beta, and had literally only been announce. At the time, I needed to make a rapid host move from Media Temple to a London, UK based hosting provider and Azure ticked all the boxes. I also liked and enjoyed that I had free rein over the Virtual Machine. Full control over installs of Apache, PHP, MySQL, storage location, cache, and much more. Plus I had control over tracing errors and failures, I would be able to resolve internal server errors myself. Something I can’t do with the App Service. Uptime and response rates have also proven considerably better via Virtual Machine hosting, than that of the App Services*.
Rewind time back when I first made the switch to Azure. If I had to make the decision again today, to choice from Virtual Machine or App Service - I wouldn’t change and thing.
The outages have not yet been formally resolved, but we are liaising with the Microsoft Azure team to trace and resolve the outages with App Services. I will be sure to provide updates as and when they arise.
If you are in the position of making a switch to Azure and need further advise, support, help, or just want to ask some questions, please do leave a comment or send me an email to firstname.lastname@example.org.
Disclaimer: The views and opinions expressed in this article are my own and do not necessarily reflect the official policy or position of Microsoft Corporation.
*No significant tests were carried out, I have judged this purely on Pingdom reports.
Towards the end of 2017, we kicked the SKOOLping landing page ideas and concepts into production. This involved the creation of the page website design within Photoshop, then reproducing into a functional working website,…