Kubernetes (K8s) often catches users off guard with its complexity. Harnessing its full potential requires paying attention to detail and keenly understanding its core concepts. If you don’t, K8s can fall apart quicker than a wet paper straw.

J.R.R. Tolkien once said, “It does not do to leave a live dragon out of your calculations if you live near one.” Similarly, while Kubernetes offers enormous power and flexibility for container orchestration, you’ll find that even the most experienced professionals have trouble navigating its configuration and services. 

Platform practitioners that manage kubernetes-based platforms often experience significant frustration as they encounter a multitude of challenges, ranging from intricate configuration requirements and unpredictable expenses to limitations in scalability, concerns surrounding secrets management, and a steep learning curve.

Kubernetes is an efficient platform for managing containerized applications. Dev teams use it to quickly deploy and orchestrate applications across a cluster of machines, automating many tasks that would otherwise be time-consuming and error-prone. For example, developers can deploy and manage containerized applications, automating tasks like load balancing, scaling, and self-healing, which streamlines application deployment, ensures high availability, and simplifies infrastructure management. 

A critical aspect of its orchestration capabilities is dynamic scaling, which efficiently allocates resources and seamlessly handles fluctuations in workload demand. Instead of manually monitoring usage and bandwidth, k8s manages it nearly autonomously.

Magical as k8s may seem at first, there are plenty of challenges to overcome to be production-ready. 

Understanding these challenges is essential for anyone who wants to deploy Kubernetes in production. Kubernetes is a complex system, and there are many things that can go wrong if it is not properly configured. Here are some of the most frustrating challenges that Kubernetes users face:

 conducted by Civo, 54% of cloud developers revealed that Kubernetes complexity is slowing down their organization's use of containers. 

One of the main sources of this complexity is writing and managing YAML/JSON manifests. Manifests are configuration files that outline how to use resources within a cluster. Writing them is time-consuming, prone to misinterpretation, and immensely frustrating. There are so many object types in K8s, each with its own specific requirements and specifications, users may find themselves overwhelmed when working with manifests.

 represent different resources, entities, or components within the Kubernetes system, such as pods, services, deployments, and config maps. A piece of code manages each of these object types, and the life cycles of all these objects work in tandem to orchestrate the system as a whole. 

Coordinating all these components requires esoteric knowledge. Depending on the application, you may need to specify additional parameters for certain object types, especially for a 

 (the workload API object used to manage stateful applications). None of this is well-documented—and even if it was, the docs assume a high degree of k8s knowledge to begin with.

Working with a StatefulSet is ideal for managing stateful applications with unique network identities, persistent storage, and ordered deployment and scaling. StatefulSets sometimes require many additional parameters. These parameters, tailored to your application's requirements, typically include:

However, simply configuring an application is not merely a “one and done” task; it typically needs a dedicated DevOps team willing to regularly scan Kubernetes clusters and ensure their proper configuration. This process involves validating pod resource limits and security policies to ensure a smooth operation. Kubernetes administrators also need to evaluate, select, install, and manage myriad 

Depending on the application, K8s administrators may need to install Ingress controllers such as:

With Kubernetes, complexity begets more complexity. As you add more clusters and components, the configurations get more intricate, thanks to the expanded requirements and the challenge of keeping everything consistent in a distributed system. Each new Kubernetes cluster has its own set of resource needs, including storage strategies, networking protocols, and computer nodes.  

As Kubernetes scales, the complexity of maintaining consistent networking policies across multiple pods intensifies. An illustrative challenge in this context is when a network policy selects a specific pod, as it necessitates explicit matching of traffic to and from that pod with a network policy rule to avoid blocking. While there are no inherent restrictions on Pod-to-Pod communication within a Kubernetes namespace, administrators must carefully consider network policy rules to ensure uninterrupted traffic flow and adequate network security.

In addition, the dynamic nature of the Kubernetes ecosystem introduces more complexity. With regular updates, the introduction of new features, and community-driven enhancements, staying current with best practices and emerging trends becomes essential for effectively navigating the evolving Kubernetes landscape.

, "While Kubernetes-based applications may be easy to run, Kubernetes itself is no picnic to operate."

The biggest problem for K8s is uncontrollable costs. In a recent 

 survey, 68% of respondents said Kubernetes costs are increasing, with half experiencing an increase of more than 20% per year. 

Overprovisioning resources occurs when an enterprise fails to carefully monitor spending and loses control over the costs involved. In the CNCF survey, 24% of respondents did not monitor Kubernetes spending at all, while 44% relied on monthly estimates. Only a relative minority employed predictive Kubernetes cost monitoring processes.

