DevOps without automation is like peanut butter without jelly
© Shutterstock / VelP
How important is automation in a DevOps context and what are the areas where automation is really needed? That’s an easy one! In the second part of our interview series, nine DevOps influencers weigh in on the DevOps-automation link and talk about the importance of testing.
A DevOps world is a continuous world
Mike D. Kail, CTO at Cybric and one of our top DevOps influencers, believes that “the cultural transformation of DevOps is to streamline existing tasks and processes and move to a world where everything is continuous; Continuous Integration, Continuous Deployment, Continuous Delivery.”
However, one should not assume that DevOps is synonymous with Continuous Delivery, Helen Beal warns.
For a time, some people definitely thought of DevOps as synonymous with Continuous Delivery — and it’s a common #DevOpsFail we have observed; the thought that we will build a Continuous Delivery Pipeline and they will come… but they don’t.
I think DevOps does have specific characteristics that aren’t ALL Continuous Improvement, but if all DevOps is for you is a label to try and deliver software and application services better, then that’s still useful.
— Helen Beal, Head of DevOps at Ranger4
There are as many opinions as there are people, it seems, but there is one area that’s crystal clear; many DevOps influencers agree that “without automation, there is no DevOps.” Is automation alone enough, though? If you ask Massimo Ferrari, Management Strategy Director at Red Hat, the answer is ‘no‘.
IT automation is a fundamental building block for modern infrastructures, but it is just one of the many elements that organizations require as part of the digital transformation journey.
Automation is the arm, capable of doing actions. But, like in the human body, you need eyes, (e.g. analytics tools) to direct the actions in the right place. You need a brain, (e.g. a management platform) to identify the right action to do, and so on. You wouldn’t get far without all of these elements.
— Massimo Ferrari, Management Strategy Director at Red Hat
Now let’s see how our DevOps influencers feel about automation.
In the first part of this interview series, we talked with nine DevOps influencers about the DevOps show and who’s really leading it. Plus, since the focus is slowly shifting from “What is DevOps?” to Where do we start?” we invited our DevOps heroes to clear things up for you. Now it’s time to focus on automation and testing.
9 answers: How important is automation in a DevOps context and what are the areas where automation is really needed?
Charity Majors: Anywhere that good judgment is not needed, the work should be automated away. You should only need to exercise judgment in the critical triage path and for your few business differentiators.
Mike D. Kail: The cultural transformation of DevOps is to streamline existing tasks and processes and move to a world where everything is continuous; Continuous Integration, Continuous Deployment, Continuous Delivery. Automation is a key component of making that a reality and every area along the way from commit to build and delivery should be assessed for where automation can be implemented.
No programmer would waste their time manually translating code into machine languag.
John Arundel: Without automation, there is no DevOps. No programmer would waste their time manually translating code into machine language—it’s tedious, error-prone, repetitive, boring, and a waste of time. Instead, they get the computer to do it, using a program called a compiler. The same applies to provisioning infrastructure, configuring firewalls, installing dependencies, building containers, checking web services, and so on. It’s just that not everybody realizes that yet.
Gregory S. Bledsoe: Collaboration and automation are the two foundational elements of DevOps. Without automation, what you are doing isn’t DevOps. Everything that can be automated should be automated, and everything can be automated. Collaboration is necessary to achieve effective automation that meets the organizational goals, so there is a synergy between these two axis.
Jérôme Petazzoni: Computers are fantastic to perform repetitive jobs. A program or script will never forget or skip a task in a 25-steps checklist. It will never get bored or complain about completing seemingly useless verifications, tests, and safety checks. I think everything that will be done at least twice should be automated, at least if it is important to get the same result each time. (I won’t automate a jazz solo, since I expect interesting variations each time it’s performed, for instance. :-))
But “automation” doesn’t necessarily mean bringing out the big guns. The best automation starts as a README file that you leave for future you when you will need to do the thing again in a few days or weeks and want to make sure that you won’t forget anything important. From that point, it can naturally evolve to a checklist, and then a shell script, and then (depending on the context) a Dockerfile, a Puppet manifest, a Helm chart, you name it. Another important detail is to resist the temptation to write things that are overly generic. Should I make sure that this install process works fine on different versions of Debian? On Debian and Ubuntu? On Fedora as well? On Intel 32 and 64 bits? What about other architectures like ARM? It’s important to know where to draw the line.
Thorsten Heller: Continuously Delivery, high speed of change by high quality and stability are, for many of our clients, a core motivation for going the DevOps way. CI/CD as an outcome of DevOps requires automation.
Eric Vanderburg: Automation is critical in DevOps and one of the driving forces behind further adoption. Automation can be used at each stage of testing the application, validating code, vulnerability scanning, deployment, the creation of testing environments, and many other areas.
CI/CD as an outcome of DevOps requires automation.
Quentin Adam: Anything that can be automated should be automated. It’s one of our core values and we built Clever Cloud for this. As a species, we have been automating everything from the beginning of technology, software is no different. We don’t like to repeat things endlessly.
In the DevOps context, it means enabling that culture of automating things. And that’s how you see traditional Ops writing more code, and being included in feature teams as DevOps.
Automation is the best way to be able to level up standards inside the company: always deliver production-ready quality.
Hans Boef: Automation can help get the process more structured and can take off the workload from developers/operators. There are so many tools which can be used, for instance, automated testing which can be integrated into many tools/platforms.
Should testing become an essential component of the CI/CD pipeline? Are we underestimating its importance?
Charity Majors: Testing is absolutely essential, what are you talking about? All of “CI” is about continuously running integration tests!
Actually, I think we overestimate the importance of testing. Testing, like monitoring, is good at catching all your known unknowns so you don’t make the same mistake twice. In the future, when we are running complex distributed systems and unknown-unknowns predominate, testing and monitoring are not enough to catch the most critical failures. You will need well-instrumented code that enables real-time observability.
Mike D. Kail: As with security, the testing phase of the CI/CD pipeline needs to leverage automation and measurement of results and testing effectiveness. I don’t think the importance of testing is underestimated, I just believe that it is sometimes bypassed in order to not decrease delivery velocity, mostly because it tends to be manual tasks. Automation will help reduce or remove the friction on velocity.
CI/CD is not about just pushing out new features and functionality.
John Arundel: Without testing, there is no CI/CD. If every commit results in a deploy, automated testing is the only way to know that you’re not going to break production. But testing has its limits.
In modern, cloud-native, distributed systems everything can and will break at any time, and tests can’t catch that, so your code needs to be defensive about everything it does. Everything can fail. If you can handle the failure gracefully, then handle it; if not, crash, and let your infrastructure handle it. If your system is failure-tolerant, then testing is merely a matter of inducing deliberate failures. If the system is not failure-tolerant, no amount of testing will make it so.
Gregory S. Bledsoe: Testing should definitely be automated into the pipeline — every manual action is friction and delay in the flow of value from idea to market where you can begin gathering feedback on whether what you did is actually what you should have done. The faster that feedback loop, the quicker you can pivot towards maximum value. This is also where most are struggling to get from manual process to automation, and there are many and varied reasons for that, all of which have solutions.
Jérôme Petazzoni: Yes and yes! You cannot release quality software without testing. (Anyone telling or believing otherwise is lying or lulling themselves.) But automating tests is hard, especially when you haven’t done it before and don’t know where to start; or when a project is still evolving very fast. There again, it is necessary to put the boundary in the right place; and that requires experience.
Thorsten Heller: Speed of change by a high quality of delivery can only be achieved by a CI/CD pipeline where testing is essential à CI/CT/CD pipeline (Contentiously Integration, Continuously Testing, Continuously Delivery). Positively, the community seems to agree, and CT is central to many.
SEE ALSO: The need for Continuous Deployment
Eric Vanderburg: Of course. CI/CD is not about just pushing out new features and functionality. New code must perform reliably as expected, produce the desired results, preserve data integrity, protect data confidentiality, and ensure customer privacy. Without testing, none of these can be assured.
Quentin Adam: I see testing in the same manner as I see security. How absolute do you want to be? There is always a balance to strike between the effort you want to put in and the expected results. (Which is why we give you security by updating software you are running on automatically, so you don’t have to because we are nice people like that.) And it has become so easy to integrate testing as part of a CI/CD pipeline that I believe it should be included. One should always consider the tradeoff of time spent by developers on designing the tests versus the actual gains of course.
Hans Boef: From my experience, I see very often that testing is not done in the way testing should be done. So my opinion is that is should be part of the pipeline and an important part.
In the third part of the interview series, our nine DevOps influencers weigh in on the importance of incorporating security into DevOps and the skills DevOps professional should have in order to tap into the perks that accompany the job description. Stay tuned!
Take a look at our interview series with last year’s DevOps influencers:
Are your calendars marked for JAX DevOps 2018? If you’d like to know more about the latest trends in DevOps and meet the top movers and shakers in the global DevOps scene, join us in London between April 9-12, 2018.