Screaming in the Cloud - The Human Part of Automation with Divanny Lamas

Episode Date: November 24, 2020

About Divanny LamasDivanny Lamas is the CEO of Transposit, the DevOps automation company. Divanny and the Transposit team are creating a world where humans interact with machines successfully to manage today’s complex technology stacks. Divanny is also a managing director at leading venture capital firm Sutter Hill Ventures. She is passionate about working with entrepreneurs to tackle ambitious technical challenges. Prior to Transposit, she began her career at Google and spent seven years at Splunk, where she saw the rise of big data and was one of the early product managers working on building out visualizations and analytics. She was responsible for product strategy, roadmap, and execution for Splunk's marquee product, Splunk Enterprise. She also served as a senior director of customer success and the head of new product introduction at Splunk. Divanny obtained a bachelor’s degree in government and computer science at Harvard University.Links ReferencedTranspositSutter Hill VenturesFollow Divanny on TwitterConnect with Divanny on LinkedIn

Hello and welcome to Screaming in the Cloud with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. You've got an incredibly complex architecture. This is Screaming in the Cloud. that's simple and straightforward. No more counting hosts. You can get one user and 100 gigabytes per month totally free. Check it out at Norelic.com. Observability made simple. This episode has been sponsored in part by our friends at Veeam. Are you tired of juggling the cost of AWS backups and recovery with your SLAs? Quit thecus Act and check out Veeam. Their AWS backup and recovery solution is made to save you money,

not that that's the primary goal, mind you, while also protecting your data properly. They're letting you protect 10 instances for free with no time limits, so test it out now. You can even find them on the AWS marketplace at snark.cloud slash back it up. Wait, did I just endorse something on the AWS Marketplace? Wonder of wonders I did. Look, you don't care about backups. You care about restores.

And despite the fact that multi-cloud's a dumb strategy, it's also a realistic reality. So make sure that you're backing up data from everywhere with a single unified point of view. Check them out at snark.cloud slash back it up. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week for a sponsored episode by Devani Lamas, CEO at Transposit and a managing director at Sutter Hill Ventures. Because, you know, both of those sound like part-time jobs. Devani, welcome to the show. Thank you for having me, Corey.

So I'm going to go in reverse order there and start with the Sutter Hill Ventures story. So what is Sutter Hill Ventures and what does a managing director do? So Sutter Hill Ventures is a VC firm. We tend to focus on enterprise technology as well as hard tech. So a lot of B2B, a lot of software, a lot of cybersecurity, IT infrastructure, all of those types of things. It's an old firm, been around since 1962. And, you know, we take a slightly different approach to investing. A lot of what we do is on the incubation side. So we work very closely with entrepreneurs to build really fabulous technology companies. And, you know, we've had some recent successes.

One of the most popular ones this year is Snowflake. Oh, yes. So forgive my naivete on these things. I tend to come from the bootstrapped world where my naive interpretation of what a VC does is, well, I made a lot of money by effectively winning the lottery, and now I advise other people on how they too can win the lottery. That's probably overly cynical, but where am I wrong? Well, I don't think you're wrong for the majority of VC, but building companies takes a lot of different skill sets, and it takes a lot of knowledge, and not surprisingly, a lot of different skill sets and it takes a lot

of knowledge and not surprisingly, you get better the more you do it. So we think that the role of a VC is to be helpful to founders, to help them overcome a lot of the challenges and to simplify their lives, you know, to try to give them good advice, give them good guidance, help them hire, help them sell, help them do all the things that are important in building a startup. Well, speaking of building startups, you're the CEO of Transposit. So how did that come about? I mean, before this, you're in management roles for a while at a small company called Splunk. Tiny little startup, yeah. Yeah, exactly. And before that, you were all kinds of other interesting places too. You went to Harvard, for example, and you were at Google for a while.

