How Google Improved Developer Experience with Hugo Santos

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, if you're like me, you probably wondered, how did Google improve developer experience to deliver features faster? Well, you're in for a treat because we have Hugo Santos joining us. He's the founder and CEO of Namespace Labs and brings over 20 years of expertise in tech innovation at Google. He helped build the microservices platform that powers search Photos Assistant and co led the Assistant platform driving Google's smart home ecosystem or ecosystem. So now at Namespace Labs, he's transforming developers workflows with groundbreaking tools and platforms for faster, more secure builds and tests, and really knows his stuff. You don't want to miss this episode. Check it out. Hey, before we get into this episode, I want to quickly talk about the silent killer of most DevOps efforts, that is poor user experience. If your app is slow, it's worse than your typical bug. It's frustrating and in my experience and many others I talk to on this podcast, frustrated users don't last long. But since slow performance is as sudden, it's hard for standard error monitoring tools to catch. And that's why I really dig Smart Bears Insight Hub. It's an all in one observability solution that offers front end performance monitoring and distributed tracing. Your developers can easily detect, fix and prevent performance bottlenecks before it affects your users. Sounds cool, right? Don't rely anymore on frustrated user feedback. But I always say try it for yourself. Go to smartbear.com or use our special link down below and try it for free. No credit card required. Hey Hugo, welcome to the guild.

Hey Joe, thank you so much for having me.

Awesome. So you have a great background, I guess a little bit like how did you get into tech? How did you end up at Google? What was that journey like?

Yeah, it's. It's an interesting question. I'm very much an entrepreneur at heart and I knew that without knowing it from an early age. So I actually started building software by myself. This was a long time ago when you could still get magazines that had printouts with code. So that's actually how I got started. Learned C C on my own, reading through KDE's source code back in the day, then had a little bit of a love affair with Bos, a Mac before that, but then bos, not everyone will, will know that operating system. But spent a little bit of time there, built a bunch of software, sold my first piece of software and I was 15 for BOS, an image management software. And then went through the regular path, went to college, spent a lot of time kind of on open source, got my first job. I wasn't too happy about that. I felt like, okay, I want to innovate, I want to kind of build out new things. So it was clear that I needed to start something. Managed to find some crazy dudes back in Finland that had similar goals. Moved to Finland, started my first company. We were doing edge computing before edge computing was really a thing we were streaming. So it was an advent of the smartphone. Streaming smartphone applications from kind of very close, from telcos, A lot of fun business, terrible. Lots of learnings from that. And then after going through that path I had some connections with Google because I knew a few people that work there. And honestly after my first startup I needed a break and Google came knocking and asked, hey, would you like to join? And I thought, okay, let me go and check this out. And it ended up really being, having a major impact on my life. I grew up a lot. I came in as, you know, a little bit of a youngster with a lot of energy, know it all. And I got humbled by a fantastic set of engineers that I got to work with and really see how, you know, world class technology gets built. So I still have very fond memories of that time.

Nice. So what year was that when you were at Google? I'm just curious.

Yeah, I joined 2013 and then I left 2021. And you know a funny thing that I still remember with fondness is when I joined Google was already a large company, but I remember in the internal Google, this was kind of the time Google was still a thing competing with Facebook. Actually that's part of the origin story here. But I saw many posts still, hey folks, we need to make sure that this feeling of being a startup, we need to retain that for as long as possible. And me as just coming from a startup, seeing that when it was a 50,000 person company, it was really surprising. But actually a lot of the properties of a startup were still present back then. So it's really incredible how far they took it.

So that's what I was going to say. I mean it's still cool but you were there when it was cool. Like 2013 is where everyone wanted to be at Google and you were there. So I mean I'm not Saying it's not cool anymore. But it seems like it was a really cool gig at the time, for sure.

Yeah, I was humbled by it. If you would ask a soft engineer back then, where would you like to work? And I think there would be a few places and Google would be one.

Of them, a hundred percent. So, you know, you had a lot of unique experiences there as well. One of them was creating a microservices platform. I forgot what's the name of it? Bok.

