freshidea - Fotolia
The relationship between a development organization and IT operations has always been characterized by butting heads and protecting one's turf. Cooperation has existed as a goal of competing IT factions to prevent mutually assured destruction and a loss of IT credibility. Now there's a new approach, one that replaces a shotgun wedding between development and operations with NoOps, meaning no IT operations.
Don't think of this as a future where data centers are vast empty spaces in which happy developers can play soccer out of the elements. Like most things in tech, IT operations is part planning and part execution. The NoOps concept shifts the conceptual side of operations -- planning -- from a separate IT staff to the developer organization. Developers would exercise their plans through an expanded use of automated tools. You still have servers and data centers, but your development team controls them.
The tools that create the basis for NoOps are popularly called DevOps tools because they support the cooperation needed between developers and operations. These tools aim to ensure that the needs of applications are reflected in IT operations and architectures. NoOps is essentially DevOps to the extreme, creating a level of operations automation so profound that just a few operations people stick around to keep the lights on.
You'd have to believe that a developer invented the NoOps concept. You'd also have to wonder whether the IT operations organizations of enterprises might not be promoting a NoDev model. We've had a NoDev movement for decades; it's called third-party packaged software, and most businesses, in particular small and medium-sized ones, have no development organizations at all. So is NoOps just "turnabount as fair play?" Will developer cubicles be turned into garden plots for the IT ops staff? Actually, both NoDev and NoOps are just extreme reflections of IT populism. We have more companies committing to IT even as IT is getting more complicated.
In the early days of information technology, IT belonged to big enterprises, which built software, wrote middleware and created operating systems all for internal use. IT operations just ran the developers' stuff. As the number of companies that wanted the benefits of IT grew, it was impossibly inefficient to each build their own software. Imagine someone running out to buy a bunch of PCs and then hiring a team to build their own versions of Windows and Office. Packaged software came along, and many companies rely on it exclusively even today.
Deployment is also more complex than ever. In simple dedicated-server deployments, the operations team installed package software and let it update itself periodically. In the world of multicomponent applications that spread dynamically across public cloud, multicloud and hybrid configurations, it's not that simple. Add failover and cloud bursting to all of this, and you can see how components of applications could be left hanging somewhere, on resources the company is paying for, lost forever. Even third-party software often necessitates support from DevOps tools to manage the complexities of virtualization-plus-cloud deployments. Application developers can't ignore these trends either.
The intricacies of IT operations
The mission of development in DevOps is to create deployment instructions as part of the application build. That's true whether the development is in-house or in some third-party software company, or if it's a mix of internal and external expertise. If we're evolving development toward code generation and plug-and-play applications building from components, it's not hard to imagine a world where a whole application lifecycle is defined by dragging the pieces together and sending it to a super DevOps tool for deployment. It's this model that seems to make NoOps feasible.
But remember all those complicating deployment issues? Componentization of applications is something developers must learn, but do they have to know about virtual machines versus containers, software-defined networks, multi-tenant clouds, hybridization and multicloud services? How about cloud bursting or failover? If your developers are doing all this stuff, how are they finding time to write code? Can third-party software ever anticipate all the possible configurations where it may run?
Sometimes in conflict resolution, you step back and take stock of the situation. The driving principle of NoOps is operational automation -- the use of software automation concepts for the whole application operations lifecycle -- so that each deployment, redeployment, scale-in or -out, and replacement of a failed component gets handled automatically and without human error. This critically important principle should be the goal for all users. Where it takes each user is just a matter of how that user can best apply it.
Some cloud-centric startups and web or social media companies can pare down operations staffs to a very low level, low enough to qualify as a NoOps commitment. Many small and medium-sized businesses will get DevOps automation with prepackaged software, and thus, will also have little or no IT operations staff. Does that make them a NoEverything organization? The nature of the development/operations tradeoff will always be dynamic; it will always reflect the nature of IT operations within each business.
The average enterprise IT user won't see NoOps in their future, just as they won't see a pure third-party-software NoDev configuration any time soon. Most companies will have a mixture of development and operations, and most will find the complexity of the mission of each group increasing. Companies can gain competitive advantage through custom software. They can also pull ahead through efficient use of IT resources. You can't make IT operations staffs build and change software, nor can you expect developers to spend time planning for virtualization, server configuration and cloud bursting.
DevOps, not NoOps, is the framework of the future of enterprise applications. With the right choice of tools, a business can accommodate internally developed and third-party applications, as well as the full range of hosting options emerging. Most important, enterprises can alter their commitment to these choices dynamically as their goals, and as technology, evolves. That's always the best approach.
IT stays in a DevOps model, but evolves into something new
Accommodate componentized applications on IT resources
How major businesses do DevOps