Fixing the clouds, one server at a time
I feel fortunate to have been part of the incredible shift in computing over the past decade. I first realized that major changes were afoot in 2005 when I was integrating Xen into Fedora and saw how people were starting to use virtualization for R&D. Over the next five years, I was part of several projects where virtualization was a key enabler, and I watched as an ecosystem emerged to help companies transform their IT infrastructure into what we now call the “private cloud”. But I really got excited when Amazon started to combine virtualization and hosting — creating a new type of “public” cloud computing model that promised to make computing and storage as easy to deploy and use as any other utility. I wanted to be part of making that happen, so I left Red Hat and began using AWS on a regular basis at a fast growing marketing automation company in Boston. There, I found that running on AWS was hugely empowering for the entire development team, enabling us to launch new products quickly and scale our infrastructure in line with our business.
As the team grew, my interest in building software and tools to help developers was a catalyst for me to lead a team to build the infrastructure we needed to support that growth. We needed more visibility and control over our infrastructure and applications, but were unable to find satisfactory management tools that were built for large-scale cloud environments. So we invested significant engineering time in building custom tools to fill the gap–time that I would have preferred to invest in our product if given a choice.
When I left the marketing automation company earlier this year, I was thrust again into an environment where I lacked insight and control over my cloud environment, but this time I was at a smaller startup, where I didn’t have the luxury of a team or the time to invest in building them. I again looked out at the market for tools, talked to my DevOps peers, and discovered that everyone seemed to be struggling with the same (unattractive) options–proceed with limited control or visibility, dedicate engineering time to custom infrastructure tools, or cobble together open source solutions and limited commercial products.
I am excited to be part of the Stackdriver team building the infrastructure management products that we have been looking for since we first started running business-critical applications in the cloud. I am excited to make the DevOps job easier and more proactive. I am excited to play a small part in helping the cloud realize its potential. It’s a challenge that will both be fun and hard at the same time. Hopefully we can be a part of making infrastructure management and monitoring suck less. Come join us or feel free to email me if you want to learn more about the problems we’re solving at Stackdriver.