The MacVittie-Roberts Wall of DOOM

#devops #webperf Continuous Measurement needed.

Performance. Speed. Velocity. Quality of experience.

No matter what particular turn of phrase we use to describe it, the reality is that we'll try a whole lot of things if it promises to improve application performance. Entire markets have been dedicated to this overriding unqualified principle: faster is better. 

That implies, however, that we know what faster means. Faster is relative to some baseline; some measurement that's been taken either on our applications or our competitors. Faster means improving existing performance, which necessarily implies that at some point we've actually measured that performance.

Unfortunately, as much as we chide developers for just throwing applications over the wall to operations, all too often operations just tosses that same application environment over another wall to the end user. And leaves it there.

This is something that fostered conversation a few months ago on Twitter thanks to the revelation from a study sponsored by Germain Software, LLC.indicating that "43% of mission-critical apps experience performance issues once a week."

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Now while we kidding around about naming this wall the "MacVittie-Roberts wall of DOOM", we weren't kidding about the need for better performance monitoring in production.

After all, to definitely say that application performance is faster requires that we've measured performance after some change.

You might notice that various forms of "measure" are bold. I could also italicize them, if it makes it would more clearly emphasize that measuring performance is critical to both improving and maintaining it.

That means measuring before and after measures are put in place to improve performance to ensure you didn't possible, oh I don't know, degrade performance.

DevOps isn't just about getting an application to production faster. Oh, that's a big driver right now and the value inherent in doing so can absolutely justify an investment in going "DevOps" on your operational status quo. But just as important is the ability for DevOps to adjust, to tweak, to tune, to fix issues that arise in production in a more efficient manner.

To do that requires awareness that there exists a problem, and when it comes to performance that means monitoring (measuring) performance in post-deployment (production) environments.

Performance remains a top line concern, and therefore we should be mindful of ensuring that the applications which we are tasked with deploying are as fast as they possibly can be. But we can't do that unless we know how different settings, devices and services are impacting performance. Which means continuous measurement.