And I don't know if you actually deprecated anything or not, which is the way you can really tell someone was at Google, but I digress. How did you wind up where you are? After spending some time at that startup that you mentioned, I was looking for my next role and I wanted to get back to building and get back to the early stages. And so I met the guys at Setter Hill. We connected, we decided that we liked each other and that we wanted to go into business together. And Transposit was one of our portfolio companies that I just got really excited by. A company that was in an area that is near and dear

to me, which is APIs and, you know, kind of dealing with a lot of the challenges around APIs. And when I met Transposit's founder and CTO, Tina, it was just a match made in heaven. So we teamed up about a year ago and have been building out this company ever since. So what does Transposit do? It's one of those fun names in that I don't have to spell it for anyone, But conversely, people hear, oh, Transposit. I can tell by the name that they, and then they start checking bus schedules or something. What's a Transposit? What does it do? So Transposit is an automation platform for DevOps and SRE teams. So we help modern operations teams take a lot of the things that you would traditionally call toil and automate it, which,

you know, kind of on the surface sounds like a very, very broad directive. And it is, it's a very ambitious goal, but in practice, you know, we help people streamline their incident communications. We help them, you know, kind of deal with a lot of the repetitive tasks that happen as part of managing a modern operations team. So this sounds similar in some respects to the idea of AI Ops. You're a VC, so I imagine that's the direction you're going in, right? Yeah, I mean, I think I have a slightly negative opinion of the term AI Ops. You know, when I think of AI Ops, I hear a lot of people who start asking questions about machine learning and algorithms and data science and AI. And I've built a machine learning team or two in my day, and I do not consider us an AIOps company. I think that AIOps in general is a

little bit of a bullshit buzzword right now. No offense to any AIOps companies out there, but we think of it more as a data problem, right? So we think of ourselves as a data company that really makes sure that all of the things that are happening on our platform are recorded, that we have full insight into what people are doing in the system and ultimately can use that data to help them improve later on. But, you know, that's very different than building a self-learning system that's going to take on Skynet in the future. One of the most interesting parts of the entire AI revolution, for lack of a better term, seems to be that whether it's AI or machine learning or math, it's sort of a spectrum, but how you talk about it depends entirely on what you're trying to achieve. If you're an engineer, it basically talks about the polite part that we all tend to ignore,

which is it's a bunch of if statements and magic and hope. And if you're trying to launch a company, it's, oh, it's this massive AI system that is just a hair's breadth away from a general purpose AI that will transform the world as it ushers in the singularity. And most conversations wind up somewhere in between those two extremes. What about the idea of building interactive runbooks and handling incident management lends itself to a being a big data problem well i think of different types of data right different categories of data and you've got machine data right i spent a long time working on that and that's logs and machine exhaust and then you've got completely structured customer data. That's my records of the people that are buying things on my website. And then you've got this thing that's kind of unstructured data,

and that unstructured data is the conversation we had on Slack. It's the set of things that humans did as part of a process. And at Transposit, we believe that that set of data has historically been undervalued, not really looked at, and certainly not integrated with those other two categories of data. So we kind of think of a lot of the things that happen in the process of an incident, for example, as being a really, really great place to start building systems that can structure that data to drive better insights, to help with automation. And I liken it a little bit to what's happened in terms of the structuring of marketing data, right? So think of something

like AdWords and the way that we take clicks and things that people do on a website and are now able to turn that into analytics and turn that into insights on what people are interested in and what they're buying. And so we're taking a very similar approach, but applying it to an enterprise problem, which is how do you keep the website up and running? How do you make sure that your service is meeting the needs of your customer base. This sounds very similar in some respects to some of the talk that PagerDuty has been putting out for a long time. They're sort of the name that everyone thinks of in terms of incident response. In my experience, they tend to be the component of the pipeline that calls you at three in the morning with a very polite, wake up, asshole ringtone, because production is broken and you

