This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses the use of Multitenancy and Azure Resource Manager in multitenant solutions. 

Azure Resource Management is the core management service for Azure. Every resource in Azure is created, managed, and eventually deleted through the resource manager.  A multitenant application may work with Resource Manager to dynamically provision resources for each tenant. There are also many features of Resource Manager that support Multitenancy. 

Infrastructure can be described as code. Resource Manager provides and honors resources templates as the language for describing infrastructure and the state that it must achieve.  

The Azure Resource Manager maintains tags, RBAC, ARM Templates, Locks, policies and activity logs for the resources and the create, update, delete of the resources are exposed via the CLI, PowerShell, HTTP request, and Azure Portal. It is the deployment and management service for Azure. Most services from Azure register ARM templates to provision their resources. The uniform format of this template serves well for the management layer.  
Azure templates are like formula, we can use it for dedicated purposes.  For example, we can have a quick start template for Linux Virtual machine. There is a growing community of 350 unique templates, 300 unique contributors and over 4500 visitors each day. A custom resource provider can extend the ARM API to include internal and external resources. It enables custom scenarios on top of existing Azure workflows. The ARM Templates can be customized for control and effect.  The contract between Azure and an endpoint is defined through a new resource named as the Microsoft.CustomProviders/resourceProviders. This implies there are three parts: the custom resource provider, endpoints and the custom resources. A custom resource is comprised of three fields: name, routingType and endpoint. ResourceTypes describe new custom resources. Supported http methods are PUT, DELETE and GET. Actions can be added to a custom resource or across all resources via Azure. The equivalent CRUD operation via PowerShell includes the New-AzCustomProvider cmdlet and the association with an endpoint is created via the New-AzCustomProviderAssociation.  
  

Just like with any actions surrounding Azure resources via the Azure Resource Manager templates, a resource must be added to the extension resource template at a proper scope such as resource group, subscription, management group and tenant. For example, resource createRgLock ‘Microsoft.Authorization/locks@2016-09-01' can be declared to add a lock at the resource group level. A lock prevents actions that can usually be taken on a resource with the provision for overrides. This is sometimes necessary when authoring policies surrounding resources.  

A ‘scope’ property allows an extension resource to target another resource. It specifies the resource to which this extension applies. It is a root property of the extension resource. An extension resource is for custom actions around the resource that are not generally available from the resource. It is different from a child resource.  

A child resource exists only within the context of another resource. Each parent resource can accept only certain resource types as child resource types. For example, where we can refer to resource symbolicname 'Microsoft.Compute/virtualMachineScaleSets/extensions@2021-04-01' only within the context of virtual machine scale sets and not without VMSS. The hierarchy of parent-child resource types are already registered before they can be used. An extension resource can extend the capabilities of another resource.  

Resources and their extensions can be written only in Bicep and ARM templates. Bicep provides more concise syntax and improved type safety, but they compile to ARM templates which is the de facto standard to declare and use Azure resources and supported by the unified Azure Resource Manager. Bicep is a new domain-specific language that was recently developed for authoring ARM templates by using an easier syntax. You can use either template format for your ARM templates and resource deployments. Bicep is typically used for deployments to Azure. It is a new deployment-specific language that was recently developed. Either or both JSON and Bicep can be used to author ARM templates and while JSON is ubiquitous, Bicep can only be used with Resource Manager Templates. In fact, Bicep has tooling that converts Bicep templates into standard Json Templates for ARM Resources by a process called transpilation. This conversion happens automatically but it can also be manually invoked.  

The Azure Resource Manager not only offers a standardized ARM template, but also provides a consistent management layer. When users send a request from any of the Azure Tools, APIs or SDKs, the resource manager receives the request. It authenticates and authorizes the request. The resource manager sends the request to the Azure service. With this framework, the Azure Resource manager can manage the infrastructure through declarative templates, manage and monitor all the resources for a solution, redeploy a solution throughout the development lifecycle and with a consistent state, define the dependencies between the resources so that they are deployed in the correct order, apply access control to all services because Azure role-based access control is natively integrated into the management platform, apply tags to resources to organize them, and group resources by the same tag to help with billing and cost management.     

 

 

 

 

 

 

 

 

 This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses the architectural approaches for Identity in multitenant solutions.      

Identity systems vary in flavor and size depending on the methods of authentication and authorization that they support. Not all Identity systems have the same capabilities. Multitenant solutions introduce sharing which brings a higher density of tenants to infrastructure and reduce the operational cost and management. Unlike compute or storage, isolation model can be as granular as the users.  

