Kate Deutscher
Automation Run Rampant
With the rise of micro services and DevOps culture, engineers are finding themselves responsible for the all facets of a rapidly growing number of systems. Luckily for you, many of the processes managing these systems can be automated! But where do you begin? How do you know when something is ripe for automation? Is there such as thing as bad automation? And how do you take the first step?
RubyConf AU 2017
00:00:09.890
Thank you, everyone, for being here. My name is Kate, and I'm a Ruby developer as well as one of the organizers of Rails Girls here in Melbourne. Rails Girls is an amazing initiative, and if you are not already participating, I encourage you to do so. Today, I'm going to talk to you about automation tooling—specifically, how to prevent it from ruining your life, or at the very least, how to make it manageable. Fingers crossed!
00:00:36.020
You can find my rather boring Twitter handle up on the screen: @KateDeutscher. If you'd like to get in contact with me, feel free to reach out. I'll also be posting my notes and any references from this talk online and will tweet the link afterward. If you don't like taking notes, like me, or if you want to revisit something later, please feel free to grab it all later.
00:01:38.110
This team is responsible for helping all other developers find good ways to build, package, and deploy their applications. While some of our work involves tooling, we also provide general guidance, developing patterns, and offering training. However, during this talk, we'll focus specifically on the tooling aspect of automation.
00:02:18.510
When I refer to automation and automation tooling, you might wonder what exactly that means. These are simply pieces of software designed to automate some part of the software delivery or development process. In other words, they transform steps that would otherwise be manual into automatic ones. You can typically find them managing tasks like bringing up your development environments, managing your CI/CD pipelines, or deploying your application to your preferred platform.
00:02:52.620
The tools themselves vary widely; some can be as small as a basic script, while others may offer a full platform-as-a-service solution. I like to think of them as Lego blocks that can be combined to form a common base for all your different systems. While all of this sounds great, building this tooling requires time and effort. You might wonder what prompted REA to invest so heavily in it—well, simply put, we had to.
00:03:50.150
The truth is, it came down to one major factor: growth. The number of engineers at REA has been growing rapidly, and this growth has pushed us into embracing microservices. This means that, in addition to having our systems developed by a much larger team, we also have a significantly larger number of systems.
00:04:56.560
Questions that previously came up, such as how to bring up a development environment or how to deploy an application, started happening far more often. Solutions that used to work, such as having excellent documentation for setting up a development environment or having someone on the team to assist with deployment issues, were simply not scaling anymore. Currently, REA has around 620 engineers managing 580 systems. You don't need to be a mathematician to see that this is almost one engineer for every system.
00:05:59.120
Many of these systems are deployed across different environments as well, which adds to the complexity. Maintaining this ratio of engineers to systems would indeed be impossible for us without investing in some sort of tooling. The benefits we've seen since introducing automation are substantial. We now have one-step tests, one-step builds, and one-step deploys for significantly more systems than we used to, translating to a much lower margin for error.
00:07:34.500
This improvement has led to developers feeling far more confident in the delivery process and better understanding how long it will take to release new features. Automated solutions for common issues mean every team does not need to reinvent the wheel multiple times. This enables developers to spend more time developing applications. We've also made it a goal to make our tooling as language and framework-agnostic as possible, allowing it to be used across a wider variety of systems.
00:08:38.490
This approach has proven essential as we've been scaling out our Australian portfolio. Learning a single deployment tool can empower a developer to deploy hundreds of different systems. Now that I've shared the importance of automation tooling, let's dive into how you can actually build it.
00:09:35.860
There are three main patterns I've observed during my time at REA for building this tooling. We will look at each of these patterns in detail, followed by an example of each and the problems they aim to solve.
00:10:02.800
The first pattern is what I call the Swiss Army knife tool. This tool combines multiple individual functions under a single, simple interface to provide a one-stop shop for your delivery or development process. One example of this is Kubernetes, an open-source container orchestration tool. It manages a group of servers and provides a simple API to deploy services onto those servers.
00:10:58.800
To deploy an application with Kubernetes, you can simply run a command like `kubectl run hello-world --image=hello-world`, and that's it! Your application is now deployed. If demand increases and you need to scale, you can run another simple command: `kubectl scale deployment hello-world --replicas=4`, and just like that, you've got four instances running. What makes Kubernetes a Swiss Army knife tool is its ability to allow you to perform tasks with minimal knowledge by providing a simple interface.
00:12:36.710
Kubernetes makes a lot of decisions for you, orchestrating the deployment across multiple servers and managing resources like CPU and memory. So when should you consider building a Swiss Army knife tool? These tools are designed to enable developers to perform tasks quickly without having to make too many decisions that might slow them down, which makes them intuitive and easy to use.
00:14:20.760
However, the challenge comes when engineers have many opinions about how they want to work, and they might not agree with the mandates imposed by these tools. To encourage adoption, you'll need to invest time in making your tool as obvious and easy to use as possible, as well as providing excellent support to resolve any issues quickly.
00:16:47.150
The second tool we'll explore is called the screwdriver tool. This tool focuses on solving a single problem, making it much smaller in scope. An example is Capistrano, which is known for providing repeatable deployments of your application.
00:17:05.060
Capistrano operates under a strong 'no magic' philosophy, relying on other tools that you would typically use in a manual deployment process. It offers a way to define the steps for automating that process. However, this means you need to be familiar with its configuration, which can become complicated.
00:18:24.150
While Capistrano focuses on one task—running manual deployment steps on a remote host—it leaves many decisions up to the developers. This can encourage innovation as developers make their own technical decisions and experiment with new languages, tools, or frameworks. However, be prepared for some duplicate efforts as teams might tackle the same problems in different ways.
00:19:38.350
The final tool we'll discuss is known as the duct-tape tool. This tool wraps existing systems to provide a consistent interface. You might use a duct-tape tool to create consistency over time or across multiple systems.
00:20:06.050
For instance, a duct-tape tool could wrap an existing system whose API you plan to change, avoiding disruption for users. An example from my experience is a script we developed at REA that allowed developers to use Docker without deeply understanding it. This script simplified running commands through Docker, but over time, it became a burden as developers became more familiar with Docker. In retrospect, we wondered if a better solution might have been to write thorough documentation instead.
00:21:52.900
In conclusion, I hope you now have a better understanding of the three patterns for building automation tooling: the Swiss Army knife tool, the screwdriver tool, and the duct-tape tool. Each has its advantages and drawbacks, so carefully consider the specific challenges you face before deciding which approach to take. Thank you for your attention, and I hope you find ways to creatively automate processes within your own teams!
