Development Experience Automation to Increase Productivity with Ramiro Berrelleza

Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability with some of the world's smartest engineers. Hey, I'm Joe Colantonio, host of the DevOps Toolchain podcast, and my goal is to help you create DevOps toolchain awesomeness. Hey, it's Joe. Welcome to another episode of the Tuskill DevOps Toolchain podcast. Today we'll be talking with Romero all about DevOps developer productivity, especially development experience automation. So really excited to dive into this topic. If you don't know, Romero is the CEO and co founder of Octeto, the leading platform for development experience Automation. With over 30 years of experience of engineering, Romero is a seasoned professional passionate about building developer tooling. As a visionary, Romero really always seeks to improve the software development process. And he firmly believes that building modding applications is a team sport and understands the importance of removing friction from the development process. So really excited to talk to him today and really dive into what he sees about the future of DevOps and where we're going, and also a little bit more about his solution and how to help you be more productive. You don't want to miss this episode. Check it out. This episode is brought to you by SmartBear. As businesses demand more and more from software, the jobs of development teams gets harder and harder. They're expected to deliver fast and flawlessly, but too often they're missing the vital context to connect each step of the process. That's how SmartBear helps. Wherever you are in the testing lifecycle, they have a tool to give you a new level of visibility and automation so you can unleash your development team's full awesomeness. They offer free trials for all the tools, no credit cards are required, and they even back it up with a responsive, award winning support team show on your path to great software. Learn more@smartbeer.com today. Hey Romero. Welcome to the Guild.

Hi Joe.

Thank you for having me here. Very excited to get a chance to talk to you and with your audience about all things DevOps, dev experience, automation, and a few more things.

Absolutely. Really great to have you here. Before we get into it, I usually butcher people's bios. Or is there anything in your bio that I missed that you want the Guild to know more about?

No, I think you covered a lot of it. That was actually a really critical bio. I mean, as you said, I've been working on developer tools and developer experience for a long time. Octeto is a new project. It's both an Open source project and a company. So I'm really excited about just talking about dev experience and contributing to making software development more easy, more inclusive for everybody. And that's kind of my personal mission and the mission of Octeto.

Now why is that? Did you just start off as an engineer and you're like, oh my gosh, this is so frustrating. Let me create a tool that's going to help or like exactly, yeah.

I mean Octeto came to be in a very selfish way as hey, I'm solving a problem that I've always had. I'm lucky enough to work in very large, well known companies. I work at Microsoft for a while, I work with Atlassian for a while as well, all the way to small companies and pretty much everywhere I worked we're building tools, SaaS, all these modern things. But development was always painful. This idea of I have to set up everything locally by hand, while at the same time. And your audience, I'm sure, knows this very well. Everything else, CI, CD workflows, production is highly automated. It always felt like it was odd and disconnected to me. So my co founders and I started tinkering with this as an open source project, exploring ideas and very quickly we realized that yes, this is a problem that pretty much every software team out there has. And that's when we decided, hey, yeah, let's try to make our contribution, make this a bigger project, eventually a company. And now we have 30 plus customers using Octeto and starting to see this big benefit of what we many years ago started to imagine.

Awesome. So what is one of the biggest frictions you see with developers? When I used to work at GE, we had like developers then we had a DevOps team and you know, when we were first merging people into this agile world, I'm that old. Those developers really kind of, you know, it's a lot thrown at them. It was really hard to get a seamless kind of integration into their ecosystem so they don't have to keep changing context. So I'm just curious to know from your experience, like what was the friction you see a lot of developers dealing with? Is this common that you see that.