Scaling resources helps meet the changing demand from the growing number of tenants and the increase in the amount of traffic. We might need to increase the capacity of the resources to maintain an acceptable performance rate. For example, if a single AAD instance is provisioned for all the tenants and the user belongs to more than 500 Azure AD tenants or creates more than 200 directories, the AAD instance will reject the application’s requests and all the tenants will be impacted. There are many service limits and quotas to be considered.  There cannot be more than 5000 domain names. If the domains are federated with an on-premises Active Directory, there cannot be more than 2500 domain names in each tenant. A maximum of 50,000 Azure AD resources can be created in a single-tenant by users of the AAD free edition. If there is at least one verified domain, the default AD service quota is extended to 300,000 Azure AD resources. A non-admin can create no more than 250 Azure AD resources. A maximum of 100 users and service principals can be the owners of a single application. There can be up to a maximum of 1500 app role assignments for a single user, group or service principal. Azure AD supports group nesting and group membership claims. A single application proxy is allowed a maximum of 500 transactions per second. 

The authentication process involves several aspects such as Federation, Single sign-on and sign-in risk evaluation, Impersonation, etc. Authorization can be done either in the identity provider or in the application. It might involve adding tenant identity and role information to tokens or leveraging application-based authorization. Azure AD or Azure AD B2C can be used with the multitenant application.  

Federation is particularly helpful to special logins from diverse identity providers such as those from social engineering applications and Tenant-specific directories such that the application’s IDP can be used to federate with the Tenant’s own identity providers. Single sign-on experiences enable users to switch between applications seamlessly without requiring reauthentication. A multi-tenant application may choose to provide single-sign-on for users who are part of different tenants so that work with isolated data of different tenants without requiring to reauthenticate. Multi-factor authentications that mitigate Sign-in risks might be applied conditionally to participating tenants who might have different risk policies. It can also depend on the multitenant solution provider that offers restrictive sign-in policies as part of a higher pricing tier of their service. Impersonation is user-specific and enables one user to assume the identity of another user without requiring their credentials. This is usually an advanced technique fraught with danger and difficulty to implement and control. In some scenarios, impersonation is a requirement, and the multitenant solution provider must log both identities for troubleshooting. 

Authorization data can be stored in several places. If the Azure AD is the identity provider, app roles and groups can be leveraged for authorization and the application uses the associated token claims to enforce the authorization rules. A common approach for authorization involves embedding a tenant identifier claim into a token. This enables the application to inspect the claim and verify the tenant access for the user. If role-based access control is available, the role information could also be embedded into the token.  Another option is to store the authorization logic entirely in the application so that there is better customization with fine-grained controls for role-based or resource-level authorization. This calls for the identity system to be made agnostic to tenant-identifiers and roles. Even the tokens do not have tenant identifier claims. A separate registry contains user-to-tenant mappings. The application tier can verify whether the specified user should be allowed to access the data for a specific tenant by looking up that list. 

  

  

 

This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses the architectural approaches for Identity in multitenant solutions.     

Identity services like storage services are hetereogenous in their constitution. Identity systems vary in flavor and size depending on the methods of authentication and authorization that they support. Not all Identity systems have the same capabilities. Multitenant solutions introduce sharing which brings a higher density of tenants to infrastructure and reduce the operational cost and management. Unlike compute or storage, isolation model can be as granular as the users. Services that limit the number of users supported in a single multi-tenant instance must all rely on Azure Active Directory. Different users even in the same solution might have different throughput requirements. Throughput refers to the total bytes transferred in unit time and can be affected by both the number of messages as well as the size of messages. 

When these Identity resources are shared, their isolation model, impact to scaling performance, state management and security of the Identity resources become complex. These key decisions for planning a multitenant Identity solution are discussed below.    

Scaling resources helps meet the changing demand from the growing number of tenants and the increase in the amount of traffic. We might need to increase the capacity of the resources to maintain an acceptable performance rate. For example, if a single AAD instance is provisioned for all the tenants and the user belongs to more than 500 Azure AD tenants or creates more than 200 directories, the AAD instance will reject the application’s requests and all the tenants will be impacted. There are many service limits and quotas to be considered.  There cannot be more than 5000 domain names. If the domains are federated with an on-premises Active Directory, there cannot be more than 2500 domain names in each tenant. A maximum of 50,000 Azure AD resources can be created in a single tenant by users of the AAD free edition. If there is at least one verified domain, the default AD service quota is extended to 300,000 Azure AD resources. A non-admin can create no more than 250 Azure AD resources. A maximum of  100 users and service principals can be the owners of a single application. There can be upto a maximum of 1500 app role assignments for a single user, group or service principal. Azure AD supports group nesting and group membership claims. A single application proxy is allowed a maximum of 500 transactions per second.

