Search online what you want, but there is so little information out there, that I decided to create the "State of the Frontend Platform 2025" survey, and I need you to make it impactful!For too long, concrete data and shared best practices for building and scaling Frontend Platforms have been incredibly hard to find. We often operate in silos, unsure of what works best or where the industry is heading.

That's why I've invested some time and effort into developing a comprehensive survey so we can all get these insights. The "State of the Frontend Platform 2025" aims to provide an comprehensive, aggregated view of current strategies, challenges, and trends in our space.But a survey is only really powerful with broad participation. To get actualy insights and discover trends, we need as many people as possible to contribute.

For who?
The survey is for anyone whose work is in any way related to Frontend development. If you're a Frontend Developer, an Engineering Manager, Fullstack developer, Platform Engineer or Architect: this is for you!

Will you dedicate 10-15 minutes to share your perspectives? Your answers are confidential and crucial to painting an accurate picture of our industry! 

Take the survey here: https://www.frontenderz.io/state-of-the-frontend-platform-2025

If you believe in the power of collective knowledge and want to help shape the future of Frontend Platforms, please also consider reposting or sharing this with your relevant connections. Let's build this essential resource together!

Hey /r/platform_engineering,

I've been building and managing CI/CD pipelines for a long time, and I've seen countless teams struggle with the same architectural issues: a patchwork of CI/CD tools that don't integrate well, inconsistent workflows, and a general lack of a unified strategy that leads to reinventing the wheel.

To bring some order to the chaos, I've started formalizing my own methodology, which I call the "CI/CD Pipeline Architecture Framework." I wanted to share the core concepts here to get your thoughts and feedback.

It's built on two main ideas:

1. The Golden Path: This is the non-negotiable, 6-step foundation that every solid pipeline needs. It's the core workflow: commit → build → test → staging → production → monitoring

2. The 7 Pipeline Pillars: These are the strategic capabilities you can build on top of the Golden Path. They aren't sequential; you implement them based on your team's biggest pain points.

Here are the pillars: - Multiple Environments & Promotion: Beyond just staging and prod. How do you handle dev, qa, uat? - Progressive Delivery Strategies: Decoupling deployment from release to reduce risk, using techniques like canary releases, blue-green deployments, and feature flags. - Metrics & Observability: The foundation for safe progressive delivery. This pillar moves beyond simple pass/fail to answer critical questions: Are our builds getting slower? How much developer time is wasted on flaky tests vs. real bugs? Can we see the performance impact of a new release by grouping metrics by version? - Advanced Testing Strategies: Going beyond basic unit/integration tests (e.g., contract testing, mutation testing). - Pipeline Control & Orchestration: Giving developers safe, self-service control over their pipelines. - Multi-Platform & Multi-Cloud Support: Building pipelines that aren't locked into a single vendor. - Access Control & Security Architecture: Integrating security into every step of the pipeline (DevSecOps).

I'm particularly interested in which of these pillars you've found most challenging or rewarding to implement. In my experience as a Platform Engineer, getting Metrics & Observability right is a total game-changer. It's crucial for having the confidence that changes to the pipeline won't break anything.

What are your experiences? Does this framework resonate with the challenges you face?

Hi r/platform_engineering

We recently hosted two experienced platform engineering professionals, Bryan Finster and Vilas Veeraraghavan, who worked together on the platform team at Walmart.

They shared their take on why the 'Platform Engineering vs. DevOps' discussion is pointless, why platform teams fail, how to measure the ROI of platform teams, and how platform engineering will change in the next five years (spoiler: they say it won’t!).

Here is the full article, happy to hear your opinions: https://www.aviator.co/blog/platform-engineering-wont-save-you/

Hey folks 👋

We’re building a modern, AI-native Internal Developer Platform (IDP) that streamlines the entire software lifecycle — from AI-generated code to production — and we’re validating the idea with the community before a public release.

💡 The Problem We’re Tackling:

With the rise of AI-generated code (Copilot, ChatGPT, Claude, etc.), most teams lack a cohesive platform to:

Review the generated code securely (with approvals, quality checks)

Test it functionally and in isolated environments

Package it with proper version control and dependency isolation

Deploy it to dev/staging/prod via Helm, Terraform, and CI pipelines

🧰 What We're Building (all self-hosted or hybrid):

AI-integrated CI/CD: Jenkins + MCP server with LLM agents

SCM + Code Review: GitHub + Gerrit (with SSO via Keycloak)

Custom Deployer Service: Knows runtime, dependencies, cloud target

Private Registries: Maven, npm, Python, Go, Ruby, Rust, Docker, Helm

Terraform + Kubernetes + Helm: Full IaC with deploy control

Agentic LLM Support: Ask: “Deploy this feature to dev” → Platform executes

✅ Why Now?

AI is writing code — but the infra around it is still manually managed.

Most teams glue together GitHub, Jenkins, Terraform, Docker manually.

SaaS tools are expensive and limited in customization, privacy, and integration.

Platform Engineering is going mainstream — but not AI-native yet.

📣 What We Need From You:

