Martin Sakowski, Marina Burkhardt: The Future of Platform Engineering

This talk explores the future of platform engineering, presented by Martin Sovi and Marina Burkart, both Solutions Architects at Amazon Web Services. They discuss the significance of building effective platforms that streamline development processes and meet diverse organizational needs. The speakers outline key characteristics of successful platforms, emphasizing the importance of standards and abstractions in facilitating innovation and reducing cognitive load. They also highlight the centralization versus decentralization debate in platform management, advocating for a decentralized approach that empowers application teams while maintaining quality and compliance through standardized blueprints. Through various examples and lessons learned, the session provides insights into maximizing platform utility and fostering collaboration across teams.

[Music] ladies and Gentlemen please welcome our next speakers Martin sovi and Marina burkart presenting the topic the future of platform engineering good afternoon everyone glad to see so many people in our session today hope you enjoyed your lunch had great lunch and you get back with full energy for another session um let me kick off that session with the question who of you is using a platform

that's nearly everyone another question who of you is building a platform great to see so many Builders of platforms so it seems that platforms are thing nowadays platforms are very popular concept and we want to talk we want to talk about why platforms are so special and also how we can build great platforms my name is Martin zakowski I'm a Senior Solutions architect with Amazon web services

um and I have a long history in building digital platforms architecting them designing them and actually building them and as a Solutions architect I'm interested in how to build the platform that is future proof and I'm not here alone today Marina my name is Maya Bard I'm also a Solutions architect at Amazon web services and actually I'm a former BS engineer so that means that I truly

understand which one are the pain points that developers have but also the operational team have and with that devops mindset and the practices and the perspective I'm going to also introduce you to the platform engineering how this is key for a successful organization so you see two different perspectives on the topic and we want want to share our perspectives on that topic today how to do Platform

engineering but before we look into the future of platform engineering um let's take a look back why are we building platforms and what are platforms well the word platform is a bit over used recently I would say what do we mean if we're talking about a platform in it I would say it's a group of technologies that you can use as a base for something and upon

this base you can develop some applications you can develop processes or other Technologies on top of that so we have common components that do some generic stuff and then on top of that we build something that is not generic that is the opposite that is special unique that has a distinct purpose so and this concept of doing that is not new so we find it in many

Industries um and and platforms have actually um transformed entire Industries I brought an example that most of you are familiar with the automotive industry it's a very complex industry to be honest um lots of engineering you have difficult manufacturing processes um High safety regulatory requirements um and also like a fast development cycle um the question here is like do they design every single piece for every new

model from scratch no they don't do that they use platforms like the Chassy the wheelbase transmission engines brakes and so on these are the most complex parts of a car but the customers don't really see that the customers often don't really value that but you need all of this um the C customers they look at the color they look at the interior the size some tangable features

that are interesting for them and then they buy a new car so the automotive industry has realized that they have to do this heavy lifting under the cover only once they build a platform and then they have the space platform and they can change the head of that platform and make a new car make a new model and then sell this model to different Target group to

different customers and so on one example here Volkswagen has built the Audi A4 a very decent car and the Lamborghini Euros a very luxury car on the exact same platform there's a pricing difference of more than €200,000 between the two cars platforms are very powerful one platform with multiple heads if automotive industry can build cars like that while we are smart software developers we are smart devops

people should we be able to do the same with our software let's look into this how does it work with software and one of the main goals of platforms is to increase the development speed but we still have to meet all the requirements that we're getting for our software in order to have the right balance between this development speed that we want to increase and meeting all

the abstract U um all the requirements we need something that helps us here and this is abstractions but often those abstractions also come with standardization and platforms enforce that platforms and for standards if I talk about standards people often say I don't like standards because standards are taking away the freedom standards are taking away the flexibility um if there's a standard you have to stick to that

you you have to follow that way and if you want to do it differently it's against the standard so often you're not allowed to do that um people often think if they hear standards of limitations now my bold statement I think it's exactly the opposite standard s enable Innovation standards help you to scale and standards remove friction in the process I want to give you a few

