One of the architectural patterns for application migration is about managing AWS Service Catalog products in multiple AWS Accounts and AWS Regions. AWS Service Catalog is used to create, share organize and govern the curated IaC templates. Governance and distribution of Infrastructure is simplified and accelerated. AWS uses CloudFormation Templates to define a collection of AWS resources aka stacks required for a solution or a product. StackSets extend this functionality by enabling us to create, update or delete stacks across multiple accounts and AWS Regions with a single operation. 

If a CloudFormation template must be made available to other AWS accounts or organizational units, then the portfolio is typically shared. A portfolio is a container that includes one or more products.   

On the other hand, this architectural pattern is an alternative approach that is based on AWS CloudFormation StackSets. Instead of sharing portfolio, we use AWS StackSet constraints to set AWS regions and accounts where the resources can be deployed and used. This approach helps to provision the Service Catalog products in multiple accounts, OUs and AWS Regions, and managed from a central location which meets governance requirements. 

The benefits of this approach are the following:  

1. the product is provisioned and managed from a primary account, and not shared with other accounts. 

2. This approach provides a consolidated view of all provisioned products (stacks) that are based on a specific set of templates. 

3. The use of a primary account makes the configuration with AWS Service management Connector easier 

4. It is easier to query and use products from the AWS Service Catalog.  

The architecture involves an AWS management account and a target Organizational Unit (OU) account. The CloudFormation template and the service catalog product are in the management account.  The CloudFormation stack and its resources are in the target OU account. The user creates an AWS CloudFormation template to provision AWS resources, in JSON or Yaml format. The CloudFormation template creates a product in AWS Service Catalog, which is added to a portfolio. The user creates a provisioned product, which creates CloudFormation stacks in the target accounts. Each stack provisions the resources specified in the CloudFormation templates. 

The steps to provision products across accounts include: 1. Creating a portfolio say with the AWS command line interface 2. Create the template that describes the resources, 3. Create a product with version title and description and 4. Apply constraints to the portfolio to configure product deployment options such as multiple AWS accounts, regions and permissions and 5. Provide permissions to users so that they can launch the products in the portfolio. 

 

Pure and mixed templates:

Infrastructure-as-a-code is a declarative paradigm that is a language for describing infrastructure and the state that it must achieve. The service that understands this language supports tags, RBAC, declarative syntax, locks, policies, and logs for the resources and their create, update, and delete operations which can be exposed via the command-line interface, scripts, web requests, and the user interface. Declarative style also helps to boost agility, productivity, and quality of work within the organizations. 

Template providers often go to great lengths to determine the convention, syntax and semantics that authors can use to describe the infrastructure to be setup. Many provide common forms of expressing infrastructure and equivalents that are similar across providers. Authors, however, rely on tools to import and export infrastructure. Consequently, they must mix and match templates.

One such template provider is AWS cloud’s CloudFormation. Terraform is the open-source equivalent that helps the users with the task of setting up and provisioning datacenter infrastructure independent of clouds. These cloud configuration files can be shared among team members, treated as code, edited, reviewed and versioned.

Terraform allows including Json and Yaml in the templates and state files using built-in functions called jsonencode and yamlencode respectively. With the tools to export templates in one of the two well-known forms, it becomes easy to import in Terraform with these two built-in functions. Terraform can also be used to read and export existing cloud infrastructure in its syntax but often they may be exported in ugly compressed hard-to-read format and these two built-in functions allow multi-line display of the same content which makes it more readable.

AWS CloudFormation has a certain appeal for being AWS native with a common language to model and provision AWS and third-party resources. It abstracts the nuances in managing AWS resources and their dependencies making it easier for creating and deleting resources in a predictable manner. It makes versioning and iterating of the infrastructure more accessible. It supports iterative testing as well as rollback.

Terraform’s appeal is that it can be used for multi-cloud deployment. For example, it deploys serverless functions with AWS Lambda, manage Microsoft Azure Active Directory resources, and provision a load balancer in Google cloud.

Both facilitate state management. With CloudFormation, users can perform drift detection on all of their assets and get notifications when something changes. It also determines dependencies and performs certain validations before a delete command is honored. Terraform stores the state of the infrastructure on the provisioning computer, or in a remote site in proprietary JSON which serves to describe and configure the resources. The state management is automatically done with no user involvement by CloudFormation whereas Terraform requires you to specify the remote store or fallback to local disk to save state.

