 Hi, this is your host of Limhartiya and welcome to a brand new episode of our series TFI topic of the month a.k.a. T3M. And this month's topic is platform engineering is DevOps there. And today we have with us Helen Altshuler, co-founder and CEO of EngFlow. Helen, it's great to have you on the show. Thank you. It's great to meet you. And today's topic is we are running a monthly series is platform engineering is DevOps that of course, there's a lot of discussion going on and depending on which camp you talk to. But let's start with some basics. If I ask you, how would you define that form engineering without using the platform engineering wording itself? I would say it's a central team responsible for core engineering workflow and associated tools, frameworks and practices that help the organization implement consistent and productive workflow workflow for their software developers. Can you talk about the evolution or emergence of the term? Where does it come from? Because sometimes terms come from vendors. Sometimes it comes from the user community itself. I am not quite sure of the actual history, but I would say that it did start with this kind of shift left in the industry. You may have heard the term shift left and that usually means shift closer to where the code is written. So from deployment closer to CI, from CI closer to code. And that may have been the inspiration here. So specifically when it comes to like software development organizations, you've heard DevOps, you've heard SRE. And really the difference that I could see is that the shift left defines what kind of skill set is necessary. So for SREs, and we can talk more about that for SREs, the function is focused on operating stability and managing production at scale and influencing development practices. Then the shift left from that happens, which is closer to the code with the formation of the DevOps function. And that focuses on integration of various test and deployment platforms, things like Jenkins for CI, figuring out best strategy for integrating source code, whether it's GitHub, BitBucket, and how the entire developer workflow will work through the pipeline with various tools. And so that's the shift left that happened, which means now you need more software engineering and software test engineering skill set in order for these organizations to be successful. It still is fairly operational in nature, but requires a development skill set. And then platform engineering is a further shift to the left, where this is now an engineering organization that typically sits in your engineering. And their main focus is not just on bringing tools, but very often building tools and building developer workflows that are optimal for that specific organization, such that it tailors to their unique development processes, development tools. And ultimately, these are the teams that are responsible for developer platform quality. When we do look at platform engineering, culturally, what kind of what kind of difference is there vis-a-vis DevOps or SREs? Because DevOps, once again, these are tools, these are practices. So talk about that. Sure. I mean, it is related to that model, the shift left and the evolution from SRE to actually, even before SRE, evolution from UNIX administration and database administration towards SRE, which is looking at more holistically at the platform. And then towards DevOps, which is looking at pipeline, which is essentially the developer workflow. Code to production, what are the different tools that it touches? How do you accelerate the process? How do you give people the best experience, developers that work with it? And ultimately, with the shift towards platform engineering, and actually qualify platform engineering, it's not one-size-fits-all. DevOps is also often morphs into that as well. Smaller companies will more likely operate at this SRE and DevOps model. And really, in my experience, larger companies that are working with engineers of 500 plus will start looking at centralization of different practices across various DevOps teams and create the single team that's responsible for not just managing the environment and integrating, but actually sometimes even changing the underlying tools and technologies that affect how developers build software. When we hear the term DevOps is that is it really dead? What is happening there? I think it changed shape. It's not dead, but it definitely its shape changed. And it's certainly the observation I'm making, it depends on the size of the company, it depends on the industry, it depends on what their developer workflow looks like. And so there's certainly elements of what DevOps does that are covered in SRE. There are certainly elements of that in larger companies that are done by platform engineering. And some of the prominent examples that I can tell you from speaking with our customers and partners in the software industry, really examples of Wix, Snap, Airbnb, specifically Kamini Dandapani from Airbnb has given multiple talks and I've spoken with her a lot on the subject of this SRE. Obviously the SRE has an important function to play, but there's the SRE partnership with engineering organization. And that's where I think DevOps morphed into the SRE's platform support and platform scalability and understanding of how to build platforms that will run at scale reliably and platform engineering teams that are implementing those workflows and often implementing the very foundational elements like switching the build system, which comes from a lot of the experience that I've had at Google as well. Google's platform engineering really started with the new generation build system, Bazel, in case of Google, internally blaze. And developers started using it and saw the value that it has and it created a much more opinionated stack that other platforms were built on top of for a much better, smoother developer experience. Now, at the early end, you mentioned developer experience. I hear that term also a lot these days. First of all, talk a bit about what does that mean? And second is that why do we have to or actually not we have to? Why are we talking a lot about what is the importance, significance of companies do understand the importance of developer experience today? Yeah, I would say that and obviously Google is an amazing example. And they've published a lot of its internal findings about the developer experience and created lots of really useful resources. So I would say, first of all, it starts with a key questions. Are your developers happy? People that write code, are your SREs happy? People that have to make sure that code is reliable and runs at scale? Are your product managers happy because product is shipped reliably and on time? And are your customers happy because of better release cycles because of software updates that are more frequent, better security updates and less bugs in software as well? And so these are all of the core questions that an engineering organization needs to be able to answer. And so one of the things that Google collaborated with a number of other companies to create DevOps research and assessment, the Dora metrics, and they've come up with these four keys project. And they really looked at the four key metrics. Deployment frequency. How often is an organization deploying is releasing code to production? The next one is lead time for changes. So the amount of time it takes from a single commit to get into production and all of the systems that it touches. And so this answers the question of are your product managers happy? Are your customers happy? Then the third metric is change failure rates. This is where the contract between developers and SREs are your SREs happy because the percentage of deployments that's causing failures in production is at a low rate or like you want to drive it as low as possible. And another also very related to the management of the system, which talks about are your customers happy and are your SREs happy? And that's time to restore service. So how long does it take for an organization to recover from a failure in production? And so all of these core metrics, they give you a better sense of what does your company's developer experience look like and what does your company's product experience look like? And then in terms of the actual focusing on developers, what does it mean for developer to be productive and happy? Those things typically have to do with wasting the last time waiting for slow run, slow build, slow tasks, spending too much time debugging a particular environment problem because something changed unexpected in their test server. So looking at tools that help you measure the success of the organization and ultimately providing a good developer experience means that your path to from code to production is as enjoyable and as smooth as possible because of the best practices that are implemented. What is your advice for companies so that they can embrace the right practice for their organization to just know as we had a lengthy discussion around platform engineering, DevOps, SREs? The most important thing I would say there's no such thing as one size fits all pattern here. So most important for the companies, the step one is to listen. If you're thinking about platform engineering or developer experience more holistically, listen to your engineers. So user interviews, trying to gather metrics. Again, I'll give Google as an example, because I've worked there and I saw some of the best leading practices around how to measure whether your developers are happy. Are they happy with the tools that have to do with builds or with tests? Is there is a particular team experiencing worse experience, worse problems because they're using Macs as opposed to Linux machines and really dissecting and understanding. Our developers happy and when they're not happy, categorizing into areas and then defining and designing the platform experience, platform engineering practices, it doesn't have to be a separate organization. If you're large enough, it often makes sense to have it. But for midsize smaller companies, it's really understanding what are the practices for developer experience and looking at some of the best practices that I just described. Really understanding how to focus on the tools and how to focus on making sure that the right engineering organizations are supported, that they feel supported. And that ultimately comes through user research. A lot of the kind of trial and error validation and designing prototypes, especially if you're going to start implementing some of the tools you need to measure it and you need to start looking at failing fast, like a very common example here. And really figuring out how to work from start to finish and design an experiment that validates are you addressing the problem that you just uncovered through your developer research, your user research? Are you addressing it with the right solution? Or is the problem shifting to the next bottleneck? Helen, thank you so much for taking time out today and talk about this topic. And I would love to have you back on the show. Thank you. Thank you. I'd love to be back.