New Era: Cloud and Microsoft Azure PaaS

Welcome to moving your web app into Microsoft Azure cloud platform blog series. I will explain what it means (and takes) to move your existing website from traditional hosting model to Microsoft Azure Cloud. What I mean to traditional hosting is that whether you host your app on-premise or remote location where you can remote in and have full administrator privilege in DevOps environment, or you have a hosting plan from a service provider.

This is a practical, real-life walk-through for anyone who is thinking about moving into Microsoft Cloud. Throughout the series, I will cover the Azure platform, preparing your app for Microsoft Azure, provisioning, configuring and deploying your app to Azure, creating a test environment and deploying it directly from GitHub, migrating your database to Azure SQL Database service and finally monitoring and diagnostic your app with Microsoft Azure.

Overview

Here is the quick look what I will cover in this first part of Moving Your Web App Into Microsoft Azure Cloud Platform.

  • The new Cloud Era. What we have been doing, how it can be done better with Microsoft Azure?
  • What is the Microsoft Azure PaaS offering? Where is sits between other cloud options?

So, we have a lot to cover; let me jump right into it and briefly touch on what technical (and financial) benefits we would gain by moving to the cloud. This module will lay background information about Microsoft Azure cloud platform. Then I will continue the series with a preparation of our web app for Microsoft Azure.

New Cloud Era

If you are reading this series, you probably, have a good idea what the cloud is. I will not discuss the cloud deeply, but I'm hoping that you have a clear distinguishment in your mind between a hosting provider and real cloud provider such as Google Cloud, Amazon Web Services, IBM Cloud Computing and of course Microsoft Azure. Rather, I would like to start off how we used to do things compare to how we are going to do things in this new cloud era.

So let's look at the old practices that we have been mastered over the last 15-20 years versus the new practices in the cloud era.

Order Server vs. Provision Service

We would request a new shiny server, lots of memory, lots of CPU power, lots of hard drive space. Generally, far more resource than we need at the time of order. Because we convince ourselves that it's hard to upgrade the server when it's in production; it's better to setup once and forget it. Then the waiting game: weeks of waiting to get delivered the box. Tell the truth, it's very exciting to turn on a brand-new server box and to watch its lights start blinking. Then licensing: operating system, networking tools, database, anti-virus, firewall... The list goes on and on. What that means that we have invested a large chunk of capital to tomorrow's scale requirements today. So, we had to pay things before we actually needed them. Then tedious setup. Hours of hours software installation, updates, and settings then more updates and more settings. Are you following me?

Now, it's all about services. What we can turn on and use it as we need it for a fraction of the capital we would have committed when we order our server. We actually pay for what we need now. You will get more resource when you need it. Although it has been one of the biggest selling points for the cloud, as we discover more about the cloud, you will realize cloud is much more than just the cost of ownership.

Capacity Planning which Fails vs. Magic Scale Slider

Sometimes, we become more successful than what initially anticipated, or the company grows so quickly all the capacity planning of yesterday is not valid anymore. We need more, much more resources. So, we need to order a new server, do all those setups all over again, re-purpose the old server, explain what just happened to whom pays for the new server. All those commitments for the infrastructure must be reevaluated, and make even more commitment to a newer infrastructure. It may sound good problem to have it, but still, it's a problem to operation department needs to tackle.

What if we had a magical slider, we scale up as simple as moving a slider. Wouldn't life be more enjoyable? There is nothing actually magical, as we demand more, we ask cloud to give us more resource. That's one of the things that we will discover more on that as we progress.

Local Debugging vs. Remote Debugging

One of the biggest problems a developer can face is that the application is performing well on developers computer flawlessly while there are some issues on the production server. DevOps tried to tackle this problem having test servers which are a replica of the production servers. It means that double the management effort as well as double the infrastructure cost. Granted, I never make a purchase decision for a test server, since I always had an out-dated server sitting on storage room waiting for a re-purpose. But, managing the server doesn't go away: still needed to be install software, update the operating system and manage backups as detailed as production servers.

We used to debug the software locally, on the developer's computer, then deploy it to test server as humanly as possible to examine the application in the wild. If everything goes well, then we deploy to the production server. But still, things can go wrong in the target environment. As much as we replicate the test server as production, there is always something is not quite like the production. Sometimes licensing was an issue, at times resource or something happened to the test server it's not acting as production. Often, we ended up to try to debug the software on the production environment: tracing out messages on the server, sometimes turning off custom errors, try to RDP and see what is going on in the environment. All of that is tricky, time-consuming and certainly stressful.

