Many organizations have radically changed the way they build software applications. They’ve gone all-in on agile development of cloud-native apps, containerization, and cloud architectures.
This of course has changed many of the tasks development teams do on a daily basis. Among these teams, new work cultures have sprung up around these different activities and workflows.
There are, however, some aspects of these cultures — and developers’ thinking — that haven’t leapt quite as far forward as how they build apps. The way developers approach some parts of their jobs looks a lot like they did years ago, before agile and cloud dominated the landscape.
One example of this is ensuring application performance. Despite how dynamic modern apps have become, being spun up or down on demand in just seconds, the management of their performance is nowhere near as versatile. In many (or most?) shops, the performance of these apps is still being handled with what can only be described as legacy, reactive approaches and ‘old school’ thinking.
It’s a mismatch that can cause a range of operational, financial, and team problems. Let’s take a look at why this cultural disconnect exists and what organizations can do to fix it.
The issue can be partly traced back to traditional software development approaches. These older approaches, such as the ‘waterfall’ model, were fundamentally linear and sequential. Projects were organized into detailed and pre-defined phases. There were buckets for activities at the beginning, middle, and end of the dev process, and there was very little overlap.
For example, the QA phase came after the development work was mostly or entirely completed. It essentially was a separate, post facto function done in isolation. Performance testing in QA was part of these teams’ separate and distinct workflows. The separate nature of these teams’ responsibilities led to the creation of separate and distinct work culture for the QA function, including the performance management pieces of it.
Once the QA process wrapped up, the app would be handed off to production, another world unto itself. Production is the real world where real business is done with real customers. This reality led to the creation and build-up of another culture or mindset around application performance management, with its own separate rules and requirements.
Apps had to work in order to make it into production. So, the baseline expectation was that things would work as advertised. For a backstop, teams mostly relied on a reactive, monitor-and alert approach to find and fix performance issues. Other performance evals were done only occasionally and sporadically, in ‘random acts’ of performance testing.
To sum it up, under the traditional software development model, application performance testing and management was done only in the later phases of development, done episodically in various buckets, and almost always done reactively, only after a problem was experienced.
These cultural traits, ways of thinking, or ‘muscle memory’ ways of doing things as they apply to performance management, seem to have carried over into today, into the modern application era we’re all living in. The problem is that things happen too quickly with cloud-native apps. Any kind of separate, compartmentalized, and reactive performance management approach simply will not work in this new world.
With the ‘Waterfall’ era of software development rapidly fading away, the DevOps approach is now how apps are normally developed and delivered. The term DevOps means slightly different things to different people, however, so for clarity’s sake, we’ll go with Gartner’s definition:
“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. This speed enables organizations to better serve their customers and compete more effectively in the market.”
Note Gartner’s explicit reference to the “cultural” aspects of this approach. But hold that thought; we’ll come back to it…
“DevOps” is a portmanteau – the combining of two words to form a new one. It’s also accurate because it describes what actually happens. Formerly separate development and operations teams get combined into a single unit. The idea is to get away from silos, and have dev and ops staff work with apps throughout their entire lifecycle. From design and development, through testing and QA, in production, and all the way through to end-of-life, DevOps people stick with their apps. They conceive them, build them, and manage their performance from start to finish.
DevOps is an effective approach because, as Gartner points out, it can deliver innovation with more speed and effectiveness.
However, re-engineering the formerly siloed and sequenced dev and ops functions does present organizations with some cultural challenges.
DevOps promises faster innovation, but it requires a cultural change
Broadening roles and asking DevOps team members to take on new responsibilities isn’t a problem. But the cultural carry-overs mentioned above can be a hindrance. They may cause DevOps team members to revert to old ways of doing things. Or, over time, they may begin to view new parts of their jobs as dull chores rather than interesting challenges. When things like this happen, teams find themselves on the slippery slope of ineffectiveness.
What can organizations do to head off these problems, to keep DevOps people engaged from stem to stern? How can enterprises facilitate great application performance from the first day an app hits production until its last day in use?
Here are some strategies leading companies are employing to make the change to establishing a performance culture.
The good news for DevOps teams and their organizations is that technologies are available today that will help them to take the steps outlined above. By layering in new, advanced techniques in fields such as data science, and leveraging them on innovative foundations built on artificial intelligence and machine learning, new categories of platforms and apps have arrived. These new tools are enabling teams to rethink and redefine how they handle application performance.
AI- and ML-based systems are especially well-suited for solving complex problems such as analyzing and calculating the right settings needed to get optimal performance from a cloud-native app, and automating the process of making those changes continually and in real-time.
With this type of functionality, organizations and their DevOps teams can adopt a performance culture.
They can evolve their views of not only the value of performance management, but the prestige of choreographing it against the challenging backdrop of cloud-centric environments. They can reshape their performance management approach from being reactive and slow to proactive and lightning-fast. And they can use proactive performance management to stop chasing problems and instead, stop them before they happen.
That’s the new performance culture we’re helping to make achievable for any organization. To get there, they need to make performance an integral part of their release processes and CI/CD workflows. They need to retool so they can automate the process of configuring applications to optimize for performance, stability, and cost. And they need to always be in proactive mode when it comes to testing, analyzing, and optimizing their applications.
The future is in plain view right in front of us. Getting there requires an appreciation of new performance management requirements and their importance.
The technology is ready and commercially available. To make that critical first step, the only prerequisite is that you bring that new performance management mindset. You can do that, right?
We use cookies to provide you with a better website experience and to analyze the site traffic. Please read our "privacy policy" for more information.
