DevOps, as mentioned in one of my previous articles, is about Developer-Operations. One aspect of DevOps people overlook is about ensuring your building healthy systems.
When I was previously responsible for Quality Assurance and Operations Developers, I become really focused on ensuring our team was building healthy systems, not just quality systems. What’s the difference between a healthy system versus a quality system? One might think they are one and the same, but in my opinion, they are very different. Let me try bring this down to a personal level while I relate this to a system development level.
A couple of years ago, I started playing basketball again with a recreation league. I used the gym on an irregular basis, rode my bike every other week for about 10-20 miles, and so on, so I felt I was in okay shape. Before I undertook the journey of playing on the court in a game, I went to the doctor to get a physical to make sure I wasn’t due to for a heart attack or something worse if I started playing again. The doctor ran a series of tests on me and in a couple of weeks, he gave me the “all clear” sign. So when it came to game time, I felt I was in good shape to play "big boy basketball." Turns out, after a couple of fast breaks, transition defense sprints, and fighting for position for rebounds, I was pretty winded and felt like passing out.
Now let’s take this story and apply it to system development. Going to the gym, riding a bike, etc. could be equated to activities that an individual developer does. They write code, they compile it, and maybe do some light testing. Going to the doctor for physical is like taking your application and giving it quality assurance (QA) to test. Often times, QA only focuses on the tests they are aware of for a given release, maybe some basic regression tests, and make sure things are working as designed and within established parameters, thus ensuring that what the developers have built is a "quality system." Once the application has been deployed to production (aka big boy basketball), you get to see how well the quality system scales. The application performed well under the standard battery of tests (much like the human body does during controlled conditions), but when accessed by hundreds and thousands users, the system could start locking up, performance becomes extremely bad, and so on. What we find is that this quality system isn’t a very "healthy system."
How can you check to see if your application is a healthy system? This can be done by taking testing to the next level, which is executing load and performance testing against it. I’ve seen too many companies wait until the final stages of deployment to determine if their system can scale to level they’ve promised to their customers.
Some companies wait until the end to do this sort of stress testing because the cost of setting up test rigs can be expensive because they have to pay for virtual user licenses. Using Visual Studio Ultimate, in addition to all the developer benefits the IDE brings, it comes with the features to do Web Load and Performance testing for up to 250 virtual users on the local workstation, but it can also be configured with full test rigs with an unlimited number of virtual users. You’re only real limit is the number of virtual users your rigs can scale to.
If you think back to the basketball example, instead of waiting until game day to see if your application can scale, using load and performance testing during practice (integrated development) and scrimmages (QA), you can become real confident that the system you and your team is developing is not only going to be a quality system but a healthy one, too. If you haven’t looked at Visual Studio Ultimate lately, I recommend you do. To see how you use Visual Studio for Load and Performance testing, check out the Introduction to Web Performance and Load Testing with Visual Studio Ultimate 2012 Hands-On Lab documentation.