by Tim Prendergast
We’re in a pivotal moment in technology where programmatic infrastructure, everything-as-a-service, and an explosion of internet-connected devices are combining to create amazing opportunities for businesses. The margin of differentiation between competitors is often small enough to be overcome by sufficient cash investment to accelerate one innovator over the other. However, we are now seeing perhaps the most underrated and far-reaching shift in the ability to separate winners from losers in technology – and that is the emergence of Rugged DevOps.
How is it possible that a philosophical system can overwhelm the power of money and manpower? The answer is simple: working harder never beats working smarter… and when it comes down to it, Rugged DevOps practitioners work both smarter and harder than typical engineers.
Why is this “Rugged DevOps” movement so important? Consider the changes in today’s technology landscape, especially when it comes to resiliency and security needs of consumer, industrial, and enterprise services:
Smarter attacks: We have attackers who are not only sophisticated, but who are now experts in automation and continuous delivery of their attacks and exploits. These continuous attacks cannot be mitigated through blood, sweat, and tears of your staff any longer – they need automated defenses that are as good, if not better, than what the attacker is leveraging.
Cloud-based infrastructure: Add the collapse of security perimeters and the explosion of cloud resources to the mix, and you have an ever-changing infrastructure in size, resource type, and capacity. If you can’t automate the defense of this ever-changing environment, then you are instantly at a disadvantage when trying to protect it.
Failure is (occasionally) an option: Speaking of protecting your business, you also have to come to the realization that everything will fail, often at inopportune times. By planning your architecture, operations, and incident response around an assumed failure framework, you can better prepare your organization for the actual incidents as they occur. Practice makes perfect, after all!
With these realities in mind, the time is right for more IT organizations and companies to embrace the opportunities of Rugged DevOps. Here are a few key concepts to help your organization get started down the right path to Rugged DevOps:
Catalyze the Change
Things don’t change overnight in organizations, large or small. We all work with humans, and the most effective way to engage humans is to cater to their desire for knowledge, growth, and improvement. This is especially true when introducing Rugged DevOps principles. Perhaps the most critical and foundational principle to introducing Rugged DevOps is being the catalyst to change your organization’s culture. Rugged DevOps is going to represent a significant change to the way your team might have done business in the past – and not everyone is eager to embrace change, especially if it threatens their perceived sense of usefulness or security.
How can you change your culture around Rugged DevOps? While nothing is guaranteed to work for everyone, I can confidently prescribe the following steps to facilitate your journey to a more rugged state:
- Invite all the parties to the table: InfoSec/IT Security, IT and Product Operations (including DevOps if you have it), Engineering leadership, Product/Project Management, and Support. Show them all that you value their participation and give them a clear road map for how they’re going to continue to contribute and add value in the “new world” of Rugged DevOps.
- Create a discussion path conducive to introducing Rugged DevOps: Make the conversation about the overall organization and big picture goals. For example, you could say: “We have a new project on the horizon, and we know that we’ll have to achieve certain levels of industry certification on this codebase. Would the team here be interested in trying a more progressive framework for this project?” Few people say no to better ways of achieving their goals.
- Write down the needs and challenges faced by all the stakeholders on a whiteboard and discuss them: While security may be most concerned with managing risk through more controlled pace, DevOps teams may be more concerned with faster time-to-market and less so with mitigating risk. These are immediately opposing mentalities that can be reconciled with discussion and technology. For example, you might bridge the gap between Security and DevOps teams by suggesting, “What if we put in security automation as part of our DevOps toolchain – automated risk assessment and mitigation guidance for every deployment to AWS, perhaps? That seems to enable faster releases and better risk mitigation than we’ve ever had before. Both sides win!”
- Know the strengths and weaknesses of the team: This means understanding that your Security team may not be cloud experts, and your DevOps team may not be security experts – but they can, and will, enjoy learning from each other!
Spearheading any significant organizational change can be daunting, but making the transition to Rugged DevOps doesn’t have to be – as long as you can get started with a spirit of understanding and team spirit. Show the various stakeholders that Rugged DevOps is not going to be “taking” anything away from them – if anything, it will be “adding” to their capacities and enhancing their productivity and performance.
Establish Open Communication
Once you start your organization along the process of adopting Rugged DevOps, the most important thing is to stay in communication. Create a Slack or HipChat channel to keep your Rugged DevOps team talking and sharing. Invite all of the stakeholders to this channel, and create additional topical or functional channels, if necessary, but this method of open communication will be the glue that is keeping you all on the same plane of communication. It’s easy to send an email and accidentally omit key stakeholders or participants. In a chatroom, key information and updates are always there for the parties to scroll back and read.
Another great way to keep the communication open is to inject feedback from the automation systems into the channel so everyone has the same telemetry data to work with. This keeps people from being surprised by, or unaware of, changes to the environment, systems, or operations of the project. People move pretty quickly when they see alerts from your security services pop into the channel, especially when they say things like “New High Risk Vulnerability Found in AWS S3 Bucket: Production-User-Files,” for example. With good, ongoing communication, nothing should be a surprise, and everyone should have access to the same alerts and performance data. This allows well-informed people from various disciplines to interpret and analyze the project from various angles, ensuring better coverage and guardianship.
The road to Rugged DevOps is often intimidating, but it doesn’t have to be difficult if you get started with a spirit of collaboration and open communication. As long as your stakeholders feel like they truly have a stake in the Rugged DevOps transition – and don’t feel like it’s something being imposed upon them or handed down from on high – and as long as your team has a chance to see the ongoing changes (and beneficial results) in real time as they are happening, you will be more likely to make a successful transition to Rugged DevOps while maintaining the morale of your entire team.