Serverless benefits for Startups

Taavi Rehemägi - Sep 27 '21 - - Dev Community

I’ve had a great conversation with a buddy of mine who is launching a new service, and while he is not a technical person, he came up to me asking about serverless and if it could have an actual impact on his startup

Naturally, I got very excited about the topic and proceeded to list all the benefits of serverless technology and how decentralized technology has revolutionized the industry, so on so forth. After a 15-minute monologue, the guy stops me and politely asks me the question again.

How does serverless affect early-stage startups, and how it differs from the traditional monolith architecture?

I was forced to look at the problem from a different angle. Big companies get tons of benefits from huge cost cuts, better security, and a way to scale their applications on-demand without any hassle, among other benefits. But small early-stage businesses don’t care about any of that. There is no huge demand for their service, so scaling is not a concern. They don’t have a $250,000 AWS bill, so dropping the price by 25% to 50% will do nothing for them.

How Does Serverless Technology Help Startups?

When you are trying to develop that MVP or initial application, many things can go wrong. You don’t have a clear idea of where you’re going, and chances are your initial idea will develop into something new that may or may not resemble what you initially planned.

“The only constant is change” -- Heraclitus 500 BCE

In fact, some of your favorite companies had to pivot to get to that elusive product-market fit. Instagram, Twitter, and Nokia are just some of the most popular examples of successful pivots.

With the traditional servers, pivoting would mean writing new code, changing your APIs to fit the new functionality, possibly changing the way you store and access your data, and even upgrading or changing your infrastructure.

With serverless technology, you can accelerate that process drastically. There is no need to provision the servers or worry about managing them in any way, shape, or form. Just upload the new code to the provider, and it handles everything for you. The zero to production speed (a term I love to throw around) will improve tenfold when using serverless instead of building a monolith.

Serverless platforms provide a divide between infrastructure and applications, making for a faster production speed.

Like I’ve mentioned, the cost of operating a startup may not be as high as an already established, multi-million dollar enterprise, but there are still costs associated with running that business you can cut down by using serverless. You save money because you don’t need a big DevOps team; your service provider already handles everything infrastructure-related. Serverless also gives your development team flexibility to experiment with new things since they don’t have to rely on the sysadmins constantly telling them “no.”

Last but not least, you only pay what you use with providers like AWS Lambda, Microsoft Azure, or Google Cloud Functions; you only pay per invocation and the execution duration. To put it in layman terms, you are not forced to pay for your server if people are not using your application, so if you run a service that’s only used during the day, at night, you won’t be forced to pay the same amount of money even tho you don’t get nearly as many users.

Speed of execution is a big draw-in for developers and what’s great about serverless architecture is that speed comes at a meager price compared to the traditional servers. On most providers, you get to configure the memory of your functions so that you get more control over how fast they run or how much you are paying for execution time.

Reliability and Availability to Users

Some companies are larger and have an established user base that is constantly growing, so they have to make sure service is always reliable. But many businesses can be overwhelmed by a sudden jump in traffic. Usually, these traffic jumps follow a product release or successful marketing campaign, which shuts down your site due to the extra load.

Serverless is handy because it removes the need to purchase extra servers. Extra horsepower comes from having cloud providers automatically scale. A large number of users can easily visit the site without you worrying about a meltdown.

Having your service go down for maintenance every few days is a deal-breaker for customers, but with Serverless, that doesn’t happen, at least not because of the infrastructure. Poor application performance translates to lost revenue, and that’s a fact that’s been proven time and again by big companies all over the world.

Serverless eCommerce Start-Up Example

Let’s take an eCommerce business as an example. For years, this space has required an alternative to the regular hosts as they are really not really viable past a certain point, mainly because of these two reasons: Hosting costs and scaling issues.

  1. Hosting Cost

Anybody that runs a business selling goods or services knows that margins are everything, and every penny you spend will cut into those margins, hurting your business. This leads store owners to calculate the pricing of their products based on the manufacturing costs, shipping, and marketing, leaving very little overhead for the infrastructure when selling online. 

When they spend more on ads, they don’t expect to spend more on hosting, but the more people see the ad, the more traffic their sites get. More traffic = bigger servers.

  1. Scaling

You’ll need to support your growing base of customers, and to do so; you need a server that can accommodate a large number of concurrent users. This is done through various methods, but none are perfect and prone to errors. Truth be told, regular serves just don’t scale gracefully, and forcing them to do so requires a lot of attention and a lot more money.

scaling servers

Figure 1: Scaling issues with servers, by getshifter.io

Serverless will get you the graceful scaling that your store needs while keeping the costs down.

Whenever the serverless discussion comes up when I’m around e-commerce people, I always use a cautionary tale about this British TV show called Dragon’s Den. Entrepreneurs get three minutes to pitch their business ideas to five investors. In one episode, a guy walked in with an interesting idea, but as soon as he started talking about the website. Naturally everyone jumped on the website, and before the investors got a chance to see the site, it had crashed.

You’d be surprised how many store owners struggle with this problem. And this isn’t a problem that only small shops with cheap hosting have. It problem that even the likes of Bestbuy or Cabela have faced, and let me tell you, losing a couple hundred thousand dollars because your website goes down on Black Friday ain’t pretty.

“Poor website performance is now measured in lost customers and revenues.” -- Tom Lounibos, CEO, SOASTA.

If you want to give serverless eCommerce a shot, check out this tutorial on building your eCommerce store on a serverless platform.

No Drawbacks Then?

Serverless technology is not a one-size-fits-all kind of deal. There are going to be drawbacks and some things to get used to. Things are handled differently in serverless than they’d be with traditional infrastructure. Finding the right people to design your architecture can be difficult since the whole technology is still relatively new and developers with experience in serverless are hard to find.

You don’t get to mess with the configuration or use whatever programming language you choose to.

It might not make financial sense to use serverless for time-consuming tasks and take more than 15 minutes to execute.

You don’t have access to the underlying server, so telling when something goes sideways can be a difficult task. That’s why we built Dashbird, a tool that gives developers insights and observability into their serverless applications. Regardless if you are a small startup or a Fortune 500 company, you need a tool like Dashbird to debug your apps and keep an eye out on costs and overall performance.

PS: Serverless scales fast, and this is where the real challenge begins.

Built by serverless developers with serverless technologies and specifically AWS Lambda in mind. If you’re building your environments on AWS, Dashbird is here to make sure you’re running smoothly.

Save you hours or even days! Dashbird users have seen their error discovery and debugging time reduce by 80%. Dashbird gives you customized and actionable insights based on the AWS Well-Architected Framework to improve your infrastructure further and provide a quick and easy-to-understand real-time overview of the health and performance of your serverless infrastructure.

You can use Dashbird for free for up to 1M monthly Lambda executions:

  • No code changes
  • No credit card required
  • Simple 2-minute set up
  • Access to all premium features
  • Start debugging and securely working with your data immediately
  • Simple, clean, and easy to understand interface
  • One of the most budget-friendly monitoring and troubleshooting solutions in the market
  • Small-team-friendly all around 🙂 -- see what Dashbird users are saying.

So should Your Startup Go Serverless?

Simply put -- serverless architecture for business is a great way of outsourcing server operation. Letting someone else take charge of servicing your applications and databases saves valuable time and money

You can put leftover resources into better operations and development that would not be possible by traditional hosting. Focus on your business and service and let someone else worry about making them run smoothly.

Further reading:

Challenges and Opportunities of Going Serverless in 2021

Why AWS Console isn’t the best for Debugging?

My honest review: I tried AWS Serverless monitoring using Dashbird

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .