Anti-Patterns of Platform Engineering at SKILup Days 2024

Hello everyone. Welcome to the SREs and the rise of Platform engineering episode. I hope you are enjoying the conference, the event from, as part of the skill of days from DevOps Institute and People Cert.

So today's session, I'm gonna talk about the anti-patterns of platform engineer. So if you have not registered ed, please ensure that there's a lot of exciting sessions lined up for all of you. So please make sure to register and watch all the fund with some of those interesting aspects going around platform in generic.

So my name is re gp, I'm the managing director of Top Solutions. I wanted to kind of quickly run us through the agenda for today. What I would like to cover in the next 25 to 30 minutes is to understand the trends, challenges and antipas in platform generic.

As you all are aware, there's a lot more going on on the platform engineering aspects. So let's understand the trends. Some of the challenges and some of the misconceptions are antipas that you need to be aware of when you go to build a platform engineering capability.

So we will talk about some of those aspects that you need to think about when you build platform engineering capabilities and some best practices based on my real world experience of doing consulting coaching for a lot of organizations which are in the SRE platform journey. So for people who have joined this for the first time, I wanted to introduce myself. So as I told, I am the managing director of top solutions.

I'm also the global ambassador of the DevOps Institute and People Cert. I'm the co-author of site offsite LAPD engineering practitioner, as well as Observability foundation. So these are workshops and certifications from the DevOps Institute slash People cert.

I've also been in the industry for the last 23 plus years. Um, started off in software development and then moved on to IT service management, IT governance. In the last eight, nine years as an entrepreneur, I've been focusing predominantly on agile DevOps and site lab engineer.

I keep speaking in a lot of this conferences on thought leadership, um, on ITSM DevOps, site lab engineering, observability, very passionate about this whole aspect of site active engineering and the benefits it could create for organizations. So I do consulting, coaching, and training. Um, I was also awarded the Top 25 Thought leader, uh, by HTI in US for the last three conscript.

And I'm also a recipient of four Excellence of Watch at Washington dc. So with no further due, I'll go into my presentation for today. So just for everybody's understanding, let's set the context very clear.

So this is a graphic from Gartner. I thought this would be a very simplified way of understanding platform engineering based on the audience list. I see a lot of people who are very new to SRE and platform engineering.

Some people are experts, some people are navigating through this journey. So for everybody's view, this is a simplified view of platform engineering. At the top we have product and service teams.

So whether you are a service-based organization or product-based teams, you're doing a lot of these on, on, on place and you have your own platform, right? So this is a platform where anything as a service, so infrastructure as a service, um, cloud as a service, platform as a service. Um, and you also have your developers who are checking in and checking out day and day out to develop features and functionality to roll out as part of releases.

So predominantly you have reusable components, your tools, your knowledge that exist within your platform. And this platform is a centralized platform that you cater to both internal and external groups. So we have something called as a platform t and as we start to evolve in the area of infrastructure management, we have actually moved out from the aspect of being in a traditional environment to cloud natives.

So there's a lot going on in the infrastructure as a code and platforms. So we need to really understand the complexity of how we operate. So this platform engineering is going to be a, a centralized place where we can make things a lot more easier.

Now, one of the things that you need to be aware is a lot of people think that we typically have a DevOps team, which focus on CICD pipeline, focus on velocity and stability, focus on ensuring from the left to right. And then there is site app engineering, which focuses on reliability and resilience. And then there is platform engineer.

So just to be clear, I thought this slide will explain you about the key features. What does it mean for SRE, what does it mean for DevOps and platform engineering? This way we all have a common understanding about how these aspects work and how, how do you build a relationship between these three different teams.

So if we start with the scope, it focuses on reliability and performance of software systems. So site lab engineering focuses on reliability from the beginning of the life cycle. From a DevOps standpoint, we are trying to automate the whole pipeline from the code, commit, build, test, deploy.

Whereas platform engineering is creating a setup which focuses on a foundational aspect for both infrastructure teams as well as development teams. Now, if you look at from a maturity model standpoint, the stage four and five, right? As you start to automate your things, you start doing the fifth stage of provisioning through self-service model.