What you said is exactly the friction that we see like you know, over the past 10, 15 years, you know, I'm that old as well. We've seen this very fast, really interesting innovation of like going from physical data centers to VMs to containers, Kubernetes now, you know, webassembly and Edge and all these things. And what we've seen in parallel is applications are getting, becoming Less of a big monolith, more about multiple pieces, different technologies at different levels of the stack. But the expectation that developers still need to understand everything remains. Maybe 15 years ago it made sense. You had a single binary where everything was self contained. But if you fast forward to today, where you have a modern application that has multiple databases, 5, 10 microservices, that might be even in different programming languages with different patterns of access and deployment, it's a lot for developers. So what you said, I think right now there's a lot of people talking about, okay, we learn a lot through the DevOps revolution, right? We learn a lot about the importance of infrastructure as code, of having things be repeatable. But back then we focused on CI cd. A lot of these companies that are seeing these issues now are kind of asking, hey, can I do the same thing for developers? Can I create these abstractions? Can I create this automation? So the developers have a great experience when they're developing, but they're not using a lot of their time. And more important, a lot of like their, you know, like brain power in this task because you want your, you know, everybody wants to focus on the cool thing you're building, right? And you want all the kind of like more like process, all the automation, all the manual things to be fully automated. So we see that a lot. And it's interesting because we're seeing this. You know, in my role as CEO of Octeto, I got a chance to talk to a lot of companies that are building software. And it's super interesting how this is a concern and a challenge that pretty much everybody has like early stage startups all the way to very traditional, established Fortune 100 kind of corporations. They're all talking about like, hey, dev experience, how do I make it better, how do I make it easier, how do I make my developers more productive? Now there's a lot of buzzwords around platform engineering, developer experience, DevOps, but it's all the same, right? It's all about how can we automate and create the right abstractions so that we can leverage all these new technologies while at the same time ensuring that our engineers are effective and they don't get modeled in like all small detail. To me that is one of those things that I believe very strongly in and it's one of the driving forces behind what we do every day.

Absolutely. So you know, you mentioned cicd. A lot of people just focusing on production, getting things in the hands of the customers and I think they miss out on, you know, a lot of staging areas or intermittent Sprints and as you mentioned, working with other teams, I think with microservices, because there's different dependencies. So are there any gaps between were people just looking at production? Are there other stages that could help developers make the lifecycle easier for them?

Yeah, definitely. That is, you know, and it makes sense to start with production, right? I mean, that is the closer to value. You need that, that is hitting your customers. But what companies need to start to understand is that as you build these things, you also have these internal customers who are your developers because they need to be able to produce the software that you're going to take to production.

Right?

Whether it's the same people or a different team. So as you know, once you start thinking this direction, this is where a lot of this movement around internal dev platforms or these abstractions comes to be. Because I think that in an ideal world, you want every step of the process automated. But important is like, hey, don't have a single staging environment, don't have a single testing environment. You want to be able to give developers the ability to create these environments on demand. The same goes for what I call your personal dev environment. You want all these things in an ideal world, automated, because that way you know that, hey, I know how to build them, I know how to like keep them up and running when I don't need them. You can throw them away. And it's important because if you don't spend or if you don't invest in automating these other phases of the development process, well, they're still needed. So you're either going to have a lot of developers, each of them reinventing the wheel, trying to figure out how to build their own dev environment, which I've done many times, personally, I know, and everybody else does it, or you're going to have a world where everybody's blocked because there's only one testing environment, and then you have to kind of queue and wait for your turn. And this is an anti pattern, especially as you scale up. And there's nothing wrong with this. There's no shame on this. We've all gone through that process. We all did production deployments by hand many years ago. Technology is moving forward and now there is a bigger push towards investing in dev experience, which I'm very happy because it's a topic I'm very passionate about and also because I feel like it's important. You only have one production environment typically, but you might have 100 developers, so you end up with, hey, 100 developers trying to build environments. But if you only have one way that's automated, that's good for everybody, that unlocks so much productivity that then you can put that time to use in other challenges that are more specific to your business?

Absolutely. So I come from a tester's background and a lot of times I work for these huge organizations where one person didn't know it all. So to create an environment, you need to go to the mainframe guy, you needed to go to the database guy. And it was always a struggle just to get a working environment up and running. And like you said, it then became like, okay, we're doing a demo in this environment, make sure no one tests or does any development in it. And it's okay when you get a new developer in, they had to go to a wiki page and it was never up to date and they never could get anything up and running. So is that people still struggling with that is using like maybe a newer ephemeral environments actually solves that for them?

