What's next in DevOps and what on EARTH is Platform Engineering? Nati Shalom, Cloudify (Dell) & Eran Bibi, Firefly

Episode Transcript תמליל הפרק

Hebrew, then English* בעברית ואז אנגלית:

(*Translated with Google Translate - so there may be some errors)

Yishai:         Welcome to Season 2 of Dev Interrupted - the Hebrew Edition, LinearB's podcast which discusses everything that interests the daily work of engineering managers. This season we will host industry leaders and talk with them about everything that interests engineering managers, those who work with them, and those who one day would like to manage an engineering organization. This season we will place special emphasis on Developer Experience. I'm Yishai Beeri, CTO at LinearB. Let's get started.

Yishai: In this episode I am happy to host Nati Shalom,Co-Founder and CTO at Cloudify, which was recently acquired by Dell, congrats!

Nati: Thank you.

Yishai: And Eran Bibi, Co-Founder and Chief Product Officer at Firefly.

Eran: Hello.

Yishai: Hello, what a pleasure you came, we are really excited, we are at the start of our second season, and today we will talk about developer experience, about DevOps, about platform engineering, but first of all I would be happy if everyone could tell me a few words about their path, how did you get to this point in your career. Nati, let's start with you.

Nati: Okay, so Eran, I apologize, it will be a bit long because I'm a little older.

Eran: It's fine.

Nati: So I actually started in the field of technology in the 8th grade, the Weizmann Institute, there was some course there that I have no idea why I was thrown into it but it was to pick up transistors and all kinds of things like that and then I started to discover a whole new world and it continued later with a Bar Mitzvah gift which was also to build radio kits and all kinds of things like that. Then I realized that ok, this is what I want to do, continued in high school majoring in electronics, in the army I did some sort of pivot. I said ok, now I want to diversify a bit, do things that I would never do in life, which was actually going to a combat unit, different from the usual path of people of this type, and it was really one of the best things I've done in my life. Then I got back on track, I graduated from Coventry University in England, as part of a student exchange program, which was also an experience in itself. And since then I actually, I think I mainly bring a lot of multidisciplinary knowledge, both on the one hand hardware, on the other hand software, DevOps, today in the worlds of the cloud. But at the time there was also distributed computing, HPC, information systems and also applications, hardware and software I have already described. And in the world of the cloud, I think that this multidisciplinary knowledge is almost necessary because the cloud actually turns everything into code and basically systems become something that is much more holistic and not just a certain function of an application or a certain function of a data center. This, in a nutshell, today I'm a serial entrepreneur, I founded a company called GigaSpaces that really dealt with distributed systems for solving data problems, called NoSQL, and mainly concentrated on doing it on the basis of a memory platform. From there, Cloudify grew, which was actually built as an infrastructure for the management of distributed systems. And Cloudify, as you said, was acquired not long ago by Dell, when we say not long ago it's the last month. Obviously the process is much longer, and we might talk about it a little more later, very fresh and I'm excited to get back to talking about other things.

Yishai: Yes, so congratulations again and we'll dive a little into what that means and what it looks like a month after the acquisition. Eran, tell us a little about yourself.

Eran: So I'm a bit younger than I am, 38 years old, but still relative to the folks I work with today I'm considered the oldest in the team.

Yishai: Dinosaur.

Eran: Really, and it's hard for me to think of myself that way, but it's slowly becoming that way. So really I started my love for computers at a relatively young age, when I had my first PC so I really enjoyed taking it apart and understanding what each component does and I had some kind of inexplicable passion for it, I had the privilege of participating in an experiment of high speed internet, before it was what called mainstream. And then it really exposed me very early to access to information 24/7 while people would connect to the Internet only on Saturdays when it was cheap, with the very slow line. Then I really deepened this passion and curiosity in these worlds. I really connected with the topic of infrastructure and networking and system administration. I did it in the army and after I was released I even deepened my knowledge a little in the worlds of Linux operating systems, I did some kind of Red Hat course, while everyone else was learning Microsoft, I actually went to the other side to deepen my knowledge in the worlds of Unix and Linux, I really liked it. Like everyone my age, I worked at Comverse, it's some kind of checkmark that you have to make in your career path, and from there I rolled into both startup companies and somewhat larger enterprise companies. When the cloud arrived for me it was a very natural connection because it combined my love for infrastructure and operating systems as well as development and scripts, so I entered the DevOps niche at a relatively early stage. It was around 2012, I was hands on for many years and then I moved to my role in leadership. Before I founded Firefly, I was one of the first employees at Aqua Security, I had the privilege of establishing a leading DevOps team, with all the popular disciplines SRE, platform engineering, and I got a lot of appetite for startups and entrepreneurship there. And I decided to go on my own journey and I got together with my partners and a year and a half ago we founded Firefly, a product that really provides a solution in these worlds that I feel very comfortable with, the DevOps worlds.

Yishai: And when you went to found Firefly, is this the first time you are formally in a product position? As opposed to hands on and leading DevOps and a little more irons?

Eran: Exactly like that, but it felt very natural to me because a lot of what I did, as someone who leads DevOps, was to produce internal products for our internal customers within the organization, so defining a product and knowing how to build it was something that felt very natural to me, but yes, that's right, it's the first product role, in the profession, with the title.

Yishai: You went all the way, to Chief. First time and I'm in Chief.

Eran: Yes, I cut corners, I took some shortcuts in this regard, but in the end, today I am building a product for an audience that I am actually the target audience for. So I know the persona best, I actually know best how to produce a product for this target audience. So on the one hand it's a shortcut, on the other hand I think it's one of the most important qualities for a product manager is to really know who you're selling to.

