Case Study:

Global Telecommunications Company Leverages SHI Open Source Project

SHI automates deployment of infrastructure for backend service in the cloud

Highlights:

Customer Profile

Global telecommunications company

Challenge

The customer wanted to deploy a backend service in the cloud for an IoT solution they were developing and needed help automating deployment of infrastructure.

Solution

ITAM and Licensing
Data Center

SHI helped automate deployment of their infrastructure utilizing AWS cloud technology.

Benefits/Results

  • Automated deployment of infrastructure
  • Well-designed AWS CodeCommit repositories containing infrastructure code
  • Collection of cloud pieces to leverage for future solutions

Partners

AWS

Challenge:

The customer was interested in deploying a backend service in the cloud for an IoT solution they were developing. The customer first built a development environment manually through the AWS Console – often the easiest way to get a custom solution up and running. It proved handy to have infrastructure code and automation scripts in order to repeatedly build production environments.

Solution:

Identifying Keeper Resources

The AWS Console can be compared to a garage full of tools – it allows users to experiment with different approaches to solving a problem and many ideas are quickly abandoned, but the best survive. However, this approach tends to produce a wasteland of unwanted resources, such as unused roles and security groups. Before creating automation scripts, the “sheep have to be separated from the goats.” Only a subset of the development environment needs to be cloned and modified for production.

When creating automation scripts, it is preferable to work with text rather than clicking through the AWS Console to see what resources and properties need to be copied over to other environments. To see the resources and properties created in a development environment in text format, CloudFormer can be used to produce one large AWS CloudFormation template that contains them. This reveals a snapshot of potential resources that might be needed in a similar production environment. Using one large stack to spin up components can be a bit of a maintenance challenge. To make things more manageable, a large stack can be broken down into many smaller, more understandable parts. As resources are moved into smaller stack templates, the unwanted resources can be discarded, and the keepers customized further.

Infrastructure as Code

Infrastructure as YAML has been around for a while now, but with AWS CDK, infrastructure as TypeScript becomes an even more plausible option. With it, for example, you can loop through a list of items to create tags without having to use as much boilerplate. So, when breaking apart a template from CloudFormer, it can make sense to assign some resource properties in TypeScript instead of YAML or JSON. At the end of the day, AWS CDK uses TypeScript code to synthesize AWS CloudFormation templates which can be stored in Git repositories and watched by CI/CD pipelines.

File Structure

SHI focused on customizing each piece of the puzzle, and kept the pieces small enough to remain understandable. As a result, a separate file was created for each resource to house its properties. The files were organized by category and resource type in an infrastructure directory. To simplify the process, SHI fetched base templates containing resource properties, using crpm – a command line tool that assists when getting started with AWS CDK. Infrastructure directories were stored in CodeCommit and organized in a way that permitted infrastructure code changes to trigger AWS CodePipeline, allowing AWS CloudFormation to update the infrastructure.

Coding the Cloud in the Cloud

The quickest and easiest way to stand up an AWS CDK infrastructure project is with an AWS Cloud9 cloud IDE instance. Affordable and easy to use, the instances are perfect for spinning up a TypeScript development environment. Cloud9 does not require AWS CLI installation or configuration; it is immediately ready for use. Importing Node.js modules and compiling code are also possible right away. With Cloud9, a user is able to synthesize AWS CloudFormation templates and create stacks from them with the AWS CLI in no time!

Flexible Infrastructure Code with Environment Variables

When creating reusable pieces, environment variables come in handy. For example, a customer might have an environment variable named ENVIRONMENT that is set to dev, test or prod. When creating a resource, a user might want an environment tag or to use the environment name as part of the actual resource name. SHI kept environment variables in a .env file in the root directory of infrastructure code projects. Then, dotenv was used in TypeScript code to source variables from .env.

Resource Creation & Modification

Initially, it is desirable to write infrastructure code and have AWS CloudFormation stacks created from it. Then, have the ability to change your code, and allow AWS CodePipeline to notice the changes and proceed to change the infrastructure to match. First, the CI/CD pipeline resources defined in that code have to be created. The pipeline can then start watching the code that defines itself, looking for changes. SHI created a bin directory in each project and placed bash scripts in it, our AWS experts then used those to create stacks initially to get the resources created. At the same time, we found it useful to create corresponding delete scripts to eliminate any no longer needed infrastructure, which proved useful when testing.

Benefits:

The customer has well-designed AWS CodeCommit repositories containing infrastructure code which can be used to spin up base environments in less than one hour. The customer has also amassed a collection of cloud pieces which can be used as a starting point when stitching together future solutions.