I mean, you're hitting all the high notes of every time we pitch Octetta to our customers. Everything you're mentioning, it's. I mean, I went through the same thing. It's still the reality for most companies because on top of what you said, now add the fact that a lot of these teams are now geo distributed on different time zones. So the pain of like I have to wait for another team to spin this up for me, it's multiplied by that. This still happens a lot. Ephemeral environments were born to solve this problem. The ideal for me, kind of like the gold standard is you want to have a platform, whether it's Octeto or something else. You want a platform to enable everybody in your organization to be able to spin up an FML environment without them having to have any understanding of the infrastructure, the architecture, all those things. And this makes sense for developers, for qa, for customer research, for sales, for demos. We've seen so many use cases where once you give this superpower to a team or a company, then they start using it in so many different ways. Like that demo that you mentioned, we see that a lot where organizations will set up, hey, I need, you know, startups, I need to show this new feature to a customer. It's not quite ready, so it's not yet in production, but you want to get early feedback. You put it on a branch, you spin up an environment, it's ephemeral, it's going to be on for a couple of days, but now your product research team can go show it to the Customer, have them play with it, gather some feedback. Great. You destroy the environment and you move forward. And not having to ask for permission, not having to wait for a central IT team to do this for you, or the dev team to have time to set this environment for you, is very powerful. It really enables. Can we go back to. I was thinking about being a team sport. It really enables everybody in the organization to truly contribute to the software development lifecycle instead of being more like, hey, spectators that have to wait for things to be in production and then they get to interact and give you feedback. With ephemeral environments, this happens way earlier and we have some like, we've seen very promising results from our customers in how this increases productivity. This makes their customers happier because they're involved in the process. It helps companies build better things because now you have this beautification and you're putting a lot of more points of view into the process. You have not just developers involved, but designers, product stakeholders into the cycle early on, which in my opinion only makes for a stronger, better process because you have now more points of views and people with more customer empathy or more developer empathy. All these things put together.

Does this help find issues before it goes in production better as well? Because obviously the quicker you could spin up environments, the quicker you could test things and make sure everything's running before you just push it to prod or even merge up the code. I think would save a lot of time, is what I'm thinking.

Yeah, no, it does exactly. Like once you have Ethernet environments, one of the things you can do is now you can have this kind of more realistic, like environments. Like. Actually, one of the reasons why we started Octeto is because in my previous company, one of our biggest challenges is how do you go from I have code in my editor, in my computer, to production? Like, we had this way to run things locally, but it always felt weird because we're building this massive, you know, microservice based application that is meant to run the cloud with a bunch of resources. But then we had to kind of like make this hacked version that only ran locally. And a lot of issues, a lot of quality issues were happening because there was no way to validate changes in a way that was realistic. And what you said is exactly what we're seeing. Now that we have this ability to spin up ephemeral environments. A lot of the issues that traditionally are only caught in staging, in testing environments, even in production, are now being caught super early. You know, when you write code, because now you can write code Apply this code change on your personal environment, see the whole thing end to end. Hey, this didn't work out great. I can fix it immediately while I still have the context on my head. And you no longer have to wait for, you know, in best case, commit, wait for CI, have a test fail and then come back to you. Now you can do all those verifications super early in the cycle and that saves so much time. I mean, there's so much research on how the sooner you find a bug, the cheaper it is to fix. And, you know, waiting until production adds weeks of extra work. You find the bug while you're writing the code, it's like, oh yeah, no big deal. You change this line, great, got to do the next thing. And it's really wonderful. When you see teams acting with this level of agility, it just changes completely their morale, their imagination, their capacity to tackle harder challenges. That's something that is not spoken a lot, which is if you give your teams a grade of experience and you give them these sandboxes where they can take risks and they're not afraid, hey, I may break production. Developers get better really fast and they start taking more risk and they start innovating more because they know that if I make this change, it's okay, I'm going to catch it right now. I don't have to go through the.