When configured correctly, applications are responsive, even under heavy loads and traffic spikes. Improper configuration of K8s can lead to excessive scaling of an application, resulting in over-provisioning. 

Over-allocated resources affect performance by wasting and hoarding shared cluster resources. When deployments request more resources, like CPU and memory, than they actually need, it can cause application performance to degrade. A web application configured to run hundreds of instances may overwhelm available resources, resulting in slow response times, increased latency, and even system crashes well beyond the problematic container.  

Since these environments are dynamic, K8s engineers can unintentionally overprovision their applications if they fail to account for fluctuations in usage. For example, a K8s engineer might configure a web application deployment to use 16 CPU cores and 64GB of memory, even though the actual usage of the application only requires 4 CPU cores and 16GB of memory. Recently, Webb Brown, CEO of Kubecost, a Kubernetes cost monitoring firm, 

 that many teams typically begin with a low 20% cost efficiency.

Teams often waste this extra capacity and don’t factor it into their overall cost calculations. Software company Flexera 

 that teams typically exceed their cloud budgets by an average of 13% and waste approximately 32% of their cloud expenditure due to issues like overprovisioning that leaves cloud resources unused. 

Kubernetes engineers are unlikely to employ usage reports to identify if they can cut their spending without sacrificing a comfortable buffer. Consequently, they must decide between wasting money or introducing risk, leading to overprovisioning as the default option. 

Attempting to gain control over this spending can be incredibly frustrating. As one Chief Technology Officer 

, “I spent the last two years developing with Kubernetes and containers. In one moment, I’d rave about how it handled mundane infrastructure management tasks. In the next, it frustrated me to comical degrees because it was almost impossible to control my own environment.”

This lack of control is primarily due to Kubernetes' proactive creation and disposal of container instances to meet demand, resulting in unpredictable resource usage. This volatility will challenge anyone seeking to track usage levels and allocate overhead expenses. 

Moreover, in multi-cloud environments, users may receive separate bills from different service providers for their clusters, making it hard to even identify specific containers. 

For example, suppose you have a Kubernetes cluster running on AWS and another on Azure. With such an arrangement, you will receive separate bills from AWS and Azure for the resources you use in each cluster. Tracking your overall spending becomes challenging, as well as identifying which containers use the most resources. Additionally, each cloud provider uses its own naming convention for containers, complicating identification.

Autoscaling is a prominent feature of cloud native architectures, and it often involves using on-demand containers ("if it even exists, you pay for it") to meet workload demands. To make the most of your resources, it's essential to embrace rightsizing in Kubernetes, as it allows you to optimize costs effectively.

Rightsizing is all about finding the perfect fit for container sizes, aligning them with the pods' ideal CPU and memory needs. It’s all about making the most of your resources without sacrificing performance. Adopting this approach can significantly cut expenses since you won't be paying for unused resources, making your Kubernetes deployment much more cost-efficient. However, achieving this goal may pose some challenges.

When demand spikes occur, scalability limitations impact the application's performance if resources are scaled up too late (e.g., Out of Memory errors, CPU throttling, or increased latency). Failure to rightsize leads to inefficiencies and bottlenecks. On the other hand, if a user overprovisions resources, autoscaling may increase the cost of running the application, potentially outweighing any performance benefits. Thus, it's not wise to leave resource provisions up to chance. 

Monitoring creates the right balance of resources

Instead, organizations need to closely monitor their applications to achieve the right balance in resource allocation.

Given this need, Kubernetes offers an array of scaling tools to facilitate resource requests:

Kubernetes users should know the drawbacks and difficulties of its three autoscaling techniques. Understanding them can prevent inadvertent overscaling of applications. For instance, when calculating scalability, neither HPA nor its VPA factor in network, storage, or input/output operations per second. As a result, applications risk slowing down or even grinding to a halt. In addition, VPAs do not allow users to update resource limits on active pods, necessitating their removal and the creation of new pods when new resource limits are needed.

Kubernetes Cluster Autoscaler (CA) presents its own challenges. When making scaling decisions, it only considers a pod's resource requests rather than its actual usage. Consequently, the CA will fail to detect any unused resources the user may have requested, creating inefficient and wasteful clusters.

Also, the infrastructure they run on also needs to be scaled, making it necessary to use multiple mechanisms. Merely relying on the HPA or CA alone may not suffice. To effectively manage scalability, all three mechanisms may need to be used in tandem. Neglecting these tools can lead to heightened frustration and significant costs. 

 are not really secret. Although Kubernetes employs the Secret object to store your sensitive data, the data is represented in 

