Using FaaS: implementing a web to print API
A couple of weeks ago I wrote a blog about experimenting with API’s based on Function as a Service technology. After quite some experimenting and testing I am proud to tell you today that we have released our first active service based on FaaS. During the last months, we collaborated with one of our partners to create a web to print application. After careful consideration, we decided to abstract a FaaS implementation of the API we used in this project. After some sprints, we managed to recreate the full API of the original project with just lambda functions.
We use this API as part of a web application that consists of a small game of which the outcome is used to generate a children’s book. The purpose of this book is to playfully assist young children with the first steps of reading. For this project, about one hundred individual pages were hand drawn by an illustrator. The outcome of the game is combined with additional user input and the result is used to fill and arrange the pages into a coherent story. Finally, a personalized and unique book is printed and delivered to the end user. The API we are discussing in this post is used to process the previously mentioned game outcome into a printable digital book.
From a technical perspective, this process posed some problems. Generating the books was rather resource intensive. This results in significant server loads when the printing files for a book are being generated. While at night, for example, the servers are almost idle. Moreover, a when a lot of books have to be created and processed simultaneously, problems can occur. The server might not be able to effectively process all concurrent requests. This results in the need to continuously have a powerful (and expensive) server available to adequately respond to high demand. This results in significant costs, for something you rarely use to its maximum capacity and might not even be enough to cover extreme situations.
This directly plays into the advantages of FaaS. First, it scales incredibly well, because complex tasks, such as generating print files for personalized books, can be distributed over all the resources of the cloud provider you decide to work with. Second, you only pay for the time your Lambda function (The Amazon implementation of FaaS) is running. This means you do not have to pay for resources you are not actively using. Finally, it reduces the costs of platform management. In some cases, it might even be possible to completely eliminate a webserver. In our specific case, the web to print API we designed, does not need a separate webserver anymore. Eliminating servers means that you do not have to worry about backups and security patches. So we set out to replace the current infrastructure with an architecture based on FaaS.
While the design of the new system was straightforward some aspects of the otherwise exciting new technology remain an issue. In our opinion platform dependency is, specifically, a concern. Lambda functions are currently not inter-operable between cloud providers. Up until now, we have mainly worked with amazon’s implementation. As the feature set of their implementation seems to be the largest while it remains a cost-effective solution. At the same time, we are closely monitoring intermediaries that are currently under development.
All in all, experiences so far are positive and we can not wait to apply this new technology to new fields. In the upcoming weeks, we hope to release an in-depth review of FaaS performance. As well as a, best practices guide on the subject of FaaS & lambda functions. Currently, we are looking for organizations that are interested in co-creating more web to print solutions based on our API. Moreover, we are looking towards applying our technology in new fields.
If you liked this, click the green heart below so other people will see this here on Medium. Also, if you have any question or observation, use the comment section to share your thoughts/questions.