Nati: The truth is, by the way, this is a very important point, when I explain, let's say, how in Elasticsearch and how even Mark Zuckerberg succeeded in Facebook, it is often this point. That many times it is easy to see things as shades of gray, that is, someone from the outside who does not live and breathe the domain, will not see these small nuances of the feature. Let's say in Shay's case, so he saw the need for a simple API. Not only a database that knows how to make a query or search, but also that it will be very telling to developers, open UI, more API, which is what developers see. The same with Terraform, Terraform realized that their user is a DevOps person who lives within a CI/CD pipeline, most of the solutions, including Cloudify, lived very well in the worlds of operators but less well lived in the worlds of developers. This recognition and the ability to recognize this sharply can often come from people who have actually experienced the problem, and many times when approached by all kinds of management who come and say okay, then he has previous experience with this, but they don't know the end user, they were not the end user , so this is a super important point, they will see the shades of gray, and the shades of gray today are what differentiate success from failure. And I think this is a point that a lot of people miss, but also especially in the world of DevOps where almost all the tools look similar, speak almost the same language, do very similar things, and also in the worlds of security, and this is often what I see that differentiates between a product that succeeds in the end and a product that doesn't. Everyone tries to solve similar problems, but those who manage to identify the user at the end and understand exactly his problem, are the ones who win in the end.

Yishai: I agree, I think that the companies, the startups that work on products that are themselves the customer, and that the developers, in the end the ones who turn to the developers, to the DevOps teams and the people who build the product are the ones who know firsthand the use and it's a different world. I see at LinearB, we sell products to development organizations, and every one of our developers knows, understands by heart, what this product is. And he also uses it and he doesn't need a translation from the product people or whoever talks to the customers about what they need, and that makes a world of difference in ability.

Eran: I think that even in this domain of DevOps it is even more extreme because DevOps is always in an organization from such a capsule that even the IR management does not really understand why, let's say the most important question, why do we need so many DevOps people. These are very talented people but very expensive in terms of the cost of the organization, and there is always a demand for more, and they also usually sit in some sort of separation from the developers, from their day2day, so really getting to know what the day-to-day life of the DevOps person or the DevOps manager looks like, is very It's hard to understand from the outside, but it's much easier if you've done a term in one of these positions.

Yishai: Yes, and they are also often not linked to features or capabilities, so the managers say wait, so much effort is going there, but why is it going? What does it support me or how, they don't build features, in most cases, so it's another level of how I as a manager understand that we need to invest here. Because most of the value is perceived as a feature, okay? There is another capability, I'm going to sell it.

Nati: I think that today in the current crisis in the industry, I think there is already more understanding of the value of this thing. Because obviously when you need to do more with less, you need automation, when you need automation you need people of this type. And I think that this understanding is already more present in the management layers as well. I mean actually, in a previous podcast I did with Wix, the platform engineering initiative came from the CEO, which was very painful to hear, it didn't come from the developers, it came from the CEO, why? Because he realized he needed velocity, why did he realize he needed velocity? Because his competition ran a little faster. So I think it changes in this context and it's very true, they don't know how to translate it into an operation at the end. They still need the people themselves, but I think that this trend in the market where everyone now has to look at efficiency and not just as many users as possible, no matter what the cost. Strengthens the understanding of the value, I think of automation and of DevOps people, and suddenly they become people who appreciate their value more within the organization and really when we talk about platform engineering it is really a different case because it is no longer growing from the bottom but also growing more from the top.

(transitional music)

Yishai: Great, so we're talking about DevOps, it's a loaded word, a term that has changed, and if I think about what a DevOps person does or what that role means or what the role of DevOps is in a company, it's evolved, it's changed a lot in the last 10, 15 years. With all kinds of sub-specialties and there is SRE, there are all kinds of different worlds, how do you look at these changes that have gone through and go over this basket called DevOps?

Nati: Me, precisely because I now moved to Dell, I suddenly found myself explaining it to the so-called laymen, to people less from the world, so I tried to find a way to explain it in a very simple way, this evolution that happened. And then actually if you look at it, there were 3 main waves here, I mean there was the wave where they came and said okay, we've moved to the cloud, we need automation, most of our developers don't know how to do automation, we need people who understand automation, we called it a group, and it's a fabric" When there was a very central group in the organization I would say automate me to RDS, automate me to VM, automate me to this, and they would write scripts that do the automation. It moved to a situation where most of the developers already understood what cloud is and then this core team We'll become a bottleneck, they said OK, I can't wait for this central team to do anything for me and that I'll ask them and I'll get a product and it won't be exactly what I want, so I as a development team will take responsibility for this thing and my people, I mean the developers, will start dealing with automation Then there was a situation of automation decentralization within the development teams and the infrastructure as code integrated here in a very, very nice way. We reached a point where a problem arose, because this decentralization was too great a decentralization and created a problem of consistency and governance, I mean okay, now everyone does What he wants, too democratic, the word democratic today is loaded Eh, we won't get into that now, (laughs)

Yishai: (laughs) …Who transfers??? the devops people?

Nati: But it has become too democratic...a reform is needed. So in any case they understood that order is needed here. Now a return to a central team doesn't work either because then we will return to the problem of the bottleneck, that the central team will be a bottleneck. Then the world of platform engineering entered which basically means that instead of people being a central figure, there will be a central platform that will be the self service, that people will build the platform but they will not be the interface of the developers. The developers' interface will be an API, a service that will mainly take the things they repeat and in most organizations there is some cookie cutter in the end, there is something that repeats itself and it doesn't, not every organization reinvents its cloud every time. And then it's much more scalable, it's like some kind of evolution, I would say to the place where now I'm back as if to a central team, but the central team is not my interface but the API is my interface, so I won't have a scaling problem.

Yishai: So the central team came down and is building the infrastructure.

Nati: Building the platform, exactly.

Yishai: And if we just take a super simple example, if I once had to open a ticket to get a bucket lifted, then I opened the bucket alone, as a team, but that created problems of uniformity or policy, and now I have an API or service that generates for me In acts according to the corporate policy, but that I do it in self-service and do not wait for a person.

