Skip to content

Awesome Platform Engineering Tools Awesome

A curated list of Platform and Production Engineering tools - Maintained by Saif Rajhi

Contents

image

Articles and Presentations and Books

Newsletters, Chats and Podcasts

Specifications

  • OAM: One Application Model - An open model for defining cloud native apps.
  • Argonaut - Deploy apps and infrastructure on your cloud in minutes.
  • devtron - An open source Internal Developer Platform for Kubernetes.
  • SaaS Backstage Roadie - SaaS Backstage. Simple, safe, and more powerful.
  • ZYMR - We excell at Platform engineering.
  • CTO: platform for platform teams - The platform for platform teams : Easily implement your vision for the perfect developer platform without having to build everything from scratch. We’re more than just a CI/CD pipeline. We’re an intelligent automation platform for all of your development workflows.
  • score - One easy way to configure all your workload. Everywhere.
  • kubevela - Make shipping applications more enjoyable.
  • kusionstack - Open Tech Stack to build self-service, collaborative, reliable and sustainable Internal Developer Platform.
  • Cloud Native Operational Excellence (CNOE) - CNOE will enable organizations to navigate tooling sprawl and technology churn by coordinating contributions, offering tools, and providing neutral guidance on technology choices to deliver IDPs.
  • OpenGitOps - OpenGitOps is a set of open-source standards, best practices, and community-focused education to help organizations adopt a structured, standardized approach to implementing GitOps.
  • Open Platform for Enterprise AI - An ecosystem orchestration framework to integrate performant GenAI technologies & workflows leading to quicker GenAI adoption and business value.
  • karpor: Intelligence for Kubernetes. - World's most promising Kubernetes visualization Tool for developer and platform engineering teams.

Reference Architecture

AI powered platform tools

Development

Source Code Management

Feature flags and change management

Project Management & Issue Tracking Software

Bug / Defect Tracking Software

Code Editors and IDEs

Continuous Testing

Continuous Integration

Build

Integration

Continuous Delivery

Deployment

Automation and Collaboration

  • Digger - Infrastructure as code management platform that enables you to run OpenTofu & Terraform in your CI/CD system.
  • Atlantis — Open Source Terraform Pull Request Automation tool.
  • Env0 — Automate and Manage IaC at Scale, With Confidence
  • Spacelift — Spacelift is a sophisticated CI/CD platform for OpenTofu, Terraform, Terragrunt, CloudFormation, Pulumi, Kubernetes, and Ansible.
  • Terramate — Terramate adds powerful capabilities such as code generation, stacks, orchestration, change detection, data sharing and more to Terraform.
  • Terrateam — Infrastructure as Code CI/CD for GitHub
  • OTF — An open source alternative to terraform enterprise.
  • Hatchet — An all-in-one platform to automate, secure and monitor Terraform
  • GitHub Actions - Automate, customize, and execute your software development workflows right in your repository
  • Runme - Infrastructure Notebooks Built with Markdown. Runme is a free tool that enables Markdown files to become runnable notebooks. You can use scripts in Shell, Perl, Python, and more.
  • Earthly - A versatile, approachable CI/CD framework that runs every pipeline inside containers, giving you repeatable builds that you write once and run anywhere.

Infrastructure orchestration

Container

Container Registry

Container Orchestration

Continuous Monitoring

Incident Management / Incident Response / IT Alerting / On-Call

IT Service Management

Incident Communication

Security

Internal Developer Portal

  • Port
  • Backstage Software Catalog
  • OpsLevel
  • KusionStack
  • KubeStack
  • Radius app - Open-source, cloud-native, application platform that enables developers and the operators that support them to define, deploy, and collaborate on cloud-native applications across public clouds and private infrastructure.
  • Mia platform - Don’t waste time setting up your platform, just push the code!.
  • Humanitec - Powering your Internal Developer Platform.
  • Appvia - Increase Developer productivity with self-service.
  • qovery - Deliver Self-Service Infrastructure Faster.
  • Mogenius - The Kubernetes Operations Platform.
  • Nullstone - An easy-to-use developer platform that enables developers to quickly deploy any application.
  • Kratix - A framework for building Platform-as-a-Product.
  • cycloid - Platform Engineering is DevOps with an action plan.
  • Shipa - Shipa simplifies the way you deploy, secure, and manage applications across cloud native infrastructures by taking an application-centric approach.
  • Upbound - The platform for platform teams.
  • Kubero - A fully self-hosted Internal Developer Platform (IDP).
  • Roadie Internal Developer Portal - SaaS-based Internal Developer Portal.