And that's the appropriate time for you to start thinking about platform generic. So as you go through your journey of on an Agile and DevOps and SRE, you would want to be at a particular level of maturity before you consider platform engineering. So let's not jump into the bandwagon without understanding why this is needed as an objective, a site lab to engineering wants to focus on preventing unplanned outages, uh, prevent disruption and ensure that we are able to quickly restore or remediate in kind of an auto remediation aspects in NSRA, in a dev off bot, I'm accelerating my deployment frequency, I'm improving my lead time and improving my cycle time.

I'm improving my NTTR as well as improving my change failure rate because these are the Dora metrics that we predominantly focus on. But platform engineering is a way to make these things possible much more faster. So our o overall that there is a lot more I importance towards blending software engineering practices with operational tasks, promoting a combination of cultural and collaborative spirit and ensuring that we don't, uh, spend time on the small stuff.

I say do not sweat the small stuff, make things simplifi. So I hope that gives you a context. Now, what are some of the platform engineering trends that we see in in today's world?

Um, as you know, site lab engineering is focusing on enhanced reliability, scalability, improving your incident response, right? For example, we are not just waiting for incidents, we are pre empty some of the incidents that could happen and how quickly can you, uh, auto remediate. So self feeling and auto remediation becomes important.

And with AOPs it also helps you to identify some of those unknown unknowns. So improved observability helps your journey to be much more productive. When it comes to platform engineering, there is also a, a, a concept of developer delight because as a consultant coach, a lot of organizations I see a plethora of tools, uh, that organizations implement for DevOps and CICD pipeline.

Now, one of the challenges is the developer is inundated with a lot of tools from the code, commit, build, test, deploy, and that creates a lot of problems. So this is a report from the, uh, study of platform engineering of 2024 and people found that with platform engineering, the developer's productivity improved about 50%, 40% reported better quality of software, and 36% looked at lead time for deployment. So there is an inherent benefits for implementing platform engineering because it makes the life a lot more easier because as a developer you would want to focus on your core deployment strategy and ensuring that we are doing the right things, improving your velocity of the team, and ensuring that there's quality release happens, right?

You don't want to be spending too much time on toy, which we normally talk about. And one of the toil is about exploring different kind of tools. Now from a project delivery pipeline, if you look at what is the benefit of having platform engineering, a lot of platform engineering uh, focuses on having security and compliance as part of the value chain.

So today, whether you look at static application security testing, dynamic application security testing, it has to be integrated as part of the CICD pipeline. And DevSecOps is important, but it's also has to be integrated as part of your platform. Similarly for operation of in infrastructure monitoring deployment.

So every part of the lifecycle should see it is to be more integrated in a manner that is giving us desirable results. And platform engineering makes your life a lot more easier. So there is no denial of the fact that platform engineering is going to be helpful for developers, it's going to be helpful for your teams, project teams, operations teams, SREs.

But there is some level of misconceptions around how do we go about in platform engineering. So my focus on the next few slides is on some of the antipas that you need to keep in mind when you think about platform engineer. Number one, a lot of people think that if I want to build a world class platform engineering team, I want to focus on technical skills, all about technical skills.

Well that's great, but that's not going to solve the problem. When this review was done with organizations worldwide to understand what kind of skills are required to build your platform engineering team, it is not alone to have technical skills. This is a report which says about out of the top skills that a product team, because if you're a product based organization, a product manager oversees the platform team.

So there are some reasonable expectations of what we want to achieve as part of the platform engineering team. So the first priority is are we able to have a strategic thinking? Are we able to get the big picture view?

Can you convert the strategy into objectives? Do you have collaborative skills, interpersonal skills that we can work with? Cross-functional teams?

Can you prioritize your work and can you do qualitative data analysis? So if you are thinking about creating your skills on as a platform teams do not underestimate the part of the soft skills and strategic thinking and interpersonal skills that could become a very important ingredient to make things possible. The second antipater, which I've seen is people think that platform engineering should include everything that you need in future because they are trying to build a roadmap, put everything in place.

Now this is like boiling the whole ocean. If you are starting your journey as platform engineering, you have to start more. So, which means a most important aspect when you design your platform engineering teams and capabilities is around the scope aspect of so what is the scope that you're doing it?

