Platforms at your service: How a new group of startups hopes to make it easier to ship software

As the complexity of running a software development team inside a modern enterprise has exploded, an overlooked segment of the cloud computing triangle has enjoyed a resurgence over the last year: The platform is having a moment.

Third-party infrastructure services, such as AWS, and SaaS companies, such as Salesforce, are part of nearly every tech stack these days. But inside most enterprises, platform tools — designed to help software developers build and deploy their applications in a consistent way without making them manage servers — have remained stubbornly proprietary, layers and layers of homegrown shims and workarounds that are groaning under the requirements of modern applications.

While older platform-as-a-service (PaaS) tools like Heroku will always have a special place in the hearts of developers of a certain age, countless companies have tried and failed to build newer platform services that strike the right balance between helping customers abstract infrastructure away from their developers while giving their operations teams the tools they need to make those apps work.

"You have this fine line you have to walk with PaaS, which is, if your platform is not very opinionated and isn't very feature rich, it's too little to be interesting (enough) for people that want to adopt it and use it," said Abby Kearns, former executive director of the Cloud Foundry Foundation, an early open-source PaaS. "And then you get the other end of the spectrum, where it's very feature rich and highly opinionated and does everything for you (but) the onboarding and the ramp time is really high."

But a new group of companies is strolling down that line with newer technologies and fresh approaches that focus on developer experience as enterprises grapple with the rise of complicated app deployment technologies like containers and Kubernetes. Those companies — which include Deno, Fermyon, Fly.io, Porter, Railway, Render, and Vercel, among others — are gaining converts by giving both developers and operations teams the Goldilocks amount of options they need to make this complex system work.

"The trick to being successful the next time around is going to be, can we draw the right line between what is developer responsibility and what is platform engineering responsibility?" said Matt Butcher, CEO of Fermyon.

Rate limited

Trends drive far more enterprise tech activity than you might think.

"PaaS is really interesting, because you've got the consistent developer self-service story, which is the real goal of PaaS, but you've got sort of the shifting milieu of the popular programming languages, the popular frameworks, the popular infrastructure layers," said Butcher, who founded Fermyon around the idea of building platform services around WebAssembly, an interesting binary format for cloud applications that is also having a moment.

Around the time cloud services were just getting up and running at the end of the 2000s, Ruby on Rails was one of the most widely used frameworks for web application development and Heroku rose to prominence as a platform that helped developers build and deploy their Rails apps. But after it was acquired by Salesforce in 2011, Heroku was slow to anticipate and adjust to the rise of containers popularized by Docker, and the later adoption of Kubernetes as a management tool for container-based apps.

As containers became the "cloud native" standard for development, IT organizations needed something to help their developers work around the complexity of this new operations environment. As noted, they had trouble finding a product on the market that solved those issues and resorted to building their own internal platform services.

In the eternal "build versus buy" debate that takes place every day inside enterprise tech shops, those arguing for building often cite their unique business or application requirements that one-size-fits-all products can't address. While that may be true, that flexibility comes at a cost; once you build it, you have to maintain it, and even medium-size enterprises can find themselves managing multiple platform approaches across the entire company.

"One could argue that building your own cloud every time you have an application requirement was almost like a zero-interest rate phenomenon," said Guillermo Rauch, founder and CEO of Vercel. As we all know, those days are over, but companies will still need to build and ship software quickly and safely no matter what economic conditions take hold over the next year.

New memory-safe programming languages, such as Go and Rust, are also gaining traction inside enterprise software teams, supplanting older but still widely used tools like Ruby and JavaScript. That means new platforms have to support the future of software development without forcing customers to rewrite all the software that currently runs the world, introducing a new set of tradeoffs: Between highly opinionated platforms that support only a few languages but abstract a lot of complexity, and lightly opinionated platforms that support a lot of languages but require the user to deal with that complexity.

Throw in the increasing use of multicloud environments, and it becomes clear why both older platforms and homegrown approaches fell short, Kearns said.

"It is more complex to build and run an environment today than it was 10 years ago," she said. "The number of tools and technologies, either open source or off the shelf, that you have to master and integrate together is way more substantive than it was 10 years ago."

Pieces of the puzzle

That complexity has led enterprises to invest in "platform engineering," a discipline that calls for the creation of an internal team to standardize platform tools and get developers across a company on the same page, according to Gartner. "The goal is a frictionless, self-service developer experience that offers the right capabilities to enable developers and others to produce valuable software with as little overhead as possible," said analyst Paul Delory in a recent article.

However, it's not clear that smaller organizations will be able to build and maintain teams to provide internal services for their developers that can keep up with changes in software development. Cloud providers and companies like Red Hat have tried to fill the gaps with their own managed services based around containers and Kubernetes, but those tend to fall more heavily on the "opinionated" side of the PaaS ledger, and therefore tend to work best for companies that are already using other services offered by those vendors.

The newer generation of third-party platform tools and services look to meet customers where they are, allowing users to work with whatever programming language they prefer and deploy to whatever environment they choose.

Vercel, for example, was built around the idea of allowing front-end developers — who are primarily concerned with creating and maintaining the look and feel of a web app — to mix and match components that worked with whatever their companies were already running on the back end of their production systems, Rauch said.

"In this day and age, you have to integrate with everything that's out there," he said. "You can't come into an enterprise organization and say, 'we're going to ditch your authentication solution, we're going to ditch your commerce back end.'"

Speed is also a common thread throughout many of the new approaches. Fly.io's goal is to offer a developer-friendly way to deploy distributed applications that run on servers located closer to end users, which improves performance. Railway is trying to reduce the amount of time it takes to launch a new database without forcing developers to learn how to operate cloud infrastructure or Kubernetes.

And the new class of platform services bill themselves as much easier to use than older approaches. The rush to embrace Kubernetes was a boon for operations teams that suddenly had far more powerful tools at their disposal to make sure their applications ran reliably at scale, but it passed too much work onto developers, who had to learn specialized languages like YAML or understand cloud operating environments to deploy their apps, Butcher said.

The newer approaches are built around slick user interfaces and click-to-deploy workflows, which flattens the onboarding time needed to learn a new system, Kearns said.

"I get excited about any tool these days that really democratizes access," she said. "If I've got a team of developers, and I'm an enterprise, I am struggling with a lack of skills. Just because I have the headcount doesn't mean I have people that are intimately familiar with writing cloud-native applications and running them."

Companies have been talking about adopting DevOps strategies for years in hopes of making their teams more productive, Butcher said, and a new generation of platform tools might actually help them attain that goal.

"I think the trick to the next generation of PaaS is going to be, OK, if we're going to do it well, we have to understand what a platform engineering and DevOps role is and what they need to do day to day, and what the developers need to do,” he said, “then try and minimize the friction that they encounter when they're working together."