Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.
The State of DevOps in the Enterprise
Automating IT Infrastructure changes would make Agile application deployments even faster. How far away are we from supporting that shift?
5 Min Read
Kirill Ivanov via Alamy Stock
DevOps was designed to foster collaboration between applications and operations in the planning, creation, and deployment of applications and systems. In a very real sense, DevOps has always existed.
Application developers, database specialists, network specialists, and operations specialists get together in planning sessions before major application or system projects are started. In these meetings, a cross-disciplinary team of developers, system programmers, network specialists, and database analysts look at each project from all angles to see what the total project impact will be on IT resources and infrastructure.
From a project perspective, these preliminary meetings are needed, because you really don’t know how large a project will be until you understand how the underlying IT infrastructure must be modified to support a new application. IT infrastructure changes can become major work, such as changing the schema for a database, adding more bandwidth and hardware to a network, implementing new operating systems, or modifying system operations modules and subroutines. As a project moves forward, all these changes must also be integrated, go through quality assurance, and be checked for performance.
In an ideal world, DevOps is supposed to deliver increased automation of this infrastructure-fitting work for new applications that are developed in methodologies such as Agile. The end goal for both Agile and DevOps is to speed application time to market, with everyone working together on every aspect of the project, from application development to infrastructure integration to QA testing and then to deployment.
Remember: What IT and end users would like to see is DevOps automation that can keep pace with Agile, as well as with other development methodologies like no- and low-code apps.
An illustrative example is the development of a low-code app.
In low-code application development, an end user can point and click in a user-friendly interface on programming logic and data choices to build an app without knowing any underlying code. The user can do this because all of the access paths and logic for this push-button program building is automated and done for him.
However, this user has no knowledge of programming or of the IT infrastructure (e.g., other systems, databases, networks, operating, and security subroutines. etc.) needed to fully install and run this new app. At this point, the low-code app goes to IT, which completes the app’s integration, testing, and deployment.
Meanwhile, the user gets frustrated, because he is -- once again -- waiting for IT.
DevOps solutions providers want to solve this dilemma. They want to make DevOps so automated and seamless that IT doesn’t have to get involved at all, and users don’t have to wait for IT services.
Unfortunately, few if any sites have fully automated DevOps solutions that can keep pace with Agile, no-code and low-code application development -- although everyone has a vision of one day achieving improved infrastructure automation for their applications and systems.
Here are some popular approaches and practices to consider today:
Take a hard look at infrastructure as code (IaC).
Infrastructure as code is a method that enables IT to pre-define IT infrastructure for certain types of applications that are likely to be created. By predefining and standardizing the underlying infrastructure components for running new applications on Linux, for instance, you can ensure repeatability and predictability of performance of any application deployed on Linux, which will speed deployments.
Many IT components (such as networks, virtual servers, connectors) can be defined within this infrastructure. Containers are great examples of IaC. So let’s say that you want to run a new app across all your different operating systems (for example, Linux, Windows and MacOS) used by your users. You can do it with the press of a button because the infrastructure is already in the respective containers where the app will run.
Understand what you are getting into when you start using IaC.
Moving to IaC is no slam dunk. It means that the IT group will have to abide by rulesets and guidelines, such as not changing underlying infrastructure configurations on the fly, which defeats standardization.
The tradeoff is that apps might not run as efficiently as they would if you could fine-tune infrastructure for each app’s optimal performance.
Consider the cultural ramifications of moving to IaC and DevOps automation.
If you’re moving to more operational automation and methods like DevOps and IaC that serve as back-ends to applications in Agile, no code and low code, cross-disciplinary teams of end users, application developers, QA, system programmers, database specialists and network specialists must team together in an iterative approach to application development, deployment and maintenance. This will require more meetings and the ability to empathize with end users and business objectives, which is not always easy for technical specialists who prefer to work on their own.
Tighten up IT version control and deployment standards.
Too often, an application breaks and IT springs into action to quickly apply the fix. Unfortunately, in the field of battle, these fixes aren’t always universally applied to other applications that need them. What DevOps automation can offer is a way to automate and universally apply a fix, as well as a way to control versions. This automation can work, but only if IT abides by the rules and doesn’t try to work around the automation.
Don’t forget security.
Security is seldom mentioned in Agile, no- and low-code discussions. It would seem that the assumption is that somewhere along the line, IT will take care of security.
From January-May 2024, almost 36 million known records were breached.
The bottom line is that security is a very serious issue, and it is one of the elements that must be integrated into Agile, no-code, low-code, DevOps, IaC, and DevOps development as a topmost concern, and not as an afterthought.
About the Author
You May Also Like
More Insights
