 Hi, this is your host, Sableem Khartia, and welcome to a brand new episode of our series, TFR Topic of the Month, aka T3M. And this month's topic is platform engineering is DevOps there. And today, we have with us Dothan Horowitz, Principal Developer Advocate at Logs.io. Dothan, it's great to have you on the show. Thank you for having me, pleasure being here. Before we get jump into the discussion of platform engineering versus DevOps versus SREs, how would you define platform engineering? I definitely don't think that DevOps is dead. And I actually view platform engineering as an evolution. I would say that we all know DevOps as the combination of tools and practices that enable the release of the software all the way to production. In a way, I would say that platform engineering is the productization of these tools and practices. And packaging them in a way into reusable services that can be used across the organization, across business units, across product teams, across the house, obviously very relevant, mostly relevant to large organizations where you have lots of them. And you rightly said DevOps is not a job title, it's practices, it's tools. Talk a bit about your companies, tell how do you fit into this context, Logs.io. Logs.io is a company in the DevOps and observability space. What we do is we take the best of breed, open source tools for monitoring and observability, such as Prometheus, OpenSearch, OpenTelemetry, Yega and provide them as one unified managed platform built for scale. So in essence, our customers get the unified open platform and we call it Open360. So it provides a 360 degrees view of their infrastructure and the applications across logs, metrics, tracing, even security, and they enjoy the best of both worlds. So they keep on using the open source that they know and love, but without the hassle of running and managing it. And of course, without the risk of vendor lock-in as in closed source solutions. And when we look at it from the platform engineering perspective, the platform engineering teams look for consolidated ways to see the infrastructure and application and then make it available for the different teams, the different product teams, the different infrastructure teams, the DevOps teams across the board. And that's where we fit in. We allow these teams to keep their practices, their open source, their PromQL query language or Lucene or whatever, what not. And still do that in a consolidated unified manner. We're also talking a lot about developer experience these days. First of all, let's talk about how would you define developer experience? And then we'll talk about when we look at platform engineering, how does that enforces that view or helps developers? So I come from a developer background. I've been primarily a backend developer for many years. And the thing is that for many, many years, developers were not treated as users in many respects. So we needed to do hard things about CLI and the unfriendly tools and lots of tweaking in order to get a grasp of what's going on in our systems and managing them and configuring them. And I think now there's a strong shift into developer experience where developers are actually treated as users and also as a very valuable resource within the company that we don't want to waste the time of the developer doing all sorts of boilerplate types of activities. We want to facilitate as much as possible. And as I mentioned, make platforms to enable the developer as much as possible so the developer can focus on the core business value that he brings to the company or she brings to the company. So that's developer experience for me and Acha. Can you talk also about the importance of building this developer experience because when we talk about the whole ownership from the time application is created versus deploy and also kept running, kept secure. And that's where we can also talk a bit about as you were talking earlier about the whole culture movement DevOps SREs because these are, once again, sometimes these are tools, sometimes these are practices. So I think that we see a very strong emphasis on the shift left movement. So people expect the developers to take ownership of the application all the way to production and beyond but developers need to be enabled to do so. So, and then developers are interested in what happens to their code the moment after they release it in the GitOps process whichever that might be. But in order to be effective, they need to understand what goes on there and that's where I think observability comes into play. And this is what platform engineering comes into play because platform engineering, unlike you mentioned PaaS, unlike PaaS that was off the shelf product that was taken and provided externally through the organization, platform engineering is part of your organization. It's actually engineering within your organization sitting closely with the product engineering understanding the processes, the constraints, the tools, the methodologies, the compliance requirements and then find the best ways to facilitate these in a way that fits the DNA of the organization and even the specific teams. So it needs to be flexible enough to adapt and to make the tweaks and adjustments to the specific team. So this is where the power of platform engineering enables this movement because it is a team within the organization that provides this experience to the developers. Since you are a huge proponent of open source, you are also getting a share with this cost cutting which is going on, which also means that folks will be doing less of do it yourself or not invented hair syndrome more and more companies. I mean, they're already leveraging a lot of open source. They will be adding their own proprietary as a Tabasco sauce on top of addition or not the whole sauce is Tabasco sauce, which means not the whole code is proprietary with the growing adoption of open source and this cloud native technologies, what do you see will be the impact on cultural shift? I think that the leaning towards open source is significant. I see, for example, I'm very active at the open telemetry project that aims to unify the different observability signals, logs, metrics, traces, even newer signals such as the continuous profiling and others. And you see everyone aligning behind this. This is the second most active project actually in the CNCF in the cloud native computing foundation after Kubernetes itself, which is amazing. And even the vendors that made their bread and butter out of selling agents, proprietary agents have realized that and started shifting to supporting open telemetry in one way or the other. So I think this movement is here to stay and actually amplifies. On the other hand, I do see that at least for large organizations that need to scale out these deployments, it starts becoming burdensome. Some organizations see that handling and elastic search or open search cluster at scale and managing the indexing and sharding and all of that, it requires a lot of manpower and headcount and then they're looking for ways to consolidate, to outsource and to make it more cost efficient. This is where I think managed solutions that support the open source bring additional value in this age of financial stress. Let's look at logs.io. How are you enabling teams to kind of embrace these practices? As I mentioned before logs.io provides a cloud native observability platform. So in a way, we allow these teams to understand. We then allow the developers in essence to connect to their production environment and very easily see what goes on, where the exceptions are. You just released a new drop, a new version of your microservice into production and things start breaking. How do you understand what breaks? So you have a very easy way to sift through the noise, understand where the errors come from, which exceptions, see aggregate of the logs into patterns that repeat themselves, see the trends over metrics over time, both the infrastructure and the application, understand the path of requests through a distributed system with distributed tracing and even being able to spot issues, security issues, someone now trying to do malicious work or do some Bitcoin mining. This sort of visibility and observability into production is what enables developers to take this shift left movement of taking ownership on their microservices and the drop software all the way to production. Dutton, thank you so much for taking time out today and talk about this topic today. And as usual, I would love to have you back on the show. Thank you. Thank you. It's been a pleasure talking to you.