Why #Serverless Is Eating the Stack
Tags: serverless, awslambda, cloud, microservices
Published: 2019-09-24 14:21:24

---
title: Why #Serverless Is Eating the Stack
published: true
description: Serverless has undeniably become mainstream. As more teams migrate with great success, it is eating the cloud stack in accelerating speed.
tags: serverless, aws-lambda, cloud, microservices
cover_image: https://thepracticaldev.s3.amazonaws.com/i/uuoanv5289fzwdac94so.png
---

In the technology and business landscape of today, **constantly changing** at an **accelerated pace**, it is vital to be **nimble**.

The software development industry has been building amazing tools and equipping developers with what we need to **face these challenges**.

But implementing some of these tools, whether they are tangible (e.g. an open-source project), or abstract (e.g. programming or architectural patterns), can prove to be a **hard task** sometimes.

![Man climbing ice wall](https://thepracticaldev.s3.amazonaws.com/i/wn8h48qjlf403titox28.PNG)

Take the microservices approach. **Only implementing it on an architectural level** is already a **hell of a challenge**. And you have a plethora of other things to consider...

_Blue/green or canary? Or rolling deployment?_

_How to decouple services? How to keep services as independent components?_

_Service discovery? How to orchestrate services? Or should we allow them to choreograph independently?_

_To GraphQL or to not GraphQL?_

# You get the idea. It's **overwhelming**.

![Man screaming](https://thepracticaldev.s3.amazonaws.com/i/3l4oal61hnxklfpzzkar.jpg)

Now consider we can't always have a team of +100 people for Frontend, Backend, DevOps, Testing, UI/UX, Code Reviewing, etc.

### **Most dev teams are small**!

Less than a dozen of few dozen software warriors...

And you still want to have the problem of **taking care** of the **1,000,000 ways servers will end up failing** their promise of... serving?

Well, if you are realizing what many developers, team leaders, and CTOs already did, **you want to abstract those issues away**. _Unless you have big pockets to hire a best-in-town DevOps team._

Below are some reasons the **serverless stack is eating the cloud**:

# Mature developer tooling

![Tools on wooden panel](https://thepracticaldev.s3.amazonaws.com/i/1b8z4x6o0qb1glptwt3s.PNG)

Until recently, serverless computing was still in its early stages and developer tooling was quite not mature yet. That ended up adding risks and draining a good portion of the productivity gains promised by the platform. Today, this isn't an issue anymore as it was in the past.

From **[frameworks](https://geekflare.com/serverless-apps-frameworks/)** to **[integrations](https://docs.aws.amazon.com/lambda/latest/dg/lambda-services.html)** to **[monitoring/debugging](https://dashbird.io/blog/top-serverless-monitoring-tools/)**, the market now offers a wide and rich selection of tools for development teams to choose, bringing peace of mind for tech leaders to rely on Serverless.

The [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/), for example, has utilities to **automate most of the repetitive and manual tasks** associated with developing and deploying serverless functions.

Most serverless offerings are now **integrated with dozens of other cloud services**, allowing for a **fast implementation** of a full software lifecycle, **connecting computing to object storage to databases to message queues**, etc. In terms of monitoring and debugging, we now have **[mature services dedicated to serverless](https://dashbird.io/blog/top-serverless-monitoring-tools/)** that give us necessary peace of mind.


# Fast time to market

![Horse race](https://thepracticaldev.s3.amazonaws.com/i/hwxgx5vhln2d57x2zq50.PNG)

Time is arguably one of the **main pressure points** faced by software development projects nowadays. Clients, either internal or external, usually care very much about having an application, feature or fix **delivered as quickly as possible**, provided that it **meets requirements** and is implemented in a **stable and resilient** way.

Usually, the only two ways teams have in hands to manage time are:

1. **Hire more developers** to increase development throughput;
2. **Simplify** the implementation to **maintain quality & cost** while **lowering delivery time**;

With a software developer labor market under pressure and **payroll on the rise**, item #1 isn't really an option in many cases, either for financial constraints or for not having available people to hire whatsoever.

CTOs are finding that **serverless can contribute greatly** to item #2, by simplifying the infrastructure planning, deployment, and management.

Serverless functions, such as AWS Lambda, for example, can scale out of the box to 3,000 concurrent executions and this threshold can be easily increased virtually to an infinite value, if needed. All that without setting up a single server or load balancer.

**Practically everything a team needs to think about infrastructure-wise** - choosing the right machines, configuration, load balancing, scaling, etc - before deploying an application **is abstracted away by serverless**. It simplifies the work so much and has the potential to save dozens, if not hundreds or thousands of hours.

Not only this simplification **saves time** and relief project leaders from delivery pressures, but it also enables **fast time to market** for corporations relying on teams that are keen to reap the benefits of serverless. In the long run, **these companies are up to dominate their fields**, by delivering value and adapting to market trends quicker than competitors.

# Focus on what matters

![Focus lens](https://thepracticaldev.s3.amazonaws.com/i/60bjhpcto46i6fwpelwq.PNG)

Having the best DevOps team in the block used to be a differentiator for most tech projects. It doesn't matter whether a piece of software delivered the best value if it wasn't capable of running and scaling in a performant way, and that requires battle-tested infrastructure planning and management skills. For that reason, software teams needed to dedicate a huge portion of resources (people, time, capital) to make sure the infrastructure problem was appropriately addressed.

Serverless is turning this logic upside down and teams are moving fast to adapt themselves. By abstracting away most of the issues with regards to creating a platform for software to run in the cloud, dev teams can now focus on what really matters: their client needs. And that is great for both software teams and users.

### Think about this for a second: people shopping Amazon.com do not care at all about which technologies or platforms are used to run the e-commerce.

What they do care is about having a great experience on the site, being able to search and find relevant items fast, etc. Those are the things developers are now looking to use their resources on. For instance:

*   How can software be implemented to improve the user experience?
*   Can we integrate artificial intelligence to make our application smarter?
*   Which practices will allow us to reduce bugs and improve overall software health?
*   How can I manage my team so that they are happier and more productive at work?

These are the questions your team can start thinking about with the time gained by building on serverless.

# Battle-tested

![Cannon shooting](https://thepracticaldev.s3.amazonaws.com/i/aac341tcxird1wqj8z7a.PNG)

Many thousands of companies from all sizes are already using serverless for many years now, **testing the architecture against the most strict and rough environments** in the market. From corporate behemoths to small businesses and startups, the serverless paradigm has been tested and **had its value proved** countless times.

On top of that, serverless has been **adopted across all industries**: from food & beverage companies, such as Coca Cola, to digital corporations, like Netflix, to retailers like Nordstrom.

# Low cost

Although many have the impression that serverless can be more expensive than a traditional server cluster, in most cases this belief does not hold water when we go to real-world numbers.

![Pennies in a jar](https://thepracticaldev.s3.amazonaws.com/i/cj5ms1740vowjzkjsp7l.PNG)

### I have seen cases where [serverless actually cut off 90% a cloud bill](https://www.linkedin.com/pulse/how-serverless-can-save-100000-your-cloud-bill-renato-byrro/)!

That is because serverless does not charge for idle or reserved resources. In order to match the elasticity and reliability of a serverless platform in a server cluster, a huge amount of resources need to be dedicated to accommodating fluctuations in demand, which leads to waste.

When we account for the number of work hours saved by the infrastructure abstraction - especially considering how expensive a DevOps team can be - the economies are even greater.

# How about you and your team?

Are you up to reap the benefits of serverless? In case you would like to learn more about how to better take advantage of serverless in your projects, [download my free ebook here](https://dashbird.io/serverless-benefits/).

---
### _Photo credits:_

* _Cover image: [Friso Baaij](https://unsplash.com/@boei?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/agile?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)_
* _Man climbing ice wall: [Robert Baker](https://unsplash.com/@vegasphotog?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/hard?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)_
* _Man screaming: [Stock Photography](https://unsplash.com/@aplaceforcreation?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/screaming?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)_
* _Horse race: [Julia Joppien](https://unsplash.com/@vitreous_macula?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/horse-race?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)_
* _Tools on wooden panel: [Todd Quackenbush](https://unsplash.com/@toddquackenbush?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/tools?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)_
* _Focus lens: [Paul Skorupskas](https://unsplash.com/@pawelskor?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/focus?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)_
* _Cannon shooting: [The New York Public Library](https://unsplash.com/@nypl?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/TNU8604rMVk)_
* _Pennies in a jar: [Michael Longmire](https://unsplash.com/@f7photo?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/pennies?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)_