Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

InfoQ Homepage Articles The Future of DevOps is No-Code

The Future of DevOps is No-Code

Key Takeaways

• DevOps usage is snowballing, but organizations are having problems finding enough experienced personnel to build DevOps teams
• DevOps tools and workflows allow organizations to think beyond traditional staffing sources in building DevOps teams
• Low-code and no-code tools, in particular, let organizations integrate less experienced developers into their DevOps teams, effectively bridging the talent gap
• In one report, 72% of new low-code developers can build apps within the first three months of learning how to use the tools
• Low-code and no-code tools also free up existing developers by reducing the time spent on integrating and administering DevOps toolsets

The global DevOps market has expanded rapidly in recent years, reaching more than $7 billion in 2021. That number will grow to nearly$40 billion, a five-fold increase, by the end of the decade.

At the same time, the talent gap in the DevOps chain is also growing steadily. According to the U.S. Department of Labor, the global shortage of development engineers will reach more than 85 million by 2030. Annually, the demand for DevOps professionals will likely grow more than 20% for the rest of the decade.

These two conflicting trends place software and application companies in an extremely complicated position. On the one hand, they have an opportunity to substantially increase revenue by filling the growing demand for new and improved applications. But the increasing lack of ability to find the right people to build these products limits their ability to take advantage of that opportunity. So, what can companies do to compete effectively in the global market?

One potential solution is to integrate more low-code and no-code tools into the DevOps cycle. These tools provide DevOps teams with numerous benefits and efficiencies, from streamlining the work of existing DevOps professionals to allowing companies to look beyond traditional personnel sources for expanding their teams. Indeed, it is likely that organizations that fail to integrate these tools into the DevOps process will quickly fall behind their competitors.

The rise of DevOps

DevOps is a relatively recent phenomenon, only beginning to make itself known around 2008. But it is a trend that has quickly overtaken the software and application industry.

DevOps arose as a way to streamline the overall software development lifecycle. Before DevOps, the teams involved in the various stages of the lifecycle operated independently in very insulated silos. Communication between teams was often lacking and ineffective when it did occur.

Because one hand never knew what the other was doing, software development was often highly inefficient. Worse yet, the different teams frequently had different goals and objectives, and these objectives were often conflicting. Speed of release vs. functionality vs. quality assurance strained against each other, making the development teams compete with each other rather than working together towards the same goal - a quality product that reaches the end customer as quickly as possible.

DevOps offered a new, collaborative model. While the term DevOps comes from combining development and operations (i.e., deployment), as an overall philosophy, DevOps means much more. Amazon Web Services defines DevOps as:

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes.

But DevOps is more than just better communication and integrated teams working towards common goals. Instead, the truly effective DevOps team extends beyond traditional development and deployment. It also tightly integrates monitoring (for example, Java logging), quality assurance, and security to ensure that customers receive the best product possible and one they can trust with their information.

DevOps also demands applying the right tools and workflows to achieve those goals. Indeed, the automation of workflows is one of the most essential practices of DevOps. And well-implemented automation further enhances the communication between parts of the DevOps team.

In the 15 years since organizations began applying DevOps, it has seen rapid adoption with excellent results. According to one recent survey, 61% of IT decision-makers said DevOps practices and methodologies helped them deliver better products to their customers. And 49% of companies relying on DevOps could reduce time to market for their products.

DevOps was not a perfect solution

DevOps was unquestionably a substantial improvement over traditional software development methodologies. In addition to removing communications obstacles throughout the development chain, DevOps provided benefits such as:

• Increased speed of development: Because all parts of the chain are working effectively together, they can resolve issues more quickly.
• Reduced time to market: Improved workflows and automation, including continuous integration (CI) and continuous delivery (CD), allow for more frequent and rapid distribution of products to consumers.
• Enhanced scalability: With many automated and robust testing and production environments in place, teams can more easily scale products to meet new demands.
• Built-in security: Many DevOps teams now employ processes such as policy-as-code that integrate security into the development process rather than having it be an afterthought.