examples where I believe that is true think of this highly standardized piece of paper 210 by 297 M mm not roughly 200 by 300 no exactly 210 by 297 mm which is by the way exactly 1/16 of a of a square meter so this standard is called dna4 and I believe it's a very good standard no one has to argue how big a piece of paper has

to be we can rely on that and we can build accordingly we build like a lot of other things based on that standard like envelopes folders drawers pockets and so on we even build printers that fit D4 or F machines but don't use them anymore please and yes um if you have that standard you have to adjust to that standard if you write a letter for instance

and you have a very very long sentence you have to include a line break because of that format and you have to start in another line or if you draw a picture you have to accommodate that to the format but does that standard limit you does it limit you to write great texts does it limit you to draw nice pictures but we have seen a lot of

really good texts and and and artwork on this piece of paper so it doesn't limit us another example think of containers shipping containers also highly standardized they are all the same like um rectangular closed boxes 20 foot or 40t um size and they can be stacked and they can be connected um with those twist logs different features um some are general purpose containers some are tank containers

or refrigerated containers and so on but they all use exactly the same standard so you can fit them on a ship you can fit them on a truck and it fits on on Rail and if if you think of containers it sounds so obvious to do it like this but believe me or not there was a time before containers and it's not that long ago what did

people do they just take everything and put it in bike on a ship that was not really efficient for the transfer but then with containers they reinvented how to do that they reinvented the transport the unloading the reloading and that actually redefined Supply chains and that enabled global trade at scale so containers are a standard for transportation they are a platform do we have something like this

in technology I don't use the obvious container example because you can imagine that let's go a bit more low level we do have a standard HTTP we are using HTTP to ensure that your browser can talk to a web server and we're using HTTP everywhere we can't imagine a world without HTTP well there are certain limitations in HTTP but still think of what have we achieved with

that protocol like everything we do with the internet which is basically our job nowadays all of that because of that standard that allowed us to connect everything so standards enable Innovation we have to realize a few things now that's the first learning from the talk locking things down agreeing on things can boost Innovation can boost creativity um because standards and abstractions help us to move or remove

um this nitive overload that we would have otherwise and they help us with increasing speed of development and still meeting all the requirements and we're getting more and more requirements so if you want to be successful you need abstractions if you want to be successful you need standards we need platforms but the question is if we need those platforms what makes a great platform I think it's

a complicated question what makes exactly a great platform but something that I'm 100% sure of is that if a platform is implemented correctly then it's going to automate and enable the vops at scale and that's exactly what we are looking for and we are still a little bit far away to really understand exactly how a great platform or how actually a digital PL a digital platform looks

like a great platform but let us dive on the capabilities and characteristic that absolutely every successful platform has you may have thought before before joining this session that if there are a lot of abstractions in place and a lot of standards in place then our platform is going to limit you and actually it's exactly quite the opposite a platform should enable you a platform should abstract complexity

should make it easier for you to use absolutely every single team that you have in your company you would like that that team actually use it as that platform and in order to do that you would like to use lot of shared components and a lot of transparency also well if lot of teams actually are going to use that platform a concept that we need actually to

introduce here is the shared responsibility so absolutely every single team should feel responsible to just treat that platform as their own project as their own software as their own technology and everything to just make it the best directly to keep using IF lot of teams are using that platform it becames obvious that the marginal cost is going to be really low so that means if every single

team actually builds uh and deploys everything by their own the cost the total cost of ownership at least is going to be really high and we are looking for exactly the opposite by building the platform we are going to just reduce the marginal cost so how does actually a shared responsibility look like in the sense of who feels responsible for that and how do we actually really

Implement transparency on that well in order to really get a tool understanding of how the platform um is built how the platform or for what is the platform intended and for what is the platform not intended we need to just have good documentation so have the possibility to share documentation between the team in order so that they really understand how it works under the hood we do