In Microsoft Azure, debugging is simply feature; it's a first class citizen of the platform itself. We will see how much better debugging remotely on Azure than how you would do before.

Humans vs. Automation

In the old era, we also used to things very manually with people. Such things like, server management, app deployment, security compliance, database management: often very laborious often error-prone.

I will focus on automation throughout this blog series as much as possible and show how it can be done with ease. So you can ask, who is going to manage the server, operating system or database? Well, it's not going to be you, but Microsoft. At the end of the day, the money you pay is also included management of resource not only resources itself.

Microsoft Azure PaaS (Platform as a Service)

Before going into Visual Studio, I want to discuss little but about the platform (PaaS) that our web app is going to live in.

All of the component that makes the infrastructure which the software runs on it quite same. We still need networking, storage, server and virtualization on a hardware level. Do you remember the times we install operating system directly on the box without virtualization? Then we need an operating system, middleware, runtime and backups to put our application top of it. Cloud doesn't take away those tears in the stack. The difference is who is going to manage those.

On-Premise applications, you (your team or perhaps a contracted company) need to handle both hardware and software as well as your application and data within your on-premise. Naturally every responsibility on DevOps' shoulder. If a hardware fails you need to take care of it, if a new patch released you need to install it, if some hackers try to sneak in into your network you are responsible for defending it even it's the middle of the night...

IaaS (Infrastructure as a Service) may be a better option for many applications, this where to start to take away responsibilities of some components of the system. All the hardware and network level responsibilities transferred to IaaS provider and you can focus on only software. There are still physical servers somewhere in a data center, you just never see them yourselves. On top of that, they manage the virtualization tear. So you end up with is a logical operating system that you can remote into and operate just like you seating next to the server on-premise.

IaaS is a significant improvement, many application has already moved to IaaS and running flawlessly. However, you still need to deal with a lot of platform related things other than the application itself. Imagine; you want to launch an e-commerce website. You go Amazon (in fact, you can go any other real cloud provider including Microsoft or rent a VM from a hosting provider) and fire up a VM instance (with pre-installed shopping cart application), in minutes you are ready to start selling. Not so fast! You still need to take care of operating system updates, database creating, user management, SSL installation... It continues an effort to keep the server alive. The only difference is that you don't need to deal with network connections and hardware fails, but the rest is still on your shoulder. You are still the administrator with full privileges!

Then we move across to PaaS: Platform as a Service. Keep taken away the things you have to manage: so now only the app and data. Delegating the responsibility back to the cloud provider. Of course, it isn't just a Microsoft Azure concept, the same principles apply to any other true cloud offering. The beauty of PaaS is that you only worry about application and data. You don't have to do any support on the OS tear, or the middleware or the runtime. You don't even need to take a backup. Because all of them is part of the PaaS and the cloud provider (in this instance Microsoft) does that for you. Because they do on a vastly large number of servers and automation, they do it for you exceptionally cheaply.

There is more step further in a cloud model, that is SaaS: Software as a Service. I will not go details on that, but briefly you don't write your own software or managing your data. Everything is managed by SaaS provider, you use fully managed service by the service provider. Good examples of SaaS are Github.com, SalesForce or Google Gmail You don't know the actual code, you don't manage anything. You just configure it and use it.

There are a lot of changes ahead of us. A lot to take in, a lot to adjust. But they make life easy for software developers and information technology (IT) professionals. It's such better time to working today. From now on, I will focus excursively on moving traditional hosting (on-premise or IaaS) to Azure Web App and Azure SQL database -and of course both of those Microsoft Azure PaaS offerings.

Summary

One of the first things I discuss was how we have been doing things and how they would be different in the cloud platform. In this new cloud era, we really get to think more about what is it we need now, not what we would need tomorrow. We need to plan for it, code for it; because we are going to need and pay for it sometimes; but we don't need to pay it now. That is a really significant difference.

The other thing that I discuss is that PaaS: Platform as a Service. We are going to avoid creating an infrastructure. We are going to focus on coming modules fastest, cheapest and most efficient way running your web app on Azure that's using PaaS.

So let's get our app ready for Azure.