Picture this – The operations team has spent months developing a hard-won understanding of technical bottlenecks and application-specific performance issues only to discover that this knowledge is no longer valid after a new feature launch fundamentally alters the way the app runs. The result? Slowdowns, errors and crashes.
It’s a common enough scenario. Development organizations are under pressure to release software at light speed, making conversations between Dev and Ops teams seem like a luxury at best and a derailing of critical resources at worst.
When Dev and Ops aren’t talking, developers may find the environment isn’t configured for the products and features they’re building, which can lead to application performance and availability issues or any number of other costly inefficiencies. The Ops team, in turn, may not understand the application requirements and consequently overprovision (or worse, underprovision) resources. This lack of actionable insight into the IT environment can result in slow or underperforming apps, along with even bigger impacts on the organization’s bottom line.
Dev teams want to focus on new releases. Ops teams want to stay in the loop and continuously gauge the reliability of those releases. In the tenuous power struggle that results, Ops may be perceived as a roadblock, prompting Dev to look for ways to sidestep Ops restraints or bypass them altogether. Inevitably, application performance suffers.
Silos don’t work, and most companies know it. But eliminating silos isn’t easy to do, and in the meantime companies feel the Dev vs. Ops pain.
Application performance sits at the nexus between development and operations. Understanding the good, the bad and the ugly of application performance first requires an understanding of the application code – how it’s structured and intended to run – along with infrastructure requirements like server and database size and network bandwidth.
Here are five steps for optimizing application performance:
Integrate DevOps best practices into the organization by identifying a champion committed to creating and overseeing a plan, building buy-in from Dev and Ops and calling out problems along the way. Many companies have trouble making this cultural shift on their own, which is where outside help may be most practical. Look for an objective observer that can sidestep the politics and won’t shy away from the tough conversations – all while respecting the dollars and mindshare required.
Learn about the development goals and the strategy for accomplishing those goals. An app written in Ruby won’t have the same requirements and issues as an app written in Java. Start with individual servers. Are they CPU bound, memory bound or network bound? How do different services talk to each other, how much network bandwidth do they require and is there a better way to use that bandwidth?
Review the individual services used by the app, and work to understand how the application is accessing each of those services and what it’s trying to do. For example, if large database calls lock the database for long periods of time, the application might be reprogrammed to use smaller calls that reduce the load.
Channel ongoing Dev and Ops insights to stay on top of the volume, velocity and variety of configuration changes. Raise red flags early and often to make sure apps are adequately tested before they’re released.
Iterate. One and done doesn’t apply here. If you eliminate a network bottleneck between your servers and your database, you may find that the next bottleneck is the database itself. (For example, maybe it lacks the memory needed to respond to all the requests coming across the network.) The point is to address bottlenecks in priority order so you can shave minutes or even hours off future troubleshooting.
When Dev and Ops teams collaborate up front, Ops teams can stop being firefighters and start actively contributing to the development of applications with optimal performance.
To break down silos, you need to know what’s coming down the pike and adopt more strategic ways of working. A true DevOps culture encourages quick-turnaround design, reliability and accountability, making it more about people and processes than about the underlying technology. Simply put, companies that embrace transformative DevOps/SRE-type integration methodologies outstrip the competition.
