If time be of all things most precious, wasting time must be the greatest prodigality, since lost time is never found again; and what we call time enough always proves little enough. Let us then be up and doing, and doing to a purpose; so by diligence shall we do more with less perplexity
Benjamin Franklin
Once upon a time, I bought digital things in physical formats to play on physical devices. Whether it was music or film, I put a physical thing into physical media player. When things went well, it was a very satisfyingly experience. However, when the media device was scratched or the player decided to act up, it was anything but pleasant. Adding to the annoyance was the fact that all those CDs and DVDs began to take up a lot of room — especially movies I only played once or bands I outgrew. What was once a small bookshelf of disks became bookshelves, boxes, and piles of uncategorized and practically unsearchable entertainment.
All those pain points went away when streaming music and video services came into being. I can now switch from Bach to The Beach Boys in seconds. In addition to all that saved time, I now spend a fraction of what I once spent on aural and visual stimulation. My monthly subscription for Netflix is less than a what I typically paid for a single DVD let alone the handful I purchased every week or so.
Programming Life
For the past several years, I have been paying GoDaddy for a Linux server that I use for my software creations. With GoDaddy’s ala carte approach to cloud services, I purchased a fixed amount of CPUs, RAM, and storage that was mine to do with as I saw fit. The “seeing fit” part included everything I had to do to build, configure, and maintain an environment for application development. That included obtaining and managing security certificates, loading and updating runtime services, scaling my software, etc. As with my digital entertainment, when thing went the way they were supposed to, I was a happy programmer. Sadly, I can name too many times when everything broke at the wrong time. If you are ever interested in how many things can go awry when a certificate expires, I have stories not suitable for the faint of heart.
Like those CDs and DVDs, I was ready to move on from my bare metal programming ways. I wanted a platform that allowed me to focus my time and energy on programming logic and not the plumbing required for that logic to run.
Avaya Virtual Agent
My most recent job at Avaya has me working with our Virtual Agent (VA) platform. In it’s most simplistic form, VA is a cloud IVR (Interactive Voice Response) system — “Press 1 or say Agent to speak with a customer support representative.” In it’s more sophisticated form, it’s an open platform that allows enterprises to create customer experience workflows that connect people with a myriad of backend services. These services range from Customer Relationship Management (CRM) systems to traditional databases to just about any cloud service you can think of (Salesforce, ServiceNow, etc.).
In particular, my job has been to help build these integrations and surround them with VA scripts. At first, I did what I always did. I wrote a node.js service and ran that service on a particular port on my GoDaddy Linux server. As before, I did all the heavy security, scaling, and reliability work. That quickly became a complicated and convoluted process as I was asked to support the many use-cases that were being thrown at me. All the different permutations were eating up ports, RAM, CPU, and most importantly, my time. Something had to change.
Living the Serverless Dream
Enter serverless computing. Of course, we haven’t reached the stage where a physical infrastructure isn’t required to run software — i.e. we haven’t created the vapor-computer…yet. By serverless, I mean a development and runtime platform where I don’t care what the operating system is, who supplies and maintains the certificates, or how clever I need to be to scale my code and ensure that it’s available every time someone invokes it.
There are quite a few serverless computing platforms to choose from, but because of my experience using AWS, I chose to start writing my integrations on AWS Lambda. Quoting Amazon:
AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume – there is no charge when your code is not running. With Lambda, you can run code for virtually any type of application or backend service – all with zero administration. Just upload your code, and Lambda takes care of everything required to run and scale your code with high availability. You can set up your code to automatically trigger from other AWS services or call it directly from any web or mobile app.
This is exactly what I need to support the use cases I have been asked to develop in a timely and cost effective manner. Better yet, this is a far more realistic ask for the customer base of Virtual Agent. Not every enterprise has a pool of virtual servers that can be repurposed and configured for VA integrations.
While Lambda doesn’t eliminate the need for a programmer to write code, the amount of code that needs to be written shrinks to the bare minimum. The software becomes a microservice that implements the business logic of the integration. Everything else is left up to Lambda.
The Nearly Nitty Gritty
Rather than going into all the details of building a Lambda solution (I am saving that for my next article), here are a few of the most important steps:
- Write your code in the language of your choice. This code consists of the business logic of your integration. For example, if all you need to do is pull data from a database, the code might be limited to some SQL (e.g. “Select * From Table Where id=xyz”), packaging the returned dataset into a JSON object, and sending the object back to the API caller.
- Create a zip file. The zip contains your code, any external libraries referenced by your code, and a package.json file.
- Create a Lambda function description. At the end of this step, Lambda provides you with a public link for the function.
- Upload your zip file into the function. This connect your code with the public link. Call the link and you call your code.
And that’s all there is to it. By following this recipe, I have been able to write several integrations of differing types in record time. Additionally, when I made a mistake (which is a regular event), the Lambda logging tools immediately led me to the error. A quick fix, another upload, and I’m flying.
Another benefit, albeit a very geeky one, is at no time do I have to Putty into a Linux server and run the myriad of the cryptic shell commands I am forced to drag out of my brain when things don’t go according to plan. No more “sudo fuser 3030/tcp” to find that rogue application.
Note: I am writing my integration microservices for Virtual Agent, but these are public web services that anyone can invoke. As most good programmers do, I always test my REST APIs with Google Postman. For example, here is an invocation of my Lambda service that obtains the current value of Bitcoin in various currencies.
Mischief Managed
Composability is combining disparate components from different vendors in order to create new and unique solutions. That is the world that serverless, microservices programing empowers. Lambda is one of many such platforms and all are embraced by Virtual Agent. This brings composable customer journeys to any enterprise looking to build experiences that matter.
I hope this is enough to make you appreciate a little about serverless computing. As I wrote, I am saving the really technical stuff for my next article. Stick around if you want to see the previous four steps, plus a few more, detailed in a step-by-step manner. I promise not to disappoint even the nerdiest of nerds.
Tao, Zen, and Tomorrow 