Eran: Right, exactly, I think Natty described it fantastically, what has happened in the last decade is all kinds of trial and error of models of which model works best. At some point we saw that the DevOps teams really became an illogical bottleneck, instead of increasing the velocity they slowed down the development because everyone depended on DevOps and there were never enough people. And it actually hurt the development's ability to develop quickly. They also kept some kind of expertise on this whole subject of the cloud for themselves, and I don't think that the DevOps are to blame for this, I think that there is also on the development side, the development has not always shown a willingness to come and learn all these subjects in depth, things related to infrastructure or infrastructure as code, we have not always seen the willingness from the development side to be an expert in this and in the end I can understand it. They wanted to deal with business logic and the things they came to do, which is actually to develop features and bring the product another step forward and less to deal with operations, and this topic of platform engineering. I think it's some kind of model that basically addresses two worlds. On the one hand, you have one team that is truly an expert on this topic of infrastructure, on the other hand, it is not a bottle neck because it provides the same framework that allows for controlled freedom of action as opposed to, you know, everyone doing what they want, it is really controlled with the help of the tools that maintain uniformity and governance and security and all the aspects of costs, this is now a very popular topic, I open brackets, a few years ago the CEO was not so important how much you pay for a cloud because everyone wanted to run fast and no one was focused on optimization, You were focused on let's run fast and don't waste your time on it. And today everyone looks at the cloud, opens their eyes, says wow, I'm spending a lot of money on it, I have to do optimization, and a lot of that is because people ran without controls.

Yishai: Yes, it's simple, the investors were looking for growth at any price, so I'm going for growth at any price. Now they look at my margin, I have to take care of the margin.

Eran: Exactly, platform engineering actually enables control, control of all aspects, part of which is also cost control. Making sure that the same machines that the developers pick up in the morning are closed at night is just a very classic example of something that can be done easily.

Nati: Now many times when there are waves like this, they say wait, it's terrible, it's so obvious, how come we didn't think of it before? And this is where the point of maturity comes in, I mean it took time to reach a situation where there is some kind of standardization in the market. And the standardization, let's say around Kubernetes, around Terraform, without that we wouldn't be talking about platform engineering, and that's also important to understand. Because when everyone had their own tools and things that were very different from organization to organization, then obviously you can't build a generic platform that will solve this problem and you can't produce tools like Firefly and other things that are growing today because there is this standardization. There is an entire industry that has grown up around the Kubernetes ecosystem that wouldn't exist if there wasn't such a thing called Kubernetes and all the organizations were using it. Then a situation arises where suddenly everyone finds themselves in some kind of situation, doing the same thing, everyone picks up a Kubernetes cluster namespace for development, a cluster for production, a separate cluster for development, we become something that is very canonical and why do I have to waste time every time?

Yishai: 95 percent do exactly the same thing.

Nati: Exactly the same thing with different nuances, I need it in such regions and not such regens, with such optimization, but not many differences and it becomes very repetitive. And then it's a classic case where, when the problem becomes generic, then comes the platform. This wouldn't have happened before, in 2015-16, so I'm just putting it in perspective that we won't think about it, we were stupid then, now we're smart today, how come we weren't smart then, what is this weird industry called hi-tech? who keeps reinventing the wheel.

Yishai: Yes, well, 20 years ago we, in order to pick up a server, had to pay 15 thousand dollars and wait two months for it to arrive in the cage, and someone had to go there and install it.

Eran: This transition in general from classic infrastructure people, system administrator to DevOps, to the platform, it was really due to technologies that make it possible to do these things. If there was no cloud, we would still be dealing with data centers, and it is completely true, the uniformity that container platforms provide today really creates some kind of alignment and a very large common denominator between the organizations.

Yishai: What about the shift in the focus of the DevOps function from questions of uptime and runtime, at the end at the end people sometimes stretch the DevOps to runtime, to SRE, to Ops really who gets up at night or how do I know that something fell at night, and on the other hand , I think it's a shift that part of this process of moving to platform engineering and the questions of almost everything you've just described in three stages, we'll talk about the velocity of development. So on the one hand there is velocity and enablement for development, and how do I improve the developer experience, and on the other end uptime. How did the focus change?

Nati: I think there are two points here, I mean I will actually touch on the developer experience which has actually been neglected for a long time. Why are we neglected for a long time? Once again, a matter of evolution, because most of the time we were busy with how to automate the infrastructures, so obviously the developer experience received secondary validity for the purpose. Today, when the platforms have stabilized a bit, then suddenly developer experience becomes very, very important. developers find themselves doing a lot of things 90 percent of their time in some statistics, which are not their core business, do not know how to really manage infrastructures, and instead of developing code, so the issue of developer experience suddenly becomes important now. And so the platform people for that matter today need to give much more emphasis on this, they are measured on this and they need to give it because this is the expectation of the developers in the organization from this thing. The uptime is created by the very fact that you move to the platform, I mean if until today I had to maintain the database and maintain the clusters and maintain it and put a person who receives alerts and then he has to get up at night and do it, I become more of a product, I mean DevOps themselves become product people, which is also a very big change in DevOps. Within the organization it is a product, and I manage it like a product and I don't manage it like pipelines and scripts that are constantly moving and moving and this is a very big change, because this means that DevOps people are no longer just operations people, they develop for everything themselves. This means they have to think like a product and many times you see that part of the organizational change is to put a product person on the team itself, and plan releases and plan everything we know from the product world.

Eran: By the way, do you see this?

Nati: I see it happening in organizations such as Wix and AppsFlyer and other organizations that are relatively large, that have a lot of teams, so it happens in practice. Smaller organizations it’s not happening yet, and it is usually also a matter of evolution, I think that as the platforms stabilize, we will see it in small organizations as well. In large organizations it is for sure.

Yishai: Are you actually saying that part of the maturity, part of the maturity of platforms and platform engineering makes the uptime something that is exempt? If I have a service, it is well built, so its uptime will be fine, and now I can focus on velocity?