Are you looking at automating workflows and process? Are we looking at practices to ensure that you do build, deploy, run? Are you looking at provisioning of the environment?

I'm not saying that these are all things are important. This is in the order of peripheral. They look at what we need to do in order to achieve that outcomes.

So be it access controls, uh, provisioning, uh, automating workflow you desire, what is the most important factor that you need to have as part of your scope within the platform? Uh, engineering aspects so that we are able to get benefits and like, uh, MVP, you need to look at incremental value. A lot of organizations, uh, do this mistake of going all out.

To build a robust platform engineering capability, you need to be very careful that you need to focus on people, process, products and partner ecosystem because without that knowledge going all out on some of these aspects could be very detrimental and could have adverse effects. So before you start something on platform engineering, ensure that you have a very good clarity of what is needed to be supported for the benefit of the team. The next ante pattern that I see is that, oh, we need to look at platform engineering differently for DevOps and SRE teams.

Now why would you have different approaches for handling DevOps teams or SRE teams? Because this has to be a centralized one step process and all we have to do is ensure that we make that aspect work. You remember the, the, the difference I gave you around SRE DevOps platform engineer, it has to be as part of a single unified chain because at the end of the day, if I create separate approaches for handling my DevOps teams and cycle app engineering teams or operations teams, it's not going to be the best use offi.

So when you are designing a platform engineering, it's absolutely critical to start thinking about how do we integrate this approach end to end so that you can get the full value of platform engineering? Because if you don't do this one, then the chances of making it work might be very difficult. So do not, uh, create silos.

Again, be aware of the top end goal that we want to achieve and take an approach of the scope and precise reasons of making sure that we all understand each other. So have a common understanding and vocabulary to make sure each and everyone understands the benefits, the scope, and the objectives of a platform that it. So how do you build a capability?

As I said, you need to focus on people, process, products and partners. So are you having that ability to understand what's your level of maturity on agile? What is your level of maturity on DevOps?

Do people understand site lab engineering across the value stream, right? What is the level of um, uh, sophistication of tools that you have? Have you standardized things?

So it's a very important part, and this is one approach that I've seen worked and this is part of the ARI practitioner workshop, where you need to understand as you start to build this structure, you need to start thinking about what's the business process that you have, right? What's the area of application development? Because right now we have an ability to connect with third party systems and other systems through APIs, right?

Um, but then at the bottom is your platform engineering team. So it could be your platform components like Cassandra, Elasticsearch or containers and orchestration or cloud operations. Now, one of the bigger challenge I see is how do you bring that all these teams as part of one single unit called platform generic?

'cause traditionally we have cloud ops reporting to someone else, containers and orchestration team being part of another team. So how do you bring that synergy of making this as one team? This is one of the critical factors that you need to think about when you go about implementing platform engineering.

So understanding your op structure, how things are operating, what are the lead, the delineation of responsibilities, and how do we build that synergy and have a common set of metrics like SLO service level objectives, which everybody in the value chain is responsible for. Customer experience is going to be critical. So in my opinion, and this is what we should think about, look at platform engineering in a form of a self-service.

So whether it's a developer tester, qa, we need to start thinking about a system of securing the whole aspect of security as a code and ensuring that we build that pipeline throughout, right? Security and governance, source code management, um, cloud landing zones, all of this stuff, whatever you think and, and make it work, should be possibly handled properly, right? So it's a very important aspect to uh, uh, think and and manage that whatever the team needs you should be able to deliver without inhibitions.

So how do you set up your team structure and skillset When I'm trying to focus on building a good team structure and skillset, it is important for you to start thinking that your platform engineering team should have system integration capabilities. They should know how to automate process. They should be familiar with CICD tools.

They should be able to execute the end-to-end performance testing. So some of these stuff are very, very important to build the platform teams because most of the things today are managed through a full stack DevOps team. And until you have these skills embedded as part of your cohort, building a platform engineering team is going to be very difficult.

So start thinking about what kind of structure and skillset would you focus on in order to make a robust platform engineering team. And you learn by iterating over and over and again, and it takes time to make things work, but be patient to see the long-term goal rather than short term. So what are some of the best practices for implementing platform engineering?

