Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
The beginning of every new tech buzzword is surrounded with developer excitement. Through the excitement and alien-like technical terms, it may be hard to the tell will this new buzzword bring any benefits to your business.
Serverless is one of the new top tech buzzwords at the moment. It started back in 2014. with Amazonâs re:Invent announcement of AWS Lambda - a compute service claiming:
- No servers to manage
- Continuous scaling and balancing
- Automatic fail-over
- Subsecond metering (paying only for used, not reserved time)
If youâre not a tech-savvy person (or youâre explaining serverless to one) these things might not mean much. They sound like a bunch of technical words promising to help you serve slightly more customers, a bit cheaper. That might be good enough, but there wouldnât be that much racket if it was just that.
So, what does serverless mean business-wise and in what ways can it benefit your business?
- Shorter time to market
- Increased efficiency
- Your fixed costs have become variable costs
- Less waste
- Easier pivoting (more flexibility)
- Better service stability
- Better management of development and testing
Letâs explain.
1. Shorter time to market
For many companies, the path of delivering applications to market is a long one. Along with product planning, design and development, you also have to think about the needed infrastructure, setup and capacity.
With serverless, you no longer have to worry about renting and buying infrastructure, its setup, and capacity planning. These steps are removed from your product development process and are now the responsibility of your serverless platform provider. You âonlyâ have to think about how to properly plan, design and develop your applications. This significantly shortens your time to market, as the development cycle is shorter.
2. Increased efficiency by paying only for used, not reserved time
Imagine you want to buy a car. A nice, but an also efficient one for you and your family.
But the salesman states that the car you wanted has to be run all the time.
Whether youâre using it or not.
On full gas.
Your car alternator may fail if you turn it on and off a lot, but your serverless function wonât.
Youâd think this guy might be insane. Why would you buy such a car?
- âBut thatâs how things work, for you to use it, its needs to run. Plus when you want to use it, you just jump in and drive!â, says the salesman. âAnd itâs the standard. Unlike these new cars you have to turn on to drive and wait up to a second when turning them on.â
The way that car is working is actually the mode how most of the current infrastructure your software is running on is working right now.
Compare it with an simple payment for one of your products. Normally, to be able to run such a service, youâd need to rent or buy a server. The server would need to run all the time, sitting idle until a payment request comes. An average usage of the server would look like the following figure.
The top border represents the maximum amount of requests your server can sustain. The left axis shows your estimated average server usage, going from 0 to 100%. The bottom axis shows the time during one working day.
This looks fine, as this is how your servers usually âneed to workâ. Regardless of the quantity of requests, you âneedâ to pay for both the server idle and working time, if you want to have a functioning service.
But if we simply inverse the perspective, you would get an average waste of the same server, like in the next figure.
Currently, whether youâre renting virtual servers or owning a datacenter youâre wasting resources*. Youâre paying for the reserved time whether your applications are being used or not.
*This diagram does not show the different dimensions of that waste. Memory, disk space, power consumption and so on. With those, the waste is even bigger.
Serverless changes âthe gameâ, so you pay only for the time it was used.
This diagram shows that with serverless, your capacity is strongly following your usage. Therefore making minimum waste.
This might look OK, but where is the Y axis? And why did you remove the previous black frame box around the edges?
The Y axis and the gray frame have moved, because with serverless, your capacity is scaled automatically per your usage, by your serverless provider. Serverless makes server capacity no longer your problem. That includes capacity planning, infrastructure, setup and large DevOps teams.
3. Your fixed costs have become variable costs
Imagine your company has 10 million user requests daily. Each user request is also making a couple of internal calls too, totaling up to 30 million requests. (This is a simplified real-world use case from a client, so we wonât go into details)
To handle that volume, currently you need to either rent a fleet of virtual servers or setup your own datacenter. Incurring infrastructure monthly costs ranging from several hundred to a couple of thousand dollars. If we add in the cost of a team of DevOps engineers to setup and handle your infrastructure, the data center costs, maintenance and so on, the cost goes much, much more.
Serverless computing services bill you on used request time. An average AWS Lambda pricing states a $0.20 per one million requests . Seems extremely cheap but thatâs not your total. AWS Lambda is a compute service, so you will also need data storage, notification services and so on. Additionally, serverless (with AWS Lambda) recommends separating your application into many smaller services. Causing the number of internal calls to soar, totaling up to at least double or 60 million requests daily. That sounds a lot, but the cost for computation services along with data storage and others you might need will be ranging around $900 per month.
But that still not where the cost reduction comes from. The cost reduction comes from the fact that serverless made your fixed costs become variable costs.
Serverless made your fixed costs become variable costs.
Fixed costs are the ones independent of the output. They include buildings, machinery, rent. Variable costs vary with output.
If you have a datacenter, whether you have lots or no usage, you still need to pay for them, their setup, usage and maintenance. Also hire DevOps engineers. With serverless, if just in one day you had 60 million requests, youâd pay $1000, the second one youâd pay zero.
4. Less waste
When developing multiple products, certain features are repeatedly developed over and over again. For example, payment processing or user authentication.
Imagine a car manufacturing company making their own tires for every new car model, over and over again. The price of the car would be the one of a Formula 1.
Serverless with AWS Lambda functions focuses your team to develop product services as independent components. These components can then be effectively reused, reducing the waste in spent time and effort.
5. Easier pivoting (more flexibility)
Businesses, especially startups, often need to pivot their products or ideas. When pivoting, usually you need to change the audience youâre targeting. Sometimes even rethinking the way your applications work. Nowadays, many applications are tightly coupled, which is a big problem. Even a slight change in your product course can cause painful refactoring or rewrites.
Serverless increases your product flexibility. Serverless (with AWS Lambda) recommends you to separate your application into many small independent services. Thus increasing your product flexibility. Then if you need to pivot your product to a different market, you refactor only the services you need.
6. Increased service stability
As a result of being independent, your newly-separated services are more stable. How so?
Currently, a large number of applications are bundled in big blocks. You can describe them as bundled services or applications packed into a single block. Monoliths are not that bad. But they have a major flaw. A single service crashing can cause the whole monolith to crash. Like washing multicolored clothes, one clothâs color can spoil the rest.
7. Better management of development and testing
Building an application consisting of many independent services will help you have:
- Better project overview.
- Easier testing
- Better estimates
Better project overview
Developing your applications as independent services will help your measure your progress better. Youâll gain a better understanding how do your services work and interact with each other.
Easier testing
Designing your applications as multiple single responsibility units makes them easier to test. Usually while developing, you also need to setup multiple environments and pay for them as well. With serverless setting up multiple environments is free and easy.
Better estimates
Separate single units usually have a smaller scope. Small scope units are easier to estimate, develop and test.
Nonetheless, there is no single approach, technology or strategy that is a silver-bullet, itâs all based on your context.
What are the potential side-effects of serverless?
Serverless does bring a lot of benefits to the table. Nonetheless, there is no single approach, technology or strategy that is a silver-bullet, itâs all based on your context. Also with serverless, there are potential side-effects that might make it unsuitable for your company or your case.
1. Vendor lock-in
Running your applications in a serverless environment can tightly couple your applications and services with your platform provider. Even though your business logic isnât reliant on the service itself, it still needs a direct connection to the platform provider services. With interface and protocol differences between serverless platform providers âin the mixâ, any potential move of your applications to other serverless platforms will be a painful rewrite. You can mitigate some of the bad effects by applying Hexagonal architecture.
2. SLAâââService Level Agreements
At the moment, for certain serverless services there are no strong Service-Level Agreements. In the case of AWS Lambda there are no uptime or operational agreements, yet. A paper by Gojko Adzic and Robert Chatley found that AWS Lambda had an approximate uptime of 99.6%. Thatâs good enough for almost all businesses. But in case of critical tasks requiring higher availability, Lambda might not be suitable. AWS does not publish official uptime numbers for Lambda.
3. Maintaining many small services may be troubling
Some may debate on this. Maintaining and debugging many smaller services instead of a few bundled applications does require more focus and dedication. Especially for large-scale enterprise environments. You can avoid it by setting automated testing as a prerogative and using AWSÂ X-Ray.
4. Potentially slightly slower service start*
Because your serverless provider is automatically scaling your applications, if you donât have any activity for a longer time some of your application instances may be down when a new request arrives. The situation then requires a âcoldâ start of your services, which may result in a higher latency of up to 1s. The latency, naturally, depends on the environment. Node.js, Python have lower latencies below 1 second, while Java going a bit higher (between 3 and 10s).
*This is what was our imaginary âalways-onâ car salesman complaining about.
Hope you liked the article, feedback is very appreciated!
Thankful for your shares, comments and critics!
If you liked it, feel free to take a look at the book âServerless Apps with Node and Claudia.jsâ Iâm authoring with Slobodan Stojanovic. Published by Manning Publications.
Serverless Apps with Node and Claudia.js
Iâd like to say a big thank you to my friends Slobodan Stojanovic, Gojko Adzic, Victoria Riquelme and Viktor Tuba who have helped me with reviewing, restructuring and sharing their insights how to improve the article.
You can also find me on Twitter, LinkedIn and Github.
7 ways Your Business will benefit through Serverless was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.