Nati: So I say something like this, let's take a second look at what uptime was in the past and what uptime is today. Today the cloud itself gives you a lot of infrastructure that, let's say if we're talking about EKS and Kubernetes and all kinds of things, there are a lot of solutions that guarantee you relatively a very high ceiling for why the cloud guarantees you a much higher uptime in the stack than it was before. Previously it was VMs and storages and you had to take care of the entire upper layer. So you already have a much higher coverage that is granted by the cloud providers. You still have the uptime of the application left and this is another layer that you are responsible for, but it has been reduced. The second thing related to uptime is really the procedures. I mean, how do I actually make sure that the entire process of continuous updates and all these things doesn't break my processes? And here, too, many tools have been created that already know how to do this job in a more stable way. So simply the delta that today's DevOps people have to concentrate on has shrunk. And on the other hand, the part they almost didn't touch, which is the actual development of a product, and which is dealing with the UX of developers, it becomes a bigger part that they are measured on and that is transition. This is a difficult part by the way, not many will pass it, there will be many DevOps people who will not fit this transition. And it's happening now and it's in transition and it's not easy, for many organizations it's even very difficult.

Yishai: Eran, how do you see this transition from focusing on uptime and building infrastructure to focusing on developer experience and velocity?

Eran: In the end, the way I see it - once everyone who wasn't in the feature teams or scrum team writing the development, it was the DevOps people, and then it doesn't matter if on the spectrum you look at developer experience on the one hand, or about production engineering, it's like these are the people who do it. But if you really understand the dynamics, it is actually a slightly different profession. That is, the same people who are responsible for the reliability of the service and the scalability and all the things of the so-called non-functional testing, does it meet the scale, is it bulletproof, this whole issue of regens and what happens in disaster recovery. It's actually the same subcategory of DevOps, the SRE or the production engineering, we see it in a lot of organizations, which are completely different teams and this is their expertise. What you do see is how it connects to the platform, which is also responsible for how to produce the same developer service with the same metrics, with the same guardrails related to monitoring, and I see this seeping into the development teams. That is, this world is not really managed on the side by a dedicated team, but the same dedicated team that is the subject matter expert in these worlds of monitoring and engineering, it actually gives the Torah and really makes sure that the service accessed by the platform contains Also those elements related to the monitoring of the application and not only the business logic. That is, do you have the necessary health check? Does it know how to scale and what happens in situations if the service is down? And as Shanti also said, a lot of the new technologies like Kubernetes, they abstract it. Kubernetes takes the approach that a pod, which actually runs the application, can die at any moment and it doesn't matter, there is no problem with it if a pod crashes, because Kubernetes will do the orchestration and another pod will come up or you always have more than one pod in the deployment.

Yishai: Under the assumption that the application knows this and knows how to manage.

Eran: True, and this is really the job of those platform people, to make sure that what describes the application contains the same components so that Kubernetes does its job properly.

Nati: This is also where the issue of the shift left comes in, I mean in the past those SREs what they would do was fix them retroactively. I mean, someone would do something, would do something wrong, check, oh, you didn't do the configuration right? And they say more or less 95 percent of the downtime is due to human error. And one of the downsides of automation is that it does, I'm trying to think of the Hebrew word, a kind of amplification of the problem.

Yishai: The error comes on production.

Nati: Exactly, you end up with a much larger blast spectrum for each mistake. And the shift left is actually intended to transfer the responsibility from, for that matter, to identify the problem in production, to identify it in the development stages. So the role of the DevOps people would change from the role of monitoring and identifying problems afterwards, to creating policies, scripts that do validation, that is, not to be the person who is the bottleneck for the matter, but to create the policy that in advance will ensure that everything that passes through this pipeline probably will be production grade. And it's a different perception to how I am, to my role for that matter as an SRE or whatever it is, I now make policies. I don't talk to the developer and audit him, I create a policy that audits him so that the developer himself will see that he made a mistake and he put something wrong here and will fix it himself.

Yishai: What do you think is the next thing in the world of DevOps, what is the challenge around the corner, where will DevOps and platform engineering focus in the next year or two, what is the next frontier?

Eran: I think that a great many of the cloud services will move to provide even more abstractions, that is, if today I actually have to take care of the Kubernetes cluster and everything related to its operation, then we will see more abstractions on top of that and then the developer's life will be much easier in the context of how he brings the Its code to run and how many processes on the way need to arrive so that this thing will be reliable and the service will be up. So a lot of this, a lot of the evolution that we are going to see is really related to a new offering that will be of cloud services.

Yishai: Basically, parts of the platform engineering will become a managed service as part of the cloud service.

Eran: Yes, I see let's say now they released at the last Re:Invent, AWS announced a service called Code Catalyst, which is exactly that. He takes all the elements of platform engineering, and brings one platform that enables, that is, makes blueprints accessible, does CI, that is, all in one, so the key that he accesses AWS is no longer some kind of store with full of services and full of configurations - but everything is very abstract and very accessible. We will see it coming from the big vendors, not only from startups, and little by little it will really make platform engineering mainstream and not a cool niche that only the early adopters embrace.

Nati: I think it's come in, you know, today everything that asks what will happen in the future? So ChatGPT and such, I'm tired of even hearing it or hearing myself talk about it,

Yishai: This podcast is created by real people.

Nati: Exactly, yes, but the truth is I had some interesting nuance to tell about it, but I'm not sure it will fit into today's topic. But in any case, I think that if I look at the closest thing in the future of ChatGPT and its impact on DevOps, it is a Co-Pilot of sorts that is based on an engine called Codex, which is actually a much smarter code generation, because at the end of the day, what takes DevOps people the most time is to write the the templates and make sure they work properly. I've been experimenting with this recently, I even said Cloudify will create a Cloudify template for me from such and such a version. Boom, I got it without reading a single line of documentation, so finally picking up the Kubernetes cluster or whatever, took a little more time. It shortened my time very significantly, it's right here, it's not something in the future, it's already happening.