Authentication process involves several aspects such as Federation, Single sign-on and sign-in risk evaluation, Impersonation etc. Authorization can be done either in the identity provider or in the application. It might involve adding tenant identity and role information to tokens or leverage application based authorization. Azure AD or Azure AD B2C can be used with the multitenant application.

Federation is particularly helpful to special logins from diverse identity providers such as those from social engineering applications and Tenant-specific directories such that the application’s IDP can be used to federate with the Tenant’s own identity providers. Single sign-on experiences enable users to switch between applications seamlessly without requiring reauthentication. A multi-tenant application may choose to provide single-sign on for users who are part of different tenants so that work with isolated data of different tenants without requiring to reauthenticate. Multi-factor authentications that mitigate Sign-in risks might be applied conditionally to participating tenants who might have different risk policies. It can also depend on the multitenant solution provider that offers restrictive sign-in policies as part of a higher pricing tier of their service. Impersonation is user-specific and enables one user to assume the identity of another user without requiring their credentials. This is usually an advanced technique fraught with danger and difficulty to implement and control. In some scenarios, impersonation is a requirement and the multitenant solution provider must log both identities for troubleshooting.

Reference: Multitenancy: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=fBoKcN         

 

 This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses the architectural approaches for storage in multitenant solutions.   

Storage services involve a variety of storage resources such as commodity disks, local storage, remote network shares, blobs, tables, queues, database resources, and specialized resources like cold tier and archival. Multitenant solutions introduce sharing which brings a higher density of tenants to infrastructure and reduce the operational cost and management. Unlike compute, data can leak, egress or remain vulnerable in both transit and rest, therefore isolation model is even more important. 

When these storage resources are shared, isolation model, impact to scaling performance, state management and security of the storage resources become complex. These key decisions for planning a multitenant storage solution are discussed below.  

Scaling of resources helps meet the changing demand from the growing number of tenants and the increase in the amount of traffic. We might need to increase the capacity of the resources to maintain an acceptable performance rate. For example, if a single storage account is provisioned for all the tenants and the traffic exceeds the specific number of storage operations per second, the Azure storage will reject the application’s requests and all the tenants will be impacted. When additional storage is provisioned or rate limit is adjusted, the multitenant solution can perform retries to overcome the transient failures from requests. When the number of active users reduces or there is a decrease in the traffic, the storage resources could be released to reduce costs. When the resources are dedicated to a tenant, they can be independently scaled to meet the tenants’ demands. This is the simplest solution but it requires a minimum number of resources per tenant. A shared scaling of resources in the platform implies all the tenants will be affected. They will also suffer when the scale is insufficient to handle their overall load. If a single tenant uses a disproportionate amount of the resources available in the system, it leads to a well-known problem called the noisy neighbor antipattern. When the resource usage increases above the total capacity from the peak load of the tenants involved, failures occur which are not specific to a tenant and impact the performance of those tenants. The total capacity can also be exceeded when the individual usages are small but the number of tenants increase dramatically. Performance problems often remain undetected until an application is under load.  A load testing preview can help analyze the behavior of the application under stress. Scaling horizontally or vertically helps correct the correlated application behavior.  

Data isolation depends on the data storage provider. When the CosmosDB is used for instance, separate containers are deployed for each tenant and databases and accounts can be shared between tenants. When Azure Storage is used, either the container or the account could be separated per tenant. When a shared storage management system such as a relational store is used, separate tables or even separate databases can be used for each tenant. Finally, storage resources can be provisioned within a single subscription or separated into one per tenant. 

Varying levels and scope of sharing of storage resources demands simplicity from the architecture of the multitenant application to store and access data with little expertise. A particular concern for multitenant solution is the level of customization to be supported. 

Patterns such as the use of the deployment stamp pattern, the storage resource consolidation pattern and the dedicated storage resources per tenant pattern help to optimize the operational cost and management with little or no impact to the usages.  

Reference: Multitenancy: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=fBoKcN       

 

The how of happiness – a new approach to getting the life you want by Sonia Lyubomirsky

Sonja Lyubomirsky is a psychology professor at the University of California and the winner of the Templeton Positive Psychology Prize

Singer Bobby McFerrin released a hit song in 1988 titled “Don’t worry, be happy” which was perky and happy and spread across the globe. It seemed to have an uncanny success in lifting people’s mood and appealing to audience everywhere. The lyrics said something like “In your life expect some trouble, When you worry you make it double, don’t worry, be happy. Be happy now”.

That is a recommendation if only that were easy to achieve so the author carries us through a plan with considerable focus and effort to realize it. She gives some gems of advice and explains why they work. Just follow through with it.

These include:

Happiness is a state of mind.

Ultimately, your happiness is not conditioned by life’s external circumstances whether you realize it or not.

Some people are more disposed to happiness than others.

Anyone except for the clinically depressed, can be happy if they choose to be.

Most happy people share the same “happiness habits”

To be happy, establish new happiness habits for yourself.

Establishing such habits requires dedicated effort and hard work.

There are “happiness exercises” that can be practiced daily.

These exercises include being joyful about life, feeling grateful for what we have and always living in the moment.

Some exercises work better than others depending on people’s personalities, lifestyles and attributes.

To quote the author, “You can be happy, even if you aren’t wealthy, thin, beautiful, admired by your peers or a lottery winner”. External circumstances don’t determine true happiness. Instead, it depends on attitude towards life. If you are positive, you will be likely to be happy.

The fountain of happiness can be found in how you behave, what you think and what goals you set every day of your life.

Genes also have to do with happiness. Some people are born with “set points” who feel more satisfied than others and more content. Others just need to aim higher with more endeavor and commitment because you can’t change your genes.

Statistics show that “set points” only account for 50% of overall happiness. Another 10% is determined by life circumstances whether they are rich or poor, healthy or unhealthy, fat or thin, loved or unloved, lucky or unlucky – and individuals directly control the remaining 40%.

There is consistency to the dataset. Happy people are all alike. Every unhappy person is unhappy in his or her own way.

Sometimes it requires changing thinking or behavior and there is conscious choice involved. Happiness can be induced using basic, scientifically proven concepts and it involves a great deal of effort.

The author is candid to admit that some individuals continue to feel grossly unhappy despite their admirable efforts to follow this practice but those individuals require therapeutic intervention. For the vast majority of others, we can choose those exercises that can help us improve our mood and feel happier.

There is a saying attributed to Talmud that says, “If I am not for myself, who will be for me? If I am only for myself, what am I? And if not now, when?”

We must leverage our strengths. If we are naturally competitive, we should engage in a sport or physical activity where we can excel and feel happier and better about ourselves. If we are stressed, taking time to count our blessings may be all we need.

The author lists twelve activities of happiness:

1.       Be grateful – this is a powerful antidote to negativity and people who appreciate things feel a strong sense of satisfaction and are more optimistic.

2.       Stay optimistic – Pessimism is about viewing everything through a dark lens. Optimism is about feeling energized and being more goal oriented.

3.       Don’t overthink – if we worry constantly about problems, we will feel bad, sad and depressed. Switch to focusing on something enjoyable like movie or exercise.

4.       Be kind – Kindness is an ultimate secret where we feel good and eliminate negative feelings including guilt and emotional distress. We turbo charge a positive attitude

5.       Become social – Barbara Streisand sang a song about “people who need people” as the “luckiest people in the world”.

6.       Learn to cope – “Stress is universal” and it can arise from a number of problems but coping with stress is about focusing on solutions. Take things step by step.

7.       Forgive others – Forgive and forget is an adage that goes a long way to be happy. It only hurts to hold anger, resentment and hostility – both emotionally and physically.

8.       Seize the moment – Neither living in the past nor living in the future will matter. The present really is all that we have.  The present way to be in the present is to focus on the current activities. Don’t waste a minute.

9.       Be joyful – when we savor life and enjoy every minute, even the roses smell better. 

10.   Become goal oriented – People who strongly commit to goals commit to life. The choice of goals need to be sensible, achievable and truly fulfilling.

11.   Become spiritual – Research indicates that religious people are much happier than non-religious people. They are also in better health, cope more effectively with disease and trauma and even get a degree of above average motivation.

12.   Stay physically and mentally fit – Meditation represents the “cultivation of attention”. A period of meditation is patient, non-striving time when we let things go, detach from standard thinking and stop making customary judgements about everything. Exercise is the other aspect that makes us feel good and smile more.

One of the hard-learned lessons is that happiness is not fleeting. It increases the chances of becoming permanently happy when we follow the twelve strategies constantly.

Stay positive despite what comes at you because most disappointments are rare and there is an abundance of things to be happy about.

Pay attention to timing and variety of experience. The twelve positive actions can greatly boost the happiness but choose which portions to apply daily

Build a support system – Do not hesitate to try hard everyday to be happy. Friends, family and members can help.

Commit to goals – Swimmers cannot be great at their sport without regular practice. This is equally true for achieiving happiness.

Habits – Happiness activities must be performed habitually.  Repetition and constant practice only improves it.

Everyone’s goals should be to turn positive thinking and behavior strategies into habits. It is not appropriate to go through life being unhappy and while it requires conscious effort and strong determination, the commitment will help make one a happy person.