not want to have like a black box in sense of that the people do not know exactly what happens inside we're looking for kind of opposite and again the the idea here is not to force absolutely anyone to just use the platform but instead building in such a way that absolutely everyone wants to use it this is the first characteristic let us dive to the second one

and the second one is actually about making a platform extensible extensible but also scale it across the organization as well so we do not want to be the bottleneck of any developer team um neither for any operational steam as well but that doesn't mean that you have to foresee which one is the feature that every single team needs in the future kind of opposite like stay flexible

really ask for feedback and really try to get to know every single team what they are using what they need and how to help those teams to just find a standard PR way to implement it across the whole company how do we do that well the idea here is to make the platform and build it in such a way that it's self-service so that absolutely every single

team is going to have the possibility to just deploy the needed capabilities by their own and one of the way of doing that is by having a good UI a good user interface with a good user experience as well so how does actually scaling look like well absolutely every single company would like to just grow in the sense of more uh developer teams more operational teams and

also to just somehow like grow the business side as well and we want to just accompany that process and give the possibility all the developers and all the operational teams to not become the bottl net but at the same time build as fast as possible all the different projects that they need through the platform that we are also giving them to them and again here the idea

is to say to stay always flexible so don't enforce any team to just use a specific pattern or use a specific um way of working but the other way around just to try to understand how they work and try to find a standardized way that works for all the different teams the third capability that I brought you is about making it evolutionary so that means of course

absolutely everyone is going to agree here in the room that we live in addition world and digital means that we are always trying to somehow be the with the have the better technology or be actually with keep the pace of new software and new capabilities that come into the game and exactly the same for the business side and we are looking exactly for this capability in a

platform as well so that means that we want to actually also understand if there is like another layer of automation or another layer of ab struction that actually our teams always need or that they need in order to move forward but always always always we want to keep a focus in making it cheaper and making it more efficient but at the same time keep keep the simplicity

so that every single team wants to use it as well what's the key here how do we actually achieve to have a evolutionary platform like and the the answer is by treating it like a product so have that mindset of develop the whole platform as it would be a product have a road map try to brainstorm all together which one are the features that they need and

try to again implement it so that every it something that I'm still learning with the time and that experience is actually giving me that it's it doesn't matter if you are really good knowing all the characteristics of something if you really know end to endend how a business process look like if you are the best on doing it and if you have the intentions if you do

not have a mechanism in place there isn't any way that you can actually scale that across organization so what I brought you here is are four different mechanisms that hopefully it allows you to just map the idea and a specific characteristic that we need with the goal that we are actually in aiming to achieve with that the first one is related to abstractions so that mean we

want to build an application that highs the complexity but at the same time keeps a really high transparency to the whole different teams we also want to have some San defaults so that means that we do want to avoid the mistakes but that any single team can do by doing things manually but at the same time try to flexibility third thing is related to automation so we

want to keep and help the teams to just gain a better and a faster speed but still without having a friction in the process and last but not least the fourth mechan mechanism that I brought you is related to the controls so we want to really inforce compliance with some guard rails and some security measures on top but still without losing focus on the share responsibility concept

that I just introduced to you before and I strongly believe that if we do have these characteristics in place then the platform that you're going to build is going to be a successful platform but I think Martin the question would be whom are we going to enable platform yeah that's a good question and let me start there with a quote um from Peter Gillard Moss from thoughtworks

he said that platforms are a great way to centralize expertise but he also says you cannot Innovation you have to leave this Innovation to the teams that are closest to the customer because they have the best ideas and they know how to build Innovation on top of a platform for customers let's look into those teams I don't know if you have read team topology good book it's

really looking into that how do those High performing work they are usually small and self-sufficient that means they can do most or maybe all of their work independently from other teams and they can make all or maybe most of their decisions on their own how does that work with a platform um here we need to talk about two different approaches maybe one that you associate with Platforms

