At Aptible, we’re creating the No Infrastructure future. If we have our way, every developer will be able to provision and manage scalable and reliable apps and databases without becoming an infrastructure expert, earning a special certification from AWS, or getting their Ph.D. in Kubernetes.

As outdoor enthusiasts, we're also committed to protecting the environment.

This Earth Day, we're combining our mission with our love for nature. For every developer who signs up and deploys an app on Aptible, we'll plant 25 trees 🌳.

Experience Aptible's platform and contribute to a greener world.

Eden Reforestation Projects

 to plant trees from April 21st to May 22nd, 2023. Sign up below with your work email—no credit card required. Let's make an impact, one tree at a time.

BlogCTA

🌳 Plant 25 Trees for Earth Day 2023

In honor of Earth Day, Aptible is planting 25 trees for every developer who signs up and deploys an app on Aptible. Let’s grow a forest together. 🌲🌳🌲

Deploy the Trees 🌲

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 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 PaaS 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.

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:

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 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 

, which allows for simplified deployment on auto-scaling infrastructure.

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.

 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).”

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.

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.

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?

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: 

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.

TweetEmbed

PaaS has lots of room to grow—and we’re bullish

PaaS solves a lot of the problems of IaaS:

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):

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.

Aptible is the No Infrastructure PaaS

Learn why developers are questioning the future of PaaS and why PaaS will dominate the future of software development, despite the current limitations.

Return of the PaaS

Aptible has a new look. But more importantly, we want to talk about the future of platform as a service, and how we intend to rapidly expand the value our platform delivers to you. Also, it’s the Aptible platform’s birthday!

You might’ve noticed a few changes on aptible.com, in our docs, and in our product. Our visual design, how we talk about ourselves, our pricing page, and the product dashboard. What’s going on you ask?

Aptible has been fortunate to experience steady growth in our user base for the last 10 years, thanks primarily to the resilience and growth of our customers. Today marks the Aptible platform’s 9th official birthday. It also marks the beginning of the future for Aptible.

We’re proud of how far we’ve come since the platform launched on March 21, 2014. But there’s so much more ground to cover if we’re going to achieve our vision of making it possible for any developer and company to launch and scale products without building and managing infrastructure.

Over the years we’ve gotten countless suggestions and ideas on how to improve our PaaS. The most useful source of feedback has been the hundreds of calls we’ve had with existing customers, and the many we’ve had with prospective customers as well. We intend to continue these discovery processes and, in fact, we intend to accelerate our pace of learning further.

Today’s changes are just a step in that direction. While we plan to rapidly expand the value our product provides to customers, and to iterate quickly, what we are “soft launching” today is just the first in a long line of changes we anticipate making. All with the same end goal in mind: continually improving how we eliminate the pains of building and managing infrastructure for companies like yours.

Upcoming changes that we’re particularly excited about are:

But that’s just three changes. What’s guiding our focus moving forward?

While we’ve long delivered different user interfaces for our PaaS–CLI, Terraform, Dashboard–the developer experience, especially of our Dashboard, has become a bit dated. It certainly wasn’t the “magical” experience developers expect, or the one we want to deliver to make good on our promise to eliminate the pains of building and managing infrastructure.

We’re just at the beginning of this journey to deliver a magical developer experience. Our team is completely reimagining how developers use Aptible, making it more like this: 

At the same time, we continue to tackle the really hard scaling problems we’ve worked with hundreds of fast growing companies to solve. Problems such as: optimizing resource costs via autoscaling, right-sizing, and instance class tuning, deploying complex architectures just as easily as monolithic web apps, and finding and fixing performance bottlenecks in distributed systems.

Building for all startups–and every company

Hundreds of digital health companies have used Aptible to go from 2 developers in a garage to unicorn status, successful acquisition, and even IPO. But few outside of digital health know of Aptible. 

Aptible has great security and compliance benefits that are, in truth, industry agnostic. While we’ll continue to ensure we’re the best PaaS for digital health startups, we know our PaaS can be useful to every startup, regardless of industry focus.