need to fix it. People love it for that, but the story that they're telling about moving up the stack, about incident management, incident response, event intelligence, et cetera, et cetera, it sounds like they're trying to be something that the industry and its customers don't necessarily want them to be. It feels like they are trying to effectively become you folks in some respects, whereas you started off, as best I'm aware, not ever offering as your core value proposition to wake me up at 3 a.m. Yeah, you know, I think PagerDuty is really good at waking people up. And it's a great company. I think everyone has been woken up by PagerDuty. I've been woken up by PagerDuty. They're really,

really persistent and really, really good at it. But the incident doesn't end when you alert someone, you know, like that's the first step. I thought the incident finally ended when you conducted a blameless postmortem and blamelessly concluded that it was the person who's not in the room's fault. Yeah, it's the pointing fingers. I'm blamelessly going to point my finger at this person. No, look, I mean, I think Page of Duty is a great company, but we believe that there is a really big untapped area that happens between the first alert and the resolution of that incident. And today that process is highly manual, involves a lot of tribal knowledge and a lot of people running around with their heads cut off trying to figure out what to do. That process is inconsistent. Getting learnings from that is difficult to do, and it's very rarely automated. So our goal is to take that very scary time,

that very painful time, that very expensive time, and simplify it, you know, really give people guidance to help them be more effective and improve that customer experience. So I think that we have different goals at the end of the day from companies like PagerDuty. So I guess the eternal question then becomes, where does automation start and stop? Where do humans start and stop? What's the handoff look like? Because every time I've seen a company, and frankly, there have been a lot of them, that try to automate the incident management story, it's always one of those things where they have a few golden examples of, it's this issue, and you just so happen to have hooked

this up to all the services and tools you need to find this particular incident. And then, okay, great. What if it had been my previous incident in the real world that I'd encountered and it was, oh yeah, it wouldn't have caught that yet, but great idea. We'll catch that one too. And it feels like it's a perpetual game of whack-a-mole as they write ever more if statements. How does that handoff work?

What is the reality of that? Yeah, you know, I think of automation on a spectrum. And I think that most of the time when people think of automation, they think of the automation that's been popularized by tools like RPA vendors, like the UI paths of the world. And I call that deterministic automation. So that means that every single time the steps are going to be the same and you know what's going to happen. And that works for a lot of back office tasks. That doesn't really work for incidents because to your point, incidents are unique. Every single time you get an incident,

it's different. But automation can run the gamut from a checklist. A checklist is ultimately automation. It's a set of things that you need to do as a human. And like you're the automaton in this scenario. And when are we not automatons? all the way to ML, AI, fully cognitive systems. And we like to think of human-in-the-loop problems. And human-in-the-loop problems are things that you can automate parts of it, and then you can enable the humans to do their jobs faster. So let the humans be good at what humans are good at. Humans are good at intuition. They're good at context. They're good at understanding pieces of data that might not have gone into the original analysis

by the system. But they're really bad at certain types of things. Like they're really bad at passwords. They're really bad at repetitive tasks. They're really bad at copying and pasting scripts. So we try to let humans be good at human stuff and let the machines be good at machine stuff. And that assumes that you can find the humans

and the machines that are respectively good at things, which is never a guarantee, but we're getting better sometimes at solving for those particular problems. The nice thing that I've discovered in the, I guess, couple years now that I've been loosely tracking what Transposits is up to is that you're not telling the same stories as all of the other, yes, I do that too, type of company. It seems that you are approaching this from a fundamental point of philosophical difference, specifically around the idea that the current way that people handle incidents is broken. How did you get to that point? And what is it you think the rest of the industry is missing? Well, you know, I think that, again, so much of the world is focused on that initial page, right? They're focused on how do you get the thing rolling? How do you get the thing started? And I think that honestly, if I'm really frank, I think a lot of people don't think about humans. They don't think about the human problem. You just mentioned it before, the types of skill sets that are required to run modern operations and things that are built on a modern cloud stack, it's a very rare skill set. You find very few people

