Over the last 15-20 years, Cloud computing has had its fair share of paradigm shifts – from the conception of PaaS services, to containers, and most recently, the explosion of AI. Businesses have adopted the Cloud at their own pace, some even moving to, then away from the Cloud. For businesses who have either yet to start, or are near the beginning of their Cloud journey thinking that they’ve started in the race too late – starting your journey to DevOps today is better than starting tomorrow.
What is DevOps?
“Currently, DevOps is more like a philosophical movement, not yet a precise collection of practices, descriptive or prescriptive.” — Gene Kim, author of The Phoenix Project
The idea of DevOps is a cultural and technical shift from traditional waterfall models to a more agile development process. The DevOps culture aims to break down silos of different IT teams and bring them together into a more closely knit delivery function. For an overview on what Agile is, refer to this article on Agile Methodology from Asana which goes into depth on the topic.
Here are some of the key takeaways from some of the clients I’ve worked with to build and evolve their DevOps processes.
Assess your readiness
Before undergoing such a fundamental change it’s important to assess from a business and organisational perspective how the transition will happen. Most often, a new “delivery” team is born out of the existing teams that most often consist of some (or sometimes all) of the IT department. This new team’s first action will be to evaluate the key areas in the organisational process that slows down delivery of projects, and implement plans to streamline them.
Choose your tools
Which tools and products you use to build your infrastructure and support your processes is one of the most important decisions you can make, and just like you would shop for the best tools for the job before starting that DIY project, so too must you ensure you pick the right tools that fit for your organisation – from both a technical and cost-effective standpoint.
First and foremost, it is essential to use a method of version control – also known as Source Code Management (SCM) tools. An SCM tool –
- Serves a central repository for code for version control which enables many hands to work on code simultaneously through branching strategies
- Enables user-defined guardrails to ensure code is maintained in a sensible fashion.
There are a few providers for this, 3 examples would be Azure DevOps, AWS CodeCommit, or GitHub. The choice depends on your exact requirements and choice of Cloud platform – which I won’t delve in to here.
Choosing which languages to leverage rests heavily on whether the direction is agnostic vs Cloud specific. Terraform & Pulumi are Cloud agnostic while CloudFormation and Bicep are Cloud native to AWS & Azure respectively. Powershell or Python is more dependent on your workloads and use-cases. Finally, there are configuration tools – for example, DSC, Ansible, or Chef.
Define your standards & conventions
Naming conventions
Most organisations will have a standard naming convention for identification of resources. When moving to the cloud you have additional considerations – you’ll now need to identify resources in specific regions as well as environment, as well as resource identifiers, and number increments.
Luckily, there’s a tool available to assist in naming decisions and provide a future reference, along with limited tracking – the Azure Naming Tool. This tool can give you a good idea of what your requirements will be and customise them to your preference.
Having implemented the naming tool for a client, they’ve been able to generate and clearly view the planned resource names with their custom requirements, allowing them to plan ahead and eliminate any issues before they arise – for example, limitations on name lengths.
Code standards
This is one that businesses may not have already, and will form a large part of operating procedures going forward.
Each language has it’s own best practice coding style guide. Generally, you can adhere to and follow these without having much trouble although consistency across the team (or teams) is key. For Terraform in particular it’s important to get it right from the beginning as some choices can be more difficult to back out of later – for example, resource naming.
Documentation
Another key component to transitioning to an effective DevOps function is effective documentation.
Any documentation should be clear, include stepped processes where necessary and – most of all – be written so the reader would be able to follow the processes without prior contextual knowledge. This can come in many forms – whether that be –
- Readme files in a code repository,
- A visual process diagram contained in a wiki
- Descriptive release notes on versions
Good documentation will lend itself heavily into your delivery team being able to smoothly transition projects into support.
Common challenges
While embracing a DevOps culture brings a multitude of benefits, businesses often face hurdles in the path. I’ve split these into separate headings below –
Resistance to change
Common challenges to moving towards a more agile approach to IT include resistance to change and breaking down silos between teams. There may be fears that work is being “taken” from existing individuals and teams, where historically they have been the primary owners of the service/process.
The best way to tackle these issues early is evangelise the benefits of DevOps and the Cloud – frame the advantages in a way that benefits them. Actions speak louder than words, and a live demonstration of how quickly a VM can be deployed using IaC and pipelines against existing manual methods can go a long way to getting people onboard faster.
Training issues
Infrastructure-as-Code is a concept that traditionally on-premise facing teams will be largely unaware of, and is a large paradigm shift in ways of working. The biggest barrier to entry that I’ve found has been onboarding – the time it takes between starting to learn and being able to write working code to deploy something meaningful.
In the past, I’ve run training sessions, generated training materials, and implemented templated “starter” code for new projects to allow teams with various levels of skills to onboard & upskill faster.
Along with this, I’ve written and documented Terraform modules to save time and reduce human error, in one such case reduced the amount of lines to create a “new” project by 60% and the time to turn a basic project around from 2 or more days to less than 4 hours.
Security
DevSecOps is a term that frequently appears in job descriptions. The term came about from the rise of businesses and engineers that thought only of deploying fast over deploying securely. I’ve always firmly believed that DevSecOps isn’t a replacement for the term “DevOps”, Doing DevOps correctly means building infrastructure in a security-first, least privilege manner by default. Ensuring builds abide to basic security principles and common-sense can ease fears that effective governance is in place
Closing summary
Moving towards a DevOps culture isn’t a one-time process, and is not an initiative that can be undertaken in isolation. The core of DevOps is continuous improvement and development – automate more, incorporate more to code, reduce toil. This requires buy-in from all levels of the organisation to achieve.
If you have any questions or would like to discuss how I can help you to onboard to DevOps & the Cloud, reach out to me on LinkedIn or contact me via the Contact Form on the website