in the beginning centralization but we also want to talk about DC centralized approach let's see um how that works if you have a centralized platform well we have a platform that is designed and operated by our platform team um so and we learned our platform has to be evolutionary so we have to add new features to our platform all the time um so you're going to add

those features in a perfect world let's imagine the perfect world we have our platform team it's super smart they anticipate every single feature request before someone ask and then they Implement that feature before someone ask and they they just have it when someone comes and like we need this feature it's like glad you ask yeah here it is now let's go back to reality um in reality

those app teams approach the platform team say like we need this feature and we need it tomorrow because we have like this urgent customer project and the platform doesn't help us so you have to extend the platform um and add new features um what then happens um the platform team needs to understand that feature the feature request and then um see like how can we build that

into our platform and then they have to build it and all of this while operating a huge platform so you're basically moving the cognitive load that was like the idea captured by the app team to your platform team from the app team to the platform team and if you get more and more app teams and that's the idea of a platform you have like maybe 20 30

40 um app teams doing this you will kind of overload the platform team and the platform team will eventually become your bottleneck because and that's the quote from from Peter gilmos um you not only centralize the expertise here you centralize the platform Innovation how does this work for a decentralized um um platform approach so team provides support of blueprints That's A New Concept here um support a

blueprints from the from the platform team and the app teams can use use those Blueprints and maybe create a own version of it so we are putting more responsibility in the hands of the developers of the app teams so they can own the entire life cycle of their app it's through full stack that's what like everyone1 have full control full stack including the platform components they can

use the platform components now you might say like yeah but then they have the cognitive overload but they don't get this cognitive overload because they get platform components blueprints they get abstractions from a platform team um and they they the app teams they can operate they have the full responsibility they can operate their full stack um they can meet like all the central requirements because that's kind

of baked into the blueprints and they can evolve the stack together the app teams and the platform teams because you can easily Fork platform components adapt them change them so in this case hearing back what Peter said we are centralizing the expertise into blueprint but we somehow decentralize The Innovation to our app teams and that's exactly what we want want to achieve when we're doing this so

This decentralized approach I think that's pretty new because people often don't think about decentralization when talking about platforms that helps us to scale the platform by thinking of our bottlenecks and then removing the bottlenecks and Shifting the responsibility from the platform team to the app teams but it is still a platform just a decentralized platform like we talked about like now we have a bit more responsibility

between the app teams and the platform team how this does this work and that's an interesting question and here we have to look into into some patterns how you can build this and how you distribute ownership well there are different ways to just make everyone feel responsible for every single part of that platform nevertheless there shouldn't be any finger pointing despite which one of the three different

options that I brought you here related to openers ship patterns you pick you always and actually you never should lose the focus on three different characteristics the first one is that you do have to ask yourself which one is the objective of building in in such a way which one is the added value that you're going to add to all the different teams that they are going

to use the platform and last but not least you never have to lose the focus that the platform is there to just help the teams accelerate the development and to also reduce the cognitive load so the three different patterns that I brought you is something that I'm slowly seeing or actually I see a lot with different ads customers from our side that they are just picking for

the different aess environments so what I brought you is to just something that makes it more like tangible so how can we actually implement it and how does it even look like for this ownership pattern and the first one is about adess accounts and how they treat those adess accounts as a platform the easiest way to just understand this in my opinion is by visualizing this in

an account as an account vending machine so the account the platform team is going to provision AWS accounts to every single team that actually needs them and they are going to have basic components set it up in a specific way with standards from the organization that are going to help you to boost the development which one are those standards it could be like um networking so all

the networking stuff related to the networking topology do they need like private subnet do they need like public subnets do you do you need any specific bpn how to set up the VPC for example also the security measures so some guard rails some policies some things that are going to enforce some specific ways of implementing stuff directly in your organization and also something related to um observability

so something related to how to monitor your different workloads how to set up logs how to use traceability and all those basic components are going to be there and present in this type of platform for those teams that need like a really Broad flexibility the second uh ownership pattern that I brought you is something with a more um C in a combination of a centralized and decentral

