Application Modernization

One of the Gartner Reports for Information Technology called out the paths to adopting the public cloud as one of Five R’s – Rehost, Refactor, Rearchitect, Rebuild and Retire. Many Solution Architects would tend to agree with such separate workstreams for the progression from assessment through deployment and finally release of the cloud hosted applications. But while the analysts and even customers tend to focus on one approach, the Solution architects often see many paths and even involving intermediary steps between the start and the finish.  While they fine tune the path by optimizing several parameters and often on a case-by-case basis, they generally agree with the break-out of these definitions.

Rehosting is a recommendation to change the infrastructure configuration of the application in order to “Lift and Shift” it to the cloud using Infrastructure-as-a-service.

Refactor is a recommendation to perform modest modifications of the application code without changing the architecture or functionality so that it can be migrated to the cloud in a container using Container-as-a-service or using Platform-as-a-service.

Rearchitect is a recommendation to dramatically modify the application code thereby altering the architecture to improve the health of the application and enable it to be migrated to the cloud using Platform-as-a-service or deployed serverless using Function-as-a-service.

Rebuild is a recommendation to discard the code of the application and develop it again in the cloud using Platform-as-a-service or serverless Function-as-a-service.

Retire is a recommendation to discard the application altogether or potentially replace it with a commercial software-as-a-service alternative.

All of the recommendations above can be made on an application-by-application basis but must be elaborated with additional information such as the Lines of code analyzed, the number of files read, a score or ranking, the total number of full-time employees required, a quantitative assessment for cloud readiness, the number of roadblocks encountered, the estimated effort, Operations and Business Support system dedication, the SR, SA, and SE assessments, and tentative dates for the release.

As you can see, this process can be quite intensive and repeating it for dozens of legacy applications can be quite tedious. Coming up with a table for the results of the rigor across all these applications and for a dashboard to represent the insights via canned queries can easily become error prone. Fortunately, some trail and documentation are maintained as this analysis is conducted and there are quite a few tools that can help with the visualization of the data even as the data is incrementally added to the dataset. An end-to-end automation that can help with detailed analysis, drill downs and articulated charts and graphs is possible if those applications were merely scanned by their source. Indeed, a rapid scan of a portfolio of applications can be a great start in the roadmap that requires us to assess, mobilize, migrate and modernize but iterations will remain inevitable and even desirable as they help towards optimizing continuously.

 

Zero Cost for IT Cloud Automation and managed services:

Introduction: Analogies from open source total cost of ownership aka TCO are directly applicable to the inventory of an IT provider in any organization. Costs such as acquisitions, operations and personnel are not only amplified at the cloud level for an IT provider but also incur increased workflow automations and complexity costs. While the TCO was coined around the era of war between managed software and open source, it continues to draw parallels and hold as much relevance in the new IT world dominated by public and private cloud inventories. In this writeup, we review some of these in detail.

 

Description: An IT Organization provider has the following costs:

Costs of resource instances – Today we rely more and more on virtual and shared resources and additionally we now have more granular and fragmented resources as containers, virtual networks and migratory applications and services. There is no longer a concept of ownership as much as there is weak reference established via tenancy. 

Cost of operations and services: Erstwhile notions of patch management, backup and security no longer apply on a periodic assessment basis and instances are more short-lived than ever. Furthermore, management of resources is now done via dedicated agents and central command that transcend cloud and on-premise boundaries. The running of these services is now no longer triggered as much as they are serviced automatically via alerts and notifications.

Cost of manpower: With increased complexity of cloud computing, there is more manpower needed than before. This runs contrary to the general belief that the cloud services are self-serve and increasingly automated.

 

Detail: We reduce the cost in each of these categories above.