Both have their unique ways for addressing flexibility for changing requirements. Terraform has modules which are containers for multiple resources that are used together and CloudFormation utilizes a system called “nested stacks” where templates can be called from within templates. A benefit of Terraform is increased flexibility over CloudFormation regarding modularity.

They also differ in how they handle configuration and parameters. Terraform uses provider specific data sources. The implementation is modular allowing data to be fetched and reused. CloudFormation uses up to 60 parameters per template that must be of a type that CloudFormation understands. They must be declared or retrieved from the System Manager parameter store and used within the template.
Both are powerful cloud infrastructure management tools, but one is more favorable for cloud-agnostic support. It also ties in very well with DevOps automations such as GitLab. Finally, having an abstraction over cloud lock-ins might also be beneficial to the organization in the long run.

Extending datacenters to the public cloud:

 A specific pattern used toward hybrid computing involves extending datacenters to the public cloud. Many companies have significant investments in their immovable datacenters and while they can create a private cloud such as a VMWare cloud within the public cloud, they might find it costly to maintain both an on-premise cloud and one on the public cloud. A reasonable approach between these choices is to extend the existing datacenters to the public cloud. This article explores this pattern.

 

Although technology products are not referred to by their brands or product names in a technical discussion of an architectural pattern, it simplifies this narrative by providing a specific example of the technology discussed. Since many technological innovations are patented, it’s hard to refer to them without using product names. In this case, we use the example of a private cloud with VMWare cloud and refer to its products for manageability. A VMWare vCenter is a centralized management utility that can manage virtual machines, hosts, and dependent components. VMWare vSphere is VMWare’s virtualization platform, which transforms datacenters into aggregated computing infrastructures that include CPU, storage, and networking resources.

The pattern to extend the datacenter to VMWare Cloud on AWS uses Hybrid Linked Mode. Inventories in both places can be managed through a single VMWare vSphere Client interface. This ensures consistent operations and simplified administration and uses a VMWare Cloud Gateway Appliance. It can be used to manage both applications and virtual machines that are on-premises.

There are two mutually exclusive options for configuration. The first option installs the Cloud Gateway Appliance and uses it to link from the on-premises vCenter server to the cloud SDDC. The second option configures Hybrid Linked Mode from the cloud SDDC. The Hybrid Linked Mode can only connect one on-premises vCenter Server Enhanced Linked Mode domain and supports on-premises vCenter Server running more recent versions. When a cloud gateway appliance is connected to the Hybrid Linked Mode, there can be multiple vCenter Server connected to the appliance but when the cloud SDDC is directly connected to the Hybrid Linked Mode, there can be only one vCenter Server.

Different workloads can be migrated using either a cold migration or a live migration with VMWare vSphere vMotion. Factors that must be considered when choosing the migration method include virtual switch type and version, the connection type to the cloud SDDC, and the virtual hardware version.

A cold migration is appropriate for virtual machines that experience downtime. These virtual machines can be shut down, migrated and then powered back on.  The migration time is faster because there is no need to copy active memory. This holds true for applications as well.  A live migration, on the other hand, uses vMotion to perform rolling migration without downtime and is advisable for mission critical applications. The idea behind vMotion is that a destination instance is prepared and made ready and the switching from source to destination happens near instantaneously.

This pattern establishes promotes the visibility of existing infrastructure to the cloud.

 

Migrating remote desktops

Most migrations discuss workloads and software applications. When it comes to users, identity federation is taken as the panacea to bring all users to the cloud. But migrating remote desktops for those users is just as important for those users when they need it. Fortunately, this comes with a well-known pattern for migration.

Autoscaling of virtual desktop infrastructure (VDI) is done by using NICE EnginFrame and NICE DCV Session Manager. NICE DCV is a high performance remote display protocol that helps us stream remote desktops and applications from any cloud or data center to any device, over varying network conditions. When used with EC2 instances, NICE DCV enables us to run graphics-intensive applications remotely on EC2 instances and stream their user interfaces to commodity remote client machines. This eliminates the need for expensive dedicated workstations and the need to transfer large amounts of data between the cloud and client machines.

The desktop is accessible through a web-based user interface. The VDI solution provides research and development users with an accessible and performant user interface for submitting graphics-intensive analysis requests and reviewing results remotely

