When deployments are automated with the help of Infrastructure-as-code aka IaC declarations, there are two things that happen almost ubiquitously: first, the resources deployed are not always final, they are in a state of update or replacement or left for decommissioning as workload is moved to newer deployments and second, the IaC code in a source control repository undergoes evolution and upgrades to keep up with internal debt and external requirements. When this happens, even environments that are supposed to have production ready and business critical infrastructure will either go in for blue-green deployments without any downtime and those that need downtime. Perhaps an example might explain this better. Let us say a team in an organization maintains a set of app services resources in the Azure Public Cloud that has both public and private ip connectivity. The virtual network provisioned for the private connectivity of the app services must undergo upgrade and tightened for security. Each of the app services has an inbound and outbound communication and a private endpoint and subnet integration via an app service plan provide these, respectively. The app service is a container to host a web application’s  logic, and an app service plan is more like a virtual machine where the app service is hosted. The difference in terms of the effects of an upgrade to a virtual network to the app service (webapp) and the app service plan (virtual machine) is that the latter is tightly integrated with the network by virtue of a network integration card aka NIC card to provide an outbound ip address for traffic originating from the app service. If the network changes, the nic card must be torn down and set up again. This forces replacement of the app service plan. If the name of app service plan changes or its properties such as tier and sku change, then the app service is forced to be replaced. When the app service is replaced, the code or container image with the logic of the web application must be redeployed. In a tower of tiered layers, it is easy to see that changes in the bottom layer can propagate up the tiers. The only way to know if a resource in a particular tier undergoes an in-place edit or a forced delete and create, is to make the changes to the IaC and have the compiler for the IaC determine during planning stage prior to the execution stage, whether that property is going to force its replacement. Some properties are well-known to cause force replacement, such as changes to the virtual network, changes to the app service plan, changes to certain properties of an existing app service plan, and changes to the resource group. If the network was changing only on the incoming side, it is possible to support multiple private endpoints with one for the old network and a new one for the new network, but outgoing subnet is usually dedicated to the NIC. Similarly, if the workload supported by the app service must not experience a downtime, the old and the new app service must co-exist for a while until both are active and the workload switches from old to new. At that point, the old one can be decommissioned. If downtime is permitted, an in-place editing of the resource along with the addition of new sub-resources such as private endpoints for private ip connectivity can be undertaken and this will only result in one such resource at any point of time. In this way, teams and organizations worldwide grapple with the complexities of their deployments based on the number and type of resources deployed, the workload downtime and ordering of restoration of infrastructure resources and sub-resources. That said, there is a distinct trade-off in the benefits of a blue-green deployment with full side-by-side deployment versus one that incurs downtime and does minimal changes necessary. 

#codingexercise

Problem: Rotate a n x n matrix by 90 degrees:

Solution: 

static void matrixRotate(int[][] A, int r0, int c0, int rt, int ct)

        {            

            if (r0 >= rt) return;

 

            if (c0 >= ct) return;

 

            var top = new int[ct-c0+1];

 

            int count = 0;

 

            for (int j = 0; j <= ct-c0; j++){

 

                  top[count] = A[0][j];

 

                  count++;

 

            }

 

            count--;

 

            for (int j = ct; j >= c0; j--)

 

            A[c0][j] = A[ct-j][0];

 

            for (int i = r0; i <= rt; i++)

 

            A[i][c0] = A[rt][i];

 

            for (int j = c0; j <= ct; j++)

 

            A[rt][j] = A[ct-j][ct];

 

            for (int i = rt; i >= r0; i--) {

 

                   A[i][ct] = top[count];

 

                   count--;

 

            }

 

            matrixRotate(A, r0+1, c0+1, rt-1, ct-1);

 

        }

 

 

 

// Before:

1 2 3

4 5 6

7 8 9

 

 

 

// After:

7 4 1

8 5 2

9 6 3

 

// Before

1 2

3 4

// After

3 1

4 2