If you use serverless components to build your application, your application is serverless—but what does serverless mean? It’s an abstract and overloaded term that means different things to different people.

When trying to understand serverless, you shouldn’t focus too much on the “no servers” part—it’s more than that. In general, this is what people mean when they call something serverless, and why they are excited about it:

• It simplifies the developer experience by eliminating the need to manage infrastructure.
• It’s scalable out of the box.
• Its cost model can result in significant savings because you pay for what you use, not for the capacity, you reserve upfront. If you use nothing, you pay nothing.

Here the focus is on the first characteristic. What does that simple developer experience mean? Eliminating infrastructure management means you can focus on writing your code and have someone else worry about deploying, running, and scaling your application. The platform will take care of all the important and seemingly simple details that are surprisingly hard to get right. Examples include autoscaling, fault tolerance, logging, monitoring, upgrades, deployment, and failover.

One thing you don’t have to do in the serverless context is server management. Servers still exist in a serverless platform, but you don’t have to worry about them anymore. The platform offers an abstraction layer. This is the primary reason we call it serverless.

When you are running a small system, server management might not seem like a big deal, but readers who manage more than 10 servers know that this can be a significant responsibility that takes a lot of work to get right. Here is an incomplete list of tasks you no longer need to do when you run your application logic on a serverless platform:

• Provisioning and configuring servers (or setting up automation)
• Applying security patches to your servers
• Configuring networking and firewalls
• Setting up Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates, updating them yearly, and configuring a web server
• Automating application deployment on a cluster of the servers
• Setting up logging and metrics monitoring to provide insights into system performance

And that is just about servers. Most businesses have higher and higher expectations for system availability. More than 30 minutes of downtime per month is generally not acceptable. To reach these levels of availability, you will need to automate your way out of every failure mode; there is not enough time for manual troubleshooting. As you can imagine, this is a lot of work and leads to more complexity in your infrastructure. If you build software in an enterprise environment, you’ll have an easier time getting approvals from security and operations teams, because a lot of their responsibilities shift to the vendor.

Availability is also related to software deployments, now that it is more common to deploy new software versions on a daily basis instead of monthly. When you deploy your application, you don’t want to experience downtime, even when the deployment fails.

Serverless technology helps you focus on solving your business problems and building a great product, while someone else worries about the fundamentals of running your app. This sounds convenient, but you shouldn’t take this as all your responsibilities disappear. Most importantly, you still need to write and patch your code and make sure it is secure and correct. You still need to manage some configuration, like setting resource requirements, adding scaling boundaries, and configuring access policies.

Serverless is great if you value a simple and fast developer experience, and if you don’t want to build and maintain traditional server infrastructure. The servers are still there—you just can’t manage them anymore.