I’ve had a great conversation with a buddy of mine that 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, to having a way to scale their application on demand and without any hassle, amongst many other benefits. The issue with that is that small early-stage business 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 $250K AWS bill so dropping the price by 25 to 50% is going to do nothing for them.
So how does Serverless impact startups?Here's the thing, when you are trying to come up with that MVP or the initial application, there's a lot of things that 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.
In fact, some of your favorite companies have had to pivot in order to get to that elusive product-market fit. Instagram, Twitter and Nokia are just some of the most popular examples of successful pivots.
The only constant is change - Heraclitus 500 BCE
With the traditional servers, pivoting would mean writing new code, changing your API's to fit the new functionality, possibly changing the way you store and access your data and even upgrading or changing your infrastructure.
With Serverless, that process happens way faster. You don't need to provision the servers or worry about managing them in any way shape or form. You upload your new code to the service provider and it handles everything for you. Meaning that the 0 to production speed (a term I love to throw around) is going to improve ten folds when using serverless as opposed to building a monolith.
Serverless platforms provide a devide 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 that can be cut down by using serverless. You save money but not needing a big DevOps team, since everything is already handled by your service provider. That 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, with serverless 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 nights you won't be forced to pay the same amount of money even tho you don't get nearly as many users. Makes sense, right?
Speed of execution is a big draw in for developers and what's great about serverless architecture is that that speed comes at a very low 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 enjoy the responsibility to make sure service is always reliable.
Many businesses can empathize with a sudden jump in traffic.
Usually, this stems from product release or successful marketing campaign, which in turn 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.
No drawbacks then?Serverless technology is not a one-size-fits-all kind of deal. There are going to be drawbacks and some getting used to. Things are handled differently in serverless than they’d be with a traditional server. Finding the right people to handle designing 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 chose to.
It might not make financial sense to use serverless for tasks that are time-consuming 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 build 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.
Should you consider serverlessSimply 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. Leftover resources can be put into better operations and development that would not be possible by traditional hosting.