Path to senior platform engineer handbook

Platform Engineering serves as a distinct and valuable career path within an organization, complementing roles like DevOps and Site Reliability Engineering (SRE). While DevOps and SRE ensure smooth software development processes and reliable, scalable infrastructure respectively, Platform Engineers are entrusted with the unique responsibility of crafting the tools, processes, and platforms on which software development and operational tasks occur

Platform Engineering Career pathing

image

image

Platform Engineering Roles Summary

Junior Platform Engineer:
Handles routine tasks, troubleshooting, cloud configurations, and code reviews.
Skills: Basic scripting, cloud tech, containerization, Golang, Kubernetes.

Platform Engineer:
Implements features, security, system scaling, and CI/CD tools.
Skills: Advanced cloud platforms, containerization, CI/CD, scripting, Golang, Kubernetes.

Senior Platform Engineer:
Designs architecture, mentors, manages projects, ensures security.
Skills: System architecture, cloud computing, containerization, CI/CD, Golang, Kubernetes.

Lead Platform Engineer:
Leads team, manages projects, strategic decisions, stakeholder interaction.
Skills: Systems design, project management, various tech stacks, Golang, Kubernetes.

Staff Platform Engineer:
Sets technical direction, standards, leads projects, guides cloud services.
Skills: Multiple tech stacks, system design, performance, security, Golang, Kubernetes.

Principal Platform Engineer:
Technical leader, sets vision, strategy, engineering processes, cloud strategy.
Skills: Broad tech expertise, strategic planning, complex engineering processes, Golang, Kubernetes.

Platform Engineering Manager:
Oversees teams, strategic direction, performance, budgeting, alignment with business.
Skills: Technical background, budgeting, talent development, Golang, Kubernetes.

Senior Manager, Platform Engineering:
Sets organization-wide strategy, manages teams, cross-team collaboration, cloud strategy.
Skills: Broad tech knowledge, business understanding, engineering management, Golang, Kubernetes.

Director of Platform Engineering:
Sets vision, plans execution, tech decisions, team structure, budget management, strategic planning.
Skills: Vision setting, strategic planning, cloud strategy, Golang, Kubernetes.

Notions and concepts

Fundamentals

  • Keep it simple, stupid. You ain't gonna need it.

  • You should think about what to do before you do it.

  • You should try to talk about what you’re planning to do before you do it.

  • You should think about what you did after you did it.

  • Be prepared to throw away something you’ve done in order to do something different.

  • Always look for better ways of doing things.

  • “Good enough” isn’t good enough.

Code

  • Code is a liability, not an asset. Aim to have as little of it as possible.

  • Build programs out of pure functions. This saves you from spending your brain power on tracking side effects, mutated state and actions at a distance.

  • Use a programming language with a rich type system that lets you describe the parts of your code and checks your program at compile time.

  • The expressivity of a programming language matters hugely. It’s not just a convenience to save keypresses, it directly influences the way in which you write code.

  • Choose a programming language that has a good module system, and use it. Be explicit about the public interface of a module, and ensure its interals don't leak out to client code.

  • Code is a living construct that is never “done”. You need to tend it like a garden, always improving and tidying it, or it withers and dies.

  • Have the same high standards for all the code you write, from little scripts to the inner loop of your critical system.

  • Write code that is exception safe and resource safe, always, even in contexts where you think it won’t matter. The code you wrote in a little ad-hoc script will inevitably find its way into more critical or long-running code.

  • Use the same language for the little tools and scripts in your system too. There are few good reasons to drop down into bash or Python scripts, and some considerable disadvantages.

  • In code, even the smallest details matter. This includes whitespace and layout!