that are good at that. And so I think if you kind of imagine that every single person who works at a company is a kick-ass SRE DevOps person with 30 years of experience in Kubernetes, and you build systems for that person, those systems are going to be fundamentally different than the way that we see the world, which is there are a lot of companies that are trying to modernize. There are a lot of companies that are trying to be like Google, be like Amazon, be like Facebook, and who don't have an army of Kubernetes experts and who are instead trying to deal with that gap in knowledge. And if you approach it from that perspective, where not every single person is an expert on day one, then the problems that you focus on are different. It's really oriented around knowledge management. You start thinking a little bit about how do you

make someone who's on call for the first time productive at 3 a.m. and how do you make their experience a little bit less traumatic? So, you know, I think ultimately it's probably based off of my experiences and Tina's experiences in the real world of being people who were on call for these types of services. Part of the problem that we see across the industry, whenever we talk about incidences, you're right. Everyone sort of envisions this as starting off when the pager goes off. But on some level, that's sort of a point of failure because it means that something out of the ordinary has happened to the point where you've got to wake someone up and you've got to understand what goes on. Very often, the post-mortems, if you want to

call them that, tend to focus on the things leading directly on up to the page of, well, the disk filled up. And at some point it was one of those, well, why wasn't there an alert on the disk filling up without ever getting to the actual human factors that factor into all of these things, such as why in the year of our Lord, 2020, do we have to care about individual disks on individual systems? That seems like something a computer should worry about more than a person. It never seems to take that step beyond. That's always what annoyed me about this stuff anyway. Does that align with your collective view of the world, or am I still not seeing it the right way? No, I think you're

getting it 100% right. I was talking to someone recently about MongoDB and I hate pointing fingers at the database, but I will for a second. That's okay. If they don't like it, they're going to lose that data too. Yeah, I know. They'll make sure no one hears this. So I was talking to this company and the company has a bunch of really, really technical, great people in their SRE team and their DevOps engineering team. And they had one guy in the company that understood how MongoDB worked. And they kept running into issues between MongoDB queries that were causing all sorts of failures at the application tier. But there was one guy that knew how MongoDB worked. So every single time there was an incident that kind of affected this

particular part of the infrastructure. The problem wasn't that there was a challenge with that MongoDB query, because if the rest of the company had known how to kill a query, how to identify the query that was causing the problems and then kill the query, you know, that's a pretty easy thing to fix. The problem was that there was like one guy that knew how the UI worked, one guy that knew how to kill the queries. And so we helped them build out an automation that will go and create a little bit more self-service of a process around that, where when the incident happens, you can see the listing, you can kill the query, and you're guaranteed that you're not going to bring down the entirety of the system. And that's had a really big impact in how they think about incidents. But that's not a technical

problem, right? That's not MongoDB failing, right? Like it's kind of a configuration problem, maybe. It's a human problem. It's that they don't have enough people that know how that part of the system works. And it's not surprising that with modern systems, they're very complex and there are lots of pieces to think about and there's lots of pieces to know. And expecting every single person who might be on call to be an expert in every single part of the system is no longer sustainable. This episode is sponsored in part by our friends at Linode. You might be familiar with Linode. I

mean, they've been around for almost 20 years. They offer cloud in a way that makes sense, rather than a way that is actively ridiculous by trying to throw everything at a wall and see what sticks. Their pricing winds up being a lot more transparent, not to mention lower. Their performance kicks the crap out of most other things in this space, and my personal favorite, whenever you call them for support, you'll get a human who's empowered to fix whatever it is that's giving you trouble. Visit linode.com slash screaming in the cloud to learn more and get $100 in credit to kick the tires. That's linode.com slash screaming in the cloud. So I'm going to take that a step further and indulge one of my own personal favorite hobbies of dunking on large enterprises. It feels like at some point when, let's take the example of a disk filling

