Causely is bridging observability with automated orchestration for self-managed, resilient applications at scale. Here is part one of their two part interview.
Daniel Karp, Partner, Cervin: Thanks for joining me today, Ellen! Tell us a little bit more about yourself, Causely, and your entrepreneurial path.
Ellen Rubin, Co-founder & CEO, Causely: I’m what you would call a very seasoned entrepreneur. Causely is the third company that I've started. I've always been intrigued with enterprise infrastructure problems. It's really interesting to see how things run in the real world and understand the underlying technologies that make that possible. That’s been a theme for me for a long time. I really like working with early adopter enterprise customers that are thinking about how they're going to build things for the future.
A Founder's Origin Story
When I started off in my career, I was part of a company called Netezza, in the data warehousing space. I was among the first few people on the business side joining when we were still building a product, and that was pretty formative for me. At Netezza, we built a very advanced system that enabled people to do data analytics at 100 times the performance at half the cost. The customers loved the product. I created the go-to-market engine, we created a category, Data Warehouse Appliances, the company went public and ultimately, was bought by IBM.
After that, I pivoted into the cloud, which is a career passion for me. In 2008 I started my first company, CloudSwitch, and it was all about hybrid cloud. Then in 2014 I started ClearSky Data, which was focused on storage and how storage can be used at the edge at much higher performance, all while taking advantage of the economics and the scale of the cloud. CloudSwitch was acquired by Verizon, and ClearSky Data was acquired by Amazon Web Services (AWS). So then I did a tour of duty at Amazon for a year and a half.
DK: So you were acquired by Amazon around 10 years into the formation of cloud and roughly nine years after you started your involvement in the cloud, since AWS started in 2006.
ER: Yes, and I started CloudSwitch in 2008. So at that time, there was no other cloud and Amazon was this emerging superpower. I've always interacted with Amazon as a competitor, a partner, a scary behemoth; and then I became part of it. I joke with some friends of mine that we all end up working at cloud computing companies. We’re either acquired by them or we become them. That's the era that we're in.
And now coming to Causely. When Shmuel Kliger (Causely Co-Founder) and I started working together almost two years ago, the whole frame of reference that we both had was that the world is in the cloud. And that doesn't mean there’s not still hybrid with some things staying on prem, and that you don't still have a lot of legacy, but we're focused on the stuff in the cloud that is already mature, advanced, decentralized, and chaotic. Even though cloud apps are designed and built in order to get rid of a lot of the previous generations of messy, horrible IT operations, we’ve managed to create a whole new set of complexity and challenges in the cloud. So there's lots of room for a new start.
DK: Both you and Shmuel, you're part of that transition into the cloud, you've seen multiple markets expand and get centralized again in mainframe and then cloud. Causely starts as cloud based, but it also would need to take care of very complex workloads that are hybrid environments. And also, if you think about building applications in the cloud, those are kind of compartmentalized with multiple building blocks. So how do you think about that complexity and what inspires you to solve that huge problem that no one was able to so far?
ER: Causely’s vision comes from Shmuel and his background. He was the founder of Turbonomic and before that, he was founder of a company called SMARTS. He’s been looking at automating IT operational challenges for a long time, starting way back when we were still dealing with hardware on prem and then moving from there into virtualization and then into the cloud. We've both been on these journeys, over many, many years.
The philosophy that he and I share is that in spite of how much automation and ability for people to see everything clicked on, and how prevalent observability tools are, which show everything happening – if you are running cloud applications, these lend themselves to being incredibly multi-layered in terms of the complexity that exists. And so we're starting off thinking about it in the context of applications being built using microservices, decoupled, highly elastic and very scaled environments. And so in that environment, the thing that turns out to be really hard is understanding the interdependencies between all of the disparate components. You could potentially have millions of interdependencies between all of the different services across all possible layers of the application and down into the underlying infrastructure. People who manage and run these applications, frankly, often only understand the piece that they're working on, or maybe they developed a particular set of services and they understand that. Some people are platform people that are closer to the infrastructure, other people don’t want to be bothered to talk about load balancers. So you have these teams that are troubleshooting and dealing with a lot of the complexity manually. What Causely is doing that nobody else does, is capturing causal relationships and causality across the entire application environment in our software. We feel that even though you have observability, and tracing and metrics and logs, a lot of what happens today is that people apply human knowledge and human effort based on their expertise to understand what's going on. What problems are emerging, are they getting into a situation where there could be failures, performance, latency, availability (issues), and they don't have a way to capture that into software which could then lead to automation, through prevention all the way to remediation. Up til now, knowing causal relationships requires human beings to do their best job based on expertise they have.
DK: I think that’s because of the scale of the environment. I believe that the company labels the relationships as manifestations and attributes, while others call them permutations, but those are impossible to capture by a human.
ER: Think about it almost like here in New York City. You're standing on the street corner and can see that there is something causing a delay or that people are not able to move, and you can understand what's going on around you. But you might not know that all the way down at the other end of the island, other things are happening and that’s what's impacting you. All you're seeing are symptoms.
DK: And that's what the industry is focused on - Just make sure that you're not underwater and the service is up and running, and you just look for the most probable cause, rather than trying to figure out how to solve the problem in its entirety.