Shame of breaking production because of this change I made. And that makes for happier teams, more effective and I think overall better software.

I completely agree. Once again, I don't know if I worked in a dysfunctional environment, but developers were afraid to change code from other developers so they would start creating their own functions and methods that did pretty much the same thing. But I would assume like having this as, like besides unit tests as a safety net, I never even thought of this. Having ephemeral environments is almost like the ultimate safety net as well, it seems like.

Yeah, no, you're right. And I don't think this is something that dysfunctional environments like. I think it's more around, you know, every step we take technology wise, you know, enables more things like this realistic ephemeral environments. I don't think they were possible 10 years ago because 10 years ago spinning infrastructure was more expensive.

Right?

You had to like, or maybe 15 years ago when you had to go to data center and there's a physical limit to how much you can spin up. And you know, building a VM takes a long time. But as we moved forward to this world of like containers, kubernetes, like we can spin up Infrastructure so fast that now it makes sense to have the safety nets. Now you don't need to wait until CI as the only place where you can run tests. Like we're doing a lot of research now into like, hey, what would it take to bring more of the integration testing, end to end testing to ephemeral environments? Because then you can give this to your developers and it's one less thing they have to wait until CI to figure it out. And this is where like tools like Postman, Browser Stack or a few others, if you can find a way to integrate those with family environments, it's just part of the work we're doing. It's just one more tool developers have in their toolbox that makes their life easier. And for me it's all about CI is a great safety net, but it shouldn't be the only one. And you shouldn't be surprised when things fail in CI and be like, I don't know what's going on. It should be more for very edge cases or very specific things. But most issues, developers should be able to catch them as part of their normal developer workflow. And this to me is one of those keys where I work in teams like what you described, where we all depend on CI and it becomes very annoying and very sad. And what you said, nobody trusts the other teams because what if I break that? I'm not going to know how to fix it. I don't want to go through that hassle. I'm going to have to block the entire team until I'm done all that. It's not a silver bullet, but a lot of those things do go away as you implement ephemeral environments on an organization. It's really a, you know, it's a new tool that solves a big chunk of problems and you know, there are more. Of course there's no one thing that solves everything, but it is a catalyst for productivity for sure.

So find a size ephemeral environments. Is there anything else you think makes up for a great dev experience?

Yes, I mean definitely when we talk about the experience, when we started the company, we're very focused on family environments as the step one. As we understand this space better, as we talk to more organizations and we see how they evolve, I think that making sure you provide everything for your developers fully automated, one click is very important. IDE configurations, access to all the other tools you need. Like if you need an access to an AWS account, how do you automate that? Do you want to have to train every team in having to go open a ticket to get access, do this thing other thing. If you're using something like LaunchDarkly for feature flags, do you want to make this available to your developer or just in production? I think that as our understanding of software evolves, we are all coming to the realization that developers need access to all these things. So the more self service, the more automated. For me it's always talking about how these things need to be invisible. It's like hey, I go, I start my work as you said, new employee, I join a team, I want to have a one click experience. Hey, give me my environment and that environment should be the application, my aws account, my LaunchDarkly account. If I'm using something like MongoDB same thing if you have infrastructure around Datadog or maybe Prometheus Grafana is make everything available to developers in a way that they don't have to think about it. It's there, it's ready for them when they need them, but without overwhelming them because you don't want to. Like what you said the infamous wiki page that I've gone through that too where you have like 25, 30 different accounts you have to create on day one. Like I mean I joined this company many years ago, I'm not going to name it but I remember that they gave me this printout of like okay, welcome to this company, you need to create this 30 different accounts. I was like oh my God, this is terrible compared to like now where you join a company like okay, welcome to this company, go to this portal, click one button and everything is there ready for you. I think that's very important. And that's where like things like backstage, I find them super exciting. I mean even like the fact that single sign on is now the standard is so much better than before and have to keep track of 25 different logins and all of these things matter for the developer experience. And that's part of what I'm. As we talk more about this topic is what I want to make sure that more companies understand or more teams understand is developer experience is everything from the moment you give your new engineer the company laptop all the way to when they're pushing to production. And you have to think of all the different steps. Where are they getting the code from? How are they configuring their machine? What things for us in our space we push hard for hey, don't install things locally. Just have your ideas and your source code and let everything else run on this final environment as a way to lower the bar of the things you need to get started. But just like that example, I think teams need to think of every other piece, you know, as they add more pieces to their architecture, make sure it's available, make sure it's discoverable, make sure it's easy to understand because it's very easy for those things to get out of control. And then you have this kind of very slow team. But if you stay on top of that, if you measure it and you're kind of very. Not cautious, but intentional as you add more things to your dev experience, you can create these very complex experiences, but they are agile and that they keep developers happy and going at it, which is what we all want, that magical flow state. And I say developers, but I mean developers, PMs, designers, QA, like everybody.

