New greener region discount. Save 3% on Upsun resource usage. Learn how.
LoginFree trial
FeaturesPricingBlogAbout us

Platform engineering vs the Upsun Platform-as-a-Service

kubernetesPaaSplatform engineering
21 March 2024
Ori Pekelman
Ori Pekelman
Chief Strategy Officer

Platform engineering aims to streamline software development and deployment processes by providing a standardized system with guardrails and control mechanisms. However, it's a costly endeavor, with experts projecting platform engineering to consume a significant portion of IT budgets into the future. Upsun offers a managed PaaS solution, advocating for its benefits in simplifying infrastructure complexities and accelerating development processes.

What is platform engineering?

Like every new moniker—and this one is barely a year old— it takes time for the dust to settle and for a common definition to emerge. But for platform engineering, we can go straight to the source with a definition from Gartner, Inc. VP Analyst Paul Delory in their 2023 What is Platform Engineering? article: 

“Platform engineering emerged in response to the increasing complexity of modern software architectures. Today, non-expert end users are often asked to operate an assembly of complicated arcane services. To help end users, and reduce friction for the valuable work they do, forward-thinking companies have begun to build operating platforms that sit between the end user and the backing services on which they rely.”

The industry figured out that banging together a few dozen services with a huge impedance mismatch between them and no actual plan leads to chaos. Organizations now want to define some common ground rules.  I’ve shared in previous blog posts about the cycles of chaos and creativity vs standardization and control—see Chapter 1: Upsun and the decades of the web. Platform engineering welcomes a new cycle of IT urbanization. 

As a practice, platform engineering means your organization can define how you develop and deploy, and allows you to wrap up this process into one robust system: 

  • A system that has guardrails.
  • A system that allows for control.
  • A system that reduces the number of choices for developers so they can focus on creating actual value.

More importantly, the idea of platform engineering is that you wrap up the whole system, not only the code but the organization that produces it—from product managers to support staff. This means multiple operational loops that overlap—from code quality to operational excellence. 

In a way, platform engineering is DevOps assuming control. Previously, the assumption would have been that software engineers design a complex system with potentially dozens of services in interaction (internal, underlying, and external). Now, DevOps practitioners are responsible for mechanizing all of that. Automate provisioning, build, deployments, scaling, and security response. DevOps practitioners should also add continuous improvement mechanics (where everything is measured and kept up-to-date) while accepting changes to the underlying system design—agility from end to end. 

The contrast between what Gartner has said about platform engineering today—as quoted above—and what they said about DevOps in their 2015 press release, Gartner Says by 2016, DevOps will Evolve From a Niche to a Mainstream Strategy Employed by 25 Percent of Global 2000 Organizations, is striking: 

“Organizations with agile development will be slower to embrace DevOps across the entire application life cycle. Cultural resistance and low levels of process discipline will create significant failure rates for DevOps initiatives, particularly when waterfall processes are still a dominant portion of the development portfolio. Nevertheless, a majority of enterprises attempting to scale agile over the next five years will recognize the need for DevOps initiatives.”

At the time, Gartner was right. It had all sprawled out of control. We want to go back to a semblance of order. From the sprawling mess, we define the main patterns. We create a system that can replicate those. And we now tell engineering, “This is your playground, these are your rules.” It has to be automated first. But unlike previous moments of control, the end product wants to be self-service

Platform engineering proposes a tradeoff. Mechanics and guardrails are a common layer for all engineering efforts. If you stay within those, you don’t need to ask Ops anything. 

Engineering a platform is a big undertaking

I believe platform engineering emerged because of Kubernetes (K8S)—from people mistaking its role in the stack. K8S replaced Linux, the operating system (or at least part of it), but it wasn’t the platform people believed it was. They believed it would be enough to create a Helm chart and things would be fully automated down the line. But K8S never had the semantics for this. It wasn’t built to be a platform. It was built to be a runtime. And because the exposed runtime concepts are low-level and complex, you still need more tooling and processes around it. People want a platform.

Engineering a platform is expensive

According to their 2023 What is Platform Engineering? article, Gartner, Inc. expects that by 2026, “80% of large software engineering organizations will establish platform engineering teams as internal providers of reusable services, components, and tools for application delivery.” Platform engineering will ultimately solve the central problem of cooperation between software developers and operators. But it comes with risks:

  1. You have to make some big bets early on. As a unified system, the base will have difficulty changing and evolving. Anyone with 100% Java in their organization for a decade knows the pain.
  2. You must hire some expensive, rare talent to build a platform that can measure up to the best on the market.
  3. If you can’t make a large enough platform, the tradeoffs you expose to app engineers might not be acceptable. Maybe they do need that shiny new runtime. Maybe it is 3x faster.
  4. Once you start, you’ll probably never be able to divest. If the platform is not kept going forward, the whole system will screech to a halt. If budgets become tight, application development will have to be sacrificed.

Upsun: Platform-engineering-as-a-Service?

At Upsun, we believe platform engineering is not only useful but that the requirements for almost all organizations and workloads vary little. There will be trade-offs but not of the magnitude that DevOps practitioners imagine.

Upsun is a single, fully managed, self-service PaaS, which frees development teams to securely and easily experiment, quickly iterate, and confidently deploy applications at scale. 

We provide a platform that eliminates the complexity of the infrastructure and thereby enables developers to focus on code. They bring their code, we manage the rest. They are less dependent on IT to provide them with a development environment. Their time is not wasted on manual, low-value repetitive tasks. Instead, they can accelerate innovation and time to market.

We provide a platform with which you: 
Have a standardization of languages and services across all environments on a single platform

  • Can deploy anytime with confidence because teams know they've tested and previewed work with an exact copy of production
  • Scale effortlessly from one web application to 1,000+
  • Get up and running quickly with a PaaS that can grow as applications, sites, and teams evolve
  • Monitor all critical applications and infrastructure across the organization
  • Provide consistent security and privacy without service interruption

In the end, it’s about composable cloud infrastructure. Platform engineering is basically, “PaaS is dead, long live just the P.” The idea was great, but you can’t get this as a service. So you need to build one. Which will be true, sometimes. We’re sharing that you need to figure out within your own use case whether you need to build your own platform, or whether you can use one (hey, like us) as a service—one that already comes with operational maturity.

Upsun Logo
Join the community