We're your hosts (Christian Weichel and Pauline Narvas) 👋
In today's episode, we're joined by Ohad Maislish, CEO of env0 where we talk about infrastructure developer experience.
The hosts â–»
Our guest â–»
Things mentioned â–»
Let's chat some more! â–»
We're your hosts (Christian Weichel and Pauline Narvas) 👋
In today's episode, we're joined by Ohad Maislish, CEO of env0 where we talk about infrastructure developer experience.
The hosts â–»
Our guest â–»
Things mentioned â–»
Let's chat some more! â–»
Now developers are more aware of infrastructure, basically influence infrastructure way more, and then can Terraform cloud formation, which is like the total replacement of the old school. It, and now developers write code that is a full representation of their infrastructure. So when they have the visibility and they have the influence. They also have the responsibility to do that properly.
Chris:Welcome. You're listening to the Devex podcast, the show where product and engineering leaders share their thoughts and insights on developer experience. I'm Christian joined by my cohost poly novice.
Pauline:Hello Ohad, thank you so much for joining us for today's developer experience podcast. We're so excited to have you on board and to do a deep dive on your journey and env0. How are you doing today?
Ohad:Thanks. I'm doing fine. And thanks for having me Pauline and Chris, it's a pleasure being here. I've heard so many great things about Gitpod and it's for me a great experience to spend time with you.
Pauline:Oh exciting. Thank you. So for those who have not heard of you and your story, could you tell us a little bit about yourself?
Ohad:Let's start with the most important thing. I have a cat and I love cats. So that's the most important. That is true. I'm glad you said that first. I'm 40 years old. I have two kids. As you probably know a cat. I live in California in the Sunnyvale, in the San Francisco bay area. And I was maybe, probably still am a geek. I started programming at a young age. Uh, I worked for a couple of companies and yeah, I love code in the last few years I became an entrepreneur. So I don't code that much or any at all, to be honest, but I missed that. For me developing is divided to two different things. One is to actually develop the product. And the other thing that I find more interesting is how to improve the lives of the developers and to make the developer organization more efficient. So that's usually what I did as an engineer, try to improve things. And as a founder, like with env0 to improve the lives of the developers to become more efficient.
Pauline:I think that's what makes your perfect guest today. I'm really excited to deep dive into that a bit more. So you've mentioned env0 and I've read a little bit about it. And so as Chris, but I'd love to hear from your own words, what the elevator pitch is for env0.
Ohad:So in order to understand what env0 is, you need to understand infrastructure as code. Okay. If you're not familiar with Terraform, with Pulumi, with cloud formation env0 is, is irrelevant for you, but let's assume you are no longer managing your cloud, your AWS, GCP, Azure by clicking buttons and you move to actually writing code. In one of those languages, Terraform, Pulumi, Cloud Formation. I do wanna mention also cross plain becoming the new cool kid on the block on templates bicep. All of those are infrastructures called frameworks, which means the cloud is no longer just cloud resources. It's a combination of cloud resources and code being managed as one in AWS, GCP, Azure. They have no idea where your code is GitHub , GitLab, BitBucket. They have no idea that your code represents cloud resources. So in order to manage cloud with code, you need to have something like env0. You probably heard about our main competition. It's HashiCorp Terraform Cloud, by the way, it's that specific for Terraform. Env0 is not just for Terraform. We support Pulumi. We support telegram. We support others, but let's say just for Terraform. So we have the open source Terraform. We have the commercial product like thefor cloud or env0, which is direct competition with that. And that's the business solution on top of the opensource framework in a way, it's the signal to the difference between GitHub and Git. So Git is an opensource framework, but you don't have the concept of pull request who can change the code. How do I approve code changes that exist in GitHub? So same goes here in Terraform. If you execute something. The cloud resources change in env0. You can define who can execute which code and which cloud account who approves code execution, that kind of how much it's gonna cost you to execute that code. Those concept don't exist in, in Terraform and in the frame of those exist in the management solution on top. So long story short env0 is a management solution for infrastructure scope.
Chris:Awesome. From our experience. This really drives home. Like we ourselves are struggling with things like Terraform drift and drift detection.
Ohad:Yeah, definitely.
Chris:Yeah, exactly. It thinks that exist in our repo don't exist in a real world or vice versa. That problem seems to be going away entirely.
Ohad:Yeah. Drift is one of the main reasons customers check it env0. You need to manage those two things to get a cloud and cloud resources and code. Ideally, nobody should still have direct access to the cloud, but in the real world, you still have some things you need to do sometimes manually, sometimes quickly. And that's very dangerous. If a developer changes cloud resources without changing the code accordingly creates a drift. The next code execution that can happen any second might revert those changes. It's very risky. So you need to avoid that at all, or at least reduce the meantime to recover from those drifts.
Chris:Sounds like a great way to get a Step one outage so. Pulling back a bit, when we speak about developer experience, we very often mean something like sort of application service, software developer experience, and we don't necessarily talk about infrastructure. We don't necessarily include that in the term. Is infrastructure getting the short end of that developer experience.
Ohad:It's a great question. Let's talk about developers 10 or 15 years ago, developers 10 or 15 years ago didn't care about performance. They didn't care about security. Okay. It was like the role of the other folks, the operations, the it, but then came, for example, for performance came and new Relic later data dog that made it easy for developers to also take ownership of the performance of their code. Okay. They have those TVs when we used to go to the office, not sure what's happening in the last two years, but you have those dashboards that you see the latency of your app. And if the developer calls the major degradation. In the latency in the performance, they see that with new Relic, with data do with AppDynamics, with APM application performance monitoring tools, same goes with security. So if a developer used to write code and then six months later, somebody would tell that developer, Hey, listen, eh, there is a major security issue here. Now developers take ownership of their security companies like Synk, Aqua security. And they shift left security to the developers. So saying goes here with infrastructure. When infrastructure used to be physical machines, physical service, obviously developers didn't care about it. And they thought somebody else had job to be in charge of the storage of the networking of the compute resources, the servers, memory, CPU. They didn't care about that, but now it's code. Okay. If you change the code, you change the infrastructure. It started with Kubernetes. So in Kubernetes, you can define how big your pod is like the CPU memory. How do you configure your load balance with an ingress controller, stuff like that. So now developers are more aware of infrastructure, basically influence infrastructure way more and then came Terraform cloud formation, which is like the total replacement of the old school IT, and now developers write code that is a full representation of their infrastructure. So when they have the visibility and they have the influence, they also have the responsibility to do that properly.
Chris:In modern organizations, we all want to shift left. And this is a trend that shift left on X is a thing shifting left on security, shifting left on infrastructure, pushing more responsibilities towards what has become product teams, right? We're not even seeing deliberately not seeing pure engineering teams will also shifting product design and evolution into those teams as we do with infrastructure yet. It strikes me that often enough, we still have the dedicated infrastructure teams. We call them platform teams or something off the sort, and try to factor out almost the infrastructure side. I wonder how does development experience look like in those infrastructure teams? So before looking back at how we shift this back in, how does that world look like and how can we improve?
Ohad:Well, it's a great question. And I think it really depends on the culture and DNA of those companies. You have those centralized teams pretty often that control everything and you need to open a ticket for somebody in the platform team. And that becomes a bottleneck. I, I have to share a story of my own here. About 10 years ago, I worked for a company named ator. They are the competition of Robin hood. They are a social investment network. And they're doing very well. They are about to IPO to go public for about 10 billion pretty soon. So I've worked there and I managed a great group of developers. And I remember a developer working in my group. He needed two new servers. In that case, it was the windows servers with.net in order to develop that feature. So basically he needed two VMs that run windows. It's so crazy to say that story today. So we were physically in an office. Let's start with that. We were physically in an office, so the engineer talks to the manager. I was the manager. Then the manager goes to the other room where the, it is talk to the manager of the it and asks for tool servers.. Then I would never forget that the manager of dat told me, I'm sorry, the person in charge of provisioning new machines just left for honeymoon in Mexico. He will be back a month from now. So you will need to wait one month to get your two VMs!
Chris:What a different world made
Ohad:So that's a centralized team that you need to ask for permission to do simple tasks that are riskless just two separate VMs, uh, in dev, not even in production. And the fact that he gave me that answer, I think uh, proves that he thought it's a legit answer to give. Okay. Yeah, we are in charge of that. We just care about controlling the infrastructure. We don't care about developer productivity. It's not of our business. It's somebody's else problem. My responsibility is to make sure the infrastructure is stable and doesn't cost too much. And I can manage that and yeah, if you need to wait another month or two in order to get your job, that's fine. It's not my problem. And I think that in today's culture, it's totally unacceptable. I don't wanna mention that. I, I went to my manager VP ATTO back then. And the infrastructure, by the way in ATO was based on VMware back then it was before AWS so it was based on VMware. And I actually worked for VMWare. So I know how to use the VMWare infrastructure pretty well. I've worked there for five years. So I told my manager that as far as I say, that he has two options either to give me admin access to the dev data center, or I quit. And guess what happened? I got access and the next day my developer got two VMs he needed. It's unacceptable that developers should wait in order to just do their job. So back to your question, that's, that's one option, how to take the platform team to centralize everything and treat that as the most important thing is stability and governance. The other way to look at it is that they are, let's maybe say a service provider for the developers. Okay. The developers eventually the goal of every company is to win the market, to win against the competition. And you have to run fast in order to achieve that goal. So if the centralized team or the infrastructure team, the platform team doesn't enable developers to do things the way they need. The way they want, they would lose. So the modern teams look at solutions like Gitpod, like env0, like others. And that's the way how to combine self-service and governance. You cannot just have governance and you cannot just have self-service. Self-service alone will give you chaos. You need to have both. So that's how you empower developers. You give them the self-service while still having centralized administration on the entire process.
Chris:That's a great take. It brings developer experience with respect to platform teams, back to the two perspectives. One, the developer experience they create rather than the one they themselves experience. That's a very interesting take. I recently came across a while, interacting with the company, we had a sort of modern day equivalent of what he just described, where the team that would want to set up infrastructure would write Terraform code, almost email that to a platform team and they would execute it. Right. And then they would give them the output. Like they, they would not be allowed to run that Terraform script themselves, but their form of governance was like, you have to go through a person. To run that and it, it had exactly the effect. It would expect. Things just took incredibly long by no means adequate for today's fast moving pace of things.
Ohad:It, by the way, it's not just taking too long. I think humans in general, we are not that smart and we make a lot of mistakes. So what does it mean manual approval? At some point it's not a good or a safe process because you look at so many things you need to approve, and it's difficult for you to recognize the dangers, the risky execution, the risky deployments, and that's why you need to scale the governance in code as well. Uh, in our world in infrastructure code, there is another concept called policy as code. Okay. The most common framework is open policy agent OPPA by a great company named Tyra. In order for you to decide, should I allow that execution or shouldn't allow that execution? The more modern and scalable way to do that is to define set of rules. In that case, an open policy agent and the humans shouldn't do manual work. The humans should define the process. And automate that process and then let that automation, those robots, or that automation to be in charge and just monitor that execution. So things like open policy agent, I think dramatically improve the governance of infrastructures code. There are some others, I think, both mentioning great open sources like checkoff and Terra scan that would not allow you to provision with a compute resource with SSH open, with an empty password. Okay. It would just warn you and block you from doing that. Even if you don't define your that's their default. Okay. Doesn't seem to be reasonable that you're about to do this crazy thing and things like infra cost and other open source allows you to know how much it's gonna cost you. Cause maybe you're about to execute. So. But it's gonna cost you too much money. Okay. You can easily, easily create financial catastrophe to organization by changing code. So things like infra cost is, is an engine to rule, to manage and prevent cost disaster for your infrastructure. Centralized team would do slow work. And would do bad work in the long term and you need to integrate those kind of solutions in order to do it properly.
Chris:I like that a lot that brings it back to a theme we had on last episode, actually, where we realized that a good part of what makes good developer experience is making the right thing easy to do. And that's exactly what you're describing, especially as all those responsibilities shift left, and developers now need to take care of infrastructure as well, making it easy for them to do the right thing, making it hard to fail on, making it hard to succeed with things they should be able to do. That is what is part of what provides good developed experience.
Ohad:Yeah. And I have also a good story. So while working at, at VMware, I was in charge of an automation group thinking about it today. It's basically the DevOps team. And I remember that we introduced a lot of new capabilities. It took us like close to two years to fully build the process and automated. And I remember a team member of mine. At some point, she asked me, Ohad, it looks like we don't have much work yet to do. And all we need is just to look at the screens and see if something goes wrong. What are we going to do here? And I told her, uh, her name was Kate and I told her Kate, that's our goal to become useless that nobody would need us. If we have a lot of work, it means that something is wrong. Nobody really needs us. Like we need that the adults could work seamlessly and not talk to us and just do whatever they want in a safe way. And I remember it was weird for her to see that we are. Running out of tasks and we just need to monitor the process. And that was beautiful to see that.
Chris:So we, we spoke a bit about how the world looks like for teams, where we shift left on infrastructure, where development teams are expected to own their infrastructure and of platform teams that provide services for those development teams to live up to that expectation. Not the world doesn't look like that for everyone. Unfortunately, I wanna say there are some postholes who are stuck in ops teams, where you have divided incentives, the ones that want to move fast and don't care if they break things and the ones that want to pervade breakage, because it calls them out of bed in the middle of the night. How does development experience look like today in more ops, heavy teams that have made that shift?
Ohad:Think to be honest, that's still the majority. Okay. We're talking about how to become more agile and self service, but it takes time, culture wise and tools to be mature enough to allow that those platform teams take their time to, to do their tasks. I remember I needed at some point from a big customer, um, to create a Sam app, something that takes few minutes and with all the processes, the priority tickets, I waited two and a half months for a SAML application. Again, it's a big, it's a big enterprise. Us enterprise. So I wasn't surprised, but back to your question, Chris, I've talked a few days ago with somebody. I won't mention his name, but I would mention the company that used to work for Cisco and he also needed some resources and he told me, took six months. To have those resources approved. So yeah, I think a lot of places have those centralized platform teams and they cannot take any risks and they still don't have the modern tools. Sometimes they don't even have cloud. I also spoke with somebody from Yahoo a couple weeks ago. Told me that they were just starting their journey to the cloud, those big enterprises, banking, financial institutes, especially governance agencies. Okay. It's not same approach that we see probably in companies like Gitpod, uh, and early stage startups that have almost everything probably automated and once very quickly. So yeah, in those companies, You need most probably to plan ahead if you need something, the only way you can do it is yeah six months before you need the resources, ask the Cisco platform team to do that. Because if you're gonna wait and assume they're gonna do that in a few days, your project will fail. So that's how unfortunately developers should adjust themselves. They, in any case, you need to maximize your chances. So if you cannot change the team, you can change the situation. So ask for infrastructure way earlier than you think you should have and hope that the platform teams will gradually improve the processes to become more agile.
Chris:So often we think of development experience as a technical problem as something where if we make that, see a life flag better, if we make that thing more responsive, if we improve that design of an API, if we're gonna make the lives of people better. And yet it turns out that developer experience much, so many other things is a social problem. And one of the consequences of that having I've never really worked in a heavy de- regulated environment. It's always been tech companies large to small from Bosch to small startups. And yet I've never been in a situation where a, or seen that happen where a technical decision, even years down the line will cost you your neck. And this is an interesting one that I think pertain really heavily to the behavior we see in larger groups where, Hey, if I give you this VM, or if I open this firewall, roll up for you, and this is how the bad guys get in, quote unquote, my neck's gonna be on the line. So I'm not gonna do that. So rephrasing the experience the developers are having with respect to risk adversity. And while saving your job at the end of the day, instead of that sense of enablement and wanting to make sure that you get your stuff done is an interesting perspective. Can we have technical solutions to those problems? You touched on OPPA and having policies encoded. Are there other ways we can make the lives of people better instead of having to wait n months for something that should take minutes?
Ohad:Think it's always a combination of culture and products. If the process is aligned with the products, with the great solutions, things should work well, let me shift to a totally different thing, for a minute - autonomous cars. Okay. So we are not such good drivers, sad things happen. You have car accidents all the time. And eventually it may be a technical solution and autonomous cars will make all of our lives better. There is a technical solution it's called autonomous cars and it has those cameras and other devices that allow the car to drive probably better than what humans can do. But it's not just about the cars. You need for example, companies to change the regulation to allow those cars for driving. I even heard that a vision that once they're gonna be like 100% autonomous cars, uh, the roads will be dynamic. So the way to the city in the morning, like most of the lanes will be directed one way. And in the evening, the same lanes will basically say the other thing you can drive now the opposite way. So if you change the process, if you define some things and you have great technology, like autonomous cars, that's the best thing. And I think the same goes here for developers, if you just try to change the culture, the regulation, the processes, without having the tech, the products to support that you would fail. If you just try to introduce great products, but you don't have the relevant process to work with that technology it's useless. So very minimal value would get out of it. But if you gradually hand in hand, uh, adopt those solutions and change the processes you will succeed. So it's a lot of small steps. I've mentioned open policy agent and check hold with Terra scan and TF sec, all of those. Or great frameworks, but if you don't define the process, if you don't allocate the time for the platform team to write those rules or to make sure those rules are right and update those as you go. So it's always the combination of both. Or even more so if you don't take the time to convince the manager of that team or their manager, that this is a way to go that having those rules encoded encode, rather than people glancing over something and going, yeah, this looks good to me. You're not gonna succeed putting those tools in place. Wow. Spot on. And I think if you are a founder and you try to sell your products to customers and you always have the adopters, those that you find that are, they have the bigger pain, they understand your quicker than others. So same goes here. If you wanna change something in our organization, there is not just one group that you need to influencer. Several groups. What I used to do is to try to identify, let's say, I need to convince and change the behavior of five different groups. Those groups have different needs and they have different managers. It's trying to sell a solution. It wouldn't cost them a dime. Okay. They're not, they don't need to pay, but they need to think differently. They need to allocate time and that's usually more expensive than actual money. So you try to understand, what is your idea of customer profile your ICP in business? Like what are the criterias for them? And then you change one. And then you have a case study so called of yeah. They improve their velocity, they reduce their mistakes. And then with that case study, you approach the bigger and the more difficult customer, the other group manager, and then you gradually change your entire organization, but it's not something that can happen naturally. It's something that you need a champion in the organization to have the time, the resources to push to such a change.
Chris:Yeah. It goes to show that improving developer experience takes a lot of intentionality, takes a lot of deliberation and yeah, doesn't happen naturally. It's something that you need to want to do, and you need to find the right people with who can write the check or who can make that call so that these things happen.
Pauline:Buy in from leadership or from whoever can move the needle. When I was listening to you, it really reminded me of my experience in a unlike Chris, I actually came from a big enterprise. I worked for a telecommunications company and I also had similar things where I was actually in the central platform team. And people were opening tickets for my team and I eventually realized how bad it was that we had all of these tickets being raised, but we just didn't have enough people to to execute them and to help these developers out. So they would be doing their standup updates and they would be like, we're waiting on platform. And it sucks on both ends because we are like, oh, we are delaying someone from being productive. They can't get on with their work. They're blocked. And then we, we can't do much either because we have to wait. The company I worked for was you described very governance heavy. So there was a lot, even with our day to day work, we needed to get permission other people. So we couldn't really make decisions ourselves. It was like a long list of people that we needed to get through, to complete our works. It just wasn't a good feeling for anyone involved, but just before I left that company, we actually formed a new team and we tried to be a bit more agile. We tried to be the people that were pushing responsibility more towards our developers. And whilst I was there, it felt like we were moving things, but again, it took a lot of work to get buy in from the important people in the organization to then talk about us in all hands to talk about us in wider company groups, so that we could actually make a change. And yeah, by the end, I actually left. So I didn't know what ended up happening there.
Ohad:Have to say, speaking of big UK, telcos, not sure where you work, but Virgin media, O2, which is a big UK telco is a paying customer of env0. And, and they, I heard the same story and it looks like they, they succeed because they have a new, more modern group. That is in charge of developers. They work closer with the developers. Yeah. And yeah, they're always introducing those new solutions such as env0 for infrastructures code. They use Terraform and yeah env0, allows them to empower developers, to have self-service and provision cloud resources without waiting for the centralized teams. So I do believe that even big companies like UK telcos, such as the Virgin media , O2, eventually understand that they need to move faster and they cannot have those centralized teams.
Pauline:Yeah, absolutely. This is the sort of thing we were talking about. We should be doing that too. Uh, but yeah, again, no idea what happened in that world, but yeah, I really resonated with the stories that you were sharing today. so just to go back a little bit more broadly speaking. I'd love to ask you. Maybe we could end the podcast with this question. Where do you see DevX evolving? What do you think the world of development will look like in the next two or five years? Deep question, I know!
Ohad:Yeah. I, i, I told you that I, I was and still am a geek, so my answer will be in that perspective. I think cloud changed everything. And 10 years ago, you could have executed everything locally on your laptop. And there was one monolith and development experience was pretty much local, but now that you are writing code, that can be executed only in the cloud sometimes. Okay. For example, S3 bucket. If your product use S3 bucket, you cannot have a three bucket on your laptop. You can have a menial, uh, container. It's not the same, but some things you cannot really have on your laptop, or it's maybe too complicated or maybe too many resources need to, you need like mega laptops in order to very powerful laptops in order to execute your code. So I think developers need to understand where they develop and where they test their changes. And the laptop is becoming more and more like a small broker to the real environment that is in the cloud. I think I don't need to convince you the Gitpod folks about that vision, but it's not just about where you develop, think where you develop. Is a pain that nicely being sold by Gitpod very nicely, but also where you test. So it's not just your code that you develop. It's where your code is being executed. That's the cloud environment of your application. So I think shifting to the cloud, the entire development life cycle and the laptops are basically just. I, I, I I'll give you a very simple example. I don't upgrade my laptops as I used to. Okay. Because I don't do much with my laptop. I do everything on the cloud. So I think that's the experience that we're seeing. Uh, it's irrelevant to continue using things locally. Everything in the process was to most of the cloud.
Chris:Frankly, the only reason to get an M1 was to be able to open more browser tabs at the same time.
Pauline:and Chris is well known to have too many browser tabs. So that's why he needs a lot of them. I actually have really resonated with that as well. I develop on my M1 Air, so I didn't even get the pro and it's absolutely fine, but I'm only code on Gitpod, so there's really no need. And also I have an iPad sometimes I use which again is mind blowing, but I definitely, I mean, you do, like you said, you don't need to convince those we know it's the future.
Chris:Preaching to the choir, but it makes a ton of sense.
Pauline:Yes.
Ohad:By the way, it's not just the developer experience here. It's also simplifies yeah the administration process here. Okay. If you have new packages in a specific version of something, you have no fear anymore that developers might install the wrong thing, or wouldn't install that if centralized cloud based solution. You just can easily manage and monitor everything and obviously allowing your developers to be as efficient as they can
Chris:Absolutely! Shifting the entire so software development life cycle into the cloud, lifting all of that up. It's definitely the way to go. And it's not just development is way more than that.
Pauline:Yeah, absolutely. I'm glad you mentioned that , Ohad. Thank you so much for sharing what you think the future of DevX will be. So just to end the podcast, we usually ask our guests about one thing they'd like to shout out about recently. This could be a learning, someone who has impacted you tech or non-tech related. So what's that for you, Ohad?
Ohad:As I always like talking about what we are doing here at env0. So if someone listening and you're using Terra or Terra grant, and you reach some scale and you think the pixels or Alanis are not good enough, please look at env0. And I do wanna mention today that we are releasing also support for Pulumi. So it's no longer just relevant for Terraform or Telegram. If you use Pulumi, even if you use both Terraform and Pulumi, you have to look at env0 and see how we can manage that in scale for you. So my big announcement for you today is that env0 now support Pulumi as well.
Pauline:Super exciting. Thank you for sharing that. We'll also share some links in the show notes for anyone who wants to find out more about that as well. If people are listening right now, I want to find out more about you. Where can they find you?
Ohad:My Twitter is DevOps. OAD the how to spell DevOps OAD is spelled O H a D. Our website of the company is N of zero.com E N V. The digit zero.com. Feel free to open the chat, ask any questions you want. We are here to help.
Pauline:Chris do you want to give your quick shout out?
Chris:Yeah. So in very much in the theme of today's episode, I feel the need to mention two books, actually the Phoenix project, for those who haven't read it, it's the motivation for DevOps. And then the book that it's modeled after called the goal. Which is also worthwhile to read, especially if you're coming from a computing background and you don't really know how the real world looks like, and you haven't seen a production lineup close. You'll wanna get that one to read as well.
Pauline:Amazing. And for me, it's actually an app called centered.app. It encourages you to get into flow state. So you have flow session with other people who are also using the app, and it's similar to several different tools out there, but I really enjoy the sounds that they have on that app. I've been using it so much recently. It's fantastic. Highly recommend it. Amazing. Well, thank you so much. We've reached the end of this podcast already and oh my gosh, there's so many great takeaways. Thank you so much again, Ohad and I'm sure we'll speak again soon.
Ohad:Thank you. Thanks Pauline. Thanks Chris. It's been a pleasure talking to you today.
Pauline:Thank you for listening to this episode of DevXPod Want to continue the conversation about developer experience head over to our community discord server at gitpod.io/chat. We have a dedicated channel there for us to talk all about DevX to make sure you don't miss the next episode. Follow us on your favorite podcast platform or subscribe to our newsletter DevX Digest.
Chris:You can also find out more about Gitpod on gitpod.io. Start any workspace and tell us about your developer experience. See you in the next episode