Co-opetition at F5? Or, right tools for the right job!
Configurability versus productivity
A long time ago, in a dark room far, far away, I wrote code. While at the time I thought it as exciting as being tapped into The Matrix, I will admit that the only real semblance came from the fact that I used a green font on a black background – years before the trilogy was made. Ha! Admittedly, those colors were the only available to me on that platform but I digress. Coding: I wasn’t very good at it and would never refer to myself as a ‘developer’ but some of the work could easily have been categorize as ‘neat’.
Having an understanding of object-oriented programming (http://en.wikipedia.org/wiki/Object-oriented_programming), did provide useful insight into application behavior - particularly in relation to resource consumption. But it DID NOT provide me a route to solving a lot of the application or network problems I encountered. If anything, it provided greater frustration. Not unlike that I recall experiencing in secondary school when provided with paint and canvas, and yet could only muster disappointment. The programming language is no more than potential. The competency of the coder is the path to a solution.
This great divide between the hack (me) and a useful solution is also how I became a Mac user. Apple’s OS X operating system gave me a comfortable migration path from a highly-configurable BSD Unix environment to a more productive commercial operating system – OS X is BSD-like underneath while smooth and shiny on top. By highly-configurable I refer to all the source code of the open source BSD operating system being available on that system allowing me to manipulate it to do anything I wanted, and by productive I refer to an operating system that has most of what I want/need already baked in eliminating the need to re-configure/recompile my days away in the pursuit of nirvana. Further to this is the improved collaboration with peers on a commercial OS - both Outlook and Lync clients connecting me with the rest of the organization.
Creator or consumer?
Fast-forward ten-plus years and now the idea of building a Unix/Linux workstation is terrifying. I don’t need that level of configurability any more; extreme configurability requires focused expertise. And one needs to live and breathe that level of configurability to be efficient with it. With this evolution came the need to accept one is no longer a creator of software. Today, I am only a consumer.
Having lived on the other side of the fence has instilled in me great respect and appreciation for those who continued to live among the configuration files, source code and Application Programming Interfaces (API’s). Those delivering the magic that gets the rest of us the information we want in its many forms and on the many platforms and devices upon which we consume.
So, TMOS or LROS?
Its time we got to the question that started this post. F5’s Traffic Management Operating System (TMOS, found on BIG-IP) or F5’s LineRate Operating System (LROS)?
The shortest way to qualify this question would be to ask, “Are you a developer?”.
NOTE: For the purpose of this article, we focus only on the data path API’s. On TMOS this is iRules (TCL) and on LROS we have Node.js
For the TMOS corner, I refer to Colin Walker’s DevCentral post “iRule Concepts: TCL, The How and Why” where he discusses the creation of iRules:
“When considering usability in this case it is important to remember our target audience. The people generally managing these systems are not full time programmers. As such, making use of a simple, easily readable language that is quick to pick up and master, and easy to read and pass from one user to the next makes a lot of sense.
The simplicity of Tcl plays into less overhead to the user when it comes to understanding the commands and tools available just as much as it plays into the system overhead required to load. It makes sense, I think, that a language with far greater capabilities and extended commands, memory structures, modules, etc. would take more time and effort to master. Given that doing so is often not the primary role of the individuals we hope to appeal to with iRules, the simpler approach makes more sense.”
So, TMOS was designed for configurability with a strong focus on simplicity, specifically for the non-developer. On the other hand, in the LROS corner, we have LineRate co-founder, John Giacomoni, who, when discussing the decision to use Node.js in LROS, said:
“…a large and active community; as of this writing the NPM repository has almost 50,000 packages and over 30 million package downloads per week.”
“Finally, node.js is built on top of Google’s V8 javascript engine that delivers amazing performance allowing for complex tasks to be accomplished using a full-featured language rather than us creating a networking optimized language.”
A Network optimized language, like iRules?
Conclusion
Had I retained any of the smarts required to tango with a clever API like Node.js I’d be all over that right now. So, having never mastered the art of code-fu, its strictly the simplicity of iRules for me. But I think its clear that there is no need to ask the question, TMOS or LROS, iRules or Node.js. Both have their audiences and respectful creators.
So, the question that remains. Do you code?