What is the cloud? The joke I always used to hear is that it’s “just someone else’s computer”. Well, if a public cloud is just treated like any other data center, with VMs and servers running statically 24x7x365, I could see how someone would be inclined to say that. But the value in using a public cloud is not about running a VM in a different data center. Workloads should not be run the same in a cloud as a typical data center.
To get the most value out of using a public cloud, more thought needs to be put into the ability to scale workloads and use only what is actually needed. As businesses modernize their workloads, they open themselves up to more technologies that lend themselves better to taking advantage of the value that a public cloud can bring.
Enter Knative serverless.
For those unfamiliar with the serverless computing concept, often referred to as Functions as a Service (FaaS), picture all underlying servers, clusters, and networking are abstracted away. Applications run when they are needed, or can be otherwise “off”. Using a serverless approach in a public cloud means that businesses are not spending time dealing with infrastructure and paying for the number of hours the worker nodes are provisioned.
Instead, businesses would focus on the applications and pay for the ms (yes milliseconds) of execution time that the application needs to respond to a request. For workloads that don’t need to run all the time, this could allow for it to scale down to 0 running instances when it is not needed. Knative brings these capabilities to Kuberentes and allows us to run container-based applications in a serverless fashion.
IBM, is one of the community maintainers of the Knative project. It is used as a foundation for their Code Engine service in IBM Cloud. Let’s dive deeper into Code Engine and how it can be used to run workloads.
To deploy Code Engine, find it in the Catalog under the Compute category. This will bring us to the Code Engine page where we can select “Projects” in the left side menu.
A project will be a collection of serverless resources that we want to group. Give the project a name, put it in a resource group and apply any necessary tags and then click “Create”. In a few seconds, the project will be created and we are ready to deploy our code.
Once in the project, we can see that there are two options for running our code:
- Applications – serve HTTP requests
- Jobs – run the code once and exit
These two options come from the underlying Knative components: serving and eventing. Let’s go into how both of these can be used.
Creating an Application
Creating an application is simple. Click “Create Application”. From here you can specify the container image from a registry or a git repository to have the application be built from source code.
Specify details such as whether the application should be exposed on the internet or a private network in a VPC. Runtime settings allow for the control over the number of instances, triggers for scaling as well as the number of resources an instance gets. Click “Create Application”.
We can see that since I set the minimum number of instances to 0, Code Engine will scale down my application pretty quickly to have nothing running, meaning I am not paying anything. I can test the application by clicking the “Test Application” button and then clicking “Send request”.
We can see the Hello World output but more important the latency of the response. It was a bit higher than what we would normally want. Since this was scaling from 0, Code Engine automatically created an instance of the application for us when it detected the request coming in and it took a few seconds to complete. Subsequent requests would be much lower. We can avoid this first request delay by setting the minimum scale to 1 so there is always at least one instance running.
If we want to test the scaling further, a load testing tool such as Siege can be used to generate requests against our Code Engine application forcing it to scale up (and down) with the load.
Creating a Job
Creating a job is almost identical to creating an application. There is no need to specify the endpoint since there is no need to access the job. Jobs can be run manually, but are more useful when paired with another Code Engine feature called “Event Subscriptions”. These are triggers that will run the job when the event happens and pass the job information about the event. The two types of events that can be used are timers and changes in Object Storage buckets. As an example, I have used the Object Storage event subscription to trigger my job and pass it the name of an uploaded object as part of an ETL process. Pretty neat.
Serverless computing is the best showcase of the value a public cloud can offer. Truly pay for what you use while scaling with ease. It will be interesting to see how serverless technologies transforms the way we think about running applications in the future.
The Cloud Guy 