Despite its clear advantages, DevOps was not without its issues. One of the most significant challenges facing organizations transitioning to DevOps was the need to create a new mindset focused on collaboration. Extensive cultural and philosophical shifts inevitably generate anxiety as team members move away from well-known and comfortable workflows.

But the move to DevOps requires more than just a cultural change. It also necessitates learning new governance structures, tools, and workflows. As anyone who has participated in the rollout of a new tool knows, it is never as simple as it sounds, especially when it involves letting go of legacy systems.

DevOps tools themselves compounded the difficulty of the transition, for many different reasons. Siloed development and operations teams typically had separate toolsets and they used them to facilitate different goals and metrics. Finding the right set of tools to bridge these differences can be challenging. And asking both teams to learn a new set of tools raises concerns about morale and the use of time.

All of this makes it doubly important to focus on cultural changes before toolset changes. Tell your development team that they have to take time away from their primary tasks to learn new tools, and more likely than not you will get disgruntled developers. But if you first show them how those new tools will make their lives easier not just now, but well into the future, you will more quickly develop buy-in. Low-code and no-code tools can do just that by allowing citizen developers to take more simple tasks off the developers’ plates, leaving them to focus on higher-end work.

Even with full buy-in, however, new tools can still pose problems. Until teams become comfortable with the new processes and structures, there is a danger of overreliance on tools, many of which seem to have features that can address any problem under the sun. And with the wide assortment of tools available, developers frequently spent more time making their tools work together than actually completing projects. Indeed, developers report spending up to 40% of their time on integration tasks.

Another major hurdle organizations face in today’s workplace is finding the right people to staff their DevOps teams. Although interest in information technology is expanding and more and more young people have a substantial amount of self-taught IT knowledge, the talent gap for developers remains problematic. According to a McKinsey study, 26% of organizations identified IT, mobile, and web design as their business area with the greatest shortage of personnel.

These are just a few of the challenges organizations face when moving to and becoming proficient in the DevOps environment. But organizations quickly discover that the benefits of DevOps are more than worth the time, money, and effort they invest in the change.

The case for integrating low-code and no-code tools in the DevOps cycle

Companies are looking outside the box to fill the talent gap, and one of the most successful approaches currently is upskilling their existing workforce. As a side benefit, upskilling improves employee satisfaction and retention, which is increasingly important as, according to recent surveys, 90% of the workforce reports being unsatisfied with their current work environment.

For DevOps, the starting point for upskilling is to train non-DevOps personnel to become effective members of the DevOps team. And this is where no-code and low-code DevOps tools come in. With no-code and low-code tools, even complete development novices can learn to build websites and applications. If someone has enough computer knowledge to drag-and-drop, they can probably learn no-code tools. And those with a little more computer savvy can put low-code tools to good use.

As their name suggests, no-code and low-code tools facilitate software and application development with minimal need for writing or understanding code. Instead of building code, developers rely on visual, drag-and-drop processes to piece together pre-made functionality. So instead of needing to understand the intricacies of specific programming languages, developers need only have a good feel for the business’s needs, the overall application architecture, and the application’s workflows.

These so-called ‘citizen developers’ fill a glaring need at a much lower cost than competing for the few available experienced developers on the market. And sometimes, they can be the only truly viable option.

While building a stable of citizen developers sounds good in theory, companies may wonder whether they can really gain development benefits from previously unskilled workers. The numbers, however, are impressive. According to studies of companies using low-code tools, 24% of their citizen developers had absolutely no programming experience before taking up low-code application development. Yet 72% of new low-code developers can build apps within the first three months of learning how to use the tools. Is it any wonder that 84% of organizations are now either actively using these tools or putting plans in place to implement them in the near future?

As the workforce gets younger, the likelihood that new employees will have little or no programming experience decreases. Many new employees are coming into the workplace having already built their own websites or blogs, and perhaps even their own e-commerce businesses and applications. And they probably did it using personal low-code and no-code tools like WordPress, Wix, or Square. Businesses should leverage this experience in filling their development needs.