up because it's an easy one for most folks to wrap their head around. If not, just write this down and keep writing it down until your computer stops working. The problem is that a disk fills up and that causes an outage. So then the company goes into full-on reactive mode where they're going to now have an alert every time a disk climbs above 80% and it's going to wake someone up. And then it wakes everyone up and they start dialing it in. And eventually it's set in stone that all systems have a disk getting full monitor on it, the end. And this is the case for everything that changes, where whenever there's an issue in production, we're going to make sure that there's now a check to make sure that specific issue never happens again.

And it's like whack-a-mole. And you wind up with these change advisory boards that have to go through all of these checks just to get the smallest change out into production. And it feels like they've become so ossified by their own process that the value of startups within the company is you're untethered from all of the process

and box checking that you have to do in most of the company. And that just feels like it's not the right direction at all. But it's also very hard to stem that particular tide of overactive changing. Yeah, no, I mean, I think that agile, we're still having a hard time, especially in larger organizations, figuring out how you implement that and DevOps more broadly, which is really just agile in a sexy sort of label. You look at companies and the reasons why they're sensitive to changes and to breaks are logical, right? It's very logical that you wouldn't want the website to go down if it's going to cost you a million dollars every 10 minutes. But the way that they handle it is so often to overlay very, very heavyweight process. And, you know, frankly, the systems, and this is a little bit self-serving, we don't believe that

the systems work for it. You know, they're not able to expose the right level of risk, you know, understanding what's a high risk change versus a low risk change and letting people take more control over their destinies. We're not really there yet from a tooling perspective. So I understand why you have a bone to pick on it, but, you know, be a little bit empathetic for the big companies that are trying to implement these things. And, you know, they're stuck between a rock and a hard place. And that's part of the challenge. It's easy to sit here and cast stones from where I sit at a 10-person company. I don't tend to work with a whole lot of regulated data. I don't have a giant pile of process and control, and my upside risk

is far greater than my downside risk. At some point, as company grows, that changes significantly. You don't usually want your bank to YOLO things into production. That's how Wells Fargo got into trouble in some respects. Well, that was more of an ethical YOLO, but that's beside the point. The problem that I see is at some point, you have to be much more cautious and cognizant of all the moving parts that touch things. And it feels like it's not a particularly well-bounded problem, which I guess naively leads me to believe that it's not really a problem begging for an AI or ML solution. What am I missing? Well, I guess I'd kind of take a slightly different lens on it, right? So think about DevOps, right? So there's two really big pieces to the phrase DevOps. One of them is dev. And we've

spent a lot of energy as an industry on the dev part, right? Like on how do you build these things? How do you make sure that developers are working on the right things at the right time? But I think the part of the process that's a little bit less paid attention to from a process perspective is the ops side. And effectively what we've done is we've taken a set of developers

and we've told them, congratulations, you are now a sysadmin. And we've given them raises and we've given them nice titles and we've given people a lot of additional responsibility and much scarier things when they break. But I don't think it's that far off to say that most organizations, when they think about SRE, they're basically treating their SREs like they are sysadmins that now have engineer in their title. And to me, it comes back to how do you approach modern operations in a way that is cognizant of the importance of some of these things? Like don't bring down the website, don't lose data, be aware of the business needs and that you're getting the right insights to the right people,

that you're building continuous improvement into the process, that you learn from your incidents and that you learn from those fancy blameless postmortems and bring them into your overall operations. And I think that that area is very early on, largely because until now, we've been papering over this problem

with people and bodies. So how does Google deal with this? Well, I was at Google. They dealt with it by having so many people focused on this problem and letting those people just build tons of tooling internally to make it happen. But if you're a mid-sized company or you're a larger company, you know, not every single company out there is going to build their own custom platform. It's expensive. It's hard.