Design

  • Modelling - the act of creating models of the world - is a crucial skill, and one that’s been undervalued in recent years.

  • Model your domain using types.

  • Model your domain first, using data types and function signatures, pick implementation technologies and physical architecture later.

  • Implement functionality in vertical slices that span your whole system, and iterate to grow the system.

  • Resist the temptation to use your main domain types to describe interfaces or messages exchanged by your system. Use separate types for these, even if it entails some duplication, as these types will evolve differently over time.

  • Prefer immutability always. This applies to data storage as well as in-memory data structures.

  • When building programs that perform actions, model the actions as data, then write an interpreter that performs them. This makes your code much easier to test, monitor, debug, and refactor.

  • Dependency management is crucial, so do it from day one. The payoff for this mostly comes when your system is bigger, but it’s not expensive to do from the beginning and it saves massive problems later.

  • Avoid circular dependencies, always.

Designing systems

  • A better system is often a smaller, simpler system.

  • To design healthy systems, divide and conquer. Split the problem into smaller parts.

  • Divide and conquer works recursively: divide the system into a hierarchy of simpler sub-systems and components.

  • Corollary: When designing a system, there are more choices than a monolith vs. a thousand “microservices”.

  • The interface between parts is crucial. Aim for interfaces that are as small and simple as possible.

  • Data dependencies are insidious. Take particular care to manage the coupling introduced by such dependencies.

  • Plan to evolve data definitions over time, as they will inevitably change.

  • Asynchronous interfaces can be useful to remove temporal coupling between parts.

  • Every inter-process boundary incurs a great cost, losing type safety, and making it much harder to reason about failures. Only introduce such boundaries where absolutely necessary and where the benefits outweigh the cost.

  • Being able to tell what your system is doing is crucial, so make sure it’s observable.

  • Telling what your system has done in the past is even more crucial, so make sure it’s auditable.

  • A modern programming language is the most expressive tool we have for describing all aspects of a system.

  • This means: write configuration as code, unless it absolutely, definitely has to change at runtime.

  • Also, write the specification of the system as executable code.

  • And, use code to describe the infrastructure of your system, in the same language as the rest of the code. Write code that interprets the description of your system to provision actual physical infrastructure.

  • At the risk of repeating myself: everything is code.

  • Corollary: if you’re writing JSON or YAML by hand, you’re doing it wrong. These are formats for the machines, not for humans to produce and consume. (Don’t despair though: most people do this, I do too, so you’re not alone! Let's just try to aim for something better).

  • The physical manifestation of your system (e.g. choices of storage, messaging, RPC technology, packaging and scheduling etc) should usually be an implementation detail, not the main aspect of the system that the rest is built around.

  • It should be easy to change the underlying technologies (e.g. for data storage, messaging, execution environment) used by a component in your system, this should not affect large parts of your code base.

  • You should have at least two physical manifestations of your system: a fully integrated in-memory one for testing, and the real physical deployment. They should be functionally equivalent.

  • You should be able to run a local version of your system on a developer’s computer with a single command. With the capacity of modern computers, there is absolutely no rational reason why this isn’t feasible, even for big, complex systems.

  • There is a running theme here: separate the description of what a system does from how it does it. This is probably the single most important consideration when creating a system.

Building systems

  • For a new system, get a walking skeleton deployed to production as soon as possible.

  • Your master branch should always be deployable to production.

  • Use feature branches if you like. Modern version control tools make merging easy enough that it’s not a problem to let these be long-lived in some cases.

  • Ideally, deploy automatically to production on every update to master. If that’s not feasible, it should be a one-click action to perform the deployment.

  • Maintain a separate environment for situations when you find it useful to test code separately from production. Avoid more than one such extra environment, as this introduces overheads and cost.

  • Prefer feature flags and similar mechanisms to control what's enabled in production over separate test/staging environments and manual promotion of releases.

  • Get in the habit of deploying from master to production from the very beginning of a project. Doing this shapes both your system and how you work with it for the better.

  • In fact, follow all these practices from the very beginning of a new system. Retrofitting them later is much, much harder.

Technology

  • Beware of hyped or fashionable technologies. The fundamentals of computer science and engineering don’t change much over time.

  • Keep up with latest developments in technology to see how they can help you, but be realistic about what they can do.

  • Choose your data storage backend according to the shape of data, types of queries needed, patterns of writes vs. reads, performance requirements, and more. Every use case is different.

  • That said, PostgreSQL should be your default and you should only pick something else if you have a good reason.

Stargazers over time

Stargazers over time

Licence

Shield: CC BY 4.0

This work is licensed under a Creative Commons Attribution 4.0 International License.

CC BY 4.0

Back to Top