Hello to community. I'm Anmar Senior Cloud architect at Unstack, and I have a question for you. How much time did you or your developers spend last week fighting with infrastructures related issues instead of building core futures that your customers actually want? If you said 40% or more, welcome aboard. You are not alone. Today I'm going to show you how the industry leaders like Netflix, Spotify, and Capital One, have solved this problem using platform engineering, and more importantly, how can you implement these strategies in your organization. Over the next couple of minutes, we'll cover the evolution from DevOps to platform engineering. Dive deep into internal developer platform. And give you a concrete action plan to get started. Let's get started. Before we dive in, let me beautifully introduce myself. I am an and over the past two decades, I have been helping organizations transform their software delivery practices. I have worked with major financial institutions like Wells Fargo, first Republic Bank, US Bank, tech, and technology like. Persistent Systems and Capgemini. I have personally led the migration of monolith applications to microservices architectures that have dramatically improved deployment efficiency. I recently published research on this topic in the world General of Advanced engineering technology and sciences, and today I will be sharing both the academic insights. And real world implementation strategies. Okay, let's start with the uncomfortable truth. DevOps has been incredibly successful, but we have hit a scaling ball. The practices that work beautifully for the team of 10, ISTs becoming nightmarish for organizations with a hundred plus microservices across multiple cloud environments. Our research shows that 69% of enterprise struggle with DevOps scalability, but here is what's really happening. Your developers are drowning in complexity. They are spending 40% of their time and efforts rustling with infrastructure instead of solving business problems. Think about the last time your team need a new environment. Did it take days? Weeks. I have seen organizations where spinning up a test environment requires approval from six different teams and takes weeks, such as like an approximately three weeks. Meanwhile, your competitors are deploying multiple times per day. This isn't just a productivity problem, it's an existential business risk. When your deployment lead, lead time is measured in weeks while your competition measures stays in us, you are not competing with in the same game. Platform Engineering isn't replacing DevOps, it's evolving it. Instead of expecting every developer to become an infrastructure expert, we are rebuilding platforms that makes infrastructure invisible. Here is the key insight. We treat infrastructure as a product. With the developers as our customers, this fundamental shift changes everything. Suddenly, we are optimizing for developers experience measuring satisfaction, and iterating based on user feedback. Here, the users are our developers. The difference is profound. In traditional DevOps, if a developer needs a database, they might spend two days learning Terraform, configuring security groups, and debugging networking issues. With platform engineering, they click a button, answer a few questions, and have a production release database within minutes. This isn't theoretical. Companies like Next, Netflix deploys thousands of times per day. Spotify onboards new developers in ads instead of weeks. Capital One reduced the time to production by 40% while actually improving security and compliance. An internal developer platform isn't just a collection of tools, it's just a COO system with five core components. Let me share some concrete numbers from our research configuration management alone, just standardizing how applications define their requirements reduced to configuration related incidents by over 40%. That's not a small improvement, that's a transformational. Infrastructure provisioning is a biggest bank for the buck. Organizations implementing self-service provisioning reduced enrollment creation time from weeks to minutes. Imagine the productivity impact when developers can spin up a complete test enrollment faster than they can get a cup of copy. Notice that infrastructure provisioning and deployment pipelines get the largest focus. Which is like a, 50% combined. These are your highest impacting starting points. The beauty is you don't need to build all five components at once. Start with your biggest pain point. If your developers are waiting weeks for enrollments, start with provisioning. If developers are fragile and slow, start with pipelines and like that. Let's look at the concrete results from industry leaders. These aren't theoretical case studies. These are real implementations with measurable outcomes. Spotify story is particularly compelling. They had over a thousand microservices and developers were spending hours just figuring out which service did what. Backstage cut service discovery time in half, but more importantly, it reduced developer onboarding from weeks to days. They were so successful that they open source of it, and it's now A-C-C-N-F incubating project used by hundreds of companies. Netflix took a different approach focusing on development deployment sophistication. Spinnaker enables them to deploy thousands of times per day across multiple cloud enrollments with advanced strategies, including Canary STA releases. They maintain 99.99% availability while deploying constantly something that would be impossible without platform automation. Capital One's success is especially relevant for regulated industries. They achieved 40% faster time to production while actually improving security and compliance. The reduced security vulnerabilities by 60%. Do automated scanning and policy enforcement built into their platform? The common thread each started with the biggest pain point see delivered early values that the expanded the business based on their developer feedback. Let's talk about the technology stack. The good news is that the ecosystem has matured significantly. You don't need to build everything from scratch. Kubernetes has become the defacto standard. 78% of elite performing organizations use it as their container orchestration platform. But here is the critical insight. Do not expose Kubernetes to your developers. Abstract it behind simpler interfaces. This Golden rule guides all platform decisions. Abstract the complex, expose the necessary. Your developers don't need to understand Kubernetes networking or storage classes. They just simply need to say, I want a scalable web service and have it provisioned automatically. GitHubs is your operational backbone. Everything including infrastructures, applications, configurations, lifts in it. This makes everything auditable, roll backable, and reproducible. When something breaks, you can trace exactly what changed and when. Service meshes handle this networking complexity that kills developer productivity. Instead of each team figuring out service to service authentication, circuit breakers and observability, the mesh provides it automatically, which is auto box. The key is composition over creation. Backstage for developer portals. Argo City for GitHubs IST for service mesh. Focus on your custom development on the unique aspects of your business needs, not the infrastructure plumbing. This is probably the most common question I get. Should we build or buy? The answer depends entirely on your context, on our con constraints. If you are a financial institution with 2000 plus engineers, unique compliance requirements and multi-year timeline building common custom one makes more sense. You have the scale to justify the investment and the need for deep customization. If you are a mid-sized company with standard Technologies stack and 200 plus engineers adopting executive solutions is best. Backstage is production ready, has a thriving community and can be customized for your needs. But here is the reality check. Building a custom platform from scratch requires at least a 10 to 15 full-time engineers minimum. I have seen organizations underestimate this by 50% or more. Factor the true cost into your ROA calculations. Most successful implementations take a hybrid approach. Start with backstage for your developer portal, Argo City for GitHubs and custom components for your specific needs. This gives you at least 80% of the value in 20% of the time. The key is starting somewhere and iterating. Perfect is the enemy of good. Remember this and good is the enemy of shit. Okay, let's make this actionable. Here is a proven implementation roadmap that minimizes the risk while maximizing EV early values. Phase one is all about quick wins and building organizational momentum. Pick your biggest developer's pain point, usually CSAD, or environment provisioning and solve it really well. Your goal is to get one capability that developers love using. I cannot overemphasize this, that you need a product owner, not just engineers. Successful platforms treat developers as customers, measure satisfaction, and it treat based on feedback. This isn't a technology project, it's a product development effort. Phase two is where you build the platform foundation add observability. So developers can debug their own issues. Integrate security so it's automated rather than a gate. Create templates. So new projects start with best practices. Built in phase three is where you get advanced AI assisted development, sophisticated deployment strategies cloud orchestration. But do not skip phase one and phase two. I have seen organizations try to build the ultimate platform from day one and fail because they didn't establish developers trust first. The key metrics phase one success is measured in our environment. Creation is less than a day. Phase two, successes, adoption, 80% of applications using your platform. Phase three's, elite performance deployment, frequency, lead times. And reliability matching industry leaders. I know it's like in a 12 to 18 months, sounds long, but remember, your competitors are either already building this or starting now. The question comes here isn't whether to start, it's whether to lead or follow. Let's talk about measuring success, because what gets measured gets managed, and what gets managed gets funded. These aren't vanity metrics. They directly correlate with business outcomes. Elite performance deployment deploys 6,000, finance 70 times more frequently than low performance, while maintaining three times lower failure TR rates. When your competition can deploy features in us while you take Wix, that's not technical problem. It's an existential business threat, but here is what's really compelling the infrastructure cost savings. Organizations with mature platforms achieve 30 to 50% lower costs per transaction. Using the better resource utilization, automation and standardization. For a large enterprises, that's millions of dollars annually. Developer retention is equally important in today's competitive talent market. Developer satisfaction directly impacts recruiting and retention costs. We have seen 25% improvements in satisfaction scores of the platform implementation. Start measuring immediately. Even if your numbers are terrible, that's still fine. You need the baseline to demonstrate improvement. I have worked with organizations that reduced deployment time from few weeks to two hours within 12 months. The ROI is unbelievable when you can quantify the transformation. Let me save you significant pain by sharing the most common implementation failures I have observed. The I trap kills more platforms than technical issues. I have seen beautifully architecture platforms that nobody uses because they solve theoretical problems instead of real developer's. Pain. Start with user research, not architecture diagrams. This is a very important point to remember. The perfect platform always falls equally dangerous. One organization is worked. Where I worked with spent 18 months building the ultimate platform. When they launched, developers complained it was too complex to use and went back to their old developer tools. They had to start over with A simpler approach not invented. Here is syndrome is very expensive. Do not build a custom service mesh when exists. Do not create a deployment pipeline when Argo CD is proven at scale. It means and you don't need to reinvent the wheel. Focus your custom development on what makes your business unique. Governance balance is tricky, too rigid, and you still innovation too permissive, and you get chaos. Start with lightweight guidelines and tighten based on actual problems, not theoretical risks. Most importantly, this isn't a technology project. Remember, it's an organizational transformation. You need executive sponsorship, change management, and clear communication about how roles and responsibilities evolves. Technical excellence without organizational alignment leads to beautiful systems that nobody uses. Looking ahead. The next 2, 3, 2 to three years will bring transformative changes to platform engineering. AI integration is the biggest game changer. We are already seeing platforms that generate deployment configurations from natural language descriptions. Imagine describing your infrastructure needs in plain English and having production ready environments provisioned automatically with security best practices. Built in GitHub copay showed us, yeah, as a coding. The next wave is AI assisted infrastructure management Platforms that can predict scaling needs, automatically remediate common issues and suggest optimizations based on UCS patterns. Democratization through low code means your business analyst can build workflow automation without bothering developers. This isn't replacing developers, it's freeing them. To work on harder and more valuable problems. Multi-cloud isn't coming. It's here. 84% of enterprise uses multi-cloud providers. The platforms that when will abstract those differences seamlessly, your developers shouldn't need to know whether their service runs on AWS Azure, Google Cloud, or IBM. Or LL Boomi and any of the cloud different clouds, they don't need to know about it. Platform engineering is becoming a special career path with dedicated training, pro training programs, and premium compensations. This is a high demanding rules. The demand for platform engineers has grown 300% in the last two years, and it's exhilarating. The organizations that invent invest in platform capabilities now will have sustainable competitive advantages in developer productivity, operational efficiency, and innovation. Speed. Okay, so now we already have discussed it quite a lot. Let's make this immediately actionable. Don't leave this presentation with your just inspiration. Live with the concrete plan. You can start executing this week. Week one, send a developer experience survey. Ask one simple question. What's the most frustrating part of getting code from your laptop to production? The answers will be given to you based on the developer's experience and your platform roadmap, and create organizational awareness for the problems your platform team needs. Someone with product management skills, not just engineers. This person will be responsible for developer satisfaction, roadmap prioritization, and stakeholder communication. This role is very critical for success. Your MEP should solve one problem extremely well, not 10 problems poorly. Pick something you can deliver in six to eight weeks, maximum enrollment. Provisioning and CICD standardizations are usually good starting points. Success measure starts immediately. Track time to enrollment creation, deployment frequency, and developer satisfaction codes. These metrics will justify continued investment and guide you decisions towards your decisions. Here is your homework assignment. Okay. Start your developer survey this week. Do not wait for perfect conditions or complete buy-in. Create momentum through small actions and early wins. The orations that start will now, the orination who are starting right now will have 12 to 18 month advantages over those that are still waiting. Platform engineering isn't optional anymore. It's table stakes. Table stakes for competitive software delivery. Let me leave you with five principles that separate successful platform implementations from expensive values. Fast. This isn't about collecting more tools. I have seen organizations with 47 different development tools who is thinking that they may need another 40th one. Platform engineering is about creating coherent developer experiences. That high complexity not add to it. Second, start with problems that your developers actually have, not problems you think they should be having it. The most elegant technical solution is worthless if it doesn't solve real pain. The third product mindset is what separates winners from losers. Your platform succeeds when developers choose to use it, not when they are forced to. That changes everything about how you design, build, and evolve your platform. Fourth measurement isn't optional. You need data to justify continued investment, guide roadmap decisions and prove your business that impacted start measuring immediately. Even if your numbers are embarrassing, that's still fine. Fifth, think evolution, not revolution. Small improvements compound over time. Perfect platforms shipped. Never beat. Good platforms improved continuously. Here is the reality platform. Engineering is rapidly becoming table stakes. Not competitive advantage. Every major technology company already has sophisticated platforms. The question isn't whether you will be implementing platform engineering. It's whether you will do it before or after your competitors gain an advantage. Okay, let's connect and continue the conversations. So here are my details, my personal id, email id, and my LinkedIn and the research paper, what I have done on this topic and the available resources. What we are going to discuss further down now the detailed survey questions are available. You can ping me, you can send an email to me. I can share under this template. Let me give you a concrete framework for calculating ROI On the cost side, calculate developers time waste. Take your number of developers, multiply by hours per week spent on infrastructure issues, multiply by hourly rate and multiply by 52 weeks. Add infrastructure inefficiency costs. Incident response costs and revenue loss due to the slow delivery on the investment side. Plan for 10 to 15 fts for your platform team over three years, technology licenses, migration costs, and ongoing operations. Most organizations with a hundred plus developers to see 300 to 500% ROA over three years. This math is compelling when you quantify the transformation. Here is a practical edition metrics for your technology stack for developer portals backstage for open source compost for commercial AWS per proton for cloud, native for GitHubs, Argo cd, or flux for open source GitLab. For commercial. Choose open source for customization and large teams commercial for enterprise support and compliance. Cloud native for rapid deployment and. Managed services before you start. Here is your plea flight, pre-flight. Check-in checklist. Organizationally secure executive sponsorship. Identify a platform product owner, document developer pain points, and create a change management plan. Technically document your current architecture, make technology stack decisions, and select your pilot application. For team readiness, high platform engineers ensure you have product owners, project, sorry, product management skills, and establish your support model. Don't skip these steps, they determine success or failure. I have included some extension resources in the slides, books like team topologies, industry reports, and community links to continue our platform engineering journey. Feel free to search them and Google them and join them and continue your journey. And finally, thank you for your time investing in this presentation. Platform. Engineering rep represents one of the most significant evolutions in software delivery practices, and I'm exited to see how you all apply these concepts in your organizations. I'm here if you need any help, feel free to contact me and I'm ready to share my knowledge and my experiences for your team success. And once again, thank you and thanks for Con 42 providing this opportunity. Thank you. Have a great day.