+40 256 706 057 [email protected]

Mihai Tataran General Manager & Partner | Microsoft Regional Director, Azure MVP

Before we begin

This is a continuation of the first article in the “Cloud Strategy for Your Organization” series and focuses on another of the steps we usually take with our customers who migrate to the Cloud.

Click on the image to enlarge

Some of the considerations described in the “Lift and Shift to the Cloud” article apply to PaaS migrations as well, even though they are more focused on general Lift-and-Shift scenarios.

Here we will focus more on the most important architectural decisions one has to make when either migrating an application to Azure PaaS, or creating a new application for Azure PaaS.

Why PaaS?

A very short explanation of why PaaS vs IaaS can be found in the article referenced above. But, to give more details, here is why having applications run in PaaS is better than in Infrastructure as a Service:

  • You don’t need to manage and support Virtual Machines. You simply use services provided by Azure.
  • Better Disaster Recovery mechanisms, since all these services in Azure already have DR incorporated by design.
  • Higher availability. The typical PaaS service uptime in Azure is 99.99%, reaching 99.999% in some cases.
  • Lower cost with Azure: PaaS services are usually cheaper than their equivalent in IaaS (which would be VMs running a piece of software).
  • Access to technology: access to Artificial Intelligence, Machine Learning, Big Data.

Watch a video (in Romanian) where Mihai talks about the cloud strategy and migrating workloads in PaaS, as a follow-up to this article.



Options and more options

The great thing about the Cloud in general and Microsoft Azure, in particular, is that it provides many options for everything you want to achieve. For example, there are at least 4-5 options to host an application or run code in Azure PaaS: Cloud Services, App Service, Service Fabric, Functions, Logic Apps, etc. What is great with many options is that you have very granular features designed for very specific needs, but the penalty is that you really need to understand them very well, otherwise you might make very bad architectural decisions with costly consequences down the line.

From the architecture perspective, there are at least two major design decisions you need to make:

  1. What kind of architecture does my application have (if it is an existing application and I just need to migrate it to Azure), or what kind of architecture does my application need.
  2. What is the best Azure PaaS option for my application to run on.

Architecture style

Here are some typical architecture styles for Cloud applications:

The first thing you need to do is make sure you understand in what major category does your application fall into.

Decision time

And now you must decide upon which Azure PaaS service to primarily use for your application, depending of course on the architecture style it needs and other business criteria. Here is a great chart which describes a decision tree for this phase:

Migrating to or designing new applications for Azure PaaS has tremendous advantages, but it also means we need to think differently.

Other architectural decisions

There are many other aspects you need to decide upon and here are just a few examples.

Multi-tenant applications

Let’s say your application is multi-tenant, meaning you have more than 1 customer accessing your application. Each customer might access your solution via a specific URL (e.g.: https://customer1.application.com, https://customer2.application.com, etc.), or it might simply be the same URL for everyone.

The first question we need to ask is if it makes sense or not to have a single deployment for all customers or not, considering the simplified scenario that all customers have the exact same version of the application (the same code base). The right-hand side of the picture describes a single deployment for all customers.

Here is why it seems logical to do it: you only must maintain one single application, one version of deployment, for all customers. It appears to be cheaper, easier, straightforward! Or is it?

Here is another way to look at it: what if you have different customers with different expectations regarding uptime and performance? What if, to make it simple, you have some Free / Basic customers (who don’t pay for your solution) and you have some Premium customers (who pay and expect a high quality of service – QoS)? Obviously, if you have one deployment for all customers, in order to offer the QoS needed for Premium customers you end up offering it to everyone. And maybe 80% of resources’ needs come from the Free customers.

So, a more pragmatic approach is to consider the non-functional aspects of your solution, the QoS needed by different categories of customers, and maybe it makes more sense to separate them into different deployments by category. One deployment for Free / Basic customers, one deployment for Premium customers. And then you can allocate more resources only for Premium customers, you can configure that solution to autoscale, etc.

Transient faults

If you start using PaaS functionalities – like SQL Database, Storage, Service Bus, etc. – you need to understand a basic concept: they are offered from a shared environment, and that can cause some unexpected behaviors sometimes. We call these situations “transient faults”, errors which happen because of the environment where our service resides, they have nothing to do with our code, and they will automatically disappear. A specific example of a transient fault is: when another Azure customer using SQL Database from the same physical infrastructure as our SQL Database service, is triggering a query which brings (momentarily) the CPU to 100% – in this case, for a very short time, our queries or commands to our SQL Database will result in a SQL error. The Azure Fabric, of course, resolves the problem very fast, but there is a short time window within which we can have errors which have nothing to do with our application but the environment.

What you must do is design your application code for such events, meaning the code should expect some types of errors or exceptions, which clearly identify transient faults, and act accordingly. One way to tackle this situation is a pattern called Retry Policy, and there is already a framework created for it, called Transient Fault Handling Application Block.


Migrating to or designing new applications for Azure PaaS has tremendous advantages, but it also means we need to think differently: we must understand the Azure services better, what they do and what are their limitations, and in the case of applications’ migration we need to rearchitect or change some small parts of the code.

If you are interested to explore more on this topic, Mihai talks about the cloud strategy and migrating workloads in PaaS in a video available here.


Mihai TATARAN, Microsoft Azure MVP, is the General Manager of Avaelgo, and Microsoft Regional Director, Microsoft MVP on Microsoft Azure, Microsoft Azure Insider, and Microsoft Certified Professional. Mihai has been teaching Microsoft technologies courses to software companies in Romania and abroad, being invited by Microsoft Romania to deliver many such trainings for their customers. Mihai has very good experience with large audiences at international conferences: DevReach in Bulgaria, Codecamp Macedonia; TechEd North America 2011, 2012 and 2013 – speaker and Technical Learning Center (Ask the Experts), Windows AzureConf. He is also the co-organizer for the ITCamp conference in Romania.

Get exclusive offers and the latest updates on our upcoming events

You have Successfully Subscribed!

Pin It on Pinterest

Share This