And so I think that as an industry, we need to be aware of those things company out there is going to build their own custom platform. It's expensive. It's hard. And so I think that as an industry, we need to be aware of those things and give people the right set of tools that they need to be able to manage that. And that's not entirely an ML or AI problem to your point. Like that's not really the solution here. I think you can start off with much simpler concepts. So you just touched on something that I wound up going into some, shall we put this, significant depth on the puppet state of DevOps report, where they talk about internal platforms and why everyone should build one. At least that was my takeaway. And my response was incoherent screaming. And it turns out that that's fairly controversial. And I, at the time of this recording, need to sit down and really write my thoughts out in some more depth. But I'm curious as to where you stand on

that particular position. I think that the guys at PuffPet, they really hit on something really interesting because we've been seeing this trend with a lot of our customers. And it's certainly something that has grown over the last year. And, you know, I think it's the rise of the platform team. And so you've got to ask, ask, why is the platform team coming into existence? Don't we already have DevOps teams? Don't we already have SRE teams? What is a platform team that's different? And I think what you're starting to see is this recognition that infrastructure automation

alone isn't enough, right? There's more that's needed in order to be able to operate, not just develop, not just launch things out into the ether, but to make sure that these applications and these really complex systems are running well, you need a group of people whose entire focus is on helping the rest of the organization do their jobs, right? To make sure that things are running, that the right tooling is in place, that the right processes are being followed. I know process is a dirty word, but the right processes are being followed.

There's the right level of visibility and that you're not forcing every single person in your organization to become an expert in every single thing. happening where we're finally recognizing that this is a problem that necessitates dedicated resources and thinking, and that we're not going to ask developers to solve every single problem and instead going to give them a support structure. Now, does that mean that every single company should be building their own custom platform? Absolutely not. But if you look at the industry today, where is the service now for a modern operations team? It doesn't really exist. There isn't something I can buy off the shelf that helps me operate, that helps me, you know, make sure that things are running and it has all of the different componentry. Like we haven't developed an ITIL for modern DevOps. And

I think that that's what people are hungry for right now. They're hungry for help in knowing, like, what are the necessary pieces? What are the components of that? How do I implement it? I read your tweet, Storm. It was a pretty funny breakdown. My condolences on that, Liz. I think you said, like, where do I buy a DevOps? You joke, but there's an awful lot of companies trying to sell me one. There are a lot of companies, but no one's really solving it comprehensively. You know, a lot of people are solving little pieces of it, little bits of it.

And so I empathize with the companies that are building out those platform teams. I think that you're going to see a lot of evolution in that space over the next couple of years. But I think it's a positive direction because instead of saying, my SREs are going to fix everything or my DevOps engineers are fixing it, we're finally recognizing that this is a real problem that deserves a real set

of solutions and thinking. And it's not enough to just buy the DevOps, you've also got to build the right team around it. It feels like there's entirely too much confusion around terms. And failing to disambiguate what people mean when they say certain things means that because we live in a world of outrage and immediate reactionary responses to everything means that when you say something like it's time to build an internal platform, I am going to take the least charitable interpretation of what I think a internal platform might be and then proceed to dump all over it as, well, that's a big distraction to the thing your company actually does. Trying to wrap every platform as a service or infrastructure as a service tool that you use in some crappy web UI internally is going to be a disaster. That is not, I don't think, what a lot of people are talking about,

but I've seen it done poorly enough times that I sit here and begin angrily shaking my fist at the concept. It feels like I'm really good at attacking straw men. Here's the way that I like to think about it. We know that digital transformation is happening, and I know that that's a buzzword, but here's a great example. So at the beginning of the pandemic, I live in San Francisco, a lot of businesses started closing down, right? And as those businesses closed down, specifically the restaurant industry, there was this entire other set of companies that supplied them that suddenly had no customer base. And I really like cooking at home. So there's one company in particular that was a wholesale fish distributor. So all they did was go and work directly with fishermen. And that morning, the fishermen would drop off the fish. And then