But no-code and low-code tools also benefit more experienced developers and optimize developer time. Rather than spending a large part of their limited work hours on pipelines and integration, they can focus more fully on substantive development and delivery. And because low-code and no-code tools use pre-built and pre-tested modules, there is less need to chase down bugs and rewrite code, further easing the workload of already overburdened developers.

Another key benefit of low-code and no-code tools is that they can help businesses automate and simplify cybersecurity tasks. Many tools have built-in security features that are simple for even the most novice developers to put in place. And IT staff can use low-code and no-code tools to build security “playbooks” for development teams so that everyone is always on the same page when it comes to the critical issue of application and network security.

Both businesses and customers see substantial benefits from citizen developers using low-code and no-code tools. Deployment velocity increases quickly, as much as 17 times according to one study, so businesses can push new and improved products out to their customers more frequently. And customers are getting more and more functionality, along with more stable and reliable products.

While organizations of all sizes can (and should) put low-code and no-code tools into their development toolboxes, it is small and medium enterprises (SMEs) that stand to gain the most benefit. SMEs frequently have few IT staff and limited resources to compete for talent in the increasingly competitive IT labor market. But with low-code and no-code tools, SMEs can use existing staff to effectively fill the development talent gap.

What low-code and no-code tools are available?

The number of no-code and low-code tools is growing almost as rapidly as the DevOps market. And they cover every stage of the software development cycle, from building functionality to testing and quality assurance to security.

Consider Microsoft’s PowerPlatform, which includes the Power Apps, Power BI, and Power Automate products. Microsoft recently expanded the suite to include a new module called Power Pages. This product lets users build high-end business websites without having any coding expertise.

Although Power Pages is geared towards the citizen developer, more experienced developers can take the no-code development tool and optimize it as needed using their own DevOps tools. But with more people in the chain and experienced developers focused on the most critical parts of the delivery cycle, organizations will find themselves delivering better products far more quickly than before.

Low-code and no-code tools can do far more than just build websites. There are also tools geared towards developing internal applications to help employees be more efficient (e.g. Appian, Retool, SalesForce Lightning, Creatio). And some tools allow developers to build cross-platform applications, taking advantage of an ever-increasing demand for mobile applications that can work on any device no matter what the operating system (e.g. Zoho Creator).

Naturally, these are just a few examples. Major providers from Amazon (Honeycode) to IBM (Automation Workstation) to Oracle (APEX) and others also offer low-code and no-code tools for almost any application. It is not a matter of finding low-code and no-code tools; it is only a matter of finding the right ones for your organization.

Conclusion

If you aren’t a DevOps organization already, chances are you soon will be. And you will need as many qualified DevOps team members as you can get your hands on. No-code and low-code DevOps tools are an easy way to build your stable of developers while freeing up your existing developers to focus their time on getting quality products out the door.

Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

• I still don't believe it

by Jonathan Allen,

• Re: I still don't believe it

by Leo Matousian,

• Re: I still don't believe it

by Daniel Bryant,

• Re: I still don't believe it

by Matthew Campbell,

• Re: I still don't believe it

by Daniel Bryant,

• Re: I still don't believe it

by Walt Grata,

• Low code is a crap, no code is a lie

by Leo Matousian,

• Re: Low code is a crap, no code is a lie

by Daniel Bryant,

• Re: What is a DevOps team?

by Matthew Campbell,

• Re: What is a DevOps team?

by Daniel Bryant,

• Doubt it

by Walt Grata,

• So....

by Andrea Del Bene,

• I still don't believe it

Your message is awaiting moderation. Thank you for participating in the discussion.

No code/low code is a myth or marketing gimmick. These platforms usually require you to write just as much code, but with a non-standard language that locks you into their platform. (And often I find that it requires more code to work around the limitations.)

And even when there are time savings in coding, which is rare in non-trivial applications, the real cost has always been in design. How quickly you type doesn't matter when 90% of your time is trying to figure out what the customer wants and how to translate that into something a computer can understand.

• Low code is a crap, no code is a lie

Your message is awaiting moderation. Thank you for participating in the discussion.

