In 1990s, Neal Ford (now at ThoughWorks) worked for a small company focused on a technology called Clipper. By writing an object-oriented framework based on Clipper, they built DOS applications using dBase. With their expertise in Clipper, they had a thriving training and consulting business. Then, all of a sudden the Clipper-based business disappeared with the sudden rise of Windows. With that, Ford and his team went scrambling to learn and adopt new technologies. “Ignore the march of technology at your peril” is the lesson that one can learn from this experience.
Many of us live inside technology bubbles: It is easy to get cozy and lose track of what is happening around us. All of a sudden, when the bubble bursts, we are left scrambling to find some new job or business. Hence it is important to stay relevant. In the 1990s that meant catching up with things like graphical user interfaces (GUIs), client/server technologies, and later the worldwide web. Today, relevance is all about being agile and leveraging cloud, machine learning, artificial intelligence, etc.
With this background, we delve into serverless computing, which is an emerging topic. In this article, we provide an introduction to serverless computing, serverless approach for your applications, key serverless technologies, and a brief discussion on limitations of the serverless approach.
Most of us remember using server machines of one form or another. We remember logging remotely to server machines and working on them for hours. We had cute names for servers-like Bailey, Daisy, Charlie, Ginger and Teddy-and took care of them fondly. However, there were many problems in using physical servers like these:
1. Companies had to do capacity planning and predict the future resource requirements
2. Purchasing servers meant big capital expenses (CAPEX) for companies
3. We had to follow lengthy procurement processes to purchase new servers
4. We had to patch and maintain the servers
Cloud and virtualisation provided the level of flexibility that physical servers lacked. We didn’t have to follow lengthy procurement processes, who “owns the server,” why only that team has “exclusive access to that powerful server,” etc. Procurement processes for physical machines became obsolete with virtual machines (VMs) and cloud. The way we architected also changed. For example, instead of ‘scaling up’ by adding more CPUs or memory to physical servers, we started ‘scaling out’ by adding more machines as needed in the cloud. This model gave us the flexibility of operational expenses-based (OPEX-based) economics model. If any of the VMs went down, we got new VMs spawned in minutes. In short, we started treating servers as ‘cattle’ and not ‘pets.’
However, cloud and virtualisation also came with their own problems and still have many limitations. Users are still spending a lot of time managing them, for example, bringing VMs up and down based on their need. They have to architect for availability and fault-tolerance, size workloads, and manage capacity and utilisation. If they have dedicated VMs provisioned in the Cloud, they still have to pay for the reserved resources (even if it’s just idle time). Hence, moving from CAPEX to OPEX is not enough; what users need is to “really only pay what they are using” and “really pay as they go.” Serverless computing promises to address exactly this problem.
Another key aspect is agility. Businesses today need to be very agile. Technology complexity and infrastructure operations cannot be used as an excuse for not delivering value at scale. Ideally, much of the engineering effort should be focused on delivering functionality that delivers the desired experience, and not on monitoring and managing the infrastructure that supports the scale requirements. This is where serverless shines.
What is serverless?
Consider a chatbot for booking movie tickets-let’s call it MovieBot. Any user can query about movies, book tickets or cancel them in a conversational style; for example, “Is Dunkirk playing in Urvashi Theatre in Bangalore tonight?” in voice or text.
This solution requires three elements: a chat interface channel (like Skype or FaceBook Messenger), a Natural Language Processor (NLP) to understand the user intents (book a ticket, ticket availability, cancellation, etc), and then access to a backend where transactions and data pertaining to movies are stored. The chat interface channels are universal and can be used for different kinds of bots. NLP can be implemented using technologies like AWS Lex or IBM Watson. The question is: How is the backend served? Would you set up a dedicated server (or a cluster of servers) and an API gateway, deploy load balancers, put in place identity and access control mechanisms, etc? That’s costly and painful, right! That’s where serverless technology can help.