Here’s the not-so-surprising moral of this story: The key to cloud productivity lies in automating — not only an application’s build, but its provisioning, operations, monitoring processes, in fact, the application’s entire software development life cycle. Effective, full scope automation like this limits human intervention in a cloud system. Humans get tired and make mistakes. All humans. So, curbing the need for manual action is generally good. But, the automation can’t be realized through a “black box” cloud solution. The black box, a common type of offering in the market, refers to a platform that provides cloud implementation, but inflexibly restricts a user’s granular action, system visibility, and deep API investigation. That can hamper necessary customizations in deployment and, ultimately, a business’ innovation in the cloud. That’s bad.
How, then, should cloud practitioners resolve this automation conundrum? To put a team squarely on the path to automation without sacrificing desired levels of system control requires drilling into the DevOps mindset and taking concrete actions that increase productivity.
Here are five tips to do just that, resulting in teams that move fast and well in the cloud:
- Make everything code
At its core, DevOps is about applying developer methodologies to both development and operations in IT departments — melding the two areas and making them part of the same process. Creating a successful DevOps environment accelerates business objectives. To spin up a DevOps protocol, to keep it automated, and to keep it running smoothly depends on code. Everything must be expressed as code — everything to do with your computing environment, with your application, with your configuration, with your security and controls, with your policy management, with your execution — define all of it as code. Infrastructure-as-code just becomes a routine, integrated part of your playbook. The same holds true for compliance concerns and secure collaboration built into policy-as-code. It’s all part of your code base, like your application is.
Code can be easily reviewed, certified, and automated. When everything is code, your teams build highway instead of toll booths. That is, instead of having some groups that are trying to fast track data flow (developers) and others (I&O and security) saying “Hey, wait a minute, we need to look at this,” DevOps with its coding ethic gives you an uninterrupted, yet well vetted, Autobahn. Teams move fast and correctly. They can build and deploy new software with dramatically reduced friction. They can be innovative without breaking critical system components.
- Make everyone coders
If everything becomes code, that means everyone must become a coder. This requires a culture shift. In many enterprises, a dramatic one. Such a level of change isn’t easy. To get everyone pulling the rope together culturally, genuinely embracing a unified coding and automation approach, individuals must be empowered to work like developers.
One way to do this is to support I&O and security professionals while they learn or relearn programming or hone those skills. Ideally, a cloud infrastructure coding language should be straightforward, declarative, as easy to write as YAML or JSON, but much more powerful. Scalable cloud infrastructure needs a language where functions can be used to quickly replicate infrastructure patterns, where rich libraries are easily imported into a program, where modules are easily edited, and where compiler error-messaging prevents expensive runtime mistakes. It should be made easy for people who historically have been operators to contribute code as they become developers.
The other way to achieve the culture shift is to give infrastructure coding responsibility to people who have historically been developers, but who are also interested in cloud services and their configurations. There’s a learning curve here too, and these developers must be secure with that subject matter or willing to learn. In both scenarios, having a system in place that’s approachable, understandable, and learnable is key.
It’s noteworthy that many organizations will decide to maintain a hybrid model of these approaches. If that works best based on team dynamics and the capabilities or interests of team members, it’s the route to choose. In that case, embedding cross-over learners in I&O or development teams moves an organization in the right direction.
- Vanquish fear and highlight heroes
Vanquishing fear in an organization and highlighting heroes sounds a bit medieval. But there’s useful psychological collateral in doing this that can boost productivity. When making everything code and everyone coders, when shifting an organizational culture from segmentation and toll booths to full automation and innovation highways via a DevOps ethos, one of the biggest obstacles will be the human fear of being made irrelevant. It might manifest as ridicule, resentment, low productivity, or resistance to new and better technologies. Organizations can dismantle that fear and make people feel and be relevant with short term training that yields lasting, long term benefits. This is training in a cloud infrastructure coding language. It’s training in how to code policy. It’s training in a new system that automates cloud with code. Even better would be to have a language and system so straightforward that little training is required.
Organizations bear responsibility for establishing the mechanisms to begin the culture shift and to maintain the shift’s momentum in teams. Lifting the spirits and the careers of those who embrace where cloud is going and who are thinking about next generation systems approaches isn’t only the decent thing to do, it’s good business. Find those champions on the security team and the operations team who are making the shift, showing even gradual progress, and doing the work. Put those people in the organization’s newsletter. Put them on stage at the annual meeting. Show that the culture shift can and does happen.
- Avoid point solutions and glue code
The temptation to automate a cloud system (distributed or otherwise) by connecting services, resources, and narrowly focused point solutions with in-house code and hand-rolled scripts is understandable. That’s the reality for scores of enterprises. Cloud perpetuates an environment of increasing, ubiquitous, overlapping components, the constant availability of new point solutions, software release cycles which can include hundreds of releases a day (not the entire stack, but little pieces of the system), and tens of thousands of lines of custom, sometimes disjointed code and scripts to manage it all. None of the latter is supporting your actual business offering; it’s just undifferentiated heavy lifting with infrastructure and its glue to make the system work.
All these factors combine to create severe operational complexity at scale and a big, artisanal system that isn’t easy to orchestrate. The point solutions tend to tackle a specific problem in your cloud build stage, in your cloud monitoring or in your cloud management, but not in all of those at once. Even knowing what actually exists in a system like this, who owns what, and whether drift has occurred requires deep cloud expertise from the humans engaged with it. And, humans who understand cloud really well are actually in short supply.
It is possible to avoid this kind of system—with its big piles of stuff, layers of pain, fragile, hard-to-know pieces, and mandatory expertise. Since cloud services are all API-driven and thus programmable resources, a mature system uses that characteristic as a governing principle for one holistic framework. This framework gives users both high-level and granular control as they define it. It provides constantly refreshed, known state and visibility for all its running parts.Does this really exist? It does, and with the declarative cloud infrastructure coding language as the means to control it. (Fugue is an example of such a system.)
The end game in avoiding point solutions and glue code is three-fold: 1. You enable a genuine, dynamic infrastructure that’s entirely hands-off, so not as susceptible to human error and unapproved change; 2. You simplify operational complexity which reduces deployment and cloud management friction and increases productivity; and 3. You give DevOps coders a system that is easy to navigate, iterate within, and move fast and well in order to innovate.
- Pick a greenfield project and iterate
How do you begin? Pick a greenfield project that’s not mission critical and not a huge endeavor, then experiment with these new patterns. Iteration within these parameters is the best designer by far. You have to fail, fail fast, and try again until you find the right way for your organization to operate and automate on the cloud.
In order to know if you’ve succeeded in these small, iterative projects, use success criteria. Measure whether or not you’re introducing additional friction. Measure how fast the experiments go. It’s critically important to get a gauge on speed. Measure whether or not the outcomes achieve the operational requirements of the traditional I&O setup. Make sure the I&O and security professionals are truly pleased with the results and have bought into adopting developer method and mindset. They must be engaged from the beginning of the process and given the freedom and authority to innovate.
You’ll end up with a team that’s all pulling the rope together, with experiments that worked well for everyone. Then, take those successful patterns and extend them to the broader organization. That can happen informally or even by creating a kind of “Center for Cloud Excellence” that brings engaged minds, best practices, new ideas, and executable solutions to the table, then disseminates cloud how-tos and cloud wisdom to the rest of the organization.
Developers love cloud and cloud was really built for developers. So, keep the developers — old and new DevOps — going fast. If you don’t, competitors will do it and they’ll reap the rewards in any industry.