Eran: One of the things we did recently, literally the whole issue of generative AI exploded about two months ago. We actually released CLI tools, we called ourselves AIaC, which is a combination of AIC infrastructure as code and AI, which actually does it from the terminal, anyone can request a template for any configuration they want Terraform, Pulumi, Dockerfile, not surprisingly it has gained a lot of popularity, from It's probably a free open source offering. Not related to the commercial product that Firefly sells, but it touches on that. Because the world goes to her. There is no doubt that the abilities of the AI ​​to create first are, in my opinion, very impressive. And I completely agree with Nati that we will see more and more products incorporating AI. We at Firefly have probably done it too, other vendors will do it and are already doing it, I see, almost every time I open LinkedIn I see some vendor who-,

Nati: Yes, I say, it will also be the technology that I think goes the fastest from hype to commodity. We will see it too, I mean probably a million users in 5 days, which broke every world record. By the way, also because of UX issues, because ChatGPT probably existed long before, but what made it pop was that they turned it into Google,

Yishai: This is the chat.

Nati: Exactly, that they turned it into such a Google, write a text, write it down, you will get a result. And you don't have to be a scientist to work with it, every person, including my children and my wife, write text. And you see, radio broadcasters, in short it becomes a search engine. And the second thing that I really think is happening, is really the integration within products. I mean, it becomes more and more integrated from your IDE, with all kinds of other tools, and suddenly it becomes spread all over the place, so I think it will be quite a commodity, okay, of course, it's like search, it's now part of the matter.

Eran: We talk internally within the company about futurism and try to think about what will happen. And one of the things that is very clear to us will happen because of the topic of AI, is that just as now cloud is something that is very easy to consume and very easy to spend a lot of money, it has become a very significant cost center for the organization, AI is going to be something the same, that is, people will consume AI for internal use In organizations, it will of course be AI as a service as the OpenAI and Microsoft APIs make it accessible as an AI service and it is going to be really, in my opinion, in the coming years, a very large weight of the financial expenditure of organizations will be on AI services and then even imagine that there will be startup companies that do cost reduction or AI tokens.

Yishai: Let's make a caching layer and...

Eran: Think you have several vendors, so you know, you'll need some third party product that will tell you okay, if you take the AI ​​from the other vendor you'll save this way and that way.

Yishai: Now, to this query.

Eran: or saving plans for AI. The truth is that it raises a question that I remember trying to answer for years and not succeeding and it becomes the opposite or interesting in this sense of data processing. I mean to this day the form in which monitoring systems and such things, you collect the data to you, it is yours, and you generate insights from it. And it used to be like your property too. Today we see that as much as the information is not yours, I mean the information that is not yours is probably even better quality than your information, regarding trends, regarding cost analysis, regarding all these things. So ChatGPT is an excellent example because it actually aggregates all the code in the world accumulated on Github and other sources or Quora or all kinds of things like that, and produces much better insights from the fact that the information becomes collaborative. And now if you want your system to be a learning system, then if you reduce it to only the information you collect, then you probably have less data to work with. So suddenly it also matters, and this is something that I still don't think people have fully internalized - our whole concept of information processing, of data analytics, of insights and how to generate insights. We suddenly become something that needs to be supervised learning and not something that accumulates the information and does the analysis for us. And this is a very big change in my opinion.

Yishai: And the Pandora's box of ownership of the data, of copyrights, has already been opened.

Nati: Exactly, I think there are still many, many open questions, but I think what ChatGPT illustrates is that the ownership of the data no longer becomes the property. But you still have to maintain it in some form, but making that information available out there will probably give you more value. What will become more valuable is the supervised learning, I mean how can I add domain-specific knowledge that he could say like in your case, I don't see a search for all Terraform in the world, I want a search for Terraform Modules in AWS that do this and here is someone Who knows how to filter it for me and bring it to me in a more accessible way.

Yishai: Okay, so if we go back a bit and bring the discussion back to the world of DevOps. So okay, generative AI as another tool, maybe even something that will make a shift in the skillset that a DevOps person needs to build the platform or to improve it. What do you think is going to change in terms of the type of problems, or what will be the focus of the DevOps role? If I look ahead, what main problems will they solve or start to solve today and solve more for the organization?

Nati: I can testify now from my place at Dell, so there is a whole world here that I think is less accessible today than the worlds of DevOps, it's really the topic of IoT and topics of devices and really looking at the cloud beyond the central data centers that are now sitting in the cloud. And where do we see it? Everywhere, the camera is connected to Wifi and connected to it and probably receives continuous updates without us even noticing. The car, if you have a Tesla, then you probably see it, everyone sees it in their car, the refrigerator at home, the TV, the phone of course, everything we move with today, my watch probably, everything is already connected to the Internet, everything is connected to the cloud, but when we talk about DevOps worlds, you see that the DevOps infrastructures are not built to deal with it in a generic way, that is to say, everyone will violate the update for themselves.

Eran: That is, a pipeline of how I do development and release and deployment for the same, for the same end devices,

Nati: In a generic way, in a way that is not tailored to every device and every organization and I don't need everyone to do it themselves.

Yishai: I think that the public clouds have not yet solved these questions at a level that even comes close to how they solved the centralized compute layer for classic b2b SaaS.

Nati: True, and in my opinion, this opens up a whole world of feedback loop, because apparently these components already really sample the person and connect the person into the cloud and produce some kind of scary, but also interesting, interaction with a lot of potential. I think this is still uncharted territory. Speaking of what happened to us at Cloudify is that we thought about it a little too early, it caused us some disruption along the way, but in the end someone recognized that it was what they were looking for and that's more or less how we ended up at Dell as well. So I think, from what I see, it's going to be something that probably a lot of people will need in the even near future.

Yishai: I mean, one type of new frontier for DevOps is to solve the questions of companies whose footprint is not just one SaaS product in the web application cloud,

Nati: Yes, that's allpoint of sales On the one hand, it's all the 5G we see, it's the whole issue of manufacturing in the companies that deal with it. But mainly on the analytics side, I mean there are a lot of industrial companies, manufacturers that obviously have distributed computing, the people themselves are distributed, sometimes a lot of components, I'll give the example of the Garmin I have, so I think this is the next frontier.

Yishai: interesting.