. Consequently, anyone with access to the cluster or the code can decode the K8s Secret.

By default, Kubernetes stores these unencrypted Secrets in the API server's underlying data store (

). Since anyone with API access can retrieve a Secret, anyone with access to etcd can do so as well. In addition, anyone who has permission to create a Pod in a 

 can use that same access to read any Secret stored there, even if they only have indirect access. 

Thus, Kubernetes users should either employ a third-party tool to remedy this situation or thoroughly reconsider the storage of any sensitive data within the platform.

After all, hacking attacks are hardly rare occurrences. Potential attackers constantly search online for exposed Kubernetes components protected by lax access controls, such as access to API servers. In 2022, 

 revealed that over 380,000 K8s API server instances are exposed over the internet every day. In addition, configuring cluster access and authorization roles is highly complex in K8s.

Kubernetes users should be aware that adding components to the Kubernetes environment increases the overall attack surface, including the exposure of secrets. One such component, the Kubernetes Dashboard, presents a web-based interface for managing and visualizing the cluster. Improper configuration or security vulnerabilities in the Dashboard can introduce risks, particularly when it's accessible on the public internet without robust authentication and authorization measures. Unauthorized access to the Dashboard grants attackers the ability to view sensitive information, manipulate resources, and potentially gain access to stored secrets within the cluster.

Introducing new components may also require additional configuration steps and integration with secrets management systems.

Alas, Kubernetes’ security risks appear to be a growing concern for businesses. Earlier this year RedHat 

 600 DevOps and security professionals about the state of K8s security. They found that 67% of respondents have experienced delays or slowdowns in application deployment due to security concerns. In addition, just over a third of respondents reported experiencing revenue loss or customer attrition due to a container and Kubernetes security incident.

Navigating Kubernetes can be daunting. Taking a few hours to learn Kubernetes won’t get anyone over its steep learning curve. It's a complex tool solving a complex problem. In the aforementioned 

, 57% of respondents reported Kubernetes' steep learning curve as their top challenge. 

What makes working with Kubernetes so difficult? Users must familiarize themselves with the software's three essential components: the containers, the kubectl command-line tool, and the Kubernetes manifests.

Among these three components, mastering the art of writing YAML files is the most challenging. While the YAML format is relatively straightforward, the key lies in meticulously structuring and configuring each YAML file to guarantee flawless functionality within the Kubernetes environment. Attentiveness to details such as indentation, syntax, and accurate placement of key-value pairs becomes imperative for seamless deployment. Additionally, YAML files must be thoroughly validated and error-free to prevent deployment issues and unexpected behavior. 

Understanding the underlying logic behind K8s objects is even more demanding. Users must grasp the concepts of pods, services, and deployments, comprehending their functionality and interconnectedness within the Kubernetes ecosystem. They should also comprehend how these objects interact and collaborate with each other.

Kubernetes engineers typically undergo specialized training to work effectively with the platform, since setting up a K8s cluster demands a deep understanding of its architecture and components. This process involves provisioning the infrastructure, including installing and configuring crucial components like the 

. It also involves setting up networking and cluster networking solutions and deploying and configuring storage options. Finally, Kubernetes engineers must be able to add and configure additional tools like monitoring systems and logging solutions.

While Kubernetes offers advanced container orchestration capabilities, the complexity involved in mastering the platform can be daunting and time-consuming. Due to Kubernetes' steep learning curve, enterprises must carefully consider the trade-offs involved in adopting the software. Since the benefits of using K8s may not outweigh the investment required in training and resources, it is essential to consider alternative solutions.

To recap, here’s a list of the issues we’ve discussed in this article. This list is by no means comprehensive as there are many other challenges to working with Kubernetes, but it’s enough to strike fear into even seasoned infrastructure engineers:

Despite Kubernetes' continued popularity, the container orchestration platform still provokes considerable frustration. Kubernetes users face numerous challenges, including complex configuration demands, costly or unpredictable expenses, scalability limitations, secrets management concerns, and a steep learning curve. Nevertheless, many enterprises persevere in adopting K8s due to its unmatched ability to orchestrate containerized applications.

Cloud platforms simplify deployment by abstracting the underlying infrastructure, allowing users to focus on application development and deployment rather than managing Kubernetes clusters. Furthermore, cloud platforms use Kubernetes' scaling capabilities, offering simple scaling options and auto-scaling features to improve performance and resource utilization.

