The starting point

To understand the distance we’ve come, it’s also important to understand where we have come from and what the challenges were: from my limited startup experience, it seems to me a very common pattern, and I’m hoping that by sharing my experiences here (which are almost identical to what I had to endure at SnapLogic, but hopefully with a more rewarding outcome) others will be able to benefit from it and, who knows, avoid those mistakes in the first place.

Badly burned by the SnapLogic experience, before joining RiverMeadow I’d even asked (and obtained) access to the code base to review; to this day, I’m still amazed at how badly I missed the obvious signs of impending doom: the only reasonable explanation I can imagine, is that I probably wanted to leave SnapLogic so desperately, that my brain refused to recognize what was otherwise plain to see.

The original so-called “SaaS platform” was in fact a single Java Tomcat app (WAR) calling out to a bewildering array of intricate Bash shell scripts for the low-level operations; a smattering of C code, whose purpose and raison d’etre, to this day, still escape us; and a persistence layer using HSQLDB (I’m not kidding).

Unit testing was virtually non-existent and, in fact, impossible to implement for the Bash scripts (to make matters worse, they had accumulated over the years, some were no longer used, others we weren’t quite sure, others yet were used, but we were not quite sure whether what they did was of any use).

There was no multi-tenancy (at one point, one of the founders decided that to implement multi-tenancy all we had to do was to create sub-directories for the server images – again, I’m not making this up) and security was virtually non-existent (they had been using Samba for the file transfers, and were only now slowly moving to SSH).

It should then be of no surprise that release dates had been missed, by months, and even planning releases was a challenge: the product planning, features and roadmap was all up in the air and it was virtually impossible to plan ahead – due to the intricacy of the code; the inter-dependencies; and, most critically, the absence of unit, functional and (automated) integration testing (there was a minimal – and, I’d soon discover, massively inadequate – amount of manual testing): we often found ourselves in the crazy situation that fixing a bug, or adding a feature in some parts of the product, would cause unexpected breakages in others, unrelated areas – we were never sure whether those were undiscovered bugs suddenly exposed, or new ones introduced.

Finally, we were only able to support a handful of OS platforms (4 Linux distros and 4-5 Windows 2k3/8 variants) migrating to one target cloud (vCloud).

So, dear reader, how do you go from there to a bi-weekly release cycle, with full secure multi-tenancy, Enterprise-grade security, fully scalable architecture, highly-available (HA) persistence layer using Cassandra and MongoDB (for replication and multi-DC support – both for redundancy and geo-diversity) and supporting a QA-certified 20 OS variants (and counting: we should have 24 or more in the next couple of weeks) to four cloud targets: vCloud, vSphere, Amazon AWS, Openstack (and soon Cloudstack too)?

Not only that, but we continue to add features and functionality: we just enabled the ability to include/exclude directories from the migration; we’ll soon have post-migration file-sync capabilties; the ability for the user to define pre- and post-migration custom operations; metrics, monitoring and reporting; and so on and so forth.