Eran: I would take one step, so-called earlier in time, and I think that processes that we see today that are gaining momentum like GitOps, the whole world of what the code looks like in production and what the manifest looks like in production are actually by the source of truth which is actually Git So today it is partially adopted, it is still considered the so-called cool kids, the hipsters do it,

Yishai: They do it and-trunk-based together.

Eran: Right. So I think that such methodologies are more centralized to the same place. And at least, okay, I have the code, I have the kid, after that I have the CI and after that I have the deployed ArgoCD. We will see that everything is concentrated on at least systems, it will be much easier to understand what is running in production, even for the individual developer, he will look at it in the branch of the same main, see the manifest, understand ok, this is the version he wanted. This is essentially the essence of GitOps. I think it will gain more popularity, I see it somehow slowly entering even organizations that are a little more old-fashioned in their concept.

(transitional music)

Yishai: Towards the end I would like to double click on this term of developer experience. And through the eyes of a DevOps or platform engineering team, try to go over a little about what are the, where are the biggest challenges of the developer experience? Where do the developers stop today or do they feel or have an experience that in the end also leads to a lower velocity or a feeling of, to the point of disgust / churn? Where are the biggest challenges where DevOps can and does start to help or solve developer experience questions.

Eran: I think the most classic issue is really areas where they don't have the knowledge or the experience to be excellent. So if you take that typical developer who is very good at Java, Go or any other language in Python, and then put in a layer of OK, you are responsible for the infrastructure of that service, it can put them in a place of some discomfort. Only because of the differences, on the one hand they are in the context of a sprint, they have to deliver, everything is measured, and on the other hand they have to do something they are not necessarily experts in. I think that's really really the point where you see developers kind of take a step back or it's the area where they don't feel the most comfortable.

"If you take that typical developer who is very good at Java, Go...and then say - you are responsible for the infrastructure of that service, it can put them in a place of some discomfort."

Yishai: So like it's the third step that you described Nati, this transition from shift to full pat to a state where, okay, some of the things are, I can write the function and it will run.

Nati: I think Backstage is a great example today of open source platform engineering, coming from the world of Spotify. Spotify are considered a kind of rockstar in the worlds of DevOps, almost all of them adopt their theory of how to build teams and squads,

Yishai: Is this the new Netflix?

Nati: But they are more invested than Netflix in terms of development, and less throw code to the community and say take it, they really turn it into a product and have, in my opinion, similar aspirations of Amazon. I mean who didn't follow Amazon like that, Amazon was a bookstore once, it wasn't an infrastructure company and no one expected this to happen. Spotify already has some similar aspirations from what I've talked to them about, it's their name, in the mind, I don't know how successful they'll be, and backstage is some sort of beginning, in this respect that's beginning to show that they're entering into a much larger investment, including the fact that they announced a commercial product of the platform engineering. So they experienced, and I got to interview people from them, the user experience, the developer experience was such that now I'm building a microservice, I want to develop a microservice, okay? I enter an environment that has other microservices, how do I know what their interface is, what their API is, where they are, how do I know now what their status is, it's mature, it's not mature, which version I'm working with.

Eran: Also the ownership, who is the owner?

Nati: Who is the owner, exactly, I mean a lot of things that until today were distributed among your CI/CD for monitoring system for documentation,

Yishai: To the-organization chart.

Nati: to the organization chart, and they would throw developers, telling them: "Take it, start developing." So it's probably not a good experience. And the first thing is generally very simple, come gather the information for me, I want to get to the project, I need to develop microservices, bring me all the information I need to develop in one place. After that it came in that I don't want to do surgery in places where I don't need to. I mean, if it's a recurring thing, I probably shouldn't bother with it, I'm wasting time on things I don't need to. If it's something new that just came out, a new feature on Amazon, it's probably not on the platform yet, but it's critical to my development, so I'll also want to maybe because it interests me. I'll want to learn it, I'll tinker with it, but narrow it down to this, don't make me now pick up Kubernetes Clusters 100 times for the same thing and get to know a Helm Chart I don't need to know.

Yishai: Kafka.

Nati: Or Kafka, exactly.

Yishai: Oh how fun. “Fun”-ka (Kef-ka - transliterated) (laughing)

Nati: So I think that these two things are at the level of developer experience, the accessibility of the information and, as a result, the ability to develop in an easier and simpler way. And the second thing is to really allow me the flexibility where I need it so that I don't get stuck on the sysadmin of the cloud. The flexibility only in things I need, not in things I don't need, things that are new, things that are more critical.

Yishai: Okay, so we talked about discovery and basically,

Eran: catalog,

Yishai: Let me know where the servers are, who is the owner, who will do a code review for me, who will do a design review for me, who should I talk to anyway? And where are APIs, what even exists, I think it's also developer experience that changes throughout the life of the developer in the organization.

Nati: Right.

Yishai: And most of the organizations, maybe a little less now in the down economy, but most of the developers are new developers. They have now joined, we have recruited them, everyone is growing, everyone needs to constantly search for information. Later, when I'm already a senior, I know all the organization. So…

Nati: By the way, even if they are not new, many times you drop them each time into some other project, especially in microservice worlds, it is no longer some monolith that you live in for a very long time, you are always thrown from one type of project to another, even in the same project, and then This accessibility becomes... and let's say when I even talked to this Spotify developer about his experience, he says I came to Backstage because I actually found myself investing a lot of time each time just learning to get to know who I need to talk to, who are the people who do know and have the domain expertise, and until I start writing a line of code it took me a very long time. And from there the Backstage grew.

Eran: And you also see organizations that adopt it, AppsFlyer is an example you brought up, they adopt platform engineering at a very high level and also use backstage, this system becomes business critical for everything. I mean it's not a nice to have, I have some sort of service catalog system, but it's a system that has a team that sits and maintains it and this is so crucial to the velocity of the organization, because you put emphasis on the developer experience. You can't live without it once you fire it up.

Yishai: That is, it will fail tonight, so the production of AppsFlyer will not happen to it, but the developers find it difficult to move.

Eran: It will always fail at night, so there will be someone who will wake up,

Yishai: Because the developers for velocity mean,