There is a growing demand in the market for an alternative to Kubernetes that supports globally-scalable application delivery. Cloud platform solutions like Aptible are becoming increasingly popular. Aptible allows developers to quickly scale their applications without worrying about infrastructure requirements. As time progresses, we expect more businesses to show interest in cloud platform products as they recognize their many benefits.

Explore the challenges of container orchestration and scaling in Kubernetes. Discover strategies to overcome these obstacles and ensure efficient management of containerized applications in dynamic environments. Gain insights into scaling considerations, resource allocation, and workload distribution to optimize performance and maximize the benefits of Kubernetes orchestration.

Kubernetes Challenges: Container Orchestration and Scaling

Memory policies play a major role in how Docker applications function. Docker containers share the same underlying hardware, which can result in issues if a single process eats up a core resource (such as memory). Known as the noisy neighbor problem, one memory-hungry process could shut down an entire application without the right safeguards.

Given that the core tenet of containerized applications is to separate subprocesses into their own isolated units, memory management is an important feature. Docker handles memory via dynamic 

. However, Docker’s approach involves using SIGKILL, a termination-forcing technique that has downsides.

Today, let’s discuss the issues with Docker’s native approach and how Aptible addresses it.

Aptible is a platform as a service (PaaS) that automatically scales infrastructure to meet an application's demands. Aptible is built on top of Docker, handling all the grunt work of building robust systems on containerized systems. Aptible uses Docker’s native features when they meet our users’ needs, but we aren’t afraid to engineer a better experience when called for.

When it comes to memory, Aptible differs from Docker in two ways: (i) how memory limits work and (ii) what happens to memory in the case of container recovery.

Docker enables users to set dynamic memory limits.

At a base level, Docker’s memory limits restrict how much memory an application is allowed to use. When applications run short on memory, they may swap it with disk—Docker has a setting to restrict how much memory can be swapped to disk. This can also be set as a percentage.

Additionally, Docker containers can have a soft limit. A soft limit is a memory limit that isn’t always enforced (but recommended to the application). In the case that the kernel is low on memory, the soft limit will be enforced. A soft limit could be combined with a hard limit, where the hard limit is always greater than the soft limit.

What happens if a limit condition is crossed? Docker will kill the process. It accomplishes this by issuing a SIGKILL signal to the process (or, more specifically, instructing the kernel to do so). However, SIGKILL is not a “graceful” approach to terminating a process; it’s equivalent to force quitting an application on Mac—it forces the application to immediately shut down. Even if the application had a shut-down process, it wouldn’t be able to carry it out because SIGKILL cannot be blocked or ignored, even for a brief period of time.

Quick Refresher—SIGKILL versus SIGTERM: Unix has two built-in signals for terminating a process: SIGTERM and SIGKILL. While SIGKILL immediately terminates a process, SIGTERM instructs it to shut down. This enables the process to error-handle incomplete requests and return any unfinished jobs to any external queue. Once the process cleans up its state, it can terminate itself. If a process ignores a SIGTERM signal for a lengthy period of time, a SIGKILL will typically be issued to force it to quit.

How does Aptible’s memory management work?

Aptible handles memory limits via a step-by-step procedure. This process is managed by a feature named memory management. Memory management’s goal is to gracefully terminate a container before having to force it to quit.

The general benefit of Aptible’s memory management feature is that it increases a container’s chance of exiting gracefully, enabling it to clean up its work before self-terminating. Aptible prioritizes predictability in performance and therefore doesn’t support or recommend swap limits or soft limits. Instead, Aptible is able to respond more gracefully when an out-of-memory error occurs.

A feature that’s directly connected to memory limits is container recovery. Container recovery is the practice of restarting a container if it has exited unexpectedly. Container recovery is extremely common—most applications eventually hit a snag.

Container recovery differs from process management solutions like upstart or PM2 that attempt to restart failed applications at the application layer. It’s generally advised to not combine container recovery and process management solutions because it muddles which process is in charge of restarting applications.

Just like memory limits, Docker’s and Aptible’s container recovery features work a bit differently.

Docker’s memory-preserving container recovery

—is a configurable policy that governs when a container should be restarted. For instance, a container restart policy could dictate that containers be restarted in all cases or only if the code had faulted.

Docker only executes the container restart policy if a container previously started successfully and lived for at least 10 seconds. This condition prevents an infinite loop of container restarts. However, an infinite loop is still possible if the container’s fault happens after some initial application booting.