Thinking longer term, the reason Aptible exists is to enable every developer to focus on ideas, not infrastructure. We want to empower all developers to build valuable products for their customers, without dealing with the pain of building or managing infrastructure. This goes for all developers, from those working at early stage startups to those on enterprise product teams.

We believe that “No Infrastructure” is the future of software development. You’ll hear us talk about our “No Infrastructure” vision of the future more and more as we go forward. 

While it may not feel as substantial as our plans to deliver magical developer experiences and tackling the scaling problems companies face, we’ve also updated our brand look and feel. We wanted a new, bright look that complements our optimistic outlook and commitment to our No Infrastructure vision. 

Of course, we love the Aptible arrow logo and didn’t want to replace it. So we turned to our friends at 

, who helped us with our previous successful visual redesign. We went through several (SEVERAL) versions while we collaboratively iterated towards the look and feel that most resonated with our team and the value we want to bring to our customers. 

We hope you agree that this is a much needed improvement to our brand without straying too far from what worked well.

Aptible pricing has stayed consistent for about a decade. We’re investing in ways to help companies manage costs on Aptible. The first two changes, while smaller, are a strong platform we can use to continue to improve how we help customers manage costs. Initially, we are releasing:

With Limits, companies can be sure to limit their infrastructure costs without running the risk of downtime. If you select a Limit (today, you’d select a Limit by picking a Plan), Aptible will ensure you don’t provision resources that would raise you above the max limits–and the max invoice–you’ve chosen.

Plans are the primary vehicle we are (currently) using to experiment with Limits. The point is to make it easier for companies to “choose” where they want their infrastructure spend to be based on the size, scale, and maturity of their project. 

For now, all existing Aptible customers will be grandfathered on their current pricing plan, and will not have Limits enforced. Going forward, based on your feedback, we may make Limits accessible beyond the first set of Plans we’ve implemented, making them available across the customer base. Beyond that, we anticipate continuously releasing cost optimization tools to help you control your Aptible invoice.

We’re still the same Aptible that hundreds of companies and thousands of developers have trusted to run their infrastructure for the past decade. We’re just making some changes, seeking to accelerate investment in our PaaS, ensuring we are continuously improving on how we deliver our “No Infrastructure” vision, and being the best PaaS for both starting and scaling a company on, without the pain of managing infrastructure.

Don’t hesitate to reach out to any of us or your account manager if you have any questions, suggestions, or requests. We’d love to hear your thoughts, and any ideas you have on how we can better deliver the best possible PaaS.

And most importantly, thank you to all of our customers for their support, product usage, and continuous feedback. We love working with each of you and plan to continue to earn your trust and make good on our “No Infrastructure” vision so we can run your infrastructure (so you don’t have to) for many years to come.

Aptible’s New Look, and the future of PaaS

At Aptible, we’re always focused on making it easier for engineering teams to manage their cloud infrastructure. This month, we’re excited to introduce a new set of features designed to automation easier with the use of Terraform!

Pre-built Grafana Dashboards and Alerting

Start instantly monitoring your Aptible resources, all hosted within your Aptible account! Use the 

 to seamlessly provision Metric Drains with pre-built Grafana dashboards and alerts for monitoring RAM & CPU usage for your Apps & Databases.

Guide to minimizing downtime from AWS Outages

We've refreshed our Business Continuity guide to include recommended actions to minimize downtime caused by AWS outages. Start planning today!

This month, we’re excited to introduce a new set of features designed to automation easier with the use of Terraform!

What’s new with Aptible: October 2022

Pre-built Grafana Dashboards and Alerting

Guide to minimizing downtime from AWS Outages

See what else is new with Aptible

Coming Soon

More Posts

Deploy the Trees 🌲

Return of the PaaS

Aptible’s New Look, and the future of PaaS

Focus on innovation.
Not Infrastructure.

Product

Resources

Support

Company

What’s new with Aptible: October 2022

Pre-built Grafana Dashboards and Alerting

Guide to minimizing downtime from AWS Outages

See what else is new with Aptible

Coming Soon

More Posts

Deploy the Trees 🌲

Return of the PaaS

Aptible’s New Look, and the future of PaaS

Focus on innovation.Not Infrastructure.

Product

Resources

Support

Company

Focus on innovation.
Not Infrastructure.