Eran: Because it has become a very central piece of how they develop a product, so it's no longer a nice to have, it's a business critical system.

Nati: I want to give an analogy for it to be understandable because many times, even in your question, I think it showed the mistake that many times people make. That means you have to think of a software delivery pipeline like a production line. I mean now if I told you okay, the production line at Tesla has stopped, you would tell me that obviously someone has to  make sure it continues working and there is no way that this pipeline has stopped. It is true that the car is not yet in production, but the pipeline has stopped, so it is even more critical because it is clear that the whole company is sitting on this pipeline. the matriculation I think of high-tech in general, the fact that they still don't fully understand that a development pipeline is no different from a Tesla production line, it's exactly the same. It's a pipeline, in the end code goes in on one side, a feature comes out on the other, at the end there is a customer who consumes it and pays money to the company. And somehow this insight, this internalization exists but not to that extent. And so many times you hear the question, okay, then the development is stopped, he will get up in the morning, he will do it, and I tell him no, it's not one developer, a thousand is many developers, and a house is what will eventually sell to you and you will have a delay in revenue at the end and that's it. will hurt your bottom line.

"That means you have to think of a software delivery pipeline like a production line. I mean now if I told you, the production line at Tesla has stopped, you would tell me that obviously someone has to  make sure it continues..."

Yishai: I think that in many cases it's not just delays in updates and new features, if the organizations have moved to modern cicb moves, etc., if I don't have a reliable pipe line at any given moment, I can't handle the faults. In the middle of the night now there is a problem with production, without a pipeline I,

Nati: And you wouldn't even be asking that question if it was a production line of cars, would you? or of refrigerators or of something else.

Yishai: Truth.

Nati: I say it's not different, we just haven't internalized that it's not different yet.

Eran: Yes, these organizations really do measure, they have KPIs that are a derivative of how much time I saved in development time, how many developers I saved, how many automations I did that ultimately made me much more efficient? It's things that are super measurable.

Yishai: How do I measure how much time I have saved? What's the approach to at least begin to answer that question, okay, I picked up Backstage, how much time did I save?

Nati: So I think the thing that for that matter bridges it from the worlds of marketing for that matter, is PLG - product lead growth, which actually indirectly answers this question but it answers this question. I mean you can see today, I mean today part of the way in which marketing works, is very connected to development. how is he standing If we look at Slack, an example of a PLG that everyone uses, and that's a different discussion, PLG does work, doesn't work...but by and large I know today, in many cases, how to measure which feature in the end brings me monetization. Yes it brought me monetization, improved the UX for me, did not improve the UX of the developer itself. Now obviously, as much as I have a delay in this feature, I know that now I am losing 20 percent of the login users, why? Because they can't find the right button, or whatever. So it is quite clear to me that my delay in this matter will hurt my client. I have a feature that a competitor has developed and I don't have it, for example integration with ChatGPT, so I can tell that it will hurt my sales. So there are some features that we know for sure how they translate into business value and as a result why they are critical. And there is a lot of non-functional that is soft, I would say metrics. It's not something I can really measure in the bottom line, but we know that if our system is not highly available in a good way, it will also harm the experience of our customers, but the indicators are no longer rigid or not, they cannot be translated in a way that is quantified, I mean that it is, Can't find the word in Hebrew, it doesn't sit right on the dollars, but we know it's important and it's more like Soft Matrix. But today there are quite a few things, because there is a connection between the, in SaaS, between the user experience and the features and conversion, there are a great many of the features that you can say that, really almost in a rigid way.

Yishai: So I think that really in the world of, if I ask myself how I measure how much time I saved or whether my development is more efficient because I put a tool in place, you can look at questions like OK, how did my cycle time get shorter, meanwhile to restore for faults, do I need To search without a catalog for the service and who is its owner in order to address the problem, so I can say okay, I put backstage or improved some capability or gave a cookie cutter, instead of each developer having to do it alone. I have now reduced the cycle required to pick up an end-to-end feature, and these are things that are already established today because the way to measure velocity and measure productivity of development organizations. So maybe I don't always know how to link the investment I made to the result, but I can see investment and improvements in the tools, and justify further investment in platform engineering and tools to help developers run faster.

Nati: Yes, these are metrics that I think a lot of organizations are measured on, this is velocity, which is usually how quickly you develop features for production, really add the business value to it, that is, the ability to really see how it is reflected in the bottom line , I think gives you a good picture of how critical this is to organizations.

Yishai: So we talked about developer experience, you mentioned the issue of Discovery and finding the problems, we talked about doing more or less we call it toil of repeatedly doing the same infrastructure work that may not be my comfort zone either. What’s more? Where else do you see developer experience pains or questions that DevOps and platform engineering can solve?

Eran: I think it is also on the subject of uniformity and whether what you produce is compliant with the corporate policy. So one of the things that platform engineering really enables or the toolib in this ecosystem, is that the same policy is determined once, and then there is actually enforcement already in the development phase. Are you doing it aligned or unaligned? And it doesn't have to be security, it can be anything, it can even be at the cost level. Today we see projects that allow you to do cost projection even at the CI stage. A developer knows how much a service will cost even before he deployed it and looked at the monthly invoice in retrospect.

Yishai: Yes, I think that -, if I throw it back to experience, then of course my ability not to grab the boom in the head later and correct,

Eran: You make less mistakes, you have less room for mistakes, I think it actually improves significantly. No one wants to know that he did some kind of work that he spent a lot of time on and then in the end there is some kind of, I don't know, security vulnerability for that matter, or it costs much more than it would have cost if he had changed something.

Yishai: And now he has to fix it under fire, it's already in production, it's not a good experience. I think what you called compliance also means when I go to maintain someone else's code or go to join some project, it will be familiar to me, it looks similar, it looks the same, I don't have to suddenly learn the, oh, that's how they did the infrastructure. That's how they sewed things, because I know it from my previous project and the one before it that they all look similar in these ways, and I can focus on the logic and not on learning the,

