This is a series describing various architectures I have worked with in the last two decades and some of their benefits and issues. The table of contents of the series is here.
Velidom came out of the technologies that helped increase velocity, agility, and scale of the Evant development team. This was in the mid 2000 time-frame and Evant had created technology which did mass regression testing on every checkin, enabled continuous inter-team communication (including to India), and various other major features. Velidom was an attempt to productize this whole concept: The Velocity to Dominate with an Advanced Software Development Factory.
Major System Aspects
The Velidom Factory was built primarily out of Java-based technologies and VMWare ESX capabilities. The goal was to integrate into common tools at the time (Eclipse / Subversion / etc.), automatically launch testing and deployment servers on any given checkin, verify whether a commit was clean, and either push it through to the main development line or roll it out based on that verification.
Another side of the factory was an agile development tool that tracked features, their values, the tasks needed to complete them, and the status of everything. This was for planning, agility, and measuring. The automation was to increase velocity and ‘reality’ (if it didn’t successfully go in, it wasn’t in).
A final side of the factory was a set of communication tools for both real-time and knowledge accumulation, where both of these were hooked into the other sides of the factory so what everything was visible and memorable.
If you look at the Advanced Development and Delivery Environment you will see pretty much all of this vision manifested through other companies’ solutions. Ultimately Velidom’s vision was too big to succeed with the runway the startup had and the events that occurred during its’ lifetime.
AA-1 : Virtualization and Virtualized Desktops
Of all the architectural aspects that Velidom got right, virtualizing the infrastructure was almost certainly the biggest ‘Yes!’. VMWare ESX was expensive, but having that infrastructure in place made it possible to think about computation in a way very different from the raw hardware. Ultimately from Amazon EC2 through to Vagrant, this separation has come to pass as a higher-level-language of computational hardware. Virtualized computers can be built in minutes and discarded after being used.
Velidom provided virtualized desktops and servers as a service, and we spent the money and time building out the hardware, the virtualized server side, and creating a custom desktop client. The results were impressive, leading edge, unreliable, and expensive. Things were unreliable due to the client-server desktop communication paradigm. This needed good networks and a good protocol for the remote desktop. And given these were development machines, they needed to be secure, so each had its own private network. Again, this was too big a vision to succeed at that time. Focusing on just servers may have been viable, but it wasn’t clear what the value was without a large base of customers committed to good automated test suites (which is certainly plausible).
Expensive is relative, and the virtualization Velidom provided may have been viable except for an event that occurred in 2006. Amazon announced EC2, and suddenly the price point of virtualized computers dove to a number no one else could compete with. Even 10 years later, there are very few viable cloud providers, and no small ones.
AA-2 : Tool Integration and Improvement
One of the core Velidom concepts was the integration between tools (e.g. Eclipse) and the functionality we provided. We had Eclipse plugins to do things within the factory, including chat, logging, automation, and other activities. Integrating directly with a tool is nice, but definitely development expensive. And the tools you are connecting with (Eclipse and Subversion) may ‘go away’. In 2005, Eclipse was a good choice, but if we had customers on a Microsoft development stack, they might have been unsatisfiable.
The core problem wasn’t picking the right tool, it was picking any tool before having a Minimal Viable Product. Tool integration is not part of Minimal Viable: if your product is good at group chat, people will start using it. A full suite of products (the Factory) is also not part of Minimal Viable: whether chat or automated regression testing, just get a product done and in the hands of customers to get feedback. If they like your product, they will drive integration with their favorite tools or your other products as an important improvement.
AA-3 : Reactor
The last architecture from Velidom that I am going to mention is the ‘reactor’ or ‘queue’ pattern. Doing a mass regression test with servers being created on the fly takes time. Separating the ‘request’ from the ‘task’ to complete the request is very effective for both scaling and also avoiding needless scaling. If the automation is fast enough, you don’t need to scale. If you don’t have the extra money to buy the bonus performance, you also don’t need to scale. You can choose whether to pay for time or not.
The one aspect that for a codebase or similar ‘team progessive’ activity is whether people wait for things to finish. Ideally, you are ‘unblocked’ while you wait: you can go on to something else. But in a team environment, many people are trying to get there work in the main codebase of work. With Subversion, we had to do some annoyingly fancy tricks to extract a bad build. With Git and faster testing tools (in memory databases, better functional test declaration languages), this is far less of a problem.