Yeah, you know what's interesting? Like we. It ends up still to today, still used to build a lot of applications at Google, but we never really talked about it externally. And so it's called B O Q Bach. And I was also fortunate that I joined a team really at the start of bok. So they were coming in from the. So kind of the backstory is that this was at a time where the competition with Facebook was fierce. We were building out Google, Facebook was just growing like crazy. And it was so important to move very quickly. And so block show appeared out of necessity was really to expedite the ability for Google to ship new products. And I joined really at that inflection point. And then I helped build bulk to the platform that it became where it tackled a lot of different problems because originally it was very centered around how you build services. And when we were done, it was really about the full delivery story from all the way how you build services to how do you deploy them to production, how you manage them as well. And I played a role in that story. But I want to also highlight many of our, my kind of brilliant colleagues that also kind of drove the development of bulk because it was really this massive infrastructure project that we did.

So how did you get involved then? Were you one of the folks that came up with the idea for it, or did you pitch it to someone, say, hey, we have this idea for this microservices platform, think it's really going to help? Was it almost like you were like a mini startup within Google pitching this idea and then creating it?

You know, I really like that question. A lot of these projects, they surface organically and even when bulk was started. So I was not there day one. The first starting point was we're building all of these disparate services and all of these services. So RPC services, front end services, they all have the same properties. They all need kind of request throttling, they all need kind of context propagation. So there were some properties they all needed. So that was the step one. Building a common layer to build services. And that predates me. And this particular area of the company was very Java centric, both for backend development and for front end development. And so that's what's kind of the genesis of bulk. Where then me and my team's help kind of drive was beyond this kind of service layer of how these services behave in a common way, all the way to, hey, we need to have a common specification of how to deploy these services. What's the release processes, what are the monitoring metrics that we have in place that get exported by default so that you can then generate dashboards to monitor your services. So after bulk you would write application code. So you handle a request, you issue multiple requests to your backends, you run some business logic and primarily that's what you're doing as an application developer. Everything else from let's compile this into a binary that gets distributed to production to a fleet of machines to how it gets monitored, what are the release stages, how do you test it as well. Which ended up being one of the instrumental pieces for Buck. And it had built in end to end testing, which prior to bulk was extremely hard to achieve. So it was kind of really fully serviced end to end and that ended up being organic. It also surfaced in a place where it was needed. So there was never a mandate of, you know, go and figure out the infrastructure that is required here. This was an infrastructure team that was embedded with application team and working hand to hand to solve real world problems. And on the way we realized that, well actually these problems that we're solving, they're not unique to this organization. We know these other teams that have the same problems and organically working with those other teams we started expanding the scope of bulk and eventually it was elevated to be kind of more of a company level infrastructure product that ended up being deployed throughout the whole company.

Nice. Really cool. So what was the problem or challenge that it solved for developers?

Yeah, so couple different problems. One of the problems was you want to start the process of starting a new application. So for example, Photos. Photos was a completely new experience. The starting a new application at Google was extremely difficult. Like you have to from day one be able to handle a lot of users, a lot of traffic. You need to make sure that your processes meet the bar. From a production perspective. You want to make sure that you have as comprehensive testing as possible. So getting started was extremely difficult. Box solved that by removing a lot of the complexity of okay, how do I deploy these services to production in a way that my SRE team will be happy with. How do I write these end to end tests? What are the metrics that I should be instrumenting and then aggregating and write dashboards for? What should I be looking at? What should I alert on? So all of those problems were removed. So someone else figured out solutions that were tackling 95% of the use cases horizontally. We use that word quite often like horizontally. So for multiple verticals. And so that was one big accelerator. The other part that became more obvious over time was that because now all of these new services get built in a similar way, then teams can collaborate much more effectively. When you're talking about my service makes a request to your service, I can actually look at your metrics, I can actually look at your tests to understand what's going on because they're built in a similar way as mine are. So this really had a compound effect in helping collaboration not just within a particular application area. So not just, let's say Google with a Photos team, but then also across application areas because there were touch points on those as well. So whether the YouTube team would use some infrastructure built by someone else, like being able to rely on a common set of technologies really simplified a lot of those processes.

How did the other teams like YouTube, how do they know about this platform? Like, oh, they're using this for photos. Maybe we can use it. Was it more, you had to evangelize it as well or is it the word just spread?