by that evening, those fish were being cooked at restaurants. And so when the restaurant industry stopped, effectively shut down overnight in San Francisco, those fish had nowhere to go. And I really wanted to eat those fish. So a lot of people like me want to get their hands on that. And that wholesale distributor pivoted to selling to home chefs. So it started off as a listing, you know, a page that they would put on their Instagram page, and then you would call someone and tell them what you wanted. And then they stood up a website. And as they stood up the website, you know, you still had to send an email with your request. And now they have a full checkout, and I think they're launching a mobile app soon. So I get my delivery. The name of the

company is Water to Table, if anyone is in San Francisco and wants to get some delicious, delicious, freshly caught seafood. But that shift, you know, what's happening there, it's not uncommon. You know, it's happening to every business, whether it's a small business or a medium-sized business or a large business. And if you are a mid-sized business in the middle of the country and you are trying to set up your digital presence and to support your customers in the way that they want to be supported, and you want to build in a modern way and you want to be responsible, what do you do? Do you go hire engineers from Google? Do you hire engineers from Facebook? They haven't minted enough people. So at the end of the day, these processes, these kinds of systems, these platforms, they're an attempt for all of these companies to do what Google did, but in their own scale.

And I can't blame them for it, even if I, like you, sometimes look at that and say, do you really need to build your own platform or is this a vanity project? But I think that ultimately you're going to see more and more of these things come more productized and make their way out into the market in a way that really solves problems for these types of companies. And that's part of the challenge, I think, is that there's an awful lot of folks building out solutions in this space that target specific company profiles

that they have themselves experienced. And you see this, I think, more with first-time founders, at least I would guess, where they've worked for a couple startups themselves and figure, ah, all companies look like startups. Or alternately, they wind up working at the big E enterprise companies and then come back with a, oh, everything must look like that. And the thing that surprises me the most, the longer I'm in this cloud world, is every time I think I've seen it all, all I have to do is talk to one more customer and I'm going to see something that I'd never imagined would be possible. And sure, it's easy to sit there and make fun of it as a

gut check first reaction. But here in reality, it's much more nuanced than that. And generally, unless you're working in the Facebook ethics department, you don't show up in the morning hoping to do a crappy job at work today. Yeah, you know, I think that a lot of us are, probably a lot of the people listening to your podcast, honestly, live in a bubble. And that bubble that we're in is colored by the experiences that we've been through. And if your experiences and your understanding of the needs of the industry are colored by the FANG companies and hot startups that were building and never had legacy technology to deal with, never had to deal with cloud transformation. You know, you might think, oh, this cloud thing seems to be kind of over. What's next? Like, haven't we already figured out the cloud?

Like, I think it's done. I think we've got it all. Like, I can name at least 10 CICD Like, I think it's done. I think we've got it all. Like, I can name at least 10 CICD systems, you know, off the top of my head. And you could probably put a question up and get another 50 startups listed, right? Like, isn't this a solved problem? But I think what it comes back to is everyone's solving tiny little fractions of it. And assembling those is not as intuitive as it seems.

No, sadly, it never seems to be. So thank you so much for taking the time to speak with me today. If people want to learn more about what you're up to, where can they find you? They can find us at transposite.com. And I am happy to give them a demo and show them a little bit of what we're building. You know, I think it's a super exciting area. And we think ultimately automation is critical to scaling all of these types of things, right? The only way we're going to get to the point where we really are able to scale out these skill sets to the number of companies that need them

is to embrace automation and automation and all angles of it. So yeah, if anyone wants to learn more, you know where to find me. Excellent. Thank you so much for taking the time to speak with me today. I really appreciate it. Devani Lamas, CEO at Transposit and Managing Director at Sutter Hill Ventures. I'm cloud economist, Corey Quinn, and this is Screaming in the Cloud.

If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you hated it, please leave a five-star review on your podcast platform of choice. Whereas if you hated it, please leave a five-star review on your podcast platform of choice, along with an illiterate comment explaining exactly what I got wrong

about machine data and big learning. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com or wherever Fine Snark is sold. This has been a HumblePod production. Stay humble.