approach which is a little bit less flexible and with a little bit more of obstruction and this is the case of having a managed cluster so that means there might be some teams some Developers for example that they say like sorry but I have no clue how networking works and I also do not need it in in order to implement uh a specific project in a container

and therefore I would like to have a higher level of abstraction have a possibility of use a manage cluster but I would be really interested to have some cicd capabilities in place that allow me for example to have different um deployment options for my container containers like a blue green deployment or a rolling deployment but also have some other more specific cap ities related to observability like

for example having health checks already in place to know if a container is already up and running not and of course something that they also would like to know is about like controls like to how to access um those specific clusters with a specific user or also control the network traffic so again this is yet another possibility but it's not the only one out there I also

brought you a third one that I'm seeing quite a lot and this is gaining a lot of traction lately it seems to be like the modern way of implementing uh an ownership pattern for most of our customers which is related to have some Deployable application patterns so that means having some blueprints some specific ways of already implementing stuff that allows them to just pick a specific application

from a service catalog for example with some configuration already in place and take advantage of it and keep implementing on top of that how do you actually can achieve such a blueprint from the platform engineering team well you can use for example a lot of infrastructure as code with cdk leveraging um L3 uh constructs and again here what we are going to do is that the ownership

of the account is actually going to be from the application team or from the platform team so it's really from both sides as well and this is a really interesting pattern that we are seeing for high performing teams for those teams that are completely independent and they that also need a little bit of flexibility as well but let's see how does it actually look like in reality

with an example so how can we actually Implement and put this everything work together again what I said at the very beginning we do not want to force no one to use a specific pattern but the other way around we just want to make it really attractive by giving a lot of possibilities and make them free of choice so we have the platform engineering team that is

helping and supporting lot of different teams in this case four different teams they are all working in a decentralized approach all of them need a less accounts to just deploy the workloads and work directly on the projects that they are developing so every single team is going to get an aw account the first team needs a lot of flexibility so they just take the account as it

is and they just go for that a specific ownership pattern the second team instead they are running kubernetes so they would like to have a manage cluster and actually they would be interested that on top of that they have another blueprint so this specific other pattern that we talked about for for example Helm charts the third team is also in the containers game but they are using

containers so they're using Docker so that means that they would just have a manage cluster as an ownership button and the last team the fourth account is completely into the sess game so that means they would just like to have a pattern a blueprint that allows them for example to use API Gateway Lambda S3 sqs SNS and any other service that is related to that serverless P

pattern so what's the beauty here that you do not have to just pick one ownership pattern but the combination of all of them is what exactly makes a platform a great platform Martin you do have experience building lot of platforms so do you have maybe some guidelines that you can also share with us sure let's look into that and and again like we see like we can

do things centralized and decentral calized um we are really familiar I think with the centralized approach for platforms but they might have some limitations so it's good to think of like the combination of things that you can do decentralized platforms are becoming more popular and they're a great way um to help the platform team and the app teams so I would say if you do decentralized components

or decentralized platforms right um the the way that you guide the teams that you offer them to to be faster and more efficient and can be seen as a golden pass um and this concept of a golden pass is really um popular with um in the IT industry um I also heard about the concept of a paved Road and I want to introduce another concept um that's

the golden pass on a paved road but outside of that golden pass on a paved road we do have some guard rails that's important um and what we want to achieve with our platform and our platform components is that we want to give the developers an opinionated way how to use technology but also in a supported way how to use technology so the goal of a platform

of this golden pass is be giving them an opinionated and supported way of using technology so we should try to make it as easy as possible for the developers to use our platform um and to to to follow that golden PA but the golden pass is not the only direction we have this paved Road and we even have like something outside of the paved Road within the

guard rails so we should be flexible if someone has an alternative idea how to solve that don't force them on platform say like that's the way how you have to do this give them the freedom to go a bit left to go a bit right on that paved road to a certain degree um maybe this will open road and this might open another shortcut which later becomes