Docker doesn’t wipe the container’s memory before restarting it. This could lead to a future crash if an artifact in memory was the crash’s origin.

Aptible’s filesystem-wiping container recovery

Aptible keeps track of which containers should be alive. When Aptible’s ledger doesn’t match a container’s reported dead state, Aptible performs container recovery. While Aptible invokes docker start to restart the container, it differs from Docker when it comes to the filesystem.

Before restarting the container, Aptible wipes the container’s filesystem. This technique is known as starting a container from a pristine state.

Doing this manually is possible, but is a hassle. Only the application’s created files need to be deleted; otherwise, applications might break.

Aptible’s memory auto-wipe feature can be optionally disabled. This might be necessary if an application is using its file storage to manage its state (which is discouraged when following the 

To be clear, the local file system is still an important resource to a process. For instance, a process might store temporary JSON files for query responses. It’s important to preserve this file system in case it lends details about the crash.

To address this, Aptible copies the file system into a folder outside of the container, retaining the file system while maintaining a pristine state.

Aptible designs its platform with these specific behaviors to provide the best experience to our customers, even when they run into unexpected crashes or uncontrolled memory consumption. Conversely, Docker enables developers to set more complex memory limits, it terminates processes using SIGKILL, which prevents processes from gracefully ending. In comparison, Aptible gives containers extra memory and time to end on their own terms, allowing them to clean up any remaining work. Of course, if a process doesn’t terminate itself, Aptible will also issue a SIGKILL signal.

After a memory limit is crossed, Aptible and Docker have different strategies to restart a container. Docker attempts to restart a container immediately. Aptible has a few more steps, including wiping the file system after copying it to an external location.

Overall, Aptible’s memory management features and container recovery policies were designed to address Docker’s trigger-happy faults.

How Aptible gracefully handles memory management

We are excited to announce that we’ve completely refreshed our 

 Taking into consideration both user feedback and industry best practices, we’ve redesigned the site to provide users with a
more intuitive experience and rewrote our docs to ensure that it is clear and
concise.

One of the biggest changes we made is the complete restructuring of the docs
site. We simplified the navigation, making it easier for users to find the information they need. The 

 served
as inspiration with its four distinct categories—Tutorials, How-to Guides, References, and Explanations—that serve to provide clarity to both the author and the reader. Using this framework as a guide, we implemented our own new categories:

Based on feedback from our new and existing users, we have rewritten most of
our docs to improve overall clarity. We recognized that some of our docs
covered advanced DevOps topics, which led engineers to search for additional
resources. With the rewritten docs, we aim to address this issue by providing
comprehensive explanations that don't require users to seek external information. Our goal is to equip our users with all the knowledge they need within our docs itself.

 to align with our new Deploy Code from the Dashboard release. This exciting feature allows users to deploy a Starter Template directly from the Aptible Dashboard, simplifying
the deployment process. The updated Starter Guides will guide users through the new workflow step-by-step, ensuring a smooth onboarding experience.

To enhance the search experience, we implemented an improved search
functionality that includes preview text. Users can now get a glimpse of the content before diving into the full document, making it easier to find the information they’re looking for.

We restyled our doc site last month, but to further enhance the visual
experience, we have added over 40 reference images throughout our docs. These
visuals aim to clarify concepts, illustrate workflows, and give users visual
cues to navigate the Aptible Dashboard.

But that's not all! We have also introduced new widgets to our docs site, making it even more convenient for users to engage with our platform. You can now 

 within the docs itself. Additionally, we've connected our status page to our docs site so that in the event of an outage, a notification will display directly in our docs.

We are thrilled to present these updates to our docs site, and we believe that
they will greatly improve your experience as you explore our platform. Our commitment to providing clear, concise, and user-friendly docs remains unwavering. We hope that these changes will empower you to make the most of
our services without any hurdles.

! We welcome
all your feedback on our new doc site. If you have any suggestions or ideas for further improvement, 

We’ve redesigned our docs site to provide users with a more intuitive experience and rewrote our docs to ensure that it is clear and concise.

A Closer Look at the Relaunch of Aptible Docs

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.

Blog

Kubernetes Challenges: Container Orchestration and Scaling

How Aptible gracefully handles memory management

A Closer Look at the Relaunch of Aptible Docs

Deploy the Trees 🌲

Return of the PaaS

Aptible’s New Look, and the future of PaaS

What’s new with Aptible: Feb 2023

Introducing Granular Permissions: For Fine-Tuning User Access

What’s new with Aptible: January 2023

Building a developer
platform is a thing of
the past.

Product

Resources

Support