Today as private cloud customers request compute and storage, we slap on self-service automation and maintenance workflows by default so that the resources get leased and serviced in a routine manner. However, these workflows are all utilizing existing infrastructure that have either come to end of life or have not kept up with the pace of things in the public cloud. Moreover, the discrepancy between the services offered in a private cloud and those offered in public cloud only grows with emphasis on legacy tools and platforms. Take examples such as infoblox, zabbix etc for our network address and monitoring utilities and the evidence becomes clearer. If we rely on static ip addressing versus dhcp, we may have workflows and automations in place that build up on these services in layers and each addition is costly because the foundation is not right. There is no evidence of using static ip addressing as the primary mode of address assignment in the public cloud. Furthermore, the public cloud is thought through in how it will scale on many fronts whereas private cloud groans to scale because of the bottlenecks in how these products scale to cloud loads.  Monitoring with clunky products like Zabbix is another example of why a UI-CLI-SDK masquerading product is nowhere compared to the services at the cloud scale such as AWS CloudWatch or Azure Monitor. Automations and scripts are relatively inexpensive compared to products but misguided automation and incorrect emphasis only leads to more and more technical debt that may not only weigh down the capabilities at some point but also sink the offerings if the users find the ubiquity and norm of cloud computing more appealing. This write-up does not belabor the point that betting against the public cloud is foolish and instead draws attention to the investments being made in the short term on the private cloud versus the on boarding for the public cloud. We will look at these differences in investment and come up with an onboarding strategy for public cloud in a separate section but right now we just make the case that the differences in the technology stack on private cloud versus their comparables in the public cloud should be few. For the sake of clarity, we refrain from a discussion on hybrid cloud because the state of affairs in a private cloud is focus worthy to take precedence in this discussion and the differences are much better called out between private and public rather than hybrid and anything else.

Moreover, our workflows are not that simple. We repackage existing functionalities from out of box providers that are largely on-premise in their deployments with sometimes a false claim for being cloud enabled.  There is a reason why there are no third party applications and appliances put into the mix of resources or services available from a public cloud provider. With a native stack and homogeneous resources, the public cloud can clone regions and avoid significant costs and labor associated with external purchases, maintenance, relicensing and support tools. These public clouds are betting on people and their deliverables to grow and expand their capabilities with very little dependencies or churn thrown their way. Naturally the number and type of services have significantly grown in the public cloud.

The technology stack from private cloud must not be recreating services from scratch at par with the public cloud but should be designed with fit over public cloud services in the first place before extending to the legacy hardware and private cloud infrastructure. Infrastructure as a service and platform as a service must be differentiated. Today we go to either based on whether we are requesting resource or whether we are requesting software stacks. I believe the right choice should be to differentiate the offerings based on usage requests. For example, managed clusters with marathon stacks should come from IaaS and programming stack for deploying applications should come from PaaS. In the former case, we can rely on cloud computing resources from public cloud.

Some private cloud offerings are hesitant to let go of resources and usages because they cite that the equivalent is not available in public cloud. For example, they say the flavors for operating system and the images offered from private cloud are not available the same in public cloud. In such cases, the private cloud has the advantage that it can offer better variations and customized flavors for the customer. In addition, the machines can also be joined to domain.

This sort of reasoning is fallacious. There are two reasons for it. First if the customers cannot do with public cloud offerings, then they are definitely digging themselves into a rut from which they will find it difficult to climb out later. A private cloud is offered not merely because it offers an alternative in the portfolio of cloud based investments but more so that the stack is completely managed by the organization. As such this ownership based slice must be a smaller percentage than the leased public cloud investments.  The second reason is that the private cloud does not come homogenous. It is based on either Openstack or VMware based stacks and the tools and services are separate for each. There are very few features from private cloud that make use of both equally.

The differences between private cloud and public cloud also come with existing and legacy inventory both of which have their own set of limitations that require more workarounds and workflow rework that cost significantly to make and operate. The rollover and upgrade from existing to new resources are somewhat more drawn out with the age of the systems as applications written at the time or customers using those resources may not move quickly or as nimbly as the new ones being written and deployed on say PaaS. Customers are slow to respond to take actions on their compute resources when notified by emails and a link to self-help. 

As a use case, take the example of co-ordination software such as chef, puppet, ansible, salt, BladeLogic to manage all the systems whether on-premise or in the cloud. Each of these systems have a purchase cost, relicensing cost, training cost, operational cost, and continue to add their own complexities to workflows and automations with what they support and what they don’t. On the other hand there are tools from the public cloud that spans both the public cloud and on-premise assets by virtue of an agent installed on the machine that talks over http.  These System Center tools from either public cloud are designed for the organization wide asset management and chores that has been widely accepted by many companies.

