 Hello, good morning. Thank you for coming. Let's start. My name is Ivan Pedratas. I work at Docker as a principal engineer. I've been doing distributed systems and Kubernetes and lastly more focused on understanding complexity and YAML. This session today, it's a best of feather. So I hope that you all can contribute. Now we have a microphone and if you can get a little bit closer to everybody, it would be easier for me to handle the microphone. Thank you. So I have six slides and then we can just talk with the point. What is the platform? This is a definition I really like that Ivan wrote and is about these service APIs and tools and service and the two things that usually people measure the knowledge and support. We can go over what we think is a platform. I think that right now, so I was at KubeCon in Valencia and there was a lot of talks about platform and platform engineering and it's the new SRE and I think that there's a lot of questions that we need to answer and we don't have many of those answers, I think. That's why I thought that doing the session would be good. Try to see what the real feel for platform engineering is. I think there are two things that are very important right now in the platform engineering. I think to baseline the language like backstage as this framework to create developer platforms and team topology is with the different team information like the platform team, the streamline, the enabling thing and blah blah blah. Speaking of backstage, at four o'clock there's a talk by Susan, so if you're interested in learning more about backstage, you can do that. What else is the other thing that happens is the cognitive load. It is not complexity, it is perceived complexity by the person and you have these three kinds of knowledge and it's important to understand that this one, that I will not pronounce because I cannot, is the one that it's basically the throw away knowledge. There's a thing that usually you cannot take away with you if you change context because it's how we do deployments in Docker is different than how you do deployments in new organizations. The constraints of the context are different. Patterns might be the same but and that's it. I really hope that you all contribute. I ask Brian, I don't know if you know Daniel. Mr. Brian put this straight and he's been very active asking about platform engineering so I asked him if he could give us a few questions. I was hoping that he was going to come but he did not want us to come. These are the three things that he's been asking. I don't know if we want transits now or not. This QR code will send you to this HackMD that I think that we can use to put all the questions and keep them as our lock for the session so you can use a QR code and access that. Who wants to start? Who is building a platform here? What is a platform? What are the pains that you have in your organizations? We have the microphone so like I can't repeat your comment. If you want to make a comment I think it's easier if I get the microphone and just hand it and then you talk. Who wants to start? Do you want to start? Come on. I think one of the biggest issue is trying to sell the internal platform. If you just created even the PLC platform and integrated with your internal APIs, different tooling, is to sell this to your developers. That's one of the biggest issue we're struggling with and upskills them. We're building, we're spending the time currently even on the way learning go so already for a few years I would say our team is the seven engineers at the moment so that's one of the biggest things. Yes. Another thing I see and that's another question that I would like to highlight and maybe to discuss with someone else is every single company they create their own platform. Every single company and it would be nice to define some standards around it. I know maybe sounds the awkward but would be nice to just that well so that developers could easily to be imported to this internal platforms no matter where they're working. That would be nice just to define standards maybe inputs maybe UX as well maybe like common API for them. But a standard and interface different right? Yeah. I think that that is like we suffer from not having a very well defined grammar or language like when you talk about standards and you think about interfaces is different. Like these self-service APIs who has built those service APIs here? Who is wanted to build those service APIs? What is one of the first things you have to think when you are doing this? Define internal standards. So they're like you have you have the API that has to do whatever it has to do right like that's a given but but I am the consumer I'm going to use your API I need to do something I need to know if I can use it so I need to have certain observability around that service if you don't give me that it's very hard and and this is by the way it's really difficult like I don't remember which coupon it was it was in in Copenhagen I was there and my classes were not building I was going in GK to create my class it's not working it's not working and it's because they didn't have capacity and I didn't have a way of checking that there was capacity available for me to do it right since that moment when I have to build an API that you're going to do anything creating this or creating that I will I will let you do things like can I do it do I have the permissions to do it do I have the capacity like do I have the the money or the machines or whatever resources do I need right it is it is a thing like oh I didn't I didn't think about that because when we're building the interface or we think about what we have to do and usually we forget about the UX the user experience right yeah importance to define your internal standards and in those inner source culture as well so that you know not one single team working on this internal beautiful API but maybe several different teams and they could collaborate so many other questions so as as anyone read this this read it right no it was it was at some point it came and like oh wow and it it's a classic problem that we have that we build something and then people do not adopt it right why is that there's a whole thread of people talking and then it it drills down to if you do not ask your customer what do they need then you will build something that might or might not be what they want right and this is the bit that that it's important to understand when we talk about cognitive load where is the cognitive load thing I don't know here here there right like cognitive load is what people know right and and the more that they don't know how it gets right it is I have a graph you can you can see like like it behaves a little bit like this like like a logarithmic function right like okay this is my time this is how much I can learn at some point you get saturated you cannot learn anymore right there's there's different strategies and and team topologies helps with this right like when we talk about these teams it helps like like this is this is my life complicated right but you have these stream align these people are building something and now they come the enabling team and the enabling team is going to do something right like for example if we have this model this is how my team is going to to be able to learn I can shift it right now I bring the expertise that we need to deliver whatever right but but it is very important to understand that delivery is one thing and upscaling the team is different right because this is going to help with delivery but but when these other team leaves you will be again here even worse because the team has got used to have this as a really or this person who knows and now when they leave boom that's that's the void of I don't know how to do it and this or the guy was doing it and now he is not here and I'm in trouble and all the time that he was here I was very busy so he was doing stuff and I was doing my stuff right so you have you have to understand these these kind of models right talking talking to the to the customer is very important because what is very important is that they understand what you're going to do like this there's something which is the golden path right like where's the golden path here right have you heard about the golden path no golden path is basically the pre-defining these these ways of doing things we're going to do deployments in this way we're going to do building my images I'm going to deploy to kubernetes I'm going to create this static website in this way I have to go to my portal and I have a very easy way of doing it but that does the whole point of backstage is having this system where people can go there and access to all the information that they need to do my job but so it's just not having a dashboard it's not a wiki we're like okay we have confluence we have jila what else do we need that it's not the point but then and and one of the things that happens when you adopt backstage right like this is this is a little bit like the model I put this line because this is the bit that people means a lot you have in your company you have all your services to do all these things now you're going to bring them in into into a portal you have two options you can couple it here when you create your plugin or you can create a proxy to do the couple the platform from the from the service you have to bring the tools you have to bring all the things here like a service catalog of all the stuff that you might need can be here right so one of the things we have a docker is that we have teams and we need to have a dashboard that that can show you that the pull request right now pull request by team is something that you can try to categorize like like backstage with with this service catalog has a way it's like okay you are this team and like what happens if you team has to deal with a repo that does not belong to them okay it's not going to be in my dashboard so we need a way of being very flexible here now you build a service that is going to populate all the pull requests for your team and your team says yeah but half of the pull requests are in these other repos that we don't is like okay now now what is this the disk owner we have what they're asking and where we build sometimes he's not aligned because constraints and things think about about that like bringing you services bringing you tools to one place right so in backstage I can go to backstage I think I think there are demos here that we can I don't want to work but I know that there's a demo somewhere it's because if I put my glasses I cannot see you and if I don't have my glasses I cannot see the screen so this is backstage right like like and here what happens you have you have the catalog right you have your components and then you have your apis right and then you say oh you I can make it bigger if you want a little bit bigger right so like okay the api the pet store api and the tech dogs of definition right and and now it's it's like the whole point of this is to understand how things are related right and oh it's not loading this let me get another one so you can you can see this kind of thing so I I'm a new person in your team I come here I say okay I have all these things and you can you can do things like this is the CICD this is the apis and my dependencies my documentation to those whatever plugins you need to do right like all these things are plugins and same thing here like like you're basically building the system that you need for your organization we will need CICD we will need managing dependencies but the way that you do it and the way that we do it is different doing the standard probably doing it common interfaces yes right and that's the point of you can you can try to use the the catalog definition of backstage if it maps your organization if not it's okay you can create the proxy that transform that into the backstage backstage or whichever system you use right that that's the whole point of this is now the cognitive load that I have when I join a new team is where it's more because everything is here but then and you can have ways here of like seeing your application in this corner of this plaster or these application in in this or that cloud right and then you have the templates when you come here where it is a new thing explore yes there's one option that you can create new components and and the whole point of these is that you can create these templates that it's going to go to GitHub and create the project with the different artifacts that that they need right and they have to wire up Terraform for example let's talk about Terraform right so you want to publish a static website right like the user experience can be I come here I go to my template I click in the button to create a new a new static website it asks me a few things name and and no much else and that thing goes and creates a github repo and creates a service going to the pull request into the the repo where we have our Terraform right that's that's a model that you can have doesn't mean that you have to be like this you can be completely like I have a way of calling that or creating a a github ticket for the infra team to do whatever they have to do under the point is that the user comes clicks the button and that's it so you you are simplifying the process what else and how many of you struggle with with the red reddit problem like I build these people are not using it people don't know how to use this people do not understand I am nobody understands what is the most painful thing that you have in in in your day today not with your team but with the others so um I really uh can identify every of the points described on the reddit post in my company so um the the idea of I guess the idea of of these new platforms is just to make the things easier but uh yeah but but I feel that the the complexity of creating automatic flows for everything you need to do is really high so I mean every of us are starting from the learning to the developing to deploying and so on but this flow change and the complexity of having everything in sync is high so if the I don't know backstage at all but if you are not able to synchronize every step in the right way that would be also a problem and what happens if that change are you able to to deliver like both behaviors so this is my main concern about that so I understand that we need to do something okay but I'm not sure if that is the the right path sounds like dependency yeah sounds like a common dependency issue and versioning as well of your of your internal APIs and that's something we we're also struggling with yes if you create the platform you also have to support different versions and abstract this in your internal platform somehow that's one of the biggest issues yes another one something I see from developers they don't understand our back and authentication and that's in the secret in the secrets management that's a completely completely usually even having the brown box actions Katie for specific teams it's really tough something something really really hard to abstract and I'm not sure how to we're trying to do that but that's a that's a difficult challenge so like like with secrets for example who's just struggling with secrets if you don't raise your hand I don't believe you so one of the issues that we have is that like this shifting slash pushing left like like we are basically giving the keys and the locks to the developer and say now you manage this and you have to put the right locks in the right keys in the right places and of course they should not have to do this right like why secrets is a developer concern it shouldn't be the idea it should be open ID and OIDC and what we end up with managing our back here and there true but that's slightly different because we're like you will need to have secrets but you have to define the key as a developer you define the key this is the key that I know my application needs I'm going to consume this information through this key that's it that's that's that's the interface that they create I like that this is how I consume information what happens is that then historically we say now you own the process of managing the keys and the locks so from development to production it is your problem and you have to do it properly and they do not understand all the constraints all the different environments because it's a lot right it is it what's happening with the shift left is that we're pushing so much information and concerning into one place that the logarithm thing like it saturates and like yeah whatever right so you have to start thinking slightly different the golden path is not going and building all these things it's going to them it's like okay where where are you pains like but when Danny was in like what are you pains not my pains right but like it's it's not about me writing telephone is about what is the problem you have and then they will say doing this is very slow or I don't understand this it's tricky because people usually do not like to say I don't know this right they will not tell you directly unless they're very comfortable not knowing like me I'm very happy to tell you my life and unless they're very comfortable they will not do it so you have to be aware of these you know you cannot ask like do you know this that's why we're trying to abstract these things providing the internal platform exactly but you have to abstract it in a way that they can understand right this is like if I take you to a to a restaurant where I was born right like I took a friend of mine speaks five five languages not the one that the people in the restaurant understand so it doesn't matter how much he knows he's not going to order food because you cannot speak the language I'm like okay now this is this is the situation like oh this guy is very smart speaks five languages yeah but the one that is important is missing you can do a lot of very funky things I'm sure that these people did really awesome stuff but they miss the point is like your users cannot understand you right and and the team topologies tries to tackle this right like like this enabling team isn't everything helps to help people and facilitate right like it's about it's about learning more than delivery right and in the in the curve that put earlier it's not about delivery it's about people learning and feeling comfortable with not knowing right it's super tricky now we go and try to build a golden path based on what and what they and like we know what they need to be able to set the needs you need to do something like you you need to build a darker image you need to have the helm chair you have to have the helm release because we're using guitars and you have to do these poor requests etc like we know but but we miss the point is that they don't right and then we were like how many of you have been in decision like developers need to learn Kubernetes how many and what was the reaction of of the developers this is like crying crying quietly towards the bathroom they just flip the table usually they don't like it why too many information just a lot of information a lot of kind of objects okay that's that's an option like like that's who these gentlemen would have to say because they don't find it interesting at all exactly they don't like it sometimes even darker is too much for some developers yeah they're like that I want I want just to to focus on my code right yeah good why I need to know how to build uh write this cluster right like well because your application is using brevis yes but it doesn't mean that you have to be an expert building these things right like what I usually say is like being a very good cook and knowing how to run a restaurant two different skills sometimes you have no choice you are a cook and and we wear many hats right and then let's talk about scaling knowing how to run a restaurant and knowing how to manage a chain of restaurants different as well right so it's very different and now we're asking them to do things that actually maybe they are not the right candidate for this what happens historically what happens with dev and ops and then we create the develops and like what happened like devs will not understand operations and all is like I don't know what your application is doing I cannot do it you and then the interface that we had was very crud document let's put this document let's let's try to agree on this and that the reality is that if we had a way of exposing the information that the other party needs that's it because the thing is that you do not need to talk with the other team if what they offer you if you have enough metadata to make this and the exercise that you have to do is to approach one of your teams and say I'm going to automate something for you whichever is the most painful thing I'm going to automate it and then look at what do you do when you're doing it you're going to go and try to understand what is the process has to be done and what are the things like you need to have certain information to do the automation right that is the key understanding that this is the interface between you and them now you're creating this this automation or abstraction right and now life it's easy Monzo has a tool that the deploys and developers use that tool to deploy but they don't need to know how the tool works that's a platform thing job they say okay look this is your command that's it now you run this boom I have I have a docker file that when you build a docker file it generates your helm chat and your values file you don't need to know anything right so the only thing they have to do is docker build and boom they have a helm chat right like it's it's understanding like like what we're doing with this model is trying to remove that thing that they don't like to to create the helm chats I don't think that anyone likes to create the helm chat but it does that's the model that you have to think any comments any yeah maybe I just wanted to say that a few years ago we tried here to build like this multi-cloud platform for developers and the first mistake that we've done is like uh automated the sandbox server service for them so they would have a sandbox to play in right okay but in essence they didn't care about that because well we were told by public cloud providers that developers should learn public law services but in reality it does not work that way we don't care so they want the end result right so then we shifted our but yeah back so you have you have a sandbox system right and and this is interesting because when you have a system like this what you're doing is changing completely the constraints of that context I don't talk about the environments I talk about context right like it can be in production it can be this and you can have three classes in production that's a context for me but like the constraints that you have there constraints and dependencies you have there are different from everyone else and that and that's not how we learn when we learn is like things work like this right when when we are learning things it's like okay if if I'm writing my bicycle and leave my hands I just have an accident if I'm walking in my house and I close my eyes I usually walk or step on the dog or something worse right and you you learn this very quickly and now if you do the same thing in an open field you can walk with your eyes closed no problem the only thing I don't is to change that context so what you are learning it's completely useless in the other one and then the other thing you have to think is why why do they need to learn this why do they need to learn how to get an S3 bucket because for the developer the S3 bucket is just a location like I put my my things there that's it it's a bucket right and that's the issue is like no they don't we have a problem which is we we're not enough to be able to do all the info that needs to be done all the ops right so what we have to do is to accept that it's either us building a platform and building these abstraction and automations or just hiding track of the people right then and in this model in this mode this is what happens you bring this team right this team gets embedded in the other one now it's delivering now the organization thinks okay I sorted this one what I have to do is to replicate this model I'm going to have more people like these ones and put them in the teams now my delivery is much faster and now we're hiring and hiring and hiring it creates another another kind of problem because we're not solving the real problem the real problem is basically what I said earlier just this one you're trying to shift but you are not right you you build it you run it who thinks it's a good idea nobody come on why not so do you think it's a good idea I think you can run it but you shouldn't for example you should own it not definitely run it okay you own it yeah okay into the like let me ask these gentlemen I'm I'm I'm sort of trying to construct an answer with with the thing that you're saying because I'm from a slightly I've been developing for a good 30 odd years and when I started developing you had to know everything you had you had no choice and as I've grown through my career I've continued to want to know everything and I find it difficult when I meet junior developers that are coming out of college and they want to focus on one thing and one thing only and they don't want to know how everything hangs together and that concerns me because I'm an electronic engineer from 30 years ago so I understand how things work at an electronic level and I it worries me that that our college students don't want to know that so I'm I'm of the opinion that you should try and know everything like I get the point of the cognitive load but each individual you know we have an untapped resource in our brains where we can take on an awful lot of information we've proved that many times throughout history so are you saying that we should just keep developers knowing a small piece of information now what I'm saying is you need to help them you need to help them to learn now and this is a tricky bit that usually people don't like when I say it's it's team is different it's person that is different the cognitive load that I have and the cognitive load that you have and the cognitive load yeah different because I want a situation is different right so the way that I'm going to learn Kubernetes goal rest lambda doesn't matter what is different than the way that you went to it because you know certain things that I don't right so you don't have a unified way of like everybody's going to learn like like this now you have these people have to go there and help them to learn and what they need to do that the enabling thing is to understand where the other team lives right like this is what they know these are the caps gap analysis right so we're going to do this exercise to learn yeah so as an engineering manager I have an approach of culture that I develop within my teams and one of those cultures is continuous learning and development at a team level so everyone within the team is responsible for helping everybody else on subjects that they don't know about so I think what you and I are talking about in this case is very similar but for me that's a cultural thing why you approach that oh yeah yeah so like like an organization has these three three dimensions right like like people tools and processes right and and and you cannot you cannot do one without the other you can look at that like you can flat three dimensions in two and we have the cube you can look at it and like now it's a square or now it's right but the red is that you have these three things and they're interrelated and changing one thing has an implication in the other ones changing a tool by itself is not going to solve your problem and in backstage it's not going to solve the problem the problem that these people in in the red threat hat is not about the tool like the issue here is is they're not speaking between them like these people did not talk to them like what do you need what is your problem how can I help you they didn't they're like oh you're doing these things what you need is all these bunch of terraform or services or whatever I'm going to write all these pulumi code and now this and then the developers are like I don't know what you're talking about right I started quite quite a while ago right like I did something like like I wrote assembly code and and Fortran at the university I'm I might do it older than look but now people engineers that that join the company it's like yeah but when you started it was much easier there was no so much to learn now there's too much to learn like the saturation comes much faster and that's okay it's not about how much you have to learn it's about choosing what is important and we're not helping them can you pass the microphone we have like three minutes yeah I wanted to maybe get back on what you just said and I have an electrical electronic background also I'm an electronic engineer and I like to understand pretty much all the layers that that makes up an application but I think it's it's not the case of everyone and we are I mean if we get back like yeah a bit like you said like 10 20 years ago the stack was much easier you did not have to bother very much about the infrastructure because it was pretty much manual handle back someone else or you just created packages that you you deploy and that was it I'm currently working as a consultant in a company that made the shift from this old waterfall way of working all the way to DevOps in a few months so developers that has been working like 20 years just developing code and creating MSI packages all of a sudden has to learn CICD pipelines, infrastructure code, hand shots, hope those communities works and all those things and it was very overwhelming for them they decided anyway to to to proceed in that direction but it it turned out to be a real mess because they just get back to the old habits what was automated was then manual and and and I'm here trying to move forward and I think platform engineering is a very good answer for that yeah there's there's something you have to understand because when you were talking it's like yes it is true that now the architecture that used to be there like that the constraints that we have now are different from the concern we had 20, 30, 40 years ago we didn't have much memory our CPU were not very powerful we were constrained in different ways now we have now we have big machines with a lot of memory and and so on right like so the constraints change right but but the problem is always the same we're trying to build and solve problems right and I think that that is the key it's like try to look at things slightly different like okay it is true now now I have more because I have all these latency and networks and blah blah blah and I'm not but if and we are not comfortable with these things whether you have to balance with yourself I'm not comfortable with networking I don't know much right that's okay the constraints are different like the same way that that we spend a few hours trying to understand how to reduce the the memory that that the mastermind had to do to be able to do it it's something how do I have to do to to map the network in this way right and I think it's very interesting that the whole space the evolution and platform engineering is it has a place and we need to finish sorry and thank you very much for coming if you want to to to talk about these things I would be in the booth in the docker booth you can reach out or you can ping me in twitter my twitter handle is here no it's not it's here thank you thank you for your time