Developers are questioning the future of platform as a service (PaaS)—and for good reason. Many of them have built successful products on PaaS, but when their app gets to a certain scale, they find themselves needing more. They can’t easily debug performance issues due to a lack of transparency and opinionated black box features. They can’t implement fully-configurable security and compliance controls like a web application firewall. They’re stuck with whatever limited add-ons the platform offers, if they’re even offered at all. Features like persistent storage, configurable load balancing and auto-scaling are either non-existent or too limited for real-world use on PaaS. So what do developers do? They port their apps over to infrastructure as a service (IaaS). It’s not that IaaS is better, but that it has no implementation limits. Devs can build anything they want with IaaS providers. The trade-off is one of time, expertise, and additional staffing. But that’s okay for most developers with successful PaaS apps because they’ve already gotten through the hard part of building something and finding product market fit. They’re not as worried about the learning curve of migrating to IaaS because by that point, they have a user base, revenue, and runway. It’s likely devs wouldn’t port their apps to IaaS if was a viable option at scale. But does that mean PaaS should be written off as inferior to IaaS? Hardly. The future of PaaS is bright—much brighter than many developers recognize. In fact, I believe PaaS will dominate the future of software development. The market is hungry for a “great to start, great to scale” platform to emerge and leapfrog today’s developer experience and value. PaaS will absolutely support globally-scalable app delivery, but it’ll have to overcome some challenges first. PaaS IaaS is great until it isn’t The beauty of IaaS is that it offers near-infinite configuration and scalability options. IaaS providers have generalized their products enough to support practically any use case at any scale. It’s incredibly powerful and cost-effective. Plus, IaaS providers are happy to give usage credits and discounted pricing to drive adoption and get teams hooked. However, it can be incredibly difficult to build scalable configurations without shooting yourself in the foot. Incorrect configuration changes can have catastrophic results that are nearly impossible to troubleshoot and remediate without deep infrastructure expertise. There’s practically no platform support available (outside of costly enterprise engagements) and IaaS documentation is notoriously inconsistent and difficult to read. And don’t even get me started on the actual user experience of IaaS consoles. Going all in on IaaS means building expensive infrastructure teams to use and manage IaaS. Not only are infrastructure experts some of the most in-demand people in the industry, it’s extremely difficult to find the right people who know how to get through unique growth needs. Adding to these complications are the realities of a tighter fundraising environment, teams being told to “do more with less,” and the rapidly increasing complexity of IaaS solutions. The work of the team is to set up and maintain the infrastructure as it grows—and the job is never “finished.” The typical journey companies go through with IaaS looks like this: Hire 1-2 expert back end or infrastructure engineers to determine and implement the architecture. Grow the team, experience some turnover, and the architecture changes organically. The team now maintaining the infrastructure is no longer the team that built it in the first place. When something breaks, it’s a nightmare to fix. No one remembers why decisions were made, tribal knowledge is gone, and what was working months ago is now “legacy” because no one understands it. Between funding issues and lack of available infrastructure talent, it’s hard to recommend deepening investment in infrastructure and platform work. IaaS features and capabilities are growing increasingly complex, further justifying the need for higher-level abstractions, just like the ones provided by PaaS. IaaS wishes they could do PaaS IaaS providers know this, which is why they’re making investments in PaaS-like abstractions. Google’s doing a pretty good job at this with their Cloud Platform and , their mobile development platform. Amazon has been trying to build abstractions, but their developer experience is… not good. Nevertheless, it’s clear they understand that developers want (and deserve) better experiences, like and . Azure now offers , which allows for simplified deployment on auto-scaling infrastructure. Firebase auto-encryption of S3 objects RDS integration with AWS Secrets Manager App Service The major cloud providers are getting better at PaaS-like offerings, but they’re also focused on legacy lift-and-shift strategies or sci-fi “serverless Kubernetes” fantasies. They make most of their cash from enterprises, which biases their feature development to serve more enterprises. Startups and mid-size companies are left crossing their fingers hoping their feedback leads to easier-to-use and easier-to-build PaaS-like environments that don’t require advanced infrastructure expertise to fully utilize. Raman Sharma that “at least two major hyper-scale cloud providers (Azure and GCP) started their cloud journey with PaaS products, only to quickly realize that real money (and loads and loads of muscle and institutional memory) was still in infrastructure. So, they pivoted to being IaaS-centric (like AWS was at the time).” astutely observed In other words, IaaS would be doing PaaS if IaaS wasn’t so lucrative. They’re not serving startups, they’re serving enterprises. IaaS is not a competitive advantage, it’s a distraction Building in IaaS does offer plenty of freedom and opportunity, but would you rather spend $150K on an AWS-certified admin or $150K on a developer who can build revenue-generating features? If you don't have to worry about infrastructure, hiring the developer is a no-brainer. Unfortunately, it’s not uncommon for companies to get the worst of both worlds: they hire the $150K developer and force them to also do all the DevOps work. That’s much less bang for the buck. There’s really no competitive advantage for product teams that move from PaaS to IaaS, nor for those who start on IaaS and scale up. At some point, it will inevitably require hiring an expensive and experienced cloud infrastructure architect. Of course, I have nothing against skilled cloud infrastructure engineers, but when I’m facing increasing financial pressure to “do more with less,” I’m not very excited about increasing my overhead. Besides, even if I had the world’s greatest cloud infrastructure team and even if it wasn’t as costly as I hypothetically fear, what is the competitive advantage of having that team? What advantage does that really offer any business? If I’m being honest, I’d much rather have a lean team of value-generating devs than value-protecting admins. Yes, I can spend the time and energy on IaaS to get persistent disks, point-in-time recovery on my databases, configurable load balancing, blue/green deployment logic, and auto-scaling, but I guarantee most developers would rather have all that available with a checkbox in a nicely-designed UI. The more time I have to focus on keeping the lights on, the less time I’m spending on delivering great features to customers who want to spend money on my products. More infrastructure, less value. PaaS solves the problems of IaaS The main reason PaaS exists in the first place is because IaaS is too complicated. Developers want to write and deploy code. They want to build new apps and features, see how the market responds, and iterate. And they want to do this with the fewest hurdles possible. For example, if I need HIPAA-compliant infrastructure to build a healthcare-focused SaaS, I can either start with , which is incomplete and complex, and spend weeks getting it up and running. Or, I can spin up an app on Aptible in minutes and know it’s HIPAA-compliant. Amazon’s reference architecture The same goes for PCI compliance. Stack Overflow and Reddit are filled with examples and warnings of the uphill battle for establishing and maintaining PCI-compliant infrastructure in any of the big IaaS clouds. Or, you could find a PCI-compliant PaaS and spend zero time on firewall configuration. Here’s the thing: no one is choosing to start with complex infrastructure architecture and implementation. They just don’t have many options or they’re not aware of the existing choices. Any developer or product leader would choose PaaS if it was cost-effective and capable of serving long-term scaling needs. PaaS doesn’t have a problem of cost effectiveness, but of painting itself into the corner with its long-term ability to support growing businesses. If that weren’t the case, PaaS would be a no-brainer for starting and scaling apps. This raises the question: who wouldn’t pay some sustainable amount of extra money to have everything “just work,” excellent documentation, and built-in support? PaaS needs to solve its own problems IaaS has done a great job at offering a generalized solution that works in any use case. PaaS hasn’t gotten there yet. There are too many smaller missing features and obfuscations that cause teams to move off of PaaS. There’s no single PaaS that can support every app a company needs to run, and that’s a non-trivial problem. Furthermore, application development patterns have also evolved since PaaS began to flourish in 2010. Heroku and its ilk just haven’t kept up. Here are some of the common engineering team “jobs to be done” that are essential to business, but aren’t being covered by PaaS: Object storage Event-driven compute (“serverless”) Data warehousing NoSQL and graph databases Event databases Search databases The needs are clearly diverse. The PaaS world has done a great job with specialized platforms that clearly position themselves as best-in-class at a single task, but the world needs a PaaS that can support a collection of business-enabling features. PaaS needs to support more diverse application architectures PaaS apps tend to be monolithic so as to take advantage of the various capabilities of the underlying infrastructure platform. However, growing products are likely to eventually need to split into a set of dependent microservices. Right now, devs have to go through contortions to keep a microservice architecture working correctly on PaaS. They need constructs like service discovery and direct container connectivity to function efficiently. Those are hard to find as native capabilities in the PaaS world. There’s a problematic dynamic that appears when apps become more complex than the PaaS can understand. It’s a big reason for developers to move to IaaS. If a PaaS can’t support a data warehouse, then there are few reasons to keep anything else deployed on the PaaS. IaaS users yearn for PaaS-like abstractions Once a company moves from PaaS to IaaS, paradoxically they’ll yearn for the things that make PaaS great: reduced complexity, a great developer experience, excellent documentation, and predictable costs. Read any “State of DevOps” reports today and you’ll hear about the “platform engineering” movement and its philosophical foundations. But companies shouldn’t need to reinvent the platform. It’s a major cost to productivity. Creating and evolving a top-notch developer experience is enough work to become a line of business unto itself. Building abstractions over IaaS will likely have little-to-no ROI for companies outside the Fortune 50 (much less for their customers and shareholders). It’s a nonsensical business proposition. PaaS has lots of room to grow—and we’re bullish PaaS solves a lot of the problems of IaaS: Infrastructure is a distraction, not a competitive advantage Companies and product teams are happy to pay to have their big problems solved (or outsourced to a platform) Performance, growth, and scale shouldn’t necessitate the stress of building, running, and maintaining We see an opportunity for a general-purpose SaaS that doesn’t paint developers into a corner and we are excited. We’re taking what we've already built—the best and only non-Heroku PaaS that scales to meet enterprise needs—and making it easier and more accessible to start building apps. Here’s how we’re expecting the market to respond (and how we’re approaching it ourselves): Autoscaling and simple pricing: Outside of Heroku, it’s difficult to set constraints around PaaS scaling and costs. This is the first and most important area for PaaS providers to tackle. Developer experience and first-time user experience: PaaS providers are going to focus on helping devs to quickly build and grow their apps. This is where most of the innovation has been to date–efforts to recapture the feeling of magic provided by Heroku. Support modern, higher-level developer abstractions: Support 3rd-party serverless infrastructure solutions, operational analytics, AI, supply chain security, and decentralized software. Deliver on modern use cases: Allow companies to complete engineering-adjacent tasks like static websites, object storage, etc. As AWS and other IaaS providers add more and more services to their console, we have to expect more complexity. A growing number of IaaS customers will end up relying on what will soon be legacy cloud architectures and development paradigms. These companies will inevitably seek a PaaS to break free, or even to simply avoid the complexities and frustrations of dealing with utility IaaS. I’ll close by bringing special attention to developers in smaller, relatively independent teams within larger companies. The "you build it, you run it" movement will likely be a driver for increased PaaS adoption. In fact, it’s already becoming “you build it, you run it, you secure it.” As dev teams become more responsible for their infrastructure, they’ll be responsible for their own DevOps. There’s only so much they’ll be able to manage, so PaaS will be more than appealing. PaaS will become a necessity. People may be bearish on PaaS today, but the day is coming when these teams demand a true enterprise-grade Heroku competitor. A platform is going to blaze that trail and it will catch on faster than Heroku ever did. In 2023, Aptible will show that it is that platform.
