Columbia University Fall 2016 “Serverless Cloud Applications” (Draft)

(Update — Lecture slides posted on this blog).

Serverless Cloud Applications


This course will cover core topics in designing, developing, deploying and delivering serverless cloud applications. Serverless is the natural, and perhaps inevitable, endpoint of cloud computing’s evolution from IaaS, SaaS and PaaS. The core class material will come from Serverless Architectures on AWS, by Peter Sbarski with Sam Kroonenburg. Other web resources provide technical material on serverless applications, for example:, “Serverlessconf – The future will be serverless,” “Serverless” by Martin Fowler and “Serverless: The Future of Software Architecture? — A Cloud Guru.” Figure 1: Serverless Concepts from “Serverless: The Future of Software Architecture?” depicts an overview of the concepts. The figure appears to be a standard depiction of multi-tier web applications. The core transformation of serverless is the invisibility of physical, virtual of software middleware servers. This lack of explicit servers profoundly changes and improves all aspects of application design, development, deployment and optimization.

(Click Image for better resolution)


Figure 1: Serverless Concept

The course will cover key serverless concepts and technologies in the context of a concrete, real application that a startup is developing and delivering (Figure 2: Solution Overview). The solution provides interactive and collaborative video streaming. Other features the solution provides and the course will cover include content management, integration with social media (e.g. FaceBook, Twitter), OAuth2 federated security, data analytics and insight into customer usage and behavior, programmable web, and integration-platform-as-a-service, mobile-backend-as-a-service (MBaaS).

(Click image for better resolution)


Figure 2: Solution Overview

Coursework will be a small number of design and implementation projects, each of which builds on previous projects. The design documents, code reviews and demos will determine project grading.

An initial outline of lectures is below, although rate and pace in class and emergence of new information will determine the actual schedule.

Lecture Agenda:

  1. Core Concepts: services, micro-services, serverless and serverless technology (AWS Lambda, Google Cloud Functions and Microsoft Azure Functions.
  2. APIs: Design patterns for REST APIs, API Management, implementation design patterns and frameworks.
  3. Data-as-a-Service: AWS Aurora, DynamoDB, Google Bigtable, Google Firebase, …
  4. Security and Authentication: OAuth2, Amazon Cognito, Auth0, …
  5. Social Media Integration and APIs
  6. Service Integration: AWS SNS, AWS SQS, Google Pub/Sub, Microsoft Azure Queue Service, …
  7. Cloud Based Integration and Integration-Platform-as-a-Service: SnapLogic, Azure App Services, …
  8. Content Management and Delivery: content management systems, digital media delivery, content distribution networks.
  9. Real-Time Collaboration Services: XMPP, OpenFire, Jabber, …
  10. Cloud Data Insight: Google Analytics, data models, Apache Spark, Presto, …

Application design, design patterns, continuous delivery and application testing/assurance will be a comment topic woven through all lectures and projects. A centerpiece will be cloud-based testing using Load Impact.

Observations on AWS Lambda Development Efficiency

We are nearing completion for “alpha” for the project I discussed at I have started doing stress and loading testing for some scenarios. Some observations:

  1. Load Impact is an excellent tool. The product is extremely easy to use. Defining and configuring tests is quick, intuitive and easy. I can build complex test scenarios in Lua with a small subset of the language. The Load Impact library is complete and simple to use. I was initially not thrilled to learn a new language, but Lua is extremely interesting and is also the language for extending Redis. Redis, especially in AWS, is core technology for scaleable apps.
  2. There was a startup learning curve for AWS Lambda, which our use of Java compounded. There was an initial, one time productivity hit relative to using technology compared to alternatives with which we have experience (e.g. Tomcat). This has been more than offset by the total absence of work necessary to define, configure, operate and monitor server technology for unit test, integration test and load/stress testing. We have done no configuration or operation, and use the same logic environment for unit test, integration test and stress testing. We just change some parameters in Load Impact, and the same client config drives the same “server” config. My guess is that these capabilities are increasing our development efficiency by at least 20%. Our IT dev, test and delivery “hardware” is basically our laptops. Everything else is serverless.
  3. We have amused many people with our use of “archaic” technology, specifically Java and relational databases (MySql). Mark Boyd’s article on the serverless conference correctly observed that the majority of serverless projects are startups or leading edge, or in areas adjacent to core web applications/business logic (e.g. image, cognition).  Java and RDB support provide an onramp for more traditional enterprise app developers, and the development efficiency we observed should accelerate enterprise adoption.

The “self-tuning” nature of AWS Lambda is impressive (see figure). The scenario ramped from 0 to 500 users in 5 minutes. We got some 504 errors (gateway timeout) during the ramp up. This is the first time we saw these errors, because previous tests ramped up over 10 minutes. The yellow line is failure rate, which quickly goes to zero. Req/s tails off at the end because the test is shutting down. RT and total virtual user scenario time relatively quickly stabilizing after some bumpiness.


Lambda Auto Tuning

All of this indicates significant productivity and optimization as we start going into application delivery.