Programmability in the Network: Traffic Replication
#nodejs #linerate #devops Why waste time generating fake data to test when you can use the real deal?
There are a plethora of tactics used to test applications as they move to production. For example, as a developer I've created data and captured data for testing and - my favorite - ignored testing altogether. After all, it worked on my machine.
The reason there are so many tactics is there are so many ways in which real users - and thus real data - can expose all sorts of errors and defects in software. From logic flow interruption to corrupting databases to unintentionally writing over the end of a length limited string to wipe out some other piece of data in an adjacent memory location*, the possibilities of how real users will interact with and invariably mess up an application are virtually limitless.
Optimally (for the business, for the developer and even for the user) the best scenario is one in which real users and the data they input (sounds like that would be a good book, wouldn't it?) would be used to test new versions of applications.
In most cases, this is ultimately what happens when the application finally makes it into production because no matter how hard you try you're going to miss a corner case (or three). Even if you tested for weeks, once real data and users hit the application you're going to find problems.
The solution is to replicate real user data and interactions on pre-production versions of applications transparently. Turns out this is fairly easily accomplished - if you've got the right tools.
Application Proxy to the Rescue
Production application traffic replication can be easily accomplished using an application proxy and a bit of node.js. By deploying the proxy in front of the applications it can be directed (via node.js) to send incoming user requests to both the production and staging (or pre-production or test or qa or whatever you call the environment right before production. You do have an environment right before production, right?) applications.
The trick is, of course, that you only want one of the responses (the one from the production version) to return to the user. Which means you've got to catch the response from the staging version and discard it (or log it or whatever you want to do with it - except send it back to the user). A proxy by design manages this scenario quite well, with no disruption to the network.
Network-minded folks will instantly recognize this pattern as one implemented by spanning ports or mirroring traffic (or sessions) at higher layers of the network stack. It's a well-proven and tested pattern that enables developers and devops to really test out an application - from logic to data handling - using real user data and interactions.
F5 LineRate Proxy is able to easily implement this scenario. You can learn more about (and download a free version of) LineRate Proxy here.
* Hey, we used to play with pointers in my day, all the time. If you weren't careful you could do some really, uh, interesting things to an application.