Yeah, so there was a bit of both. When you have such a large company like Google, things that we see that happen in the industry, like for example, you have an engineer that is in a company and they really love a tool or, or a piece of infrastructure and then they move on to another company and they bring that infrastructure with them. Right. Because it was. They saw the transformation that it had to their team. So a bit of that happened. You could think of it. It's kind of a property of Google. It's. At least when I was there, it was fairly common for engineers to move teams from time to time. So there was kind of a natural dissemination by. I used to be in this team that relied on bulk to build services. And now it feels like I took a step back and I'm back three years of how we used to build things. Can we move over now? Obviously, changing how you're building software is extremely painful. It takes time, it takes deliberate effort. So everything that was greenfield, it was kind of an obvious conversation. Everything that was already established, the adoption cycles took longer because. And that was the case of YouTube, for example. So they would have known about bulk earlier, but they only adopted it later when it kind of made sense in their development cycle.

Absolutely. And it sounds like, you know, microservices now have a very well known microservice architecture, but it sounds like this is probably one of the early precursors to that as well. So you're dealing with newer technology that maybe had been proven yet to all the teams.

Yeah, I must preface with the term microservice. I find it to be so divisive in a way in the industry. So maybe our definition of microservice, because indeed internally that's how we called it. We said that bulk is a microservice platform. The properties of microservices that bulk had was service composition. So you could have, you were very service centric. So service oriented architecture and then composition of different services. But it wouldn't go as far as, for example, to handle, since we're talking about photos, to handle a photo you need 10 services and then each service can only own its own data. It's fully encapsulated. So it wasn't dogmatic, it was very pragmatic. So if a team would want to share data across microservices, they could if they would want to, but there would be a very service oriented architecture that bulk facilitated. So everything that was on a service boundary worked just much better. So for example, metrics, you would have automated instrumentation based on RPC methods that you would have in your services. So that would kind of motivate teams to describe an architecture around services because they would get these features out of the box. If you wouldn't wrap your business logic in a service, you would have to go and figure out metrics yourself. And, and you can do that, but it's just additional work and, and complexity. One of the instrumental things, even today I find that I haven't yet seen that replicated in the industry is box testing framework. And, and I cannot claim any sort of. I had my contributions, but it was work primarily driven by a fantastic team that they built something unique. Every single service boundary was testable and would be replaceable by either a fake or you could also replay traffic at that service layer. So you could build fairly comprehensive end to end tests that would be very representative. Bulk didn't like mocks too much, so it was often kind of the real implementations. And that really meant that we could build very robust systems. We kind of with the confidence that they would work like testing was very representative. And all of those operated at the Service layer. So the microservices was really primarily because of having a service oriented architecture more so than anything else.

Gotcha. Yeah. So testing's a huge piece and I would assume that would help the developer experience because traditionally I don't know if developers how strongly I were testing, how much they like testing. So consuming this platform then it already had the ability to test it end to end. And also I would think performance testing because it sounds like, you know, you're doing YouTube searches, Google Assistant, all these things that require probably fast, snappy responses with a lot of load on it. Did it have performance built into it as well? And that was another benefit to the developer experience.

So let's start there on the load testing side, kind of understanding performance. It did have some components, but at least while I was there, they were not as far as we would like them to be. We wanted them to be exactly the way that perhaps you're thinking about them, that you kind of would get some performance data from, from kind of test runs and understand those. So you could. And again at the service boundary we could run a load test. So there were systems that were built into bulk to do so, but they weren't as plug and play as everything else. When it came to end to end testing, the difference to the traditional setup was dramatic. There were systems like teams prior to bulk. They would do end to end testing, but it would be a never ending story of fighting flakes. In particular, deciding which systems from other teams do I incorporate into my tests, which systems do I fake because of the interoperability. Sometimes you wouldn't even be able to easily integrate the system of another team that you depended on because the way that they built and developed that system was completely different. So with bulk you could say, well, my system that for example handles photos, it needs to interface with a system that does blob storage, like object storage or equivalent. I could declare that dependency. And then as I started an end to end test, it would bring a real blob store that I would interact with in my test. We wouldn't be faked, it would kind of be the real implementation. And that was enabled by this kind of common interoperability layer of like everything that would be developed in bulk would be naturally usable in end to end test. But then there would also be these connectors at the edges that would be able to connect back with kind of the legacy and the external world, let's put it like that. So that made writing end to end tests much simpler. And because they were fully descriptive of all of the dependencies, they could also run in a much more controlled environment. They didn't have to hit production systems or staging systems. They could run those dependencies as part of the test environment in an aromatic way. And that really dramatically improved the developer experience because there were a lot less, a lot fewer flakes that you had to work with that you had to kind of solve and understand. But also the kind of plugging in and everything was really like a one line. I also depend on Blobstore, so I also depend on object storage. And it was just kind of magically appear in your test environment. And that ease of use really transformed how teams were then writing these end to end tests.