The components of this VDI solution include: VPC, public subnet, private subnet, an EngineFrame Portal, a Session Manager Broker, and a VDI Cluster that can be either Linux or Windows. Both types of VDI Clusters can also be attached side by side via an Application Load Balancer. The user connects to the AWS Cloud via another Application Load Balancer that is hosted in a public subnet while all the mentioned components are hosted in a private subnet. Both the public and the private subnets are part of a VPC. The users request flows through the Application Load Balancer to the NICE EngineFrame and then to the DCV Session Manager.

There is an automation available that creates a custom VPC, public and private subnets, an internet gateway, NAT Gateway, Application Load Balancer, security groups, and IAM policies. CloudFormation is used to create the fleet of Linux and Windows NICE DCV servers. This automation is available from the elastic-vdi-infrastructure GitHub repository.

The steps to take to realize this pattern are listed below:

1.       The mentioned code repository is cloned.

2.       The AWS CDK libraries are installed.

3.       The parameters to the automation script are updated. These include the region, account, key pair, and optionally the ec2_type_enginframe and ec2_type_broker and their sizes

4.       The solution is then deployed using the CDK commands

5.       When the deployment is complete, there are two outputs: Elastic-vdi-infrastructure and Elastic-Vdi-InfrastruSecretEFadminPassword

6.       The fleet of servers is deployed with this information

7.       The EnginFrame Administrator password is retrieved and the portal is accessed.

8.       This is then used to start a session.

This completes the pattern for migrating the remote desktops for users.

 One of the benefits of migrating workloads to the public cloud is the savings in cost. There are many cost management functionalities available from the AWS management console but this article focuses on the a pattern that works well across many migration projects.

This pattern requires us to configure user-defined cost allocation tags. For example, let us consider the creation of detailed cost and usage reports for AWS Glue Jobs by using AWS cost explorer. These tags can be created for jobs across multiple dimensions and we can track usage costs at the team, project or cost center level. An AWS Account is a prerequisite. AWS Glue jobs uses other AWS Services to orchestrate ETL (Extract, Transform and Load) jobs to build data warehouses and data lakes. Since it takes care of provisioning and managing the resources that are required to run our workload, the costs can vary. The target technology stack comprises of just these AWS Glue Jobs and AWS Cost Explorer.

The workflow includes the following:

1.       A data engineer or AWS administrator creates user-defined cost-allocation tags for the AWS Glue jobs

2.       An AWS administrator activates the tags.

3.       The tags report metadata to the AWS Cost Explorer.

The steps in the path to realize these savings include the following:

1.       Tags must be added to an existing AWS Glue Job

a.       This can be done with the help of AWS Glue console after signing in.

b.       In the “Jobs” section, the name of the job we are tagging must be selected.

c.       After Expanding the advanced properties, we must add new tag.

d.       The key for the tag can be a custom name and the value is optional but can be associated with the key.

2.       The tags can be added to a new AWS Glue Job once it has been created.

3.       The administrator activates the user-defined cost allocation tags.

4.       The cost and usage reports can be created for the AWS Glue Jobs. These include:

a.       Selecting a cost-and-usage report from the left navigation pane and then creating a report.

b.       Choosing “Service” as the filters and applying them. The tags can be associated with the filters.

c.       Similarly, team can be selected and the duration for which the report must be generated can be specified.

This pattern is repeatable for cost management routines associated with various workloads and resources.

 

Among all the established cloud migration patterns for different workloads, one pattern stands alone because it is not specific to a resource. This is the pattern for software development and testing in the cloud so that the logic can be incrementally migrated from an on-premises application to say, serverless computing. With the elimination of a one-time deployment of migrated code, the path to incremental delivery and enhancement of logic that is hosted in the cloud becomes more gradual, deliberate and even expanding audience. Versioning of the logic helps keep existing customers while onboarding new ones.

Let us take a specific example of a NodeJs application developed with GitHub and build with AWS CodeBuild. The instructions in this document helps to set up a continuous integration and continuous delivery workflow that runs unit-tests from a GitHub repository. Unit-tests reduce refactoring time while helping engineers to get up to speed on their code base more quickly, and provide confidence in the expected behavior. It involves testing individual functions including Lambda functions. Use of an AWS Cloud9 instance which is an Integrated Development Environment is suggested but not mandatory. It can be accessed even through a web browser.

Setting up this pipeline involves a few milestones which developers call ‘epics’. The first epic involves running unit-tests on a personal GitHub repository with CodeBuild. The tasks involved are:

Sign in to the AWS Management Console and open the CodeBuild console at https://console.aws.amazon.com/codesuite/codebuild/home

Create a build project and in the project configuration, type the name of the project

