How happy would you be if you get a chance to test your app in the same platform/environment as your production?

Azure slots does that for you. To be more precisely you get to test it in your production environment.

Azure App Services is one of the extremely useful service consisting of web apps, API Apps, web jobs etc. They provide a host of amazing features like scaling, backups, SSL support, custom domains to name a few. But azure deployment slot is one such feature which is often underrated & mostly under used.

Common Deployment issues:

Testing the new version of app

Consider you have a web app running in your app service & your app’s URL is something like Prodapp.azurewebsites.net & is already live. Now you have updated your web app & you want to deploy the new version to your production URL. Before that you need to test your app for correctness. One obvious way & the common practice prevailing is to create a new app service & deploy the new web app, port the configurations & test it over there.

Deploy/Rollback

Now you have tested your app and you are ready to deploy the app to your production URL. Now you will be publishing the app, which in turn would require a downtime for deployment, test & depending on the architecture of your app you may need to pay a cold start penalty too. And what if you want to rollback your deployment in case of an issue?

Deployment Slots to the RESCUE

Azure deployment slots helps you overcome all these issues. Consider deployment slots as different boxes inside your app service. Each slot will have its own publishing profile, its own configurations & app settings. The default slot(even if you don’t create one) as soon as you do a deployment to your app service is your production slot. You can create new slots to deploy a new version of your app.

Picture1

Here, if you want to test a new version of your app, create a new slot, get the publishing profile & deploy your new version over there. You now have a production ready version of your app, in the same environment as like production but with different URL, configurations & app settings. Depicted below is how your apps would have been deployed.

Picture2

Now comes the magic of a deployment slot: To move your new version of app to your production URL, you just can use the swap option. Swapping moves your app from the source slot to the destination slot. It moves the configurations & settings too.


Picture3

You have deployed your app to production with no downtime. Azure also warms up the slots before the swap & hence you don’t run in to cold start issues. In case you need a rollback, you do a swap again and that’s it!!

Considerations

Below are few points you need to consider before starting with deployment slots

  • Deployment slots are supported only in the Standard or Premium App Service plan mode
  • When your app has multiple slots, you cannot change the mode
  • Scaling is not available for non-production slots
  • Each App Service plan mode supports a different number of deployment slots
  • Each slot shares the same pool of resources as your live/production slot. So load test is not suggested here
  • Deployment slots have a different URL than the original App Service. This URL is based on the name you give the deployment slot
  • When you scale a deployment slot, you also scale all other slots of your App Service. This is because all slots share the same App Service Plan
Advertisements

Azure App Service is one of the common and most used service. When we straight away deploy apps, jobs etc., to the app service, one thing that confuses and that makes decision making hard is the multitude of the tiers(options of plans) available. I would be comparing the different tiers that Azure App Service and how each one differs and which one to choose considering your requirement.

First and foremost, every tier supports deploying multiple apps to the same tier at no extra cost but there is a limit on the number of applications based on the tier. So all your apps would share the resources allotted as part of the tier you choose. Let’s compare each of these tiers to see where they differ.

Free Tier

As the name says, this comes free of cost but with conditions

Configuration – Shared Core, 60 mins of CPU per day, 1 GB RAM, 1 GB storage

What you get – Deploy max of 10 apps, 10 Logic App Definitions, , 200 Logic App Actions per day, 500 Active mobile devices per day

What you don’t get – Instances, SLA (support), Auto Scale, Backups, SSL certificates, Staging Environment, custom domain

When to use –  Use this plan for PoC & development purposes. Production scenarios to be avoided for sure as you don’t have neither SSL nor a custom domain support

 

Shared Tier

This tier is charged based on per hour usage

Configuration –  Shared Core, 0.5 GB RAM, 1 GB storage

What you get – Deploy max of 100 apps, 10 Logic App Definitions, 200 Logic App Actions per day, 500 Active mobile devices per day, custom domain

What you don’t get – Instances, SLA (support), Auto Scale, Backups, SSL certificates, Staging Environment

When to use –  Though this tier is one level ahead of free tier, it’s suggested only for hosting basic apps where you don’t have any security or recovery options as this tier also doesn’t support SSL and also backups.

 

Basic Tier

This tier is charged based on per hour usage and the number of instances used

Configuration –  starts from 1 Core, 1.75 GB RAM, 10 GB storage

What you get – Deploy unlimited apps, 10 Logic App Definitions, 200 Logic App Actions per day,  Unlimited Active mobile devices per day, custom domain, Up to 3 Instances, Unlimited SNI SSL certs, 99.95% SLA

