I think next time I'm going to surprise you like with the real the real thing I'll use in the movies Yeah, I'll do one too. I'll tell my needs to make me one. Yeah, okay So welcome to DevOps topics chapter or episode number nine, right? Number nine And today we are going to talk about a cool subject which is called a cool topic
Okay cool topic, which is called platform engineering right on a little platform engineering. Yes, that's the one So yeah, so as we like to start, you know, as usual Oh, Mel what's the first thing that comes up to your mind when I say platform engineering what do you think about that? I?
Address your question first because you ask what first thing comes to your mind and the things that are coming to my mind Have nothing to do with platform engineering because I want to hear that I want to hear you the things that come up to your mind and then we'll get to the real topic Okay, okay, but the things that come up to your mind when someone says platform engineering platform is like this
generic name of a team that every company for some reason has we have a team that's called platform my previous company had Team that was named platform for some reason and sitting in an application platform It has something to do with the application. Maybe an underlying layer or something, but it was it had to do with the product I'm also wondering wait also wondering about the platform that you said. So is it like also the infrastructure team
Or do you have a separate team for the infrastructure? No, no, no, no It's a platform back in team It's a back-end layer that's called the platform and it supports the product has nothing to do with my team or other operations engineer is nothing It's just a platform application platform whatever you this can mean anything So that's the first thing, okay, do you have another thing that comes up to your mind except from the topic?
I have that I have the real thing which I basically went and read and let's start I'll I'm taking a step back like I love to do and Talking about why am I hearing this thing for so long so many times not so long I'm sorry recently, but so so many times. It's everywhere It's on YouTube and I've been approached on LinkedIn and I'm sick. There's like a platform engineering YouTube channel
And I platform engineering dot orgina and what's going on? It's not a new thing The term was here for a few years now I think I've seen Hashi Corp releasing material over platform engineering and are I have open positions for platform engineers It's not a new thing What's going on recently and I don't have an answer to that and then I went to ask the god of all answers Which is chat GPT these days and I asked him
I asked him what's platform engineering and he answered like the typical answer which will touch on in a bit And then I asked why did it become recently so popular and I wanted to hear this Special answer because maybe someone is benefiting financially from promoting it No, I got a generic answer that says one reason is that recently everything becomes cloud native and all companies are joining the cloud So we have platform engineering Never mind Do you want to hear the real thing?
Okay, the real thing. Okay, so let's cut the date. Let's cut a bullshit Let's cut it. Cut. Okay, so the real thing. What is platform engineering? so Like probably when describing SRE or DevOps I'll probably be crucified if anyone hears that because every engineer has two opinions over what DevOps is or what platform engineering is But basically platform engineering is having a team of you can call them developers operations engineer
Which are responsible to building a platform that will help the developers do their work. That's Pretty much what you consider DevOps are right? It's writing the tools and Creating the automations and all the systems that developers use in their day-to-day And platform engineering is basically that but it adds the concept of let's apply software engineering principles like let's We're software engineers. Let's build a platform. Let's build
Tools, let's use sprints. Let's apply all the Cycles of sprints management and everything that developers do but in this case We're not building the product. We're building a product that its customers are the developers of the company That's a general idea. Makes sense Yeah, to my eyes being a good DevOps engineer is being a platform engineer Exactly that's exactly it and then I'm saying if you leave the DevOps engineer you are providing tools you don't want so I always say to my
You know the developer teams. I will tell some listen. You don't need me. Please don't ask for help That's the exact means that's you have the template you have everything you don't need me take it So we have issues call me but we've all had the same mentor if you will that always said that our goal is sometimes is for the
Customers not to need us in the future. We need to do our work in a way that lives them completely self-sufficient And that's essentially the idea of platform engineering I think the reason if it's not like this a big financial thing and someone's pushing it for their own mark market Yeah, like whatever the term is Benefit it's probably for the fact that DevOps and SRE Let's say just DevOps kind of deviated into these operations engineer yama engineers
You know the joke yama engineers people who just write yama's and they upload stuff to Kubernetes and maybe they push
Oh CI engineer. They just push a groovico to Jenkins and things like that. They don't do the real essence of the work I personally totally agree with that I can say that when I first came to this I heard about this term and then I said okay the new bullshit fine It's just another thing that people will now use but then I kind of read a little bit further And it made sense it clicked and that's I think the essence of DevOps by the way dev and ops
It should be developers that do operational processes and by the way, that's how I at least Recruit I'm looking for developers. I look for people that are not afraid from touching the code I'm looking for people to that can build products and that's by the way What we do we're developing tools and products that support our engineers not even big scale I think weeks weeks the company for ages have called it devx like the dev experience
So they have a team so they have a devx team. I just recently heard about it
So it's a team that responsible for the developer experience. It's a group and they're building a platform That's what they do a platform that will make their developers self-sufficient Meaning they can create new application environments create new applications create new services Deploy them to all kinds of environments do everything as much as self-sufficient as you can think of something Kind of Heroku but internal right that you can do everything on your own without knowing quote-unquote
The infra the underlying infra So that's it. That's the idea and I totally agree with it So I'll give an example of my experience with it Okay, like how I dealt with it for example like when I You know, I think that because both of us were consultants, you know Our boss always told us listen the customer don't need you the customer doesn't need you He doesn't need you make them like
Independent we don't want them to be dependent on us make us redundant. He always said yes. Yeah. Yeah, so that's weird You know, that's like antithesis like for for making money but but we made money. We were okay So one of the customers that I worked for Eventually they deployed too many things to an internal Kubernetes cluster
Too many things like it so each time a developer wanted to deploy an application. It was like Need to create some help chart and need to so every time you need to do the whole thing from scratch So then I can say that like to my eyes being a platform engineer or providing this type of service It really depends on the sweet spot, you know, so sometimes
If the developer teams don't deploy too many services. I would do everything You know manually I would do that for them because you know Why would I start creating templates for a one-time or two-time or maybe five-time thing?
But is it that I just want to double click on what you said now because Yours you said I could do it for them because it's a small team And there isn't much to do it's not Pitable and I think exactly that point is the beginning of every product company in the world You or every consultancy in the world because you're thinking okay I have all the knowledge in my mind. I can apply it easily But how do I do that in scale? What happens when there are so many scales exactly?
So when it scales when I realized that it's about to scale when I realized that I told you They were about to deploy many many many services and then I realized okay
Doing stuff manually doing stuff on my own. It's not gonna it's not gonna work So what I did was as I said about the helm chart So I created this super ultra generic helm chart Okay, that was specific to that organization So it's not like I can even share that code because it was specific for deploying internal services for that organization So it had you know Kubernetes service Ingress deployment and everything and all the developers had to do also a CI CD pipeline in GitLab CI that you love
And all developers had to do was write their code You know define a few things in the helm chart and you know the application was deployed and it was up So it was like pure platform engineering. It was like two years ago And I think you only get to that point as you said when you scale So you need to find a sweet spot because it's not always worth it to invest in those templates
To my eyes, you know because it takes time to abstract templates. It's easy to download code exactly It's always the tension between Build versus buy which probably when you grow it's it makes again again Be that I'm not showing familiar with it build the versus buy So okay, not when you when you're small it usually makes sense to buy things you Run on a platform you buy AWS service you buy servers from AWS or resources or whatever
Okay, you you buy shelf products to something to help you with BI to help you with internal communication Use slack use all kinds of services at some point to one of those services that we have some very expensive services for example Monitoring serverless, okay, not gonna name the provider monitoring serverless is a hard thing to do we use a provider Pretty hard at some point. It will probably make sense because it costs so much money to do it on our own
At least partially at least one of the environments build something on your own. So it's it's a kind of finding the sweet sweet spot between Do I need to spend my engineering hours on that or do I buy?
So that's it and I was smiling before because as you were speaking I was thinking of product so I want to try something I want to throw out my idea and see what you think of it because I think that's Kind of touching to the heart of what platform engineering is is Applying software engineering to DevOps world in order to make the developers life a lot better But with some restriction. So let me just throw it out there and tell me what you think Shoot all right, we use serverless
Okay, and that's pretty much does everything for me. I don't see a lot of framework Serverless framework. Yeah, man. That's the same way. We can use Sam by AWS or Lots of other names that I forgot that I'm out of curiosity which version are you using? I think they already have version 3. I think I'm still using 2.76 or something like that They're something enough. I just don't remember
Okay, so probably two two points something probably a little bit. It's a little bit. I want it to know if you upgrade it because it sounded crazy to upgrade Okay, sorry go ahead. We have hard time with upgrades, but we can speak about it later. There are so many restrictions to that In any case I was thinking okay that pretty much does everything for me because the developer is completely self-sufficient
They start a serverless framework. They take a template that we have a template that they use copy clone whatever and just run serverless with whatever they need they add their Permissions name of the service, etc, etc Problems they can do whatever they want. They can use an API key or not use one. They can use See we last week we talked about misconfigurations
So they can misconfigure everything. They don't sometimes don't care about the headers that are going in They don't care about different Ports and labels they just do stuff because they can because that's someone what someone else did at times They read the docs nine times. I've told them. They don't and they shoot it Self-sufficiently problem solved restrictions and whatever else I can think about is in salt
What if I were to create some kind of wrapper tool around that? It can be and by the way completely modular Right? It doesn't have to be the serverless framework. It can be
Rock creation of cloud formation templates myself. I can do that against AWS lambda Google functions Azure functions whatever Or other framework and I would let them use my tool instead of the serverless CLI, but I would it would be completely opinionated as to what I need I enforce different things like using an API protected endpoint And I would enforce the origin header to never be star, etc, etc, etc And then I help them be self-sufficient I'm applying the principles of software engineering
I'm applying product into that. I'm building a product that helps my developers But on the same time. I'm doing that not in order to Every every Monday morning fixed for them or apply the yamales for them. I'm letting them Have the power, but with the restrictions. I apply What do you think I'm wondering like I'm so I'm wondering like you know, there's always this difference
I'm not sure how to state. I don't know even if in Hebrew in English, but It depends what you want to create a vaccine or a medicine You know, so you're trying to paint a vaccine. I guess right you want them to you are preventive
You're not healing. You're not trying to heal stuff. You want to prevent stuff Yeah, I want to see many tools and services out there that are scanning your in-frame stuff Usually after the fact, you know after you create those headers that you said after you in you do security issues
They know how to scan vulnerabilities. So now I'm thinking, you know, you know with you I'm not sure like which is better because out there if you take reality You know there are many tools that are dealing with what you said scanning for vulnerabilities and everything after the fact Right after they deployed they check the things and you're saying no, no, no
I don't even want to allow it. I want to restrict it even before it happens Sounds better amazing point, but amazing point I think I have an answer that applies to me
Okay, I used to shoot shoot. I have no idea So that's what we're trying to do today We're trying to live in give No, I mean preventative is my idea What we're trying to do today because we don't have a way to prevent it is is scanning after the fact We have not really things deployed to either staging a profile production and we can scan after the fact It doesn't have to necessarily be already deployed to production It can be scanning the merge request
It's a thing we do today scanning them the merge request to find things that we probably missed First not robust enough and second you'd always have to As you said after the fact I'm creating a medicine to something that's already sick and and it's sick because the root is It's funny to use those analogies But the root is rotten because it's the template is already rotten and every developer in my company is cloning the same project
Everything necessarily has to be scanned and necessarily I'm going to have to find things So I want to solve the root cause so that's a great point and it adds to The necessity of what I'm thinking. So what if you said? Okay, so you already gave some sort of a hybrid solution You said okay, so before we deploy let's scan the merge requests and usually merge requests are before deployment So now I'm wondering isn't it enough to scan the merge request and that's it
Is it enough for you? It's it's a question. It's a question. And if I'm going back to platform engineering To the concept if I'm reminded of the fact that I'm building a product not necessarily helping developers in their day-to-day Not holding their hand. I'm building a product that they use there. I they are my end customers I want them to be happy. I want to add features But I want all of them to be happy and work correctly with the product
Is we're as a team? We're building a product and serving it to our customers and with they want we want them to be happy Etc, etc So I don't want to be the one that scans after the fact I think that's kind of the that's the DevOps aspect or the SRE aspect of things But that's not the platform engineering aspect the platform engineering is building the tool to be Not even preventative
It is actually not preventative. It's a design tool. It helps you design your application And it keeps you safe in the sense that I've already made it opinionated enough So I don't have to scan and tell them. Oh, dude You have this header that's lying around and it shouldn't be like that Or you have this port open and you shouldn't open too many ports or hey, dude
I found a found a vulnerability. Oh my tool is going to Like take the fast majority of things I can prevent from the get go and let you build something that's already robust and ready for production because I made it the way I want and that's Hand again. We don't want to restrict too much. You know what I mean again. It's always a sweet spot. So if you build the template that you're talking about
You might restrict developers and they will be annoyed because they will be left. I need this header And I don't want to tell you please allow me You know, please give me a specific permission to allow this header because this application specifically needs this header
So you always got to find this sweet spot, you know, so I'm going to answer exactly to that. That's the part that you apply It's great to say software engineering principles It's product principles and building a product and I'm listening to my customers And we're doing exactly the same way that we build modern applications today You have these small iterations with a short-feedback loop You asked the developers what's or your customers rather
What do they think of the product? What issues do they have? How are they enjoying it or not enjoying it? And then you iterate build release build release test etcetera etcetera etcetera etcetera exactly like they do with the real quote-unquote product
So I like that. So another tip would be Short iterations with the developer So if you take the developers as a DevOps engineer if you take developers as your end customers And instead of you know building them a YAML with 300 lines and telling them listen use this and that after you know Two weeks of work So instead of doing that breaking your work to 30 rows 40 rows keeping them as part of your development process
And then letting them be involved let them use it be all better testers as early as you can You know, just like you do with product just you do with your power users. I want to tell you a one-minute story Sure, as far as too many if you want too many oh god. Oh god. Oh god. You got two minutes Okay, two minutes one minute story one minute story because I don't know this completely Two minutes
Um back when I can't name names. It's not fair to name names, but we worked Together as consultants and one of the companies that I wasn't consulting on I it was pretty long project I was there for two years Pretty much part of the team and at some point We had a lot of issues with the front-end deployment So after a lot of CI iterations and trying to help them with the the for some reason which I'm not I'm not aware of CI or at least front-end deployments in my cases are always the complex ones
Not very hardly sold, but yeah, the more complex ones. I don't know Multiple deployments a lot of customers different types of front-end solutions never met I built a tool for them and exactly like the one I said now it was a CLI that helped them deploy I even released it in cycle is to homebrew We had a private app for homebrew so they can install it on their max the ones that use Linux I released it to snap and we have these iterations and I released like
Continually releasing features and whatever they needed and I had a weekly chat with the front-end group leader Which was my customer and we reviewed the product and he said what was going well What wasn't going well and I took it back I had another week of development and I released a new version and set with him and we discussed it and it went on for a few months And they used it a lot probably not to this day because it has been like three or four years
Coming to think of it. So that was a cool implementation of the same. That's it Am I gonna hear but but I didn't hear a butt in this? No, no, no, no, but It worked right. I mean I enjoyed it was developing a product. I wasn't like solving I wasn't firefighting. I was developing a product that lets them and that scales right because all of them used it They were like six or seven engineers using the same tool and join it
Was a Monorepo right. I think or maybe I'm confusing it with another product in that instance Yes, the Monorepo is one replace Yeah, okay, so we don't probably also talk about Monorepo in one of those sessions
Something we got to talk about. Yeah, it's already a thing. Oh, you know, it is it is There's things you don't want that engineering, you know It's also related somehow because how do you design a good product either by creating one Golden template, you know, gold did they think they call they call it like a golden path or golden template or something And and you recreate it or use a Monorepo and then from that you start
Creating folders. So I wonder which which is better. We'll talk about that. It's probably in the next question It's explosive and sensitive to something Yeah, but this is what we touch the explosive stuff, you know, this would be like Okay, so I think we are close to finished this session So before I even ask you, I'll tell you about a crazy thing that happened to me this week You know before I ask you, oh, no, how what was your experience this week? So yesterday?
I was finally able okay, are you ready? I was finally able to build Um a web assembly With Conan Conan is the C++ package manager Okay, and if I go if you're hearing this I'm very happy So I was able to build the web assembly. They was them and script and with Conan finally to build the
Application, you know, uh, benign eyes algorithm application to that platform. We built too many platforms, you know, iOS Android, Windows, macOS, anything you want to build for we build for that So also for web assembly, it was tough But eventually it worked. So I love Conan and that was my experience this week So omele, what was yours? I'll do the same trick for last week
And I said you're was good enough. Let's leave it On the next episode Okay, okay, so let's have a dessert by saying thank you for everyone Especially for those who are here For the entire crowd that is sitting with us Thank you. Thank you. You should put the clips, you know, like, uh, thank you. Thank you, right? They hear the crowd. Yeah, okay, and they're until next week. Do you know next week? All right. Yeah, I'll see you next week Cheers for two minute stories. Bye. Bye. Bye