Menu
Menu
​What DevOps automation looks like in AWS

​What DevOps automation looks like in AWS

DevOps isn’t just about getting the culture right – it’s also about the products and tools that will help guide your move to a more agile, smoother development approach

The widespread adoption of DevOps approaches has seen organisations working out how to move from legacy processes and embrace the benefits of a more collaborative, lean workflow.

There's often a perception of DevOps as being based around a cultural shift within a business, rather than any practical tooling. While it is true that at its core, DevOps involves real cultural change within an organisation and closer collaboration between dev, test and ops teams, there is a series of services and products that can help guide the process too.

While in many businesses the development team have been following agile approaches and using version control, unit and integration testing, the operations teams are now able to leverage these methodologies due mostly in part to infrastructure that can be defined by code.

What we're seeing recently is that learnings are improving on the ops side and the availability of Amazon Web Services (AWS) and its suite of DevOps-focused products allows you to leverage much of this.

Previously, infrastructure has been a static area where capital expenditure was needed to get a new server. Then that server is treated like the proverbial golden child, where you didn't want (and couldn't afford) for that server to go down.

The advent of cloud and AWS has changed this. The response and move to cloud services such as AWS has meant that organisations have in-built flexibility and ruthlessness when they manage their infrastructure.

A common analogy is the ‘pets vs cattle’ idea where cloud users have environments designed and intended to be flexible, scalable and need minimal maintenance. When that server falls over, the idea is that like cattle, it's nameless, faceless and without attachment. We discard rather than try and fix it.

While this approach isn’t great if your applications aren't cloud-native, when you're building something new as an AWS-native application there are better levels of automation that you can apply. Firstly, the application has to be built to accommodate this AWS-native mindset. Then there are the specific technologies that you can call on to facilitate this automation process.

These include AWS Cloud Formation - typically the starting point in an AWS context – which is designed to give developers and system admins the visibility and the capability to manage AWS resources and track changes through the lifetime of the application infrastructure. This means that key personnel are able to provision resources in a structured, logical fashion.

The automation process happens through Cloud Formation and then you can also use other CICD tools such as Ansible and Jenkins to help you control the process. This means that your infrastructure stack will be automated, so you won't physically be touching anything throughout the process.

You could also use Docker, which allows you to define applications on an operating system in a relatable way. Another product often used is AWS Elastic Beanstalk, which is designed to look after the deployment for you.

For example, you may have 100 machines that you want to roll out new software to and using Elastic Beanstalk, you can do this in an intelligent way, doing it 50 per cent at one time, 50 per cent at another time for instance. This means you can manage your environment, while deploying the software out.

The flexibility with AWS means that deployment improves across the organisation. It provides the ability to easily spin up new environments rather than doing an in-place deployment. This facilitates blue-green deployment, whereby you have your production environment running (blue), while in the background you spin up a new stack next to it as a test environment (green).

Then if you've installed updates or made changes on green, you can easily cutover and make that production-ready without missing a beat. You can do this as a hard cutover to the green environment and do it quite rapidly, or you can make changes in the background to gradually send users over to your new environment. If there are problems in this process, you can roll-back with minimal disruption.

A possible example might be if you are working in an organisation that has software running that needs to stay online 99.99 per cent of the time. This means you need access to redundancies and you need an environment that is robust, scalable and secure. The idea might be to turn that software into a fully-scaling, cloud solution using AWS.

This means there are particular things you would need to look at, starting with taking the application platform and getting it into a Docker platform to allow for appropriate control and management. Then you would want to get the Docker platform and application into Elastic Beanstalk, meaning you can run two (or more) servers at any one time.

This means you can use the blue-green approach and roll out a new service at any time, without interruption. This process won't happen overnight - often for organisations with legacy infrastructure and processes, it involves cultural change, where internal dev, test and ops teams may need time to familiarise themselves with taking advantage of cloud and AWS and running it in a lean, Agile, DevOps fashion, using small incremental changes over time.

While for many organisations moving to AWS is a cost-driven exercise, it's often more instructive to think of it as being a benefit-driven process. Cost may be a positive driver in moving to AWS, but for many organisations, the improvements in processes and the significant risk reductions are more noteworthy. This process of DevOps culture and practices using AWS tools also means that you're upskilling your team in the process.

The more regularly you are deploying, the less exposed your business is to downtime, errors and failure. For instance, if you deploy every three months, that may mean there are three months of changes and updates you need to account for, increasing your risk.

The end game should be about reaching a stage as a business where you're deploying as frequently as practical. This helps embed the idea of DevOps culture within your business, while taking advantage of the capabilities of cloud services and products.

Greg Cockburn is principal cloud architect at Bulletproof.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the CIO newsletter!

Error: Please check your email address.

Tags software developmentAmazon Web ServicesGreg CockburnAWSdevelopment teamDevopsagile

More about AgileAmazon Web ServicesAWS

Show Comments
Computerworld
ARN
Techworld
CMO