Conclusion: The adage of total cost of ownership holds true even in the new IT world although not by the same name. Managed versus unmanaged services show clear differentiation and place value in favor of managed anywhere.

 

 These are a few SQL exercises to demonstrate querying beyond spreadsheets:

Let us consider that there are

-- Employees at Company X

-- their names must be unique.

CREATE TABLE employees (

id SERIAL PRIMARY KEY,

name TEXT,

);

-- Contacts are people an employee knows

CREATE TABLE contacts (

id SERIAL PRIMARY KEY,

name TEXT,

email TEXT

);

-- employees will refer people they know

-- must be cleaned up after an employee leaves

CREATE TABLE referrals (

employee_id INT references employees(id),

contact_id INT references contacts(id)

);

Q.1: Which of the following statements is TRUE?

Creating employees with the same name will generate a SQL Error (FALSE)

Creating employees with the same name will not generate a SQL Error (TRUE)

Q.2: Which of the following statements is TRUE?

When an employee or contact is deleted, referrals will be deleted (FALSE)

When an employee or contact is deleted, referrals will NOT be deleted (TRUE)

Query ONE

SELECT * FROM (

SELECT

employees.name AS employee_name

contact_id,

contacts.name as contacts_name,

contacts.email as contacts_email,

(SELECT COUNT (*) FROM referrals as r WHERE r.contact_id = referrals.contact_id) as num_referrals

FROM referrals

JOIN employees on employees.id= employee_id

JOIN contacts on contacts.id = contact_id

) As q

where q.num_referrals > 1;

Query TWO

SELECT

employees.name AS employee_name

contact_id,

contacts.name as contacts_name,

contacts.email as contacts_email,

(SELECT COUNT (*) FROM referrals as r WHERE r.contact_id = referrals.contact_id) as num_referrals

FROM referrals

JOIN employees on employees.id= employee_id

JOIN contacts on contacts.id = contact_id

WHERE

contact_id IN (SELECT contact_id FROM REFERRALS GROUP BY contact_id HAVING COUNT (*) > 1);

Q.3: Which of the two queries is more efficient?

Query ONE (TRUE)

Query TWO (FALSE)

Q.4: A ride hailing company has their DB structured in 3 major tables as described in the SCHEMA

section below.

Write a query to fetch the top 100 users who traveled the most distance using the service.

The output should be structured as: users.name distance_traveled

Sort the output by distance_traveled in descending order, then by user name in ascending order. Show

only the top 100 users, ignoring the ties at the last position.

Note: There could be multiple users with the same name but they will have different IDs

CITIES: id string assigned id to the city represented as 32 characters UUID

name string the name of the city

USERS: id string assigned id to the city represented as 32 characters UUID

city_id string the id of the city in which this user resides.

name string the name of the user.

email string the email of the user.

SELECT DISTINCT u.name, SUM(r.distance) as distance_traveled

FROM RIDES r

JOIN USERS u

ON r.user_id = u.id

GROUP BY r.user_id, u.name

ORDER BY distance_traveled DESC, u.name ASC

LIMIT 0,100;

 

Application Modernization Questions:

One of the shifts in thinking about modernizing versus migrating an application is in terms of workload.  A workload here is a collection of software systems called components that deliver a business value. In a monolithic system, the components might be tightly integrated.  A well architected framework allows them to evolve independently. Evolution is incremental release subject to development and test. If the architecture involves independent microservices, then it is easy to test them independently and at different levels of a multi-tier microservice. When the changes are continuously incremental and delivered via a pipeline that follows a continuous integration (CI)/continuous deployment (CD), then every release is guaranteed to have little or no regressions allowing components of the overall workload to change without affecting the others. This facilitates removing pain points in the original monolithic software and a transition towards hosting them in the cloud.

Describing a well-architected framework almost always involves the five pillars conceptually regardless of the cloud to which the application is destined for. These five pillars are:  Reliability (REL), Security (SEC), Cost Optimization (COST), Operational Excellence (OPS), Performance efficiency (PERF). The elements that support these pillars are a review, a cost and optimization advisor, documentation, patterns-support-and-service offers, reference architectures and design principles. 

