Wayne Gretzky wasn’t famous for exceptional speed or a powerful shot, but his finely-tuned hockey instinct for ‘skating to where the puck was going to be’ at just the right time to make a shot on goal.
If the goal for any iterative DevOps delivery cycle is the successful and speedy deployment of new features, then managing the complexity of each change at hyper-speed becomes the primary determination of an application delivery and support team’s success.
A core tenet of DevOps is ‘automating all the things’ — from the moment any bit of code is changed by developers, to its commit, compile, configuration, testing and deployment into secure and performant pre-prod and production environments.
A host of CI/CD and DevOps automation tools have arisen, each with unique approaches to this extended problem space, many of which operate through interfaces and controls only an engineer could love.
A CLI or script-based automation inherently makes sense for highly technical project users. So how could the idea of Low-Code enter the picture?
Getting an assist from Low-Code ease of use
Glorious goal-scoring highlights would overlook Gretzky’s equally valuable passing skills, where he’d ‘put the puck where his teammate was going to be’ for even more clutch assists that changed the outcome of games.
Low-Code represents a very broad range of solutions that enable non-technical individuals, or ‘citizen developers’ to get involved in creating their own automated business processes, and sometimes even, software.
Conceptually, many of the development tools under the low-code banner are things like mobile app builders or mashup tools for combining SaaS services and productivity apps. And, like the title suggests, there should be little coding required on the part of whomever is building the functionality.
While such tools have value to business users such as salespeople and accountants who might be good with Excel macros and reporting tools, they are often laughed out of the room by hardcore techies who will only go for ‘as-code’ tooling vs. low-code.
Maybe this notion that low-code tools are too low-tech for engineers needs to change.
Today’s low-code tools exist on a spectrum after all, as my colleague Jason Bloomberg aptly illustrates in his recent “What’s Happening to Low-Code” column covering the turbulent space.
There’s a natural cycle at play here, where software development tools move from drag-and-drop easy No-Code tools to Low-Code and even ‘Pro-Code’ to allow increasingly sophisticated functionality to be coded, modified and supported in production by developers, with some automation assistance.
Simplify as much code as humanly possible
There’s a similar pressure to simplify development toward low-code and no-code simplicity in order to more quickly incorporate business-level expertise and workflows into software, and support them after deployment, with less engineering involvement.
Yes, engineers could build up YAML files and IaC packages from scratch every time they are selecting each environment configuration and deployment action. It also turns out they would much rather manage such assets repeatably in a graphical, low-code type of workflow if they can, so long as it still provides clarity into what is happening when they drill down into the details.
DevOps teams would much rather take an existing project along with all of its IaC and environment automation settings, and convert it into the context of their own new project, almost in a drag-and-drop wizard sort user experience, without always having to build it up from scratch again.
SREs and support engineers would rather be able to quickly spot the point in time when deployed changes caused something to go awry with at-a-glance diff and observability visualizations rather than raw queries, and then have an arsenal of pre-made runbooks or response plays just a click away.
A simplified ‘low-code’ style deployment UI that still encapsulates the real ‘as-code’ underlying sources would be a holy grail of repeatability and ease, while serving the goals of faster delivery and higher resiliency, especially in today’s highly ephemeral microservices environments.
Don’t start changing habits with code, start with people
“No matter who you are, we’re creatures of habit. The better your habits are, the better they will be in pressure situations.” – Wayne Gretzky
The reason DevOps came into existence was to get us beyond the stodgy habits of ITIL and Change Control Boards full of gatekeepers reviewing every unique request for change-time and support-time access to version-controlled repositories.
We wanted more autonomous smaller teams of developers, operations engineers and business stakeholders, working hand-in-hand with automation to deliver functionality faster.
So why are we seeing a trend of ‘DevOps Review Boards’ stepping into this role of process enforcement? Risk motivates control behaviors over innovation and autonomy, especially in larger enterprises.
Any DevOps team should exist not as a change control function, but to serve its development and business teams with resources, tooling, and environments. Democratizing authority and autonomy over the means of production allows teams to focus on what they do best.
To mitigate risk, strong security, identity and access controls need to be in place, from the repo to production. But more importantly, the management of privileges can benefit from clearer visibility into individual, group and role-based usage and access controls, allowing them to be simply updated by applying automated IAM policies, not just to prevent system failures and security breaches, but to avoid the risk of teams unproductively stepping on each others’ toes.
Deployments aren’t monolithic, but they should be repeatable
“You miss 100% of the shots you don’t take” is perhaps the most commonly quoted Gretzky maxim of all time for encouraging sales teams, but this truism also applies for taking a shot at establishing a smoother, less risky DevOps process.
While engineers still need to see their committed code, low-code style controls and visibility at a policy and metadata level can continue beyond production, into automating post-deployment aspects of issue resolution and runbooks.
DevOps teams want agility and performance, while leadership teams tend to gravitate toward risk and cost reduction, but it’s really all about transparency between teams, and clarity of development assets, configurations, processes, environments, and production support work.
Whether you are in development or in management, it’s worth a shot to think about how Low-Code capabilities might help you change the story in today’s highly technical deployment arena. Seek out vendors and open source projects with the power and intuitive assistance to get you and your teammates there ahead of the puck.
©2022 Intellyx LLC. Intellyx retains editorial control over the content of this document. Image source credits: DaPuglet (Tina), flickr CC2.0 license, Low-Code Lifecycle infographic by Jason Bloomberg in Intellyx Cortex column May 2021.
