The Compile Driver
The Compile Driver is a new thrill ride at the Coderland theme park. It starts by hoisting riders to the top of an enormous tower. From there, they plunge through the air towards the reinforced concrete pad at the base of the ride. Unfortunately, as the Compile Driver’s safety record has become public knowledge, ridership has fallen far short of expectations. Here's a video that explains the complete scenario:
With the park’s revenue targets at risk, management turns to you, the most talented developer in all of Coderland, to create a photo booth that captures the faces of delighted riders as they plummet helplessly to the ground. You’ll create a serverless function to take raw image data from a camera planted next to the ride, then stamp a message, the date, and the Coderland logo on the picture. Guests can, of course, purchase a copy of the heirloom-quality photo as they stagger away from the ride, filling the park’s coffers in the process.
The overall flow looks like this:
Your assignment is to take something like this picture of a happy Coderland guest:
...and transform it into this priceless memento, available for $19.95 at the Coderland Swag Shop:
Many early riders of the Compile Driver asked for a souvenir photo of their ordeal, something they could share with their friends, loved ones, and attorneys. For that reason, we believe the Coderland Photo Booth will be a smashing success.
A brief word about serverless
The main reasons for using serverless computing are more economic than technical. In the case of the Compile Driver Photo Booth, the code only needs to run for a second or two each time we find enough hardy souls willing to be strapped onto the ride. That means that even on a busy day, the code might not run more than a few minutes total. Setting up a server that runs 24/7 to host the image manipulation code means that the vast majority of the time we’re paying for processing power that isn’t being used. Even more troubling, if we maintain our own server, we’re responsible for keeping it up-to-date with patches and upgrades.
That’s what gives serverless computing its power. We don’t pay per minute, we pay per invocation. So as with most of cloud computing we only pay for what we use, but we use far less than before. We’ll deploy a service to Knative, and Knative will start and stop the service as needed. If we don’t call the image manipulation code for some period of time, Knative shuts it down. You’ll hear the phrase scale to zero often as you work with serverless computing. The service still exists, it’s just not running. When we do call the service, Knative fires it up. And, as the word “serverless” implies, we don’t have our own server to manage or maintain.
Getting from here to there
To help you complete your assignment, we’ll go through four steps:
Review the image manipulation code that works with the actual photo (covered in part 2)
Take a look at a React front end that lets you test the image manipulation code easily (covered in part 2)
Deploy the image manipulation code to Knative running inside Kubernetes (covered in part 3)
Work around an issue that prevents the React front end from calling the service inside Knative (covered in part 3)
Along the way we have more videos, git repos, Docker images, and other useful resources. Good luck and have fun!
We'd love to hear your comments and questions on this content. You can reach us at firstname.lastname@example.org.
Beyond that, there are two more articles in this series:
Be aware that the two articles are independent. You can run the image manipulation service without deploying it to Knative, and you can skip directly to the Knative article without having gone through the code.
But seriously, you should ignore all of your responsibilities and obligations and go through both articles now. Have fun!