I’ve started a new job as CTO for CohesiveFT. It’s a great company with a great team and some great products and services. As I’ve known many of the people since before the company was founded this post could be subtitled ‘a brief history of CohesiveFT’.

The people and pre-history

Alexis Richardson was the instigator. He’d seen that the financial services industry was building lots of software that did basically the same stuff (and added no differentiation or value to the firms involved), and though that open source was the answer – along the lines of JP’s open source first approach[1]. The idea was to bring together a syndicate of banks to create a mutualised open source platform (predominantly for the back office). This went by various names as he sought interest and investment (OpenClub is one I remember best). There was even some hope that firms might contribute existing platforms – I think the whole concept of technical debt was less well understood then, but the project had legs even if it was just for new stuff[2].

Alexis wore the title of ‘Founder’ when CohesiveFT came together. Later he teamed up with Matthias Radestock at LShift to create RabbitMQ, and implementation of the AMQP message oriented middleware protocol. RabbitMQ was spun out of the CohesiveFT/LShift partnership to be acquired by VMWare (in a for them classic engineering led infanticide deal), which took Alexis away from CohesiveFT to be an executive at VMWare. I’m sure he’s doing something pivotal for the Pivotal Initiative these days.

I first met Craig Heimark in a pub near Liverpool Street. Alexis was camping in the offices of Evolution, where Craig was one of the advisors, and it had been suggested that Craig might be interested in the OpenClub project. With a background in trading, risk management and senior IT leadership Craig was the perfect person to see the potential of the project, and well placed to help find investors. Craig certainly was interested, and went on to become founding CEO of CohesiveFT.

Shortly after the meeting with Craig and Alexis I saw a blog post from Patrick Kerpan announcing his departure from Borland (where I’d got to know him after they’d bought his source code management company Bedouin). I knew that Pat had worked in financial services before Bedouin, and thought he’d be a perfect addition to the OpenClub project. What I didn’t know at the time was that Craig and Pat had worked together back at O’Connor & Associates (and subsequently Swissbank following the [reverse] takeover), so at the same time I was introducing Alexis and Pat to each other Craig was doing the same.

Pat was interested enough in the project to come out to London and meet with people to discuss its potential, and I recall a lunch meeting in Canary Wharf where all four of us got together. Pat asked me what I thought was going to be hot in the industry and my answer was ‘software appliances’ (as that’s what I’d been calling them), though I noted that VMWare were holding their first ‘virtual appliance’ competition, so it seemed likely that would be the term that would take hold. Pat had made a comment to me years earlier that “installation is a software hate crime”, and it seemed that there was much to like in the idea of packaging stuff up into a deployable virtual machine. A few weeks later Pat called me (with some excitement in his voice) to say that he was going to make a virtual machine factory. Pat joined CohesiveFT as founding CTO, and their first product had been conceived.

Server3

Server3 (Server Cubed) was originally christened Elastic Server on Demand (ESoD), a name that lives on for its SaaS implementation elasticserver.com. As a virtual appliance factory it takes a ‘bill of materials’ (which might also be thought of as a recipe) for a virtual appliance, and then assembles that appliance to a given output specification. The end result is that functionally identical appliances can be put together for a range of different operating environments such as the virtualisation platforms used in many private clouds or the deployment packages used for public clouds (which Server3 can deploy to directly).

Since having a factory industrialises the process of putting together software for deployment it can borrow from other aspects of industrial design, so it’s possible for the appliances made by Server3 to have a common ‘chassis’ to provide consistent interfaces for monitoring and management.

I’ve used Server3 in the past for some of my own projects, often taking advantage of its ability to integrate directly with Amazon Web Services such as EC2 and S3. More recently Server3 has recently added support for IBM SmartCloud where it’s able to add diversity to the image library that comes as part of the standard service. Most exciting for me right now is that OpenStack support is imminent – it’s already showing on the site as ‘(coming soon)’, and I know the dev team are focussed on finishing that job. As more and more companies use OpenStack internally, and more and more providers choose OpenStack for their public services it’s going to be an important platform, and Server3 will provide an easy way for people to get the stuff they need running on it.

VNS3

Virtual Network Server cubed started its life as VPN-Cubed, but I think the change in name reflects that there’s much more to it than just a virtual private network. VNS3 is used to create overlay networks, and the overlays can be within a cloud, between clouds, between a private data center and a cloud (or clouds) or simply between multiple data centers.

Network overlays are useful for a number of reasons:

• Security by keeping network traffic inside of encrypted tunnels.
• Protocol Support for stuff that the native (service provider) network doesn’t do (e.g. multicast). I’ve used VNS3 myself to connect together a grid that depended on multicast where the network of the underlying service provider (Amazon) didn’t support it.
• Consistency of addressing schemes etc. It’s possible to run different collections of machines inside of VNS3 using the same IP allocation scheme, which can greatly simply migration between environments (e.g. dev->test->production), or troubleshooting (where an exact copy of a given environment can be cloned for fault finding).

The VNS3 overlay can connect into a typical network edge device to provide connectivity into regular corporate networks.

As the VNS3 managers have an API it makes it part of the movement towards software defined networking (SDN), which I plan to write more about in a subsequent post.

Context3

Context-Cubed is a system for the deployment and management of application topologies. If an application sits inside a single (virtual) server then things are pretty simple, but once an application spans multiple machines then it usually involves some degree of dependency management – the web server should wait for the app server should wait for the database. This type of dependency management also happens within a single system, and is dealt with using something like init; so Context3 is essentially init for distributed systems.

It isn’t just for managing startup dependencies, as it can also help with runtime scaling (up or down) so that within a multi tiered application there is enough resource to satisfy demand, but not too much (which might be running up a usage bill).

Wrapping up

I’ve only just started with CohesiveFT, but I’ve known the people and the products for long enough for it to feel something like a homecoming for me. The company has some great products and services to help people harness the power of cloud computing, and I’m looking forward to helping people understand that capability and get started with using it.

Notes

[1] Arguably financial services is a vertical market problem rather than a generic problem, and so should be served by the commercial community, but that clearly wasn’t working out.
[2] I think what’s subsequently happened at OpenGamma shows that open source can succeed in the financial services arena, but perhaps that ‘OpenClub’ was too broad in its ambition.