Web App
Web apps are Microsoft cutting edge PAAS offering. Azure web apps abstracts the management of hardware and operating
system. It allows developers to focus on
the high value activities – delivering working solutions that solve business
problems.
How we got here
(briefly)
Our journey to fully
managed development environment began with virtualization. VMs allowed us to host several instances on
the same machine. VMs had their
limits, they still required considerable
resources to run which limited scalability.
Next came containers which are huge leap forward in hosting
environments. Light weight containers
when coupled with orchestration/governer engines like Kubernetes allow for
enterprise grade scalability. Still containers can be very complex and require
specialized skills to successfully create a properly scalable application.
Enter web apps, Microsoft’s fully managed platform as a
service. Web apps offer automated load
balanced scalability, auto patching,
monitoring, and backups. Leveraging
these capabilities allows a company to focus resources on the activities that
bring the most value to the
organization.
Walk through begins….
We are going to start with a simple application and over the
next several weeks we will deploy it to azure webapps and build it into a
secure globally hosted application using a wide range of azure
technologies. You can pull the start
application here.
Our Scenario.
As a global supplier of widgets we need a site hosted in the
cloud that will grow with our company. This
site will be used by our customers to order their widgets. Since the focus of our work is to examine
azure we will keep our site a simple MVC site with minimal styling.
Our first step is going to be to prepare a location to
deploy our site to in Azure. In order to
complete this walk through you will need a free azure account. You can find that here.
Once you have your account, login to your azure account and you’ll see a
dashboard like the one shown below.
As this is our first experience with azure, we will begin by
creating the least expensive app service.
In the search box at the top type “App” . This will bring up a filtered list that
allows us to select “App Services” .
Select app services from the list and then click on “Add” to bring up the dialog below.
Here we have a number of options to select from in creating
our service. I encourage you to explore
the configuration options here. However
as this is for our initial deploy, we
will focus on those that are required.
A brief overview of required properties we will setup for
our new service.
Subscription:
A subscription is
simply a way of grouping resources that will be billed together.
Resources Group:
A resource group is an
important consideration when setting up our service. Our resource group is not limited to a
certain type of resource. We can have
multiple types of resources in a single resources group for example we may have
azure sql database, redis cache, and load balancer in the same resource
group. A resources groups purpose is to
allow us to manage resource lifecycle, and policies. More on this later but for now create a
resource group name. It’s a good idea to
include the resource type in the name for example WidgetResourceGroupUSWest.
WebApp Name:
This is the name of
our instance. For now, create a name for
the site. I’m going to name mine WidgetSite.
The site will be created as part
of the .azurewebsites.net domain
so it will need to be a unique across that domain. We can create a regirstered domain name, but we will cover that later.
Publish:
Webapps support two
types of deployments. We can publish a
docker image or we can publish utilizing code. For our initial walkthrough we will be
publishing from a visual studio project so leave the default setting.
Runtime Stack:
Here we can see the
flexibility offered by azure webapps. In
this dropdown we can pick from a wide variety of available technology stacks. Much more than Microsoft centric, webapps support Java, Python, Node, PHP, Ruby,
as well as of course .NET core. As you can see Microsoft has worked very hard
to make webapps an open door to all developers.
For purposes of our walk-through
select .NET Core 2.2.
App Service Plan
Now we get into the
financial side of our hosted application.
Since we created a new resource group azure has created a name for our
app service plan for us. The next step
is to determine the size of the resource that we are going to create to host
our application. Azure selects us a
default production instance you can change this by clicking the “Change Size”
link. Below is the change size dialog as
of this writing.
Production level resources have the full suite of Webapps
functionality. We won’t cover everything
on this dialog on this post. The one
thing that we should mention here is Azure Compute Units (ACU’s). Azure Compute Units simplify the process of
comparing CPU performance for different instances. WebApps can run on specialized instances
configured for the type of workload. You
can read more about ACU’s and how to compare instances here.
For or initial walkthrough I’m going to select D1 from the
Dev/Test tab. You should note that you
are not locked into a selected instance size.
You can upgrade your instance at any time by changing the size in your
service’s configuration tab.
Once we’ve selected
the size of our instance, we are ready to move to the next part of our setup
“Monitoring”. WebApps have built in
monitoring called Application Insights. Application Insights are much more than a
log. We will cover them in another post. For now, turn on your application insights by
enabling them with the slider.
We are now ready to create our instance, click the create button on the bottom of the
form and Azure will begin provisioning our new WebApp. Once the process completes, you’ll see a
dialog shown below.
That’s it, we’ve
completed the first steps in setting up our app service.
In the next post we will setup our CI/CD pipeline to allow
our code to be deployed directly to our instance.
Comments
Post a Comment