Multitenant Applications and the process of upgrading:

This is a continuation of the articles on multitenancy with the most recent one linked MultitenantApplicationsPart84.docx. This article focuses on synchronizing data between publishers and subscribers in a multitenant deployment.

Synchronization can occur in the following ways: 1) continuously, which is typical for transactional replication, 2) On demand, which is typical for merge replication. And 3) On a schedule, which is typical for snapshot replication. Replication happens by way of state or operations transfer which is like the well-known log shipping and mirroring options. State gets overwritten on the destinations whereas operations are re-executed on the destination.

When a subscription is synchronized, different processes occur based on the different types of replication. Snapshot synchronization is one where the Distribution Agent reapplies the snapshot at the Subscriber so that schema and data at the subscription database is consistent with the publication database. Modifications to data or schema when made at the publisher, require a new snapshot to be generated in order to be propagated. Transactional replication is one where the distribution agent transfers, updates, inserts, deletes and any other change from the distribution database to the subscriber. Merge replication is one where the merge agent uploads the changes from the subscriber to publisher and then downloads changes from the publisher to the subscriber. Conflicts are detected and resolved. Data is converged and the publisher and all subscribers eventually end up with the same data values. If conflicts were detected and resolved, work that was committed by some of the users is changed to resolve the conflict according to defined policies

Synchronizing a push subscription can be done on demand by connecting the source such as a publisher, a subscriber, or a monitor agent in the middle, to a tool that that can initiate the synchronization to the destination. Status of the synchronization is usually displayed and will show completed when done. A pull synchronization only happens from the subscriber side.

Synchronization can also be scheduled by defining a synchronization schedule that controls the replication agent will run. Distribution agents and merge agents can run continuously, run on demand and run on a schedule.

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

 

 

Multitenant Applications and the process of upgrading:

This is a continuation of the articles on multitenancy with the most recent one linked here. This article focuses on upgrading in a multitenant deployment.

Application upgrade and data upgrade are two different things. The data upgrade can be done even after the application has been upgraded. In this case, the old tenants are mounted on the server instance and then the data upgrade is performed.

Data conversion tools are usually provided to assist with the data upgrade process. In this case, the old data with the old version’s table and field structure is converted so that it can work with the new version’s table and field structure.

Before any upgrade occurs, a bunch of prerequisites must be met. Usually, the dry run of an upgrade can indicate potential issues. A tool like the upgrade advisor can assist with this discovery before the actual upgrade is performed. Prerequisites might include converting certain components in the older version, exporting permissions and permission sets from the old deployment, exporting encryption keys from the old deployment, preparing for transitioning, and installing multitenant application components.

The upgrade of the application code is not expected to break any of its functionality. In the multitenant mode, the application code is upgraded first, followed by creating a database on the new platform, then upgrading the application to the database and upgrading the data by mounting the tenant on the application database.

A tenant database can be prepared for data upgrade by first backing it up, followed by uninstalling the software components, and dismounting the tenant from the old server instance. When the data is upgraded on the tenant, it must be mounted on the server instance.

The tenant database might be different from the application database. In such cases, some synchronization is required. Synchronization can occur in the following ways: 1) continuously, which is typical for transactional replication, 2) On demand, which is typical for merge replication. And 3) On a schedule, which is typical for snapshot replication. Replication happens by way of state or operations transfer which is like the well-known log shipping and mirroring options. State gets overwritten on the destinations whereas operations are re-executed on the destination.

Post upgrade tasks include the importing of permission and permission sets, importing encryption keys, and uploading the customer license.

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

 Multitenancy and network virtualization (Continued):   

Some of the best practices for virtual network are universal design principles. For example, the address-spaces must be ensured to be non-overlapping. The subnets should not cover the entire address space of the virtual network. There must be fewer large virtual networks rather than smaller numerous ones. The virtual networks must be secured by assigning Network security groups to the subnets underlying the vNet.   

When a resource is hidden from the public internet, it eliminates a common attack vector. An application can connect to this resource over a fully private connection.  

There are three types of design patterns for private connectivity that are commonly used. These include: 