What you don’t get –  Auto Scale, Backups, Staging Environment

When to use –  This is the starting level tier for your production workloads. You get a dedicated instances & with 99.95% SLA, SSL support to put your apps to real work. With multiple instances you also get your app load balanced.

 

Standard Tier

This tier is charged based on per hour usage and the number of instances used

Configuration –  starts from 1 Core, 1.75 GB RAM, 50 GB storage

What you get –  Deploy unlimited apps, 25 Logic App Definitions, 10,000 Logic App Actions per day,  Unlimited Active mobile devices per day, custom domain, Up to 10 Instances, Unlimited SNI SSL certs & one IP SSL included, 99.95% SLA, Auto Scale, 2 Automated Backups per day, 5 staging environments

What you don’t get –  5 staging environment means 5 slots per deployed web app. But note that each slot shares the same pool of resources as your live app. So load test is not suggested here.

When to use –  This is a pure fit for your serious production apps with a IP based SSL support.

 

Premium Tier

This tier is charged based on per hour usage and the number of instances used

Configuration –  starts from 1 Core, 1.75 GB RAM, 250 GB storage

What you get –  Deploy unlimited apps, 100 Logic App Definitions, 50,000 Logic App Actions per day,  Unlimited Active mobile devices per day, custom domain, Up to 50 Instances, Unlimited SNI SSL certs & one IP SSL included, 99.95% SLA, Auto Scale, 50 Automated Backups per day, 20 staging environments,

This tier offers the best features & also provide you with access to dedicated App Service Environments (ASEs) that carve out private network space in Azure for just your Apps.

When to use –  As the name suggests, use this for your premium/high intensive apps

 

Considerations

As with any Azure service, app service too comes with some considerations that you need to be aware

  • Azure Logic Apps are available only to EA customers
  • 165 MB outbound network traffic included, additional outbound network bandwidth charged separately.
  • Premium service plan allows up to 50 computes instances (subject to availability) and 500 GB of disk space when using App Service Environments (ASE) and 20 compute instances and 250 GB storage when not using ASE.

 

* The features and plans gets updated regularly & hence this document can be referred for the basic understanding & for any specific feature details/capacity do refer azure plans documentation @https://azure.microsoft.com


This error popped up when I changed my service account for Search Service & the Search Host Controller Service as these services were using the farm admin account. Below are some of the solutions which provided were,

  • Removing the extra space at the end of ‘PSModulePath’ – This didn’t work for me
  • Adding proper permissions in the database – Which is perfectly fine already
  • Repair SharePoint under Control Panel – This is not going to be a good option

The solution was to provision the WSS usage application proxy. Use the below command to do the same.

$UP = Get-SPServiceApplicationProxy | where {$_.TypeName -like "Usage*"}
$UP.Provision()

2015 in review

Posted: December 30, 2015 in Uncategorized

The WordPress.com stats helper monkeys prepared a 2015 annual report for this blog.

Here's an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 94,000 times in 2015. If it were an exhibit at the Louvre Museum, it would take about 4 days for that many people to see it.

Click here to see the complete report.


The name “apps for SharePoint” is changing to “SharePoint Add-ins” & its official (https://msdn.microsoft.com/en-us/library/office/fp179904(v=office.15).aspx#Minor). Any references to the app with-in the SharePoint eco-system will now be termed as Add-in. This is not limited to SharePoint but also Office.

But why this change? Some reasons we get from experts,

  • Microsoft’s multi-platform support of Office client across the Windows/Mac, iOS, Android and Windows 10 environments ended terming the Office client as “apps”, and so having “apps” within “apps” was causing confusion
  • Microsoft received multiple feedback that “apps” weren’t working in the enterprise space who were building something that was valued at much more than a simple app.

The notion also needed to be consistent here with the name change across both Office & SharePoint for the Office Store perspective.

Whatever may be the reasons, we just need to update our pointers from Apps to Add-ins. Below is the table that might help you to do that.

Original name New name Applies to
apps for Office Office Add-ins Office
mail app for Outlook Outlook Add-in Office
app for Excel Excel Add-in Office
app for PowerPoint PowerPoint Add-in Office
app for Word Word Add-in Office
apps for SharePoint SharePoint Add-ins SharePoint
app part add-in part SharePoint
app web add-in web SharePoint
SharePoint App Model SharePoint Add-in Model SharePoint
SharePoint Hosted App SharePoint Hosted Add-in SharePoint
SharePoint Provider Hosted App SharePoint Provider Hosted Add-in SharePoint