your new golden pass that's the idea of evolutionary platform let the teams give them the freedom to see what they can do and then see if that is helping you and driving your platform um having a golden path which is not forcing you to do something but encouraging you to do go go that um way um you remove the finger pointing because no one can say like

that's the only way that is allowed that is the preferred way of doing things but you don't have the finger pointing that someone says like I can't do it differently um and that is helping the teams to to develop quickly so that's the idea of this golden pass the golden pass should enable many teams maybe not all teams but many teams so and if you want to

have an a golden pass that helps many teams well you can invite all of them to support this golden pass so everyone should be able to contribute to that golden pass make it better or like find a new Direction so and that's exactly the idea Marina talked about this already um having this product mindset if you build a product you're always looking for ways you can improve

this and you're happy for every input like you don't think like this is the only person that can give feedback on a product like get feedback from everyone and think of platform as a product it's the common product of your organization that should enable as many people as possible so how to build those platform products treat them as platform components and treat them as a product um

I learned a lot of things during my career from open source um and we as def Ops people like um we use open source libraries a lot so we can learn a lot of things because our platform components should be treated like successful open source projects because you want everyone to contribute and to evolve this one so vcts that's the the rule if you want to learn

how to build successful um platform components they should be versioned that is super important version platform components so you have a version piece of software where everyone can contribute but there also allow you to like maybe use an older version because you can decide um and you can contribute at a new version and so on and if it's semantic the versioning like everyone understands on what they

are reliant because they're kind of reliant on that platform on those components so they fully understand what version of the platform they're getting make it decentralized we talked about this a lot um it enables like a um an independent life cycle of platform components also super great approach and it makes the scaling so much easier if you have like those small pieces um that you can can

scale it's so much easier instead of having like a big platform um where you have to consider so many different things and if you have small components it reduces the blast radios and then make it usable we also talked about the ease of use a product mindset will help you good accessibility um good documentation scaffolding maybe think of an SDK on top of that Sy of a

CLI a good UI integration patterns and so on make it customizable open to changes we also talked about this um allow people to parameterize things that you're offering um allow to choose Escape hatches um allow them to Fork your product and build a better version out of it and transparency like don't build a blackbox we learned people are relying on a platform that's actually their job they

are responsible for what happens so if you make it a black box it's hard to rely on that people you don't have that trust build a white box don't hide the implementation be proud of the implementation show it to everyone they will like it and they will tell that you like it and Self Service everything is automated you should be able if you want to get something

from a platform you should be able to request it and deploy it VI an API that's is how you build platforms one last thing to mention platforms stay ahead with your platform so your platform always if you want or not like it always Builds on a certain base for instance you build your kubernetes platform on top of a cloud provider or data center or whatever um and

your platform should arrive uh should should evolve your platform should get better all the time and also that base evolves all the time often it evolves very very fast so if you don't evolve your platform if you don't adapt it to the base and you stick to whatever you have built all the time you have a sying platform you build a platform that is forcing people to

do something but not adding any benefits and such a platform is a burden for every developer if you evolve your platform on a regular basis if you adapt it to the base if the base has more features make them available and built on top of that you will have a floating platform a platform um that is always ahead of that base and that is adding real benefits

to the developers and that is a platform that is enabling teams so so always build floating platforms what did we learn today a few key takeaways we learned standards are not limitations standards are often the key to Innovation and don't build a platform for the sake of having a platform because everyone is doing this build a platform that is enabling your teams think of what would enable

your teams and then build a platform that is extendable and evolutionary and then also think about decentral ization of your platform don't think about like platforms have to be centralized decentralization decentralized Blueprints and then build this golden pass for your developers and always stay ahead with your platform thanks a lot for listening uh this afternoon and we really value your feedback there are a lot of QR

codes these two QR codes you can ask us questions on LinkedIn this QR code on the top you can give us feedback for the talk 15 seconds we highly appreciate your feedback thanks a lot listening now we can start queing questions um session so we have a first highlighted question that you can see in the past let's say 20 years ago platforms were also managed by their