Connection from another service using an Azure Private Endpoint for inbound connectivity  
Connection over a virtual network integration  
Connection over an app service environment for hosting web application within an isolated environment.  

The use of a virtual network with a resource is merely to help with routing traffic otherwise there are no specific appliances installed. Other subnets and workloads could also run in this virtual network and they can access this resource without having to go over the internet. The use of a private link is to setup a private endpoint for the resource in the PrivateLinkSubnet of the virtual network. Any application will then connect to the resource through the PrivateLinkSubnet of the virtual network. The firewall for the resource will allow only the traffic coming through the PrivateLinkSubnet to connect making the resource inaccessible from the public internet. The difference between the use of a private endpoint versus a private link is that the private endpoint is used to privately connect to a resource irrespective of public access while the private link helps to hide the resource exclusively for private access.  

The App Service and private link subnets could also be in separate virtual networks, but they must be peered. The virtual network integration routes traffic from the consuming services only to the private addresses in the network while the DNS resolution still results in the resource’s public ip address. This can be overcome by adding an alias record or a name-record delegation in the parent domain. If the consuming services set their traffic to be “route all” through the virtual network integration then that can also forward traffic to the private ip address of the resource. Finally, with the help of a service endpoint strategy rather than a private endpoint strategy, the use of a private endpoint, PrivateLinkSubnet and Route All regional VNet integration setting become unnecessary. Only the vnet integration is needed. It differs from the private endpoint in that it is not for a specific resource instance but for the entire service. For example, if it were to apply to a SQL Server service, it would apply to all SQL Servers of all customers as opposed to a specific SQL server instance. 

Name resolution applies to virtual networks. The name resolution to an IP address depends on whether there is a single instance or many instances of the multitenant application. For example, a CNAME for the custom domain of a tenant might have a value pointing to a multi-part subdomain of the multitenant application solution provider. Since this provider might want to set up proper routing to multiple instances, they might have a CNAME record for subdomains of their individual instance to route to that instance. They will also have an A name record for that specific instance to point to the IP address of the provider’s domain name. This chain of records resolves the requests for the custom domain to the IP address of the instance within the multiple instances deployed by the provider.  

Validation of custom domains is a necessity for the tenants to be onboarded. Without validation, tenants might accidentally or maliciously park a domain name. Typos in custom domain names are encountered often. Parking leads to an error for others wanting to use their custom domain with the message that the domain name is already in use. Domain names especially within a self-service or automated process require a domain verification step. A CNAME record or a DNS TXT record might be added to reserve the domain name until the verification is completed. Private DNS domains as well as custom domain names are supported with private virtual networks.   

#codingexercise

Path of sum from root to leaf equals a given value in BST.

bool hasPathSum(Node root, int sum) 

{ 

if (root ==null) return sum == 0; 

int newsum = sum-root.data; 

if (newsum == 0 && root.left == null && root.right == null) return true; 

return hasPathSum(root.left, newsum) || hasPathSum(root.right, newsum); 

} 

 

Multitenancy and network virtualization:  

   

The previous article talked about Application Virtualization. Resources hosting the applications can also be partitioned into virtual networks. This article talks about network virtualization.

Virtual networks or vNets for short, are fundamental to locate resources such that they can securely communicate with each other, the internet, and on-premises networks. VNet is like a traditional network placed in a private datacenter but it brings additional benefits of scale, availability and isolation.

Communication between resources, communication of those resources with the internet and communication with on-premises resources, filtering network traffic, routing network traffic and integration with other cloud services are all made possible by virtual networks.

Outbound communication from resources to the internet is available by default. The inbound communication to a resource from the internet is achieved by assigning a public IP address or a public load balancer. Communication between resources can be achieved via a virtual network, a virtual network service endpoint and VNet peering. Communication with on-premises resources is achieved by Point-to-site virtual private network, Site-to-site VPN and Azure ExpressRoute. Network traffic can be filtered between subnets using either or both network security groups and network virtual appliances.