So this is a, a kind of a simplified way of doing it. Think about whether who are you serving today? Are you serving your developers, SREs, security, finops support teams?

So what's the end user interface look like? What does the front end, how does the front end look like? What does the backend look like?

What are the components that are important? So infrastructure as a code could be one site lab engineering including kiosk engineering, uh, troubleshooting, auto remediation, could be other one. Looking at services, APIs and things that we can do.

How do you move from monitoring to observability? How do you ensure that developer experience is uh, enhanced? Right?

How do you improve productivity of the team and how do you ensure security and governance is a very important part because a lot of people don't focus on security aspects and that could provide you a very costly effect because with the level of looming vulnerabilities and threats with interconnected systems, if we don't focus on security as an integral part of the value chain, there's a lot more things that could go down. So this is a way that we have done for a couple of aspects, but it's up to you. Who are you serving, what do they need and how do you make sure that people get a unified view of leveraging everything from a centralized platform?

And as we start to do this, you will see these are my key, uh, focus areas of five key focus areas that you need to focus that to make, ensure that the platform engineering works. Number one, develop a productivity because this is a very important metric because your developers productivity has to improve, your velocity has to improve. Uh, that's important.

Collaboration and standardization because you don't want to have multiple myriad of tools that people get confused. You have to focus on standardizing. Sometimes it's tool, COE, the center of excellence teams, you collaboration, standardization.

So everyone starts following best practices, terminology, how to ensure your automation of the pipelines, send service capabilities. I talked about the buffet of a service, right? As and when you want something like infrastructure as a code or provisioning something, you should be able to pick and choose.

Uh, and this could be like a service request. If I ask something to be delivered, it should be delivered within a standard time of thing and ensure that security and compliance is not, um, compromised. So if you focus on these five critical aspects, when you build platform engineering, then your chances of sustaining a platform engineering becomes important.

So my final two sites that I want to kind of run through is one of the most important things that people leave is taking security for granted. So a lot of times when you start focusing on security, and this is what people are seeing, when you focus on security, it lowers the risk by ensuring everything is t and secure, it improves your regulatory aspects. So you don't need to worry of the implications, it reduces the time for dev needing to learn about security compliance, right?

So DevSecOps is an integrated part of it. It reduces the manual work left for auditing and hence make sure that it is able to protect all your digital assets. So another very important part as you start to build your capability is to ensure that you're building your digital assets in a manner that is secure, right?

And today with a lot of, um, problems looming in, you cannot just take it for granted. You should always go an extra mile to look at security as all level of aspects from the beginning till the end. So final slide is this is giving you a unified view of how SRE DevOps and platform engineering are doing it, right?

So you have to look at these as a culmination. We are not doing it in silos, right? So as a DevOps person, I'm looking at my CICD pipeline, I'm looking at my deployment frequency as an SRE, I'm focusing on reliability and resilience part of it as a platform engineer, I want to make my, um, IDP in my integrated development environment much more faster.

I want to make sure that there's a common set of tools that I can use. And that synergy of all these three put together is the sweet spot of platform engineering. So all you would do with this, ensure that SRE DevOps platform engineering all work towards a common goal of delivering excellent customer service, improving customer, uh, uh, developer productivity, team productivity, and ensuring that we are able to achieve the stated outcomes of better reliability, resilience, and uh, user experience, right?

So that's my, um, take on the platform engineering aspects. I hope this session was useful for you to understand some of the antipas, some of those capabilities that you need to think in mind when you develop this platform engineering aspects. And I'll be happy to take any questions.

These are my coordinates. I can be, um, reached out at uh, es GP on LinkedIn. I'm pretty active on that.

Uh, that's my email address if you want to reach as part of top solutions. Uh, we, we, we do consulting coaching and I will be more than happy to answer any questions. I look forward to hearing from you and wishing you great success in your platform engineering journey and in ensure that you follow all of the episodes because there is a treat for all of you to enhance your learning journey and all the best.

And, uh, thank you for taking time and, uh, being part of this journey. Thank you very much.