We’re very happy to announce that Cloudskiff is joining forces with Snyk.
As we enter this next step in our journey, we want to share how we started the project and why we are thrilled that we have agreed to join Snyk to accelerate the development of the driftctl open-source tool for our great community.
As we founded the company CloudSkiff back in 2019, we all had seen the challenges involved with infrastructure automation before. Some of us were experienced cloud infrastructure managers, either as developers deploying to cloud resources or as part of a larger DevOps oriented organization managing large production systems. We were all convinced that Infrastructure-as-Code was the key to empowering developers to ship their projects faster and with an even better quality. We wanted to accelerate their journey towards automation, solve their most common problems and help them achieve a better IaC quality. We had one mission: deliver the full gains of infrastructure automation.
So the first idea we came up with was to create full-fledged pipelines and workflows for Terraform code for developers that needed to collaborate on Infrastructure-as-Code.
In the founding team, we all had previous experiences of startup creation and it was only too natural for us to go through a classical feedback loop / iteration process to develop the project and make sure that we were building something useful.
To us, one of the best ways to do so was to spend time talking to would-be users and ask very open questions on their day-to-day struggles and how they dealt with that. And that’s what we did. We spent hours on end on Zoom, interviewing cloud professionals from all around the world, with various expertise levels, working for companies of all sizes. We learned a lot from that and we cannot be grateful enough for the time they spent with us.
Still, doing those interviews we couldn’t help noticing that maybe we were not totally spot-on. At some point we realized that we needed to refocus and make sure we were solving something really painful that no one had addressed so far.
It was a very tough decision to make but we dropped the project in its current form (a SaaS platform) and started from scratch again. We’d try to solve one problem at a time, differently. Obviously we were worried about the consequences this decision would have on the life of the project, the crew, and our investors. But we were aware of our key assets by that time: we had a great team, with a strong technical expertise, and tons of practitioners feedback to leverage.
So we decided to be totally transparent internally and bluntly shared the situation. Together, we engaged into the process of redefining our focus. It was a fantastic human adventure to live those moments and see how we were collectively inventing something new. For the record, we are a fully remote company and many of us have been working fully remotely for years. So building on our experience, this whole process was done remotely and it worked. As you can imagine, this collegial processus brought lots of upsides, the whole team feeling totally empowered with a total ownership of the project.
It was a very tough decision to make but we dropped the project in its current form (a SaaS platform) and started from scratch again. We’d try to solve one problem at a time, differently. Obviously we were worried about the consequences this decision would have on the life of the project, the crew, and our investors. But we were aware of our key assets by that time: we had a great team, with a strong technical expertise, and tons of practitioners feedback to leverage.
So we decided to be totally transparent internally and bluntly shared the situation. Together, we engaged into the process of redefining our focus. It was a fantastic human adventure to live those moments and see how we were collectively inventing something new. For the record, we are a fully remote company and many of us have been working fully remotely for years. So building on our experience, this whole process was done remotely and it worked. As you can imagine, this collegial processus brought lots of upsides, the whole team feeling totally empowered with a total ownership of the project.
One of the biggest challenges in an IaC managed infrastructure is to spot discrepancies as they happen. Based on the feedback we had collected so far and our own day to day needs, we came to realize that issues involving infrastructure drift kept coming back.
Infrastructure drift is what happens when the reality of what is running on your cloud provider does not match your expectations. Drift can have multiple causes: from team members creating or updating infrastructure through the web console without backporting changes to Terraform, to unexpected actions from authenticated apps and services. It was clear to us that this issue was universal (we as a team, feeling it as much as anyone we had interviewed so far) and those blindspots prone to creating security threats.
Our drive at this time was a simple one: we wanted to solve a real problem for the open source community and provide value. Whatever the outcome, we knew we would be proud if we built a brick that was useful for all. To build this, we needed to easily distribute it. The new product had to be a CLI for every developer’s toolbox. And we wanted to build it in the open, in a very transparent way as a great open-source project with an emerging community helping us with real-world and real-time roadmap prioritization.
One of the biggest challenges in an IaC managed infrastructure is to spot discrepancies as they happen. Based on the feedback we had collected so far and our own day to day needs, we came to realize that issues involving infrastructure drift kept coming back.
Infrastructure drift is what happens when the reality of what is running on your cloud provider does not match your expectations. Drift can have multiple causes: from team members creating or updating infrastructure through the web console without backporting changes to Terraform, to unexpected actions from authenticated apps and services. It was clear to us that this issue was universal (we as a team, feeling it as much as anyone we had interviewed so far) and those blindspots prone to creating security threats.
Our drive at this time was a simple one: we wanted to solve a real problem for the open source community and provide value. Whatever the outcome, we knew we would be proud if we built a brick that was useful for all. To build this, we needed to easily distribute it. The new product had to be a CLI for every developer’s toolbox. And we wanted to build it in the open, in a very transparent way as a great open-source project with an emerging community helping us with real-world and real-time roadmap prioritization.
Based on all the feedback we collected, we drafted a very precise set of AWS services to be supported, in the Terraform context. And then we were lucky enough to have first users spot driftctl and give it a whirl when it was only just released. Feedback from those early adopters were incredibly helpful to build a better tool. And very soon we got our first contributions on the project. Our first external commit came in one month after the initial release. It was from Japan. To realize that someone, so far away from us (being based in Europe) would identify the tool, and spend personal time contributing to it, was a moment of pure bliss for all of us! In the weeks and months to come, there was no limit to our gratitude and enthusiasm for contributions and discussions that came from all parts of the world: North and South America, Asia, Middle East, Europe…
This is also the time where some key players in our industry showed us some signs of encouragement and invited us to talk at their community conferences.
Our metrics started to shoot up: the number of users, the daily runs, the recurring usage… Watching over the hockey stick shaped graphs in our dashboards, we suddenly felt that we had hit the mark: this very focused tool was helping developer’s real-life issues all around the world.
At that point we knew we had solved something for AWS, so we decided to duplicate this solution for other cloud providers (GCP, Azure, but also GitHub) or anything that exposes an API and that is supported by Terraform.
Based on all the feedback we collected, we drafted a very precise set of AWS services to be supported, in the Terraform context. And then we were lucky enough to have first users spot driftctl and give it a whirl when it was only just released. Feedback from those early adopters were incredibly helpful to build a better tool. And very soon we got our first contributions on the project. Our first external commit came in one month after the initial release. It was from Japan. To realize that someone, so far away from us (being based in Europe) would identify the tool, and spend personal time contributing to it, was a moment of pure bliss for all of us! In the weeks and months to come, there was no limit to our gratitude and enthusiasm for contributions and discussions that came from all parts of the world: North and South America, Asia, Middle East, Europe…
This is also the time where some key players in our industry showed us some signs of encouragement and invited us to talk at their community conferences.
Our metrics started to shoot up: the number of users, the daily runs, the recurring usage… Watching over the hockey stick shaped graphs in our dashboards, we suddenly felt that we had hit the mark: this very focused tool was helping developer’s real-life issues all around the world.
At that point we knew we had solved something for AWS, so we decided to duplicate this solution for other cloud providers (GCP, Azure, but also GitHub) or anything that exposes an API and that is supported by Terraform.
Over time, we got more and more positive feedback and we started intensifying our efforts on how to build a community around that, with the whole team taking part in the effort. And it worked. We constantly got more issues opened (which is a good sign because it shows that people are actually using your tool), more feature requests, more interactions with users who would tell us a lot about the limitations of the tool and how we should make it evolve, more support requests too. We started seeing what we call “serious contributors” as well: people with several commits, or a lot of interactions on various platforms.
Over time, we got more and more positive feedback and we started intensifying our efforts on how to build a community around that, with the whole team taking part in the effort. And it worked. We constantly got more issues opened (which is a good sign because it shows that people are actually using your tool), more feature requests, more interactions with users who would tell us a lot about the limitations of the tool and how we should make it evolve, more support requests too. We started seeing what we call “serious contributors” as well: people with several commits, or a lot of interactions on various platforms.
When we launched driftctl, our initial plan was first to develop this CLI and then build a complete SaaS platform on top of it with premium features, while maintaining and developing the original tool in a fully free and open source model.
Snyk is part of our ecosystem. They are a company we’ve always respected because of their good values and the help they provide to the open source community with Advisor, the free tool that checks for known vulnerabilities in open source projects. Beyond that, they have an amazing platform and a very relevant approach on developer-first security. Their IaC product was born more or less at the same time as driftctl.
The first discussions we had together immediately made sense product-wise: there was an obvious complementarity between our tool and their platforms.
Pushing further the discussion, the idea of joining forces came as a natural next step. Indeed, it made a lot of sense because of the obvious cultural fit, and it felt like an excellent opportunity to fulfill our mission: solve problems for developers and their cloud deployments,and help them achieve a better IaC quality. Suddenly we would be able to do this faster, with a bigger team and more support. Plus, there was a genuine enthusiasm on Snyk’s part to keep the tool open source and provide support to develop it even further.
When we launched driftctl, our initial plan was first to develop this CLI and then build a complete SaaS platform on top of it with premium features, while maintaining and developing the original tool in a fully free and open source model.
Snyk is part of our ecosystem. They are a company we’ve always respected because of their good values and the help they provide to the open source community with Advisor, the free tool that checks for known vulnerabilities in open source projects. Beyond that, they have an amazing platform and a very relevant approach on developer-first security. Their IaC product was born more or less at the same time as driftctl.
The first discussions we had together immediately made sense product-wise: there was an obvious complementarity between our tool and their platforms.
Pushing further the discussion, the idea of joining forces came as a natural next step. Indeed, it made a lot of sense because of the obvious cultural fit, and it felt like an excellent opportunity to fulfill our mission: solve problems for developers and their cloud deployments,and help them achieve a better IaC quality. Suddenly we would be able to do this faster, with a bigger team and more support. Plus, there was a genuine enthusiasm on Snyk’s part to keep the tool open source and provide support to develop it even further.
Snyk strongly believes in open source and they are committed to backing the driftctl project, along with the community surrounding and participating in it. As stated in Snyk’s blog, “Development of driftctl will continue in the open with the belief that value in driftctl as a standalone, open source, community-supported tool should continue. If anything we hope we can bring even more attention and participation so that driftctl continues to grow and improve and conquer even more issues in drift management.”
Snyk strongly believes in open source and they are committed to backing the driftctl project, along with the community surrounding and participating in it. As stated in Snyk’s blog, “Development of driftctl will continue in the open with the belief that value in driftctl as a standalone, open source, community-supported tool should continue. If anything we hope we can bring even more attention and participation so that driftctl continues to grow and improve and conquer even more issues in drift management.”
At the end of the day, we just felt that Snyk was a great home for the whole team, the community of users and the project. This is why we are so happy to join Snyk and keep pushing further with them. It’s incredibly exciting to know that together we will build the most powerful product for developers to keep their cloud infrastructures secure while also accelerating the development of the driftctl open-source tool for our great community.
At the end of the day, we just felt that Snyk was a great home for the whole team, the community of users and the project. This is why we are so happy to join Snyk and keep pushing further with them. It’s incredibly exciting to know that together we will build the most powerful product for developers to keep their cloud infrastructures secure while also accelerating the development of the driftctl open-source tool for our great community.