Serverless can be defined as applications that incorporate third-party, cloud-hosted applications and services, to manage server-side logic and state. These are notated as “rich client” applications (i.e. mobile apps) that utilize much of cloud-accessible databases, authentication services, and various others. These types of services have also been labeled as “(Mobile) Backend as a Service” (“BaaS”).
However, Serverless can also notate applications where server-side logic is still written by the application developer. However, unlike traditional architectures this is run in stateless compute containers that are event-triggered, ephemeral, and completely managed by a third party. One way to label this is known as “Functions as a Service” or “FaaS”. AWS Lambda is an example of FaaS implementation, but there are many others as well.
Startup latency and “cold starts”
FaaS platform is time consuming in prepping an instance of a function before each event. This startup latency can vary, it just depends on many factors. This may result in a latency range from anywhere from a few milliseconds to several seconds. Using AWS Lambda as an example, the initialization of a Lambda function will either be a “warm start”—where it uses an instance of a Lambda function and its host container from a previous event—or a “cold start” — where you must create a new container instance. The cold starts bring up concern with startup latency.
Cold-start latency will depend on a few variables. Variables may include the language you use, how many libraries you’re using, how much code you have, etc. Many times these variables are under a developer’s control, so it can be feasible to reduce the startup latency incurred as part of a cold start.
Cold-start frequency is also a variable to consider. For example, if a function is processing 10 events per second, with each event taking 50 ms to process, you’ll likely only see a cold start with Lambda every 100,000–200,000 events. Also, if you process an event once per hour, you may see a cold start for every event because Amazon retires inactive Lambda instances after a few moments. This knowledge will help you perceive if cold starts will impact you, and whether you might want to perform “keep alives” of your function instances to avoid them becoming cold.
You may ask ,are cold starts really a concern? Well, this depends on the style and traffic shape of your application. For example, if you were writing a low-latency trading application you probably wouldn’t need to use cloud-hosted FaaS systems at this time. You should test performance of your app to avoid problems by focusing on production-like load. If your use case doesn’t work, you may want to wait a few months and then try again to focus on this area of continual improvement by FaaS vendors.
Severless and No Ops
Serverless doesn’t mean “No Ops”. To clarify, “Ops” means monitoring, deployment, security, networking, support, and sometimes even debugging and system scaling. These problems all still exist with Serverless apps. In some ways Ops is harder in a Serverless world because of the new environment.
Benefits of Severless
Serverless has many benefits and drawbacks that can be incorporated into designing and deploying applications. Before using Serverless, always be sure to do your due diligence and weigh the pros and cons.
- Reduced operational cost: Serverless is a great outsourcing solution. This allows you to pay for a third party to manage servers, databases and even application logic that you would have done yourself. Also with using a predefined service that other people will also use, you will see an Economy of Scale effect. This is simply paying less for a managed database because one vendor is running thousands of very similar databases.
The reduced costs appear to you as two aspects. The first are infrastructure cost gains that come purely from sharing infrastructure with other people. The second are labor cost gains, which is the ability to spend less of your personal time on an outsourced Serverless system than on an one you have to develop and host by yourself.
- BaaS: reduced development cost. IaaS and PaaS are based on the premise that server and operating system management can be commodified. Serverless Backend as a Service is a result of entire application components being commodified.
Some mobile application teams have found that it is successful if the client is able to communicate directly with a server-side database. A BaaS database takes away much of the database administration overhead, and usually provides mechanisms to undertake appropriate authorization for different types of users, in the patterns expected of a Serverless app.
Dependent of your background, these ideas might make you a tad apprehensive, however there is no denying the number of successful companies that have been able to produce compelling products with hardly any of their own server-side code.
- FaaS: scaling costs
Another positive feature of Serverless FaaS is that horizontal scaling is completely automatic, elastic, and managed by the provider. There are several positives to this component, but on the basic infrastructural side the most applicable benefit is that you only have to pay for the compute that you need. This can be down to a 100ms boundary in the case of AWS Lambda. Also, depending on your traffic scale and shape this can be a huge economic win for you and your team.
For example, some of the following additional benefits surround this concept:
- For would-be microservices that have very small and basic load requirements, it provides support to breaking down components by logic or domain. This is even possible if the operational costs of such fine granularity might have been otherwise prohibitive.
- Such cost benefits are also a great democratizer. If more companies or teams want to try out something new, they only have to worry about very small operational costs associated with introducing themselves to starting to use FaaS for their compute needs. In fact, if your total workload is relatively small (but not entirely insignificant), you may not need to pay for any compute at all due to the “free tier” provided by some FaaS vendors. This a great win for small startups looking to optimize or even small business owners looking to branch out into different areas. Example: inconsistent traffic
- Here is one example that is crucial to this: If your traffic profile is very spiky and that your baseline traffic is 20 requests per second, but that every five minutes you receive 200 requests per second for 10 seconds. Assume, that your baseline performance maxes out your preferred host server type, and that you don’t want to reduce your response time during the traffic spike phase.
- In a traditional environment you may also need to increase your total hardware count by a factor of 10 over what it might otherwise usually be to handle the spikes. This should occur even though the total durations of the spikes account for less than 4 percent of total machine uptime. Please note that auto-scaling is likely not an ideal option here because of how long new instances of servers will take to come up. For example, by the time your new instances have booted the spike phase will be over.
- However, With Serverless FaaS this concern becomes a non-issue. In fact, you literally do nothing differently than if your traffic profile was uniform and, to cap it off, you only have to pay for the extra compute capacity during the spike phases.
- Clearly the above bullet points have been picked to promote and depict how Serverless FaaS could potentially provide your team with enormous cost savings. But it is also beneficial to point out that from a scaling viewpoint, unless you already have a very steady traffic shape that consistently uses the whole capacity of your server hosts, then you may be able to save money using FaaS.*
*There is one caveat about the above to consider. If your traffic is uniform and would consistently make good utilization of a running server, there is the possibility that you may not see this cost benefit. This would mean that you may actually spend more by using FaaS. As stated before, it makes since to weigh the costs and benefits of FaaS and to compare current provider costs with the equivalents of running full-time servers to see whether costs are acceptable.
- Optimization is the root of some cost savings. Here is another interesting point to mention about FaaS costs. This aspect notates that any performance optimizations that you make to your code will not only increase the speed of your app, but it will also have a direct and immediate link to reduction in operational costs. This is of course subject to the granularity of your vendor’s charging scheme. For example, say an application initially takes one second to process an event. If, through code optimization, this is reduced to 200 ms, it will (on AWS Lambda) immediately see an 80 percent savings in compute costs without making any infrastructural changes.
Easier operational management. One last point to mention lightly touches on the management side of things. On the Serverless BaaS side of the fence, this is fairly obvious why operational management is more simple than other architectures. This means that supporting fewer components equals less work.