Or is it?
While I usually write about the capabilities that we have in business automation, many of our customers are interested to know about our architecture and how we leverage the different cloud native technologies and approaches. So in the "42" series, I collaborate with the IBM Liberty Cloud Native Architect and Chief Advocate, Emily Jiang, to examine some of the cloud native technology pop culture to separate facts from fiction, and provide a better understanding on when to use them.
(Why “42”? scroll to the end)
What is Serverless?
Serverless has become a buzzword nowadays. You might be wondering what Serverless is exactly. Do we need to run all our cloud native applications as serverless? This blog will help you with these questions.
Serverless is a short name for Serverless Computing, which is an execution model in which the cloud provider allocates resources on demand. Serverless enables developers to concentrate on their own applications without the need of worrying about servers. It does not mean there is no server running in the background. On a contrary, normally Serverless architecture contains servers. There are pros and cons for the Serverless Architecture.
- Cost effective for public cloud - Serverless architecture enables applications to scale to zero and it only uses resources when there is workload.
- No need to manage server - Serverless architecture hides the server and abstract away the maintenance of the servers.
- Not managing your own server limits your flexibility - Serverless abstract away the maintenance of servers, which means that you are limited to the services the cloud provider has.
- Vendor lock-in - Since your application chooses the services provided by a particular Cloud Provider, your Serverless deployment might not work on another Cloud Provider.
Serverless normally execute code in the form of a function. Therefore, serverless is sometimes referred to as “Functions as a Service” (FaaS). Below are the FaaS offering from major cloud provider:
- IBM Code Engine: IBM Cloud Function
- AWS: AWS Lambda
- Microsoft Azure: Azure Functions
- Google Cloud: Google Cloud Functions
You might be wondering whether Serverless is suitable for all kinds of applications or deployment environment.
What is Serverless for?
First, Serverless is a deployment architecture for public cloud infrastructure with the intend of cost saving. Serverless normally uses event to trigger your application to run. When there is no trigger, the application can scale to zero, which means no resource consumption. To respond to the event in a timely manner, the application must start fast. If it takes too long such as seconds or minutes to start up, it would have defeated the intend of Serverless. The Serverless model is like the Pay-as-you-go package for your mobile. When using Pay-as-you-go, you normally only send texts or making phone calls when there is absolute need. In this way, you will be able to keep the cost to the minimum.
If you have decided to go with serverless, the next question is that what kind of application architecture should be adopted.
- Microservice architecture - Since the application will run as a function, it works better to have a small dedicated application, such as microservice.
- Stateless - Since serverless will scale to zero when not invoked, there will be frequent start and stop. Every time on start, a brand-new container will be created, so none of the previous context will be kept.
- Fast - Serverless will need to start up and vamp-up fast so that some cost can be saved. If it takes too long to start up or shut down, serverless won’t be useful at all.
The cost of Serverless
There is a common misconception that “serverless is free”. The misconception is likely from the ideal behind “scale to zero”, i.e., if I can scale my services to zero, I am not paying anything when it is not being used. That is certainly true, provided you are not also the serverless infrastructure provider. To host a serverless infrastructure, one would have to run KNative and Kafka, both of which are not free - as in order to handle the serverless request, the serverless infrastructure must be running.
Another consideration is the purpose of a solution is to solve a business problem, not to “scale to zero”. We should always optimize first for when the service is being used, but not optimize for when it will not be used. “serverless” is not an excuse to write sub-optimized code or code that will not scale efficiently. For a service that will be used often or constantly, there is almost no benefits to serverless as the server will likely never “scale to zero”. Not to mention if you’re responsible for running the serverless infrastructure, you have to pay for the unnecessary infrastructure cost as well.
Serverless and IBM Cloud Pak for Business Automation
Serverless is not just a technology limited to the technologically savvy or those who want to write their solution cloud native solutions. We believe serverless can be beneficial if it is applied for the right reasons. With IBM Cloud Pak for Business Automation, many of our clients are running services that will be constantly used by 10s or 100s or 1000s of concurrent users, in those cases, the overhead of the extra serverless layer will likely be decremental to the overall total cost of ownership. On the other hand, we are looking at how we can take advantage of serverless technology, particular in our own Software-as-a-Service (SaaS) offering so we can optimize our operating cost in those areas where occasional use is common. Another potential area that we are investigating is to support developers deploying serverless services as functions to extend the Cloud Pak, such as Event Handler for FileNet document events, without tying to the Cloud Pak system lifecycles.
Hopefully by now you have some basic understanding of Serverless, what is it good for, and when and how the technology should be applied.
For those science fiction fans who have read the The Hitchhiker’s Guide to the Galaxy by Douglus Adams, the number “42” is the “Answer to the Ultimate Question of Life, the Universe, and Everything” as calculated by the supercomputer Deep Thought after thinking about it for 7.5 million years. We are hoping this series can help answer some of your lifelong questions about cloud native technologies and discuss the proper places to use them.