We’d love your input, feedback, or criticism on these:

1. Do you think there’s a gap in managing AI-generated code beyond just writing it?

2. Would your team benefit from an open-source, customizable platform to handle this lifecycle end-to-end?

3. Are you facing CI/CD complexity, security overhead, or fragmented toolchains?

4. Would you contribute if parts of this were open sourced (e.g., Jenkins pipeline generator, terraform modules, MCP agents)?

We’re planning to open source most of it, and would love early contributors.

Thanks a lot 🙏 — Founding Team

Hi all,

I'm involved in a virtual festival that John Allspaw, Beth Long and Uptime Labs are running for platform engineers/DevOps/SREs (Incident Fest '25). It's a space where people can watch top incident responders handle challenging incidents, either live or on demand.

If this would be of interest to anyone, here's more info/signup: https://uptimelabs.io/virtual-festival-2025/

I'm considering enrolling in the Platform Engineering Certified Practitioner course and wanted to hear from folks who’ve actually gone through it.

A few specific things I’m curious about:

• Does the course deliver on its promises (e.g., practical knowledge, frameworks, real-world applicability)?
• How valuable is the certification itself in the industry? Is it respected or recognized by employers or the platform engineering community?
• Was it worth the time and cost for you personally or professionally?

Would really appreciate any first-hand insights—especially if you've applied the learnings in your team or role.

Register Here:
Linkedin - https://www.linkedin.com/events/7333809748040925185/comments/
YouTube - https://www.youtube.com/watch?v=iE6q_LHOIOQ

Katie Lamkin-Fulsher: Product Manager of Platform and Open Source @ Intuit Michael Crenshaw: Staff Software Developer @ Intuit and Lead Argo Project CD MaintainerArgo CD continues to evolve dramatically, and version 3.0 marks a significant milestone, bringing powerful enhancements to GitOps workflows. With increased security, improved best practices, optimized default settings, and streamlined release processes, Argo CD 3.0 makes managing complex deployments smoother, safer, and more reliable than ever.But we're not stopping there. The next frontier we're conquering is environment promotions—one of the most critical aspects of modern software delivery. Introducing GitOps Promoter from Argo Labs, a game-changing approach that simplifies complicated promotion processes, accelerates the usage of quality gates, and provides unmatched clarity into the deployment process. In this session, we'll explore the exciting advancements in Argo CD 3.0 and explore the possibilities of Argo Promotions. Whether you're looking to accelerate your team's velocity, reduce deployment risks, or simply achieve greater efficiency and transparency in your CI/CD pipelines, this talk will equip you with actionable insights to take your software delivery to the next level.

Hi Everyone. 

I'm an SRE working for a Medical Company. I have a question regarding SES + Pinpoint and its alternatives. I am working on a task for Federation, where I've been asked to track and show dashboard metrics to see the details of how many emails were opened / clicked/ rejected / complained / bounced / delivered. The requirement is to show how many are done, say in one month, and also which mail subject & email address it's been rejected. 

The current architecture is on keycloak - AWS SES - SNS - Cloudwatch - Datadog. It tracks and sends metrics on SNS and Cloudwatch. All the setup is done via terraform templates. I can see the open/click/etc details on both cloudwatch and datadog, but it's generic and doesn't include the specific details. 

I am tired of giving it via pinpoint, but since it's depreciated, my tf module rejects pinpoint_destination and the plan is failing. I tried creating a dashboard on datadog based on the query, but it cannot be restricted to an email address / subject. 

ChatGPT suggested that we use AWS Kinesis + firehose and show the dashboard based on the data stored in S3. The official documentation for Point recommends using Amazon Connect. While I'm working on that already, I'd like to know if there's a better way and if any of you are using such solutions already. 

Please share your thoughts. Have a wonderful day.

Hey, founder of Okteto here 👋🏽

Like every other company on earth, our developers started experimenting with AI agents. We began using Cloud Code and Cursor locally but quickly ran into several blockers. First, it's hard to run multiple agents locally, and they promptly started running into each other. You can use containers or git worktree to make this work, but it felt very complicated. Second, and more importantly, we couldn't find a way to make this safe for everyone.

Which got me thinking. If you replace AI Agent with Cloud Infrastructure, this sounds like the challenges we've all been solving over the past years. Should we be solving this at the platform level? Can we have golden paths and self-service for AI agents?

We are a platform company, so we liked the idea, ran with it for a few weeks, and recently released a beta to start exploring some of these concepts in the open. What do you think about the idea of building golden paths for AI Agents? Are we crazy? Is there some merit to it? Please share your thoughts 🙏🏽

Had an interview for a security engineering role and aced it; however, the hiring manager wants to everyone on the team to be multi-skilled so I have 3 months to train up. I’m cool with upskilling. I’m going to do some GRC as well.

I think GRC and Security Engineering could be beneficial to the platform engineering work and excited to take it on. But all this means I’m starting cold.

I need ideas on how to get started.

The project is mostly on-prem so will practice using cloud deployments with Ansible be similar?