Nati: True, there are a lot of things that are not streamlined in the life of a developer even just when we start to develop, there’s the dev environment they now have to set up - for dev and testing. So it also takes me a while to accept this thing, certainly if I want to make a sandbox and play with something before it even enters some kind of real system. There is the, in almost every organization you will find more than one pipeline, I mean you have ArgoCD for Kubernetes and you have Jenkins or CircleCI for that matter to other things. And there are many more of these and somewhere even to see what happens if my code really takes me a relatively long time. So if we look at the whole experience of a developer today, at each of the stages of development, there is a lot of I would say jungle within this world. Backstage helps in that it centralizes the information, but there are still many things that I need to change and this is where the topic of platform engineering comes in to turn them into self service. Ok, you want to create an environment, click, there you have an environment created, you can do what you want. It's an environment that is a sandbox, so it's an environment that's already semi-production, you can turn things into much more self-service from that point of view. pipeline GitOps really makes it possible to normalize this whole topic of pipelines. So you only talk to GitOps and GitOps already connects to ArgoCD Or for that matter, you shouldn't be the one dealing with it. The thing that remains, I think and will still remain complex, is the whole issue of troubleshooting. I mean, okay, so I developed something, something that happened and broke and things like that, it's still a process that I think still takes time. And I don't see many solutions that completely solve it. There are all kinds of attempts, I think it is still rough edge in many ways.

(transitional music)

Yishai: Finally, we would be happy if each of you would give one tip like this to someone who lives the world of DevOps and wants to develop or look at what the next thing he or she should pay attention to. So this is one point to put if I am a practitioner or leader in the world of DevOps and platform engineering, what to read tomorrow or what to think about in the coming weeks.

Eran: I'll say something that - it's a bit philosophical but I say it from a position, I really believe it today that I have a slightly different perspective not only as a DevOps manager but as a vendor, always think about whether a product you buy off the shelf will be worth more to you than doing it in-house. I was guilty of this too, I think a lot of DevOps managers got addicted to building their own solution.

Yishai: NIH, yes.

Eran: Yes. And it's nice and it's cool, there's a lot of open source today and a crazy community in everything related to the DevOps engineering and platform engineering ecosystem and it's very easy to show value without spending money out of your pocket. It's not always true, again, I'm saying this from a position I'm familiar with DevOps people, so it's comfortable for me to say it, but I say it really understanding that looking at ROI in a mature way and whether it's worth paying for an off-the-shelf product rather than developing, is something that everyone , anyone who is a leader in these areas must embrace the ability to do this.

Yishai: The fact that I speak from a position does not mean that I am wrong.

Eran: I'm certainly not wrong.

Nati: I think I'll come back to two things that I think I'll touch on, one of them half in position, one of them not at all. So I will start with the one that is not in the position, which is the whole issue of really if I am a junior and I enter these worlds, my experience both with my son and with friends, learning today how to enter the worlds of DevOps is very easy with the worlds that exist today for ChatGPT and Copilot , it's unbelievable how much even this shortens the learning process. Because it filters for you exactly what you want for that point of question, how do I write code in Python for this thing, how do I find a template that saves me RDS, in a second you find, in a second you can find the solution, it's an experience that really shortens the learning process , even in the process of code review, I mean I wrote code, I want to know if it is good enough or not, the chances that I will find someone in the organization who will actually do a review and give me feedback, much more than if I run this code with Copilot and I will get a lot of feedback on it Better quality, before I finally get to production, and this is highly recommended, it can be very short, I see that there are still a lot of people who still don't know how to take advantage of this ability, it has to happen and whoever knows how to do it, I think, will make a leap in their skill .

Yishai: This means investing in learning to make prompts and learning to speak engineering.

Eran: Today it is called prompt engineering.

Nati: Yes, and it requires skill in itself how to work with these tools and how to teach them and how to get them to give you the right products and this is not what is called straight forward.

Yishai: Who among us is old enough to remember the early days of Google, and the search engine before it was, the art of knowing how to structure my search query so that I get results that make sense.

Nati: It's just like that, and here it's even more art. Here it's even more art because it's really interactive and it's real. You know, not everyone who asks a question will get the same answer, so you have to know how to ask the question, you also have to know how to check the answer and you have to, I mean you have to understand a lot in the domain to understand that your answer, ask the right question and also get the correct answer. And this is a skill that needs to be learned and there is an opportunity here, in my opinion, for those who want to develop their career, to enter these worlds now and in these worlds. The second point is to really understand that in the end, certainly in today's industry, we are measured on how quickly we bring value to the organization, to write the Terraform template or whatever it is, it's not necessarily the thing that brings me value to the organization, today there are a lot of existing templates that have already been written, the ability to do this assembly, it will bring much more value to the organization. And knowing how to find these things or use tools that know how to produce it, will bring value much faster to the organization. So less falling in love with doing all the things yourself and the not invented here that I think we all, especially in the DevOps worlds are guilty of. And to think specifically in terms of value to the organization and there is a lot of innovation in this thing, you just have to make the switch in your head, understand okay, we moved a floor, we are going up another floor, and now we are building a skyscraper and not a building made of blocks, and even in a skyscraper there is a very significant engineering challenge, But he looks

Yishai: on another level.

Nati: exactly.

Yishai: Nati, Eran, thank you very much, it was fun, I was happy to talk with you about DevOps, platform engineering and developer experience.

Eran: Thank you.

Nati: Thank you very much, I enjoyed it very much.

(transitional music)

Go to devinterrupted.com to subscribe, you can also find all our episodes in English there. I remind you that we at LinearB are in rapid growth and are recruiting for a variety of positions in all fields. Visit linearb.io/careers to find your next challenge. I'm Yishai Beeri, we'll hear from you in the next episode.

(Closing music)

Links to the nifty tools and resources mentioned in the episode:

• Cloudify
• Firefly
• AIaC
• Red Hat
• Wix Engineering
• AppsFlyer Engineering
• Terraform
• Pulumi
• Kubernetes
• ArgoCD
• ChatGPT
• Jenkins
• CircleCI