When these virtual networks are created in the cloud, the cloud providers automatically route traffic between the subnets, connected virtual networks, on-premises networks, and the internet by default. Overrides can be specified using the route tables and Border gateway protocol routes. Integrating cloud services to a virtual network enables private access to the service from virtual machines or compute resources in the virtual network by dedicating the services to a virtual network, using private link to access privately or by extending the virtual network to the service using a service endpoint. Service endpoint allows services resources to be secured to the virtual network.

There are limits to how many resources can be placed within a virtual network but there are options to increase those limits. Virtual network and subnets span all the availability zones in a region. Even if a resource is zonal, the virtual network does not need to be divided between the availability zones.

Network and storage are low-cost resources, but network administrators know that when they keep running out of IP addresses, these don’t seem to be true. The end-user might get a virtual network for free by requesting it from the cloud in a free tier but there are pricing applicable to premium tiers and SKUs.

Some of the best practices for virtual network are universal design principles. For example, the address-spaces must be ensured to be non-overlapping. The subnets should not cover the entire address space of the virtual network. There must be fewer large virtual networks rather than smaller numerous ones. The virtual networks must be secured by assigning Network security groups to the subnets underlying the vNet.

Name resolution applies to virtual networks. The name resolution to an IP address depends on whether there is a single instance or many instances of the multitenant application. For example, a CNAME for the custom domain of a tenant might have a value pointing to a multi-part subdomain of the multitenant application solution provider. Since this provider might want to set up proper routing to multiple instances, they might have a CNAME record for subdomains of their individual instance to route to that instance. They will also have an A name record for that specific instance to point to the IP address of the provider’s domain name. This chain of records resolves the requests for the custom domain to the IP address of the instance within the multiple instances deployed by the provider.

Validation of custom domains is a necessity for the tenants to be onboarded. Without validation, tenants might accidentally or maliciously park a domain name. Typos in custom domain names are encountered often. Parking leads to an error for others wanting to use their custom domain with the message that the domain name is already in use. Domain names especially within a self-service or automated process require a domain verification step. A CNAME record or a DNS TXT record might be added to reserve the domain name until the verification is completed. Private DNS domains as well as custom domain names are supported with private virtual networks. 

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

 

Multitenancy and application virtualization:

 

Application virtualization enables applications to be available to end-users and their computers without requiring direct installation. It is made possible through a process called sequencing the application, which enables each application to run in its own self-contained virtual environment on the client computer. The sequenced applications are isolated from one another, and they can continue to interact with the client computer.

 

There is a client made available to leverage application virtualization and lets the end users interact with the application once it has been published. The client manages the virtual environment in which the applications run. Publishing is the process by which the application is made available to the client computer. This process copies the virtual application icons and shortcuts to the computer as well as the package definition and the file type association to the computer. When the content is made available to the end user’s computer, it behaves as if it is installed locally.

 

The package content can also be copied locally into one or more Application virtualization servers so that it can be streamed down to the clients on demand and cached locally. File servers and web servers can also be used as streaming servers or copied directly to a destination computer as in the case of an electronic software distribution system. In a multi-server implementation, maintaining the package content, and keeping it up to date on all the streaming servers requires a comprehensive package management system. When the size of the organization is large and the number of client computers is large and geographically spread out, a comprehensive packaging and publishing helps. Managing the package to ensure that the applications are available and accessible to all users is important.

 

Multitenant solutions have often found a need for an application store to collect all the applications that can be used by their users on their tenant resources. Those users download the application after consent and purchase and then use it locally. This experience can be improved with the application virtualization without involving the user for unnecessary setup and cleanup operations.

One of the biggest appeals of using this technology is its potential to enable the rewriting of existing commercial software. Rewrites and making the software available in the cloud via an application store might sound unappetizing or less glamorous than a new groundbreaking product but it aligns with the drive towards pushing commoditization of technology deeper into the cloud. This calls for actions to go beyond the marketplace store to share applications as a slice is reserved for commitments from the public cloud provider in the form equivalent to enterprise blocks and application patterns for repurposed, streamlined, and optimized workflows with extensibility for cross-cloud integrations.