Phewwwww, another dumass article predicting no-code is the future, I'm wondering when this 'no-code future ' will ever be present since we've been hearing about it since 1990's or even earlier.

• Re: I still don't believe it

Your message is awaiting moderation. Thank you for participating in the discussion.

Exactly, no-code/ low-code tools are pure cancer.

• What is a DevOps team?

Your message is awaiting moderation. Thank you for participating in the discussion.

DevOps is developers doing Ops. In other words, taking full responsibility for running the app they build. It's about taking ownership, taking responsibility, and ensuring the quality of the code you can no longer throw over the wall.

• Re: I still don't believe it

Your message is awaiting moderation. Thank you for participating in the discussion.

Your point about the bulk of activities falling within the design space is valid, Jonathan. Those tasks are probably best suited for a full development team working end-to-end on the problem. As noted in the article, the impetus for using no-code/low-code is to help empower more people to solve common issues with automation.

As noted in the article, the idea is to empower more people to solve some problems to free up core development talent for complex problems:

But with more people in the chain and experienced developers focused on the most critical parts of the delivery cycle, organizations will find themselves delivering better products far more quickly than before.

• Re: What is a DevOps team?

Your message is awaiting moderation. Thank you for participating in the discussion.

When trying to sort out what a DevOps team is, I like to refer to this quote from Patrick Debois (from 2010):

The Devops movement is built around a group of people who believe that the application of a combination of appropriate technology and attitude can revolutionise the world of software development and delivery.

While no-code/low-code tooling is not a new thing, it might now be moving into the sphere of "appropriate technologies".

• Re: I still don't believe it

Your message is awaiting moderation. Thank you for participating in the discussion.

I'll +1 your comments, Matt. It's easy to be cynical about no code/low code tooling, and trust me I was with BPM and MDA tooling back in the 2000s. I still am somewhat skeptical today. Some of this was justified, but times are changing.

There's no denying the success of tooling like Zapier, UIPath, and Blue Prism. Objectively, the revenue and valuations of these companies are still outstanding even with the current macro climate (folks must clearly be using the products).

Anecdotally, when I was at KubeCon there was a lot of conversation about using these tools ("you can get very far with some APIs, AirTable, and Zapier" one SRE said to me").

Personally, I wouldn't be so quick to dismiss the value these tools can offer everyone, from business users to engineers.

• Re: Low code is a crap, no code is a lie

Your message is awaiting moderation. Thank you for participating in the discussion.

I don't think this is a valid argument, Leo. As the cliche goes, past performance/trends cannot be used to reliably predict the future, etc.

Some folks railed against IDEs in the 90s, but these have now become mainstream (except for the die-hard vi users :) ). Add in autocomplete and now tooling like Co-pilot and the future to me looks like pretty "low code".

It can take a long time for things to get into the right form factor and become useful.

• Re: What is a DevOps team?

Your message is awaiting moderation. Thank you for participating in the discussion.

Yeah, we all know that DevOps shouldn't be a job title and that DevOps teams shouldn't exist, but the reality is somewhat different and has to be acknowledged.

When I read "DevOps team" I silently replace this in my head with "the team(s) implementing DevOps principles".

I would disagree with your "developers doing ops" statement, too. It goes both ways e.g. ops using development practices, and also involves more than just these two teams.

• Re: I still don't believe it

Your message is awaiting moderation. Thank you for participating in the discussion.

This comment doesn't add much to the discussion, Leo. Can you at least provide some more context, please

• Doubt it

by Walt Grata,

Your message is awaiting moderation. Thank you for participating in the discussion.

These approaches are neat, but every "citizen developer" I've ever met has been completely useless when it comes to debugging problems. I need people that can solve problems on their own, not people who make problems for others.

• Re: I still don't believe it

by Walt Grata,

Your message is awaiting moderation. Thank you for participating in the discussion.

Can you back this up with a study?

• So....

Your message is awaiting moderation. Thank you for participating in the discussion.

...now they call 'low-code' what 30 years ago was Visual Basic :-)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p