Very cool. What was driving the end to end test though? Was it technology? Was it APIs, or was it like Selenium? Was it some other thing?

So the end to end tests were also very driven by service boundaries. You would write a test and that is issuing requests to this system under test. So as you can see, there's this kind of a pattern here. It's very service oriented. So your test driver is actually emitting requests back to its backend. It's almost operating as a custom client which you control. You can say, I want to issue this request and then this other request. And so that's how it operated on the backend. On the front end, it was also very service oriented. The testing setup was a little bit different there, but kind of similar principles around. You're making a request to a subset of the system like service, that service is a part of your front end.

Gotcha. Now, you mentioned flakiness a few times. So I assume that one of the developer experiences that helped was when a test failed, maybe developers would pay more attention to it. Was that one of the things as well that maybe helped that, oh, it's just a flaky test, it's like, oh, this is usually really very reliable. Maybe I actually have a real issue.

Here because of the way that the tests were set up, that they allowed us to run the whole test. So what we would call the system under test in a controlled environment. Like we would create an environment and we would start all of those. Not only your server that has your code, but also the servers that you're interacting with to issue requests. And that environment was very controlled because it was not handling any other requests. It was not subject to different load. It was not subject to, okay, I'm issuing a request across regions. The latency might be different. So it was a very controlled environment that by itself dramatically reduced the flickiness of tests. Then we also had folks that were invested in deflaking. So because you run these tests in a way that is deterministic because the environment is fully defined, again you're not dependent on an external system. You can run them multiple times to try to figure out okay, is this a real failure? Is this a probabilistic failure? Was this failure introduced when this change was made? And that whole journey was really helpful for developers.

Nice. I know working at big companies having to worry about dependencies in environment. Do I have the right dependencies? This sounds like it solved that as well. It was so self contained. So it solved all those issues.

Yeah, it had. I mean there were pros and cons with bulk, I must say, or the.

Consent.

Like life is all about the trade offs. And there were definitely trade offs that you did when you adopted bulk. It guided you towards a particular model that might not be your personal preferred model. So we had teams that were that like to build very complex high performance monoliths and it made a lot of sense for their business needs. And moving over to Bach required them to rethink that architecture. And that was a tension point at times, like they didn't want to, it wasn't obvious from at the beginning sometimes the benefits that they would get with having to change the way that they wrote code. So I think that was one of the major things with bug that it required. If your code base was not already structured in a particular way, it required an investment. Your engineering team would have to do some refactoring, would have to move things around to be able to obtain all of those benefits. Another problem was that it's kind of interesting because it was a design principle, but over time it became, at least in my opinion, a little bit of a liability. It was very monolithical. So even though Bach told you build services in a very composable way, bulk worked really well end to end. But if you would want to go and do testing in a different way, for example, it would be very difficult, extremely difficult to interoperate with the system. And the reason or one of the reasons that was made? Well, one of the reasons was because it was simpler to implement. But another reason was also we felt that it was a tool to drive a cultural change as here's how. Let's build on the many years of accumulated experience of building services and now help teams kind of go down the, you know, the happy path as we sometimes we called it from the get go. But as we kind of expanded to more parts of the company, it was clear that inflexibility was at times constraining.

All right, so you start off at a startup, then you start off, then you went to Google, you were there for looks like almost 10 years. Sounds like a really cool gig. What made you then go on a new adventure and start Namespace Labs?

Yeah, it's a great question. Was extremely difficult to decide to leave Google because it's such a fantastic place. I think I'm at heart an entrepreneur. I like to think through, I like to connect with the customer, I like to understand their pain points. I like to be able to talk with them about how we can help them. I love technology and a reality is that to innovate you're kind of unconstrained. Outside of Google, inside of Google the stakes are extremely high. And doing any sort of larger change requires a lot of people to be aligned behind what you want to do. Because just as you can imagine, it's, it's a well functioning machine and if you want to kind of steer it a little bit, there's a lot at stake. I really appreciate personally that agency and I know that many of the folks that work with me at Google also appreciated that agency of just going in and building new technology that could help teams and in particular kind of interacting with, with our customers directly. And that kind of was the primary thing that precipitated starting Namespace.