I just keep thinking back to what you mentioned, the frustration. Just think if you can alleviate the frustration of a developer, how much more creative they can be and really focus in on the high order things rather than the. Like you said, I have to create 30 accounts. Which ones? I missed something, which one is it? And then they just go down a rabbit hole for a week. And all the productivity that's been lost because of that.

Yeah, I mean that high order, you have it right? Like imagine just like the difference when you, you start a new project and you're like, okay, new project, here's your ticket assigned, it's very well defined. Now you have to spend a week setting everything up just to get started. Compared to like a modern experience where like, okay, here's your ticket and by the way, here's a link that's environment, it's ready to roll. Just go log in there and everything is set up for you. Like not having to worry about all those things. It's massive because it's not just when you join the company, it's every time you're going to start a new feature, it's like a lot of that cost needs to be paid again and not having to worry about it. Like now that I, you know, we use Octeto internally of course. And whenever I have to work on something, I kind of forgot how like, oh yeah, I don't have to run anything. I just go say new ticket. Great, great environment. Sure, I'm ready to go. And it takes a huge weight off my back so that as you said, I can focus on high order things which is what makes, you know, the team different. And that's what, that's what we want like the 90% of time to be on, right, building these cool Things. Somebody told me that say, hey, you know, people join companies to build cool things, not to spend their days configuring things. And it's like, yeah, you're right, that's what we need to focus on and enable that as much as possible.

Absolutely. So we mentioned Octeto a bunch of times. I don't think we actually gave it a proper introduction. What is it? I also have in my notes Devex code or devex as code. So does this platform allow you to do this type of automation that frees developers up from low level type of activities? I'm assuming. I don't know.

Yes, exactly. So Octeto is a platform for developer experience automation. What it enables you to do is you create this file on any repository, Octeto YAML. And this file contains, you could see this as like the description of your developer experience. That's why we call this developer experience automation. And once you have that, what you give your team is the ability to go to a web portal or through a cli, execute one command, octetta up and then that will automatically create everything they need to get to work. And everything means, you know, all your microservices. If you need to import data into your application, it will do it for you. Create any cloud, resources, provision, other type of infrastructure, give you access, as I was saying earlier, to a launchdarkly portal to Grafana if you're using it, bring documentation into the UI so you know how that environment goes. The goal with our platform is that all of these things you have a central team that needs to configure it, the platform team. And once it's configured, everybody else in the organization, they no longer have to pay this tax. They just go to this web ui, click one button, get the environment they need to work, and when they're done, they destroy it. Great. And then the next day they can spin up another one again. And this applies to developers, to test environments, to environments. We have this one feature where you can integrate Octeto with things like BitBucket, GitHub or GitLab. So you can spin up these environments for every pull request. You can do it as you said before merging, to get modification, you can do it after merging. If you want to do end to end testing, show it to a customer. Like once you have this ability to spin up environments with one click, which is what Octeto gives you, really the, the possibilities are endless. It's really fun how every time I talk to a customer I see a new use case. I'm like, oh wow, you're seeing it for that. It's really cool because they just kind of like as you said, now they're freed from this. Wait. They come up with a lot of really cool ideas. Oh yeah. Now we can do this thing. Now we can do this type of testing or we can do this type of validation, or we can use this for a demo in a booth or for a conference stop or for xyz. It's fascinating.

