arrow_backward Back to blog

Robotics, Deployment, and Becoming CTO

I recently joined Intridea as CTO after a two-year foray into the realms of 3D printing, embedded hardware, and robotics. My time spent hacking on physical-world hardware problems was super challenging and invigorating, and has given me new perspectives on how to approach software projects. Much as I enjoyed physical hacking (and I still do), I found that my time away made me yearn for my Ruby and software roots; I was ready for a new challenge.

Jumping back into the software world at Intridea is the perfect fit for me – I could not have made a better decision or found a better company to join. In the short time Iโ€™ve been here, Iโ€™ve found my fellow Intrideans to be some of most talented engineers, UI/UX designers and project managers I’ve had the pleasure of working with.

Intrideaโ€™s full embrace of distributed development is one of this companyโ€™s most unique and compelling features. There are Intrideans all over the USA and all over the world. This allows me to remain living in my beloved Portland, OR while still interacting with a world class, world-wide team developing gorgeous web and mobile applications. Though I havenโ€™t had the opportunity to meet all my fellow co-workers in person yet, I still have felt a very warm welcome from the team virtually through IMs, emails, and video chats.

I have several initiatives I will focus on in the coming months that I believe will help Intridea internally but will also be valuable open source contributions to the community. Iโ€™ve always been a deployment geek of sorts, and after a few-year hiatus from rubyland I am back and see that deployment is still not a fully solved issue. ๐Ÿ˜‰ Iโ€™m hoping to help fix that.

Warning: Iโ€™m dropping down into deployment geek speak for the next few paragraphs!

One approach Iโ€™m excited about is a new develop / deploy-local / deploy-remote framework. The framework will use LXC linux containers to capture all of the applicationโ€™s code, data, and state, and then be able to run this amalgamation either locally via Vagrant or remotely on a hosted server or cloud.

These types of container systems are all the rage lately with the release of and the warden project buried in VMWare’s CloudFoundry PaaS. Google even recently released lmctfy – “Let me Containerize That for You”.

All three of these projects add a wrapper around LXC linux containers and the cgroups kernel feature found in newer kernels. This allows for fine-grained resource and visibility management. These are effectively “containers” for your application to run inside of and thereby be abstracted one additional layer from the underlying infrastructure.

This approach is not quite as heavy as a full-on Virtual Machine, as these containers share the kernel and userland binaries and do not pay the overhead cost of virtualized processors. These containers are more of an abstraction for managing deployment and resource allocation of multiple applications across multiple machines or machine pools.

The idea behind this approach is that by wrapping your applications and its services inside of a container abstraction, you can isolate it from other applications and users sharing the same physical or virtual host computer. This allows us to treat application deployments as black boxes that have certain resource allocation needs. These can then be packed in different ways onto a pool of physical or virtual compute resources.

Now we can apply many classic bin-packing algorithms and other optimizations at the infrastructure layer to increase efficiency and hardware utilization. Since applications see the same underlying environment whether run locally or remotely, they will run the same regardless of where they are. This allows for nifty under-the-hood tricks to optimize workloads across server pool or cloud allocation, allowing us to make the best use of compute and storage resources without the waste of unused potential.

I’ve barely scratched the surface here of this new deployment abstraction, and thereโ€™s much to be done, but I plan to follow soon with much more detail and open source code releases.

Intrideaโ€™s embrace of employee open-source contributions is one of the big reasons I came here as CTO. The challenge of solving difficult problems was another. Intridea works with some of the most interesting companies across every industry and tackles their hardest problems.

I am honored to be CTO here at Intridea, and excited about all thatโ€™s to come.


New Project Request