So I guess with all your learnings, with the developer experience and developer workflows, what is Namespace Labs then? What did you build that you're like, this is really going to solve an issue. I know is going to help a lot of people.

Yeah. So Namespace at its heart, the mission is to kind of bring the same kind of managed developer experience that we had at Google to many teams out there, to many companies in the industry. Because we see this kind of over and over that the same problem, like different teams face the same types of challenges and they kind of find their own way to solve those problems, but very often in a way that is not unique to them. And it's also always struggling for time because if you go and talk with a startup or a mid market or even a larger company, they're very focused on their products and the value that they want to bring to their customers. And infrastructure is something they do because they have to, not because it's the thing that is bringing value to their customers. So trying to bridge that gap. So that's generally like we're leaning on our experience to help engineering teams out there to kind of go faster. What namespace is doing today is something very specific that's we actually stumbled upon it as we were building out our own technology that the performance of build and test is kind of underserved in the market. The hyperscalers are fantastic. They do great at supporting production workloads. But then when you use that infrastructure to run your tests, run your builds, to run various orchestrations, this just doesn't quite hit the mark that you would have. Like for example, when you're using your own laptop. Like I talk with so many folks that they have an Apple laptop, whether it's, you know, M2, M4 doesn't matter and they building their application and it's so fast and then they go and ship that to CI and all of a sudden it's so slow and like why is that? Well, part of it is because those workloads are running in traditional kind of production oriented hyperscaler server hardware and architecture. And so we took a different path. We said okay, what if we would target building the best performance possible for build and test? What if tests wouldn't and builds wouldn't start from scratch all the time, but they would be incremental very much as they are in your local workstation. So that's what we set ourselves to do. And it's been working, at least that's what we hear from our customers, that they get a lot of value from it. The tremendous difference in performance.

All right, this is a big pain point. I know from working for large enterprises. Test work locally, put in cicd, it fails, don't know why. Can you talk a little bit more about the build and test approach then? Is it an ephemeral environment that spins up, it has all your resources and data you need, it runs, it's fast, runs tears down so you don't have to worry about maintaining all these physical environments and connections. I'm just assuming, I guess Chuck a little bit about what the build and test approach is, I guess.

Well, you did a great job at describing at the heart what it is. It's a specialized test compute system. So we're a specialized cloud provider that can create ephemeral environments really quickly cold booted. So without any previous state, we create environments that run a set of containers that you can define in under two seconds and then you can use those to run any workloads. One difference that we do is we deploy those workloads on hardware that that is the best in class for build and test. So if you think of the best workstation that you could get in the market that gets you the best, you know, build performance, the best test performance. That's the hardware that you're using when you're deploying to Namespace. But there's a second part to the magic story, which is we understand that when you build something, when you test something, there are objects that are intermediate, outputs that are persisted, that are useful next time that you run a build, next time that you run a test, so that it's incremental. So we have this feature called cache volumes, where in the second run or nth run, we have folks doing thousands of runs in the span of just a minute. They have access to this previous data and very much as you would in your local workstation. And that means that those runs will be full incremental. So it's not uncommon that we see the transition of, even in a small repository, kind of build and test, end to end, three minutes and a half in a small repository, as a baseline, moves over to namespace, two minutes, just much better hardware. And our scheduling moves over to our incremental kind of caching Solution. And it's 10 to 20 seconds. So kind of going from three minutes and a half to 20 seconds, that just changes how a company operates and how often they ship changes. So that's kind of the vertical that we're very focused on tackling, and we do that kind of with full heart. So one of the things that we do that is unconventional is we deploy our own hardware. We couldn't find the right hardware out there in the hyperscalers in aws, Google Azure, and we wanted to build something of extreme, high quality for our customers, extreme, high performance. So we had to go and deploy hardware ourselves. So we actually have hardware in multiple locations that we orchestrate end to end to serve these workloads.

Can you give some quick examples? What's stored in that cache? Is it like a test needs data, needs to run the next round of tests that the first round created? Like, what's the cache for? I guess.

