Roll DevOps tools into your AWS migration plan

Source – techtarget.com

accelerated dePublic cloud platforms such as AWS have changed how many businesses develop applications. Cloud affords development times — and enables some dev teams to release new features and app updates multiple times a day. But none of this would be possible without a vast array of DevOps tools and services.

After an AWS migration, businesses can model their infrastructure as code (IaC), build and test code with managed services and automate deployments using continuous integration (CI) and continuous delivery (CD) orchestration services. Enterprises that haven’t yet embraced cloud, however, have a long wait before they can see the benefits of using AWS DevOps tools. But before IT teams become technically proficient with AWS tools and services, they must make a cultural shift and change the way they think about traditional deployments.

Businesses should devise a strategy to take advantage of the new capabilities that are available after moving to AWS. Businesses can reach improved levels of operational maturity post-AWS migration, but it takes commitment and know-how from all lines of business.

Define infrastructure as code for resiliency

Operations engineers who work in on-premises data centers spend a lot of time writing server build documents that ensure other IT staff members follow the steps to properly deploy businesses workloads. But this approach has potential problems. Step-by-step documents go out of date quickly. And humans make mistakes, especially when they get tired and are reading through a long build document.

Using IaC during an AWS deployment means replacing old server build documents with a declarative template that can provision any AWS resource as needed. IaC templates become executable versions of those documents.

Administrators can author IaC templates with AWS CloudFormation and then store them in a version control service, such as AWS CodeCommit or GitHub. Once the admin defines IaC, the IT team can build a replica of the production environment for testing; this provides an exact infrastructure blueprint in case teams ever need to rebuild the infrastructure.

Embrace configuration management early in an AWS migration

While admins can use IaC templates to provision AWS infrastructure, they will likely have to run multiple server operating systems on various Elastic Compute Cloud (EC2) instances. Before automating deployments with code, developers and admins need to be up to speed with the concept of configuration management (CM). Many IT teams already use CM tools, which provide a way to automate the configuration of applications and the OS. In addition, CM tools can prevent configuration drift — server or application settings changing over time on a system because of a mistake or the installation of another application.

AWS integrates with all CM tools as well as OpsWorks, the configuration management service based on Chef. Amazon EC2 Systems Manager works as a Chef alternative to automate system patching, build and query inventories and automate the execution of any command with its Run Command feature. This enables admins to use existing CM assets or EC2 Systems Manager with Run Command and a State Manager feature to consistently configure applications and eliminate configuration drift.

Enforce compliance through policy as code

Beware of unexpected server or application settings that can take down an application. Automated compliance controls in AWS can prevent these problems, and enterprises should implement them shortly after an AWS migration.

One such service, AWS Config, takes inventory on AWS resources. In addition, AWS Config Rules ensures that resources comply with a desired state. AWS records state changes and alerts an IT team whenever a user creates, deletes or modifies any AWS resource.

Implement monitoring and logging

It’s important to collect and monitor application performance information and log files. Amazon CloudWatch collects performance metrics from all types of systems and monitors log files. IT teams receive alerts when system performance lags or when errors occur in log files. CloudWatch metrics and alarms also play key roles in Auto Scaling servers based on resource utilization. For example, admins can create a CloudWatch Alarm that triggers a scale-out action to deploy additional EC2 instances when CPU use on existing servers rises above a certain threshold. Alternatively, configure a scale-in action to delete additional capacity when the resource demand drops back down.

IT teams can also tap into event-based automation capabilities. Admins can configure CloudWatch Events with rules that trigger custom logic when changes are made to resources. Use state-changes data from various services as the source of these rules; this includes activity, such as launching EC2 instances or signing into the AWS Management Console. Configure rules with targets that can take an action on these events. Common actions use AWS Lambda functions with custom logic or Simple Notification Service topics that send an IT team a notification about the event.

Use CI and CD

CI is useful when merging small changes to code into a central repository. Admins then can run automated builds and unit tests to compile applications and ensure the code works as expected. This process helps to quickly identify bugs and improve software quality.

CD takes CI a step further. The CD process ensures that the code is ready to move to development or staging for further testing. Once all tests have passed, the latest version of the application is deployable to production.

Businesses can implement CI and CD with AWS-native services. AWS CodeCommit works as a secure version-control repository; AWS CodeBuild automatically performs builds when code enters the repository. AWS CodePipeline makes sure committed code is automatically built, tested and deployed into testing or staging environments, which ties together the various CI and CD services.