Each pillar contains questions for which the answers relate to technical and organizational decisions that are not directly related to the features the software to be deployed. For example, a software that allows people to post comments must honor use cases where some people can write and others can read. But the system developed must also be safe and sound enough to handle all the traffic and should incur reasonable cost. 

Since the most crucial pillars are OPS and SEC, they should never be traded in to get more out of the other pillars. 

The security pillar consists of Identity and access management, detective controls, infrastructure protection, data protection and incident response. Three questions are routinely asked for this pillar: 

1.       How is the access controlled for the serverless api? 

2.       How are the security boundaries managed for the serverless application? 

3.       How is the application security implemented for the workload? 

The operational excellence pillar is made up of four parts: organization, preparation, operation, and evolution. The questions that drive the decisions for this pillar include: 

1.       How is the health of the serverless application known? 

2.       How is the application lifecycle management approached? 

The reliability pillar is made of three parts: foundations, change management, and failure management. The questions asked for this pillar include: 

1.       How are the inbound request rates regulated? 

2.       How is the resiliency build into the serverless application? 

The cost optimization pillar consists of five parts: cloud financial management practice, expenditure and usage awareness, cost-effective resources, demand management and resources supply, and optimizations over time. The questions asked for cost optimization include: 

1.       How are the costs optimized? 

The performance efficiency pillar is composed of four parts: selection, review, monitoring and tradeoffs. The questions asked for this pillar include: 

1.       How is the performance optimized for the serverless application? 

In addition to these questions, there’s quite a lot of opinionated and even authoritative perspectives into the appropriateness of a framework and they are often referred to as lenses. With these forms of guidance, a well-architected framework moves closer to reality

 

A proposal to group microservice candidates from existing applications:

Introduction: Human interpretation of existing applications for the purposes of refactoring relies on knowledge of abstract software models. There is no substitute for reverse engineering it this way because the levels of abstraction can be decided by those who benefit from them. Forward engineering part of the application modernization becomes straightforward when the abstractions detail just what needs to be refactored. On the other hand, most web application software often follow well-known patterns of model-view-controller and their variations. They also benefit from well-defined levels of front-end, middle tier and backend.

In these cases, the refactoring of application into microservices is possible when there are groups drawn from those levels and components. Even if the middle-tier is a large object-relational model and the database is a large instance, it is possible to determine many independent groups from the schema and classes by merely establishing a graph with classes as units and edges as relationships in terms of inheritance and composition. The independent groups will be those islands of sub-graphs that are not connected.  Establishing a graph of the class dependencies is helpful because the frequency of usage can be overlayed over the graph as weights on the edges, which then helps to ease the hot spots by splitting the usages. It will not help with forming new entities or objects but that is a detail that can become apparent once the groupings are well-formed. It is also possible to define new entities by grouping the properties and methods within a set of units but that is a level of detail further than the grouping of classes that encapsulate them and beyond the scope discussed here.

Grouping of units is based on the criteria of connected components in this case. This does not have to be the only criteria. Many other criteria can be included to form groups and these groups can even be ranked by the collective use of criteria. A frequently occurring group across criteria is ranked higher. Criteria can be based on co-occurrence of certain classes. Model, view and controller are classic examples of those classes that co-occur. Even when the mappings are not straight forward such as thick layers or monoliths, the combination of criteria such as independence sets and co-occurrence can help to improve the cohesion and separation of clusters. If there are multiple criteria, then the groups can be assigned a score by each criterion and the largest total can be thresholded to determine the selection.

Sample grouping: https://ideone.com/BUxjZT

 

  

 

 

 

Sample authorization with AWS recognized tokens and users:

The steps for authorization in AWS are as follows:

1.       A user pool is setup with an app Client

2.       An HTTP API is set up with this user pool authorizer.

3.       The authorizer is validated using the identity token for a user

a.       This is available from the user pool using the following steps:

import { Auth } from 'aws-amplify';

 

