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.
The only constant is change - Heraclitus 500 BCE
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.
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.
#serverless #architecture