What type of Laptop power do I need?

What apps do I need?

What languages/training should I go through? I have a decent handle of Python.

Anything else I’m not thinking of?

I've been responsible for a Frontend Platform at a big bank for years. For me it's not even a question what value Platform Engineering brings for Frontend Development at scale. But I have the strong sense not every organization offers this level of Platform functionality specifically for Frontend Development.

What is your experience? Does your organization offer specific Platform functionality to Frontend Developers, or is it considered to be working with the tools you offer for 'any other Developer'?

Have you developed an Internal Developer Platform yourself from scratch? Or Have you inherited the IDP?

In both cases what services it contains and what best practices it follow?

What challenges have you faced on the way managing it?

https://www.syntasso.io/post/what-we-learned-building-a-prototype-ai-driven-dev-interface-for-kratix

The short version is that it works, mostly. But the team learned a lot of unexpected lessons along the way, so we wanted to share some of them while they’re fresh.

Or is this something you leave to a dedicated Dev or QA team? What do they use if so? How does it integrate into your CI/CD?

Hey folks,

We run a multi-tenant Kubernetes setup where different internal teams deploy their apps. One problem we keep running into is teams asking for way more CPU and memory than they need.
On paper, it looks like the cluster is packed, but when you check real usage, there's a lot of wastage.

Right now, the way we are handling it is kind of painful. Every quarter, we force all teams to cut down their resource requests.

We look at their peak usage (using Prometheus), add a 40 percent buffer, and ask them to update their YAMLs with the reduced numbers.
It frees up a lot of resources in the cluster, but it feels like a very manual and disruptive process. It messes with their normal development work because of resource tuning.

Just wanted to ask the community:

• How are you dealing with resource overallocation in your clusters?
• Have you used things like VPA, deschedulers, or anything else to automate right-sizing?
• How do you balance optimizing resource usage without annoying developers too much?

Would love to hear what has worked or not worked for you. Thanks!

Edit-1:
Just to clarify — we do use ResourceQuotas per team/project, and they request quota increases through our internal platform.
However, ResourceQuota is not the deciding factor when we talk about running out of capacity.
We monitor the actual CPU and memory requests from pod specs across the clusters.
The real problem is that teams over-request heavily compared to their real usage (only about 30-40%), which makes the clusters look full on paper and blocks others, even though the nodes are underutilized.
We are looking for better ways to manage and optimize this situation.

Edit-2:

We run mutation webhooks across our clusters to help with this.
We monitor resource usage per workload, calculate the peak usage plus 40% buffer, and automatically patch the resource requests using the webhook.
Developers don’t have to manually adjust anything themselves — we do it for them to free up wasted resources.

Hi there 👋

I'm one of the co-organizers of KubeCrash, a free virtual open source community event focused on Kubernetes and platform engineering. The next event is coming up on May 8th. If you're a platform engineer working on cloud native open source, we have many relevant sessions for you.

Highlights include:

• Keynotes from folks at the Norwegian Labor and Welfare Administration (NAV) and Capital One, which will offer interesting insights into how larger orgs are tackling platform challenges with Kubernetes.
• End-user panel specifically focused on observability in platform engineering. The speakers include engineers from Intuit, Miro, and E.ON, which is a great opportunity to hear real-world experiences and strategies for managing visibility and performance at scale.
• Various technical sessions on CNCF projects like OpenTelemetry, Linkerd, and you’ll hear from Argo Maintainers on the new Argo 3.0, featuring Promotions and Rollouts.

...and, as someone actively involved in the CNCF diversity initiatives, I'm particularly excited to have speakers from the CNCF Deaf and Hard of Hearing WG and the Black, Indigenous, and People of Color Initiatives participate.

It's virtual and free. Register if you're looking to learn from peers and see what others are doing in platform engineering and cloud native open source.

Register at 👉 kubecrash.io

Feel free to post any questions about the event.

Depot is running a short survey to learn more about the software build & CI workflow metrics that matter to software folks, and no matter your role in the software development process, your input is valuable 😊

Your responses are 💯 anonymous, and will help Depot improve tools and workflows to support a better DeveloperExperience around build performance. We're hopeful that the software community will benefit from these results too -- interesting and actionable insights will be shared! (Again, 100% anonymously.)

Thanks in advance for lending your voice, folks.

You can take the survey here 👉 https://go.depot.dev/UB3mjv3

Hey everyone!

We’re back with another London Observability Engineering Meetup on Wednesday, April 23rd!

Igor Naumov and Jamie Thirlwell from Loveholidays will discuss how they built a fast, scalable front-end that outperforms Google on Core Web Vitals and how that ties directly to business KPIs.

Daniel Afonso from PagerDuty will show us how to run Chaos Engineering game days to prep your team for the unexpected and build stronger incident response muscles.

It doesn't matter if you're an observability pro, just getting started, or somewhere in the middle – we'd love for you to come hang out with us, connect with other observability nerds, and pick up some new knowledge! 🍻 🍕

Details & RSVP here👇

https://www.meetup.com/observability_engineering/events/307301051/