async function signIn() {

    try {

        const user = await Auth.signIn(username, password);

    } catch (error) {

        console.log('error signing in', error);

    }

}

 

To repeat the signin, we can signout globally from all devices with:

import { Auth } from 'aws-amplify';

 

async function signOut() {

    try {

        await Auth.signOut();

    } catch (error) {

        console.log('error signing out: ', error);

    }

}

b.       Only the identity token in well-known JSON Web Token format is supplied. The access token is discarded

4.       When the authorizer is validated successfully, a sample API call can be made across the wire using a Postman sample as follows:

a.       Make an OAuth token using the Cognito’s oath endpoint

b.       Pass the OAuth token in the authorization header field.

 

 

This is a continuation of the errors encountered and the resolutions for the deployment of a function handler.

The credentials used for executing cli commands needs to be set beforehand only once. This option works very well for almost everyone. The only caveat is for the federated identity users who might not have a key and secret issues. The recommended approach in this case is to request the root user to take this specific action.

 

AWS has provisions to generate temporary programmatic credentials via its secure token server that can be utilized to perform command line actions. The use of this credentials requires account level privileges for a one-time setup that many federated users might not have. Hence, the request to the root user to enable the above-mentioned command to be executed.

 

The following are some of the ways to generate the credentials for command-line usages:

1.

 

a. aws configure sso

SSO session name (Recommended): my-sso

SSO start URL [None]: https://my-sso-portal.awsapps.com/start

SSO region [None]: us-east-1

SSO registration scopes [None]: sso:account:access

CLI default client Region [None]: us-west-2<ENTER>

CLI default output format [None]: json<ENTER>

CLI profile name [123456789011_ReadOnly]: my-dev-profile<ENTER>

 

b. aws configure sso-session

 

Signing in and getting credentials:

aws sso login --profile my-dev-profile

aws sso login --sso-session my-dev-session

aws sts get-caller-identity --profile my-dev-profile

aws s3 ls --profile my-sso-profile

aws sso logout

 

 

2. One can configure the AWS Command Line Interface (AWS CLI) to use an IAM role by defining a profile for the role in the ~/.aws/config file.

[profile marketingadmin]

role_arn = arn:aws:iam::123456789012:role/marketingadminrole

source_profile = default

 

3. Clearing cached credentials:

del /s /q %UserProfile%\.aws\cli\cache

 

4. Using credentials process with:

credential_process = "C:\Path\To\credentials.cmd" parameterWithoutSpaces "parameter with spaces"

 

 Handler Errors and resolutions continued. 

This document is in continuation of the errors encountered and their resolutions for deployment of a function handler in the AWS cloud. The first part of the article is linked here. This is the second part. 

One of the troublesome errors encountered is ensuring that the handler can put objects in an S3 bucket. The error encountered is usually “403: Forbidden” and it defies even the bucket administrator and sound bucket policies. 

It might seem surprising that even an S3 bucket owner might not be able to effectively use bucket policies, but it is inherent to buckets they are created as private with deny access by default. Clearing this default before authoring new bucket policies is sometimes the only resolution even though the bucket owner might be an admin on the AWS account. If there is an error with read-write access to bucket, the following things might need to be checked to resolve the dreaded “403: Forbidden” error.    

1. Permissions are missing for s3:PutObject to add an object or s3: PutObjectAcl to modify the object’s ACL.  

2. The requestor might not have permission to use an AWS Key management service (AWS KMS) key  

3. There is an explicit deny statement in the bucket policy  

4. Amazon S3 Block Public Access is enabled.  

5. The bucket access control lists don’t allow the AWS account root user to write objects.  

6. The AWS organizations' service control policy doesn’t allow access to Amazon S3.  

 

One of the ways to resolve this error has been to clear the initial bucket policy. There are two ways to do this: 

 

First, sign in to the AWS management console as the root user which might be different from an administrator who has AmazonS3FullAccess privileges. Only the root user can take effective steps to delete the initial bucket policy from the user interface. That is why this step might not be an effective resolution for everyone. 

 

Second, use the command-line interface to specify the following command: 

Aws s3api delete-bucket-policy –bucket <bucketName> --debug 

And this will also succeed in clearing the initial bucket policy.