In the source section, specify the provider as GitHub and point to the existing personal Repository in the GitHub account by specifying its URL.

In the primary source webhook events section, specify to rebuild every time a code change is pushed to this repository.

In the environment section, choose managed image and the latest image for an Amazon Linux instance.

Leave the default settings and complete the project creation.

Start the build.

The CodeBuild console will display the tests run and the unit-test results can be reviewed. These results validate the repository integration with the project that has been created with the steps above. When the webhook is applied, code changes automatically start a build.

Unit-tests often involve assertion, spies, stubs and mocks.

An assertion is used to verify an expected result. For example, the following code validates that the results are in a given range:

Describe(‘Target Function Group’, () => {

 It(‘Check that the result is between 0 and 1000’, function () {

              const target = new Target();

             expect(target.id).is.above(0).but.below(1000)

});

});

A spy is used to observe what is happening when a function is running. The following example shows whether a set of methods were invoked.

Describe(‘Target Function Group’, () => {

It (‘should verify that the proper methods were called’, () => {

     const spyStart = spy(Target.prototype, “start”);

     const spyStop = spy(Target.prototype, “stop”);

     const target = new Target();

      target.start();

      target.stop();

      expect(spyStart.called).to.be.true;

      expect(spyStop.called).to.be.true;

});

});

A stub is used to override a function’s default response. For example, a stub can be used to force a return ID from the getId function

Describe(‘Target Function Group’, () => {

         It (‘Check that the Target Id is between 0 and 1000’, function () {

             let generateIdStub = stub(Target.prototype, ‘getId’).returns(99999);

             const target = new Target();

            expect(target.getId).is.equal(99999);

            generateIdStub.restore();

});

});

A mock is a fake method that has predefined behavior for testing different scenarios. A mock can be considered an extended form of a stub and can carry out multiple tasks simultaneously. For example, a mock can be used to validate three scenarios: 1. A function is called, 2. That it is called with arguments. and 3. It returns an integer, say, 9.

Describe(‘Target Function Group’, () => {

    It (‘Check that the TargetId is between 0 and 1000’, function() {

let mock = mock(Target.prototype).expects(‘getId’).withArgs().returns(9);

const target = new Target();

const id = target.getId();

mock.verify();

expect(id).is.equal(9);

});

});

 One of the advantages of migrating workloads to the public cloud is that there are well-known patterns to leverage which make the assess->deploy->release path quite predictable. For example, we can talk about the migration strategy identification itself as a pattern that leverages the notion of an AppScore. The idea behind this pattern is that the challenges around missing operational data crucial for studying applications such as recovery time objective, recovery point objective or data privacy, can be overcome by using an application centric view of the portfolio of applications to migrate. This includes a recommended transformation route for each of the application against the 5 R’s model described in the earlier post

The score helps to capture application information, determine the ideal transformation route, identify the risk, complexity, and benefits of cloud adoption, and quickly define the migration scopes, move groups and schedules.

The score is used towards a recommendation based on the following three categories of application attributes:

1.       Risk – which is the business criticality of the application, whether it contains confidential data, data sovereignty requirements, and the number of application users or interfaces.

2.       Complexity – which is the application’s development language, age, UI, or number of interfaces.

3.       Benefit – which is the batch processing demand, application profile, disaster recovery model, development, and test environment use.

There are four phases of iterative data capture, which include:

1.       Signposting – questions that are combined with server data to produce the assessments.

2.       Scoring – questions that produces scores for risk, benefit, and complexity.

3.       Current state assessment – questions that provide a current state assessment of the application.

4.       Transformation – questions that comprehensively evaluate the application for future state design.

Only the signposting and scoring stages are required to receive application scores, assessments and enable group planning.  After the applications are grouped and scopes are formed, the latter two stages are used to build a more detailed overview of the application.

While the migration evaluator helps to create a directional business case for planning and migration, the application centric view helps to bridge the gap between discovery and migration implementation and provide a recommended route to the cloud.

This workflow can be described with the following stages:

1.       Start the discovery and assessment.

2.       Align Applications and servers.

a.       Capture the application and business information.

b.       Import server and technical details.

3.       Obtain recommendations, scoring and costs for each application.

4.       Plan costed schedules using move groups.

5.       Design application migration or transformation activities

6.       Export Application assessment and transformation reports from 3. 4. And 5.

7.       Perform approved migration or transformation activities.

With this pattern, the determination of the recommended migration strategy becomes more predictable.