te guide do you think it might happen again with the introduction of AI getting merged a good question um of course yeah you can think of like um what would be the benefits like how how can you how can you help developers getting faster and um especially jny I can um can help to to to increase the development speed also that can be considered as a type

of platform to to increase the developer speed and the quality of that so it's a combination if you look at the runtime maybe j i if you look at the developer experience and like platforms are always there to help developers building better products um Jenny I would definitely um be a part of that remember the evolutionary capability so we always want to keep the pace of technology

and that's one of the ways also of to just bring that technology directly to the platform so let's see thank you so the next one says can you give a good example of what is a pattern would it be something like a chef cook book unil Playbook or terraform yes yes yes um it could be various patterns like um we we mentioned a few of them um

a good pattern can be can be built in something like cdk for instance you can also do this in terraform or anible like we don't look too much at the tooling it's more like question does the tooling help you to achieve that that um and there are great ways if can tell you a bit about the cdk for instance we encourage you to look into that um

if you look at infrastructure as code you can do it on the very low level but the idea is of a platform of blueprints to build it on a higher level um for instance um we have a blueprint um where you only need four lines of code to spin up an entire account with VPC all the security stuff and fargate cluster um and you only have to

provide the parameter where the container is and then everything runs fully resilient and so on um that's the idea of an abstraction and you have to think like whatever tool you pick doesn't allow you to build those abstractions easily and and also for the developers then to use those modules um to spin up their own great so the next question reads platforms are great but espicially close

to Matrix organizations with subsistent teams how can we avoid the problem their problems spittering responsibility waiting or something else I'm not 100% sure what's the direction of the question um like the responsibil like we talked a bit about like this um where do you put the responsibility and also this um cognitive load and um you want to remove the finger pointing and it's different like different types

of platforms uh successful or not successful in different organizations look at your organization like look into Conway's law how that works that's actually also thing for platforms um and understand like you know what would enable the teams like what are like the dependencies between the teams um and then design a platform that is removing the finger pointing that might happen in your organization um that is like

one of the ideas and decentralized platforms definitely are more flexible to accommodate for that compared to centralized approach I don't know if that one was the direction of the but if it wasn't just feel free to just jump in seems like this question was answered yeah so next one reads does decentralized path lead applications team to start caring about the infrastructure also as they will start creating

infrastructure according to blueprints um it can it makes it transparent for them so they know what is happening so they can have the full responsibility but you don't want to like you you don't want to have an app team building a front end that should understand like the network too much um you want to give them abstraction that they don't have to learn network from scratch um

but they have the full control in case they want to modify this is if they're familiar they say like yeah but we need something else it should be extendable enough that they can change it parameterizes but they don't have to that's the right level of abstraction layer um in Ideal World if there's a team that is good building Java containers build them an abstraction where they can

easily deploy Java containers and they don't have to see all of that that's a perfect abstraction but so transparent that they know what is going on uh under the hood I really really like that there are so many good questions I think we have one transferring ownership to application teams would require a strong trust in those teams and the expertise of those teams and actually building such

an expert sorry I think I didn't understand it transferring ownership to trust in the expertise of those teams and actually building such an expertise wouldn't transfer the ownership maybe but trust is always like if you're relying on something and if if you have like a platform team building something for you and you have to use that and it's in your stack yeah you have to rely on

that um and you have to trust that team um how do you get trust the questions like do you trust them because you know them you're friends with the other teams and you say like yeah they're good guys or do you get the trust because you have transparency and you have kpis if if it's measurable like seeing like the availability of those components like how resilient they

are if you make it measurable if you have data for that then you can make a datadriven decision to trust those components so the questions have uh ended and uh you may still uh ask our speakers some questions in the ask me corner so thank you a lot we also have some stickers actually so if you would like to paste it on the computer or whatever else

also as well we will be more than happy to stay there in the um ask me anything corner with stickers as well I'm more than happy to just answer any other question that you have [Applause]