Yeah. So if you're in the GO ecosystem, the GO compiler will generate objects for every single of your libraries. So every single library that you have will have an intermediate object representation. If that doesn't exist, it has to be rebuilt. And so what Namespace does is it configures the GO toolchain. So actually that was something was really important for us. And it was also a hard lesson connecting back to bulk. So bulk required you go and change your application. We wanted something that required as few changes as possible. So we configure your existing toolchain, for example, the Go toolchain, and we tell it when you're storing, when you're creating these intermediate objects, rather than placing them somewhere in a particular directory, place them in this other directory, which is where our cache volume exists. Then we rely on the fact that the Go toolchain is correct when it reuses these results, because that also correctness is very important in the build and test world. And so next time around you'll have all of these intermediate objects already present. So when you're doing GO test, which requires a build first, most of your build outputs already there, and Go also tests also caches test outputs. So if the test binary didn't change, it will, remember that test already passed and that's also persisted. So it's very much the same experience that you would get in your own workstation. You write some code, you run the tests, you can have closed the laptop, you go, you do it, open the laptop, do another change, and it's fully incremental because all of your previous outputs are still there. And that's what Namespace does as well.

You know, when you start, you started in 2021, your company and I think the, you know, AI has been around forever, but the ChatGPT really became really popular in 2022. So I guess my question is, where do you see AI evolving with the developer experience in the next one to five years maybe? And have you planned for that to bake it into your system?

Yeah, it's a great question. It's obviously top of mind. I think internally at Namespace, we believe in AI, empowers humans and we see engineers building better and more robust systems because they have the support of AI. So that's how we are thinking about the problem right now. None of our features leans on large language models, but we have a few things that we can already see that would benefit from kind of a semantic understanding across multiple runs. So, for example, you're trying to understand why a particular error is occurring. And if you have to sift through kind of many services that you're running to understand, okay, what was the actual root cause? That's the kind of thing that a language, large language model can help you kind of surface much more crisply. Actually, there's this. It seems like there was also an issue here. Like there's this log line. So we're looking at AI as kind of empowering developers. And then the other thing that we're seeing is that there's. With code generation, there starts to be a Lot more code out there. And there's a question on okay, well how does validation look like when you have so much more code being generated? Because that code we cannot or today we don't assume that it's correct. Right. So we still need to build it. And folks know that like if you use Copilot, perhaps in January 2025, it's slightly better. But a lot of the outputs of these AI tools, they still need to be verified by an engineer, by a human, by a developer. So we're also thinking about how can we help with automation around some of these verification that can scale with the increase in co generation in the industry that is kind of driven by AI. But for us it's still nascent times we're looking for. We're very value oriented, you know, we're developers, developers don't like, you know, gimmicks, bs. So we're, we like to kind of work with folks and kind of bring very concrete value. And so we have ideas but we haven't yet nailed that value. But it's something that we expect to get to in as we go into 25.

Okay, Hugo, before we go, is there one piece of actual advice you can give to someone to help them with their developer experience, DevOps efforts and what's the best way to find or contact or learn more about namespace?

Yeah, to learn about namespace, head over to namespace. So an advice which I see folks kind of doing less but I think in today's age is still important is become comfortable reading code. Code is the ultimate documentation, is the ultimate interoperable layer. And if I think through the best engineers that I've ever worked with, they always were very comfortable sifting through their code, other people's code to understand what's going on. And so that's something that I tell people that I work with nowadays, like just read through the code, feel comfortable reading through the code and maybe use a copilot to help you do that. But just feeling comfortable going through your code base, your teammates code base, other people's code bases. I think that's a superpower that is under invested in.

All right, before we wrap it up, remember, frustrated users quit apps. Don't rely on bad app store reviews. Use SmartBear's Insight Hub to catch, fix and prevent performance bottlenecks and crashes from affecting your users. Go to smartbear.com or use the link down below and try for free for 14 days, no credit card required. And for links of everything of value we covered in this DevOps Toolchain show head on over to test guild.com p1.79 so that's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed creating end to end full stack DevOps toolchain awesomeness. As always, test everything and keep the good. Cheers. Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation, testing and DevOps. If you haven't yet, join our vibrant community@testguild.com where you become part of our elite circle driving innovation in software testing and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges, we're excited to to collaborate. Visit testguild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve.

With lutes and lyres, the bards began their song A tune of knowledge, a melody of code through the air it spread like wildfire through the land Guiding tester showing us secrets to behold.