What exactly is “Performance Engineering” in an enterprise environment?
While Performance Engineering has been used to describe developmental processes within the software community, it is commonly being used to describe methodologies and approaches that exist within other facets of the enterprise.
As with performance engineering within the software realm, there is no single cut and dry template or definition for what it comprises within the networking, systems, security, and monitoring realm. Rather, it is used to define a framework and a guiding set of capabilities and usages of those capabilities. Since the end goal isn’t a single product or workflow, but rather how to address the ever increasingly complex needs and expectations of IT, it is easier to compare enterprise performance engineering to DevOps.
For clarity, a short definition of DevOps is a merging of multiple silos for the sake of delivering business value through expedited software development, delivery, and bug identification/resolution.
Traditionally, enterprises have help desks, systems monitoring teams, tool teams, and perhaps even QA teams who do not work alongside those who actually created the code their environment is using or selling. This means that identifying a problem goes through multiple channels, monitoring systems, ticketing, or email systems and, therefore, has inherent inefficiencies. DevOps merges those silos and the teams work collaboratively to greatly increase the speed and efficiency of identifying and resolving new issues as they arise.
Modern IT has continued building similar silos and inefficiencies, and again faces business and technical requirements that cannot be efficiently met with bureaucratic team structures and fragmented toolsets.
In this scenario, modern IT enterprises have become fractured islands of sometimes contentious cooperation between departments. Perhaps those “server guys” blamed the network team just one too many times, and now they aren’t exactly best buddies. So, if there’s an outage, you don’t just have to rely on one of many tools to accurately report it, but you have to wait for each department to disseminate the information. Perhaps that information is valuable for the next time…perhaps it isn’t. Perhaps its communicated clearly and quickly…perhaps it isn’t.
In 2016, Gartner stated that the average IT infrastructure has 5+ monitoring tools, and EMA Network Megatrends 2016 reported the average enterprise has 4-15 management tools. These “islands of responsibility” and visibility lead to many of the problems that Forrester, Gartner, IDC, and others describe, providing a steady flow of statistics to support existence almost everywhere.
DevOps is more than a toolset, however. DevOps also teaches, and has years of data to help quantify and substantiate, that culture is its own asset within the enterprise. Key aspects of this culture may be familiar within your own career – for better or worse.
For example: DevOps thrives on open communication, not hiding one’s faults or mistakes, discussing what went wrong and collaboratively making an effort to resolve it as part of the underlying system and culture, and openly sharing ideas for the sake of innovation.
Sound familiar? In many enterprises, that might sound utopian and naively far-fetched. (If that is how you feel, you have our condolences, but also our contact information!) But it IS happening, and it’s happening today, and the movement is spreading. The State of Devops reports that organizations responding to their inquiries just recently began identifying “DevOps” operations around 2013. Yet that number has grown from zero to approximately 22% by the year 2016. (In 2015, Gartner predicted the number would be 25%. Well done, Gartner.)
Year after year, the companies with generative cultures, merged or collaborative silos, and progressive toolsets are the ones at the top of their industry. Just observe Amazon or Facebook. While your organization may not be a social media giant, or researching how to deliver home goods with drones, it doesn’t mean we can’t learn from them.
In answer to these silos of responsibility, fractured and numerous toolsets, and the fact that we already have multiple success stories to copy DevOps ethos and principles from, we now have Performance Engineering for IT.
While Swish doesn’t aim to fix everything at once, there is definitely one thing we can fix: the tools.
If every department is on the same page, outages are no longer phone calls, blamestorming, video conferences, emails, and MTTR’s that seem like recommended years of aging for a fine wine. Culture might be hard to fix overnight, but if an outage is immediately sent to the correct team with actionable information, and nobody is arguing about whose responsibility it is…well, we’re halfway to having it resolved. No longer do server guys possess a magic crystal ball that lets them know the servers are fine, while the network guys have a crystal ball looking solely at packets and netflow. That legacy approach didn’t scale with the growth of IT or the increasingly complex landscape.
So, if you ask Swish what Performance Engineering is, we’d say unified, comprehensive, and collaborative visibility and analysis – followed up by rigorous optimization. Simple words for the big picture requisites Swish fulfills!
(This is an introductory post to a small piece of Performance Engineering best practices. We’ll be covering many facets of it here in the coming posts, and look forward to you joining us for the journey.)