Sounds awesome. So I don't know if I heard you correctly. Did you say there's an open source version of this as well? Yeah.

So there's three versions of Oktera. There's an open source, which is what started the whole thing. The open source is a CLI single binary that you can download on your laptop, on your machine and that allows you to deploy a dev environment. Oktera up, you bring your infrastructure, you need a cluster, some work, push your environment that's open source. And please check it out. GitHub.com octeto we're always looking for contributors, accept PRs, all that stuff. And then we have a SaaS version, octeto.com, where you can go and, you know, try it out yourselves. And then for bigger customers, we have also a enterprise version that you install in your company's infrastructure. But it's really the same experience. It's all about automating the developer experience. It's all about helping you to define what you want your developers to have access to. Put that on a file, so it's in a repo, so it has governance and auditing. And then from there it's just, hey, what do you want to do to deploy? Do you want to use the terminal? Do you want to use a web ui? It's entirely up to you. And our product line kind of covers this of like, hey, open source to small teams, to entire companies.

Absolutely. You know, just random thought. I know a lot of times developers have more and more on their plate like performance testing and security. So it sounds like using a platform like Octeto would help with that as well because you'd have a lot of those things automated in place as well to get it into a place where it's easier to do that type of testing, I assume.

Yeah, security pretty much everywhere. Where having all your services running helps, like security testing. Chaos Engineering is also a good use case for this. Any sort of like pen testing, because as the usage of a federal environment matures, you're going to realize that they start to look a lot more like production. And that's our goal. We're going to get you as close to production as you want and as economically and practical. Which means that a lot of these validations, you can do them there. And you're right. Security chaos, engineering, end to end testing, security scanning, UI based testing. We even have some customers where mobile developers are using Octeta to spin up environment. And then they're still using something like Xcode or Android Studio, but now they have this live API they can call and that way they can validate that their mobile app is working as expected, rather than having to create some sort of mock or like fake requests. And then once they do that, then at some point they have to go and try with the real thing and they discover that, hey, somebody changed an API. Like all of these scenarios are made a lot easier and it's wonderful. As I was saying earlier, all of this is examples of ways that our customers are using ephemeral environments to empower their teams and allow them to go faster.

Very, very cool. Okay, Romero, before we go, is there one piece of actual advice you can give to someone to help them with their DevOps efforts? What's the best way to find contact you or learn more about octeto?

Yeah, so if you want to contact me, we're going to talk about developer experience, about Octeto, about what we think is a modern dev experience. Please just reach out to us@podcastctera.com Happy to set up some time and talk to you and share some of this as part of what you do. Like to me, I mean, and this is probably obvious advice for anybody in DevOps, but automating as many things as you can is super useful. Like automate everything, put it on a repo. In our case, if I have environments, deployments, scripts, it makes a big difference. When we moved from kind of having everything on tribal knowledge to like, hey, no, there's code, their CI that is for me the most useful thing. And the same way that we've been investing in CI and testing, put your dev experience on a file. There's many solutions, October is one of them. But make it easier for your developers, like help them by not having to think. Like, if they don't have to make those choices, that means they have more time to think about cool things to build and that makes it easier for everybody. So definitely invest in that and make a conscious effort early on. Don't let it become a problem. Invest early on so that you have a clear, nice growth path that makes a huge difference, especially as you, as you scale organizations.

And for links of everything of value, we covered in this DevOps toolchain show, head on over to test guild.com P116 and while you're there, make sure to click on the SmartBear link and learn all about SmartBear's awesome solutions to give you the visibility you need to deliver great software. That's smartbear.com so that's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed with creating end to end full stack DevOps toolchain awesomeness. As always, test everything and keep the good. Cheers. Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguild.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real world value that can improve the skills or solve a problem for the Guild community, I'd love to hear from you. Head ON over to testguild.info and let's make it happen.