Serverless is the emerging trend in software architecture. 2016 was a very exciting year for serverless and adoption will continue to explode in 2017. This post covers the interesting developments in serverless space in 2016 and my thoughts on how this space will evolve in 2017.
What Is Serverless?
In my opinion, Serverless means two things:
Serverless was initially used to describe fully hosted services or Backend-as-a-Service (BaaS) offerings where you fully depend on a third party to manage the server-side logic and state. Examples include AWS S3 (storage), Auth0 (authentication), AWS Dynamo (database), Firebase, etc.
The popular interpretation of Serverless is Functions-as-a-Service(FaaS) where developers can upload code that is run within stateless compute containers that are triggered by a variety of events, are ephemeral, and fully managed by the cloud platform. FaaS obviates the need to provision, manage, scale or manage availability of your own servers. The most popular FaaS offering is AWS Lambda, but Microsoft Azure Functions , Auth0 Webtask, and Google Cloud Functions are also coming up with fast-maturing offerings. IBM OpenWhisk and Iron.io allow serverless environments to be set up on-premise as well.
This post will focus more on FaaS and especially AWS Lambda, since it is the leader in this space with the largest feature set.
Serverless vs. PaaS
People are comparing serverless and Platform-as-a-Service (PaaS), which is an invalid comparison in my opinion. PaaS platforms provide you the ability to deploy and manage your entire application or microservice. PaaS platforms will help you to scale your application infrastructure. Anyone who has used a PaaS knows that while it reduces administration, it does not do away with it. PaaS does not really require you to re-evaluate your code design. In PaaS, your application needs to be always on, though it can be scaled up or down.
Serverless, on the other hand, is about “breaking up your application into discrete functions to obviate the need for any complex infrastructure or it’s management”. Serverless has several restrictions with respect to execution duration limits and state. Serverless requires developers to architect differently, thinking about discrete functionality of each component of your application.
New Features From AWS for Serverless
- Lambda@Edge: This feature allows Lambda code to be executed on global AWS Edge locations. Imagine you deploy your code to one region of AWS and then are able to run it in any of the dozens, and soon hundreds, of AWS Edge locations around the globe. Imagine the reduction in network latency for your end users.
- Step Functions: Companies that adopt serverless soon end up with thousands of functions. The logic and workflow between these functions are hard to track and manage. Step Functions allow developers to create visual workflows to organize the various components, microservices, events, and conditions. This is nothing but a Rapid Application Development (RAD) product. I expect AWS to build a fully functional enterprise RAD based on this feature.
- API Gateway monetization: This is big deal in my opinion. There are various trends like:
- Startups are increasingly API-first.
- All enterprises and startups build dozens or hundreds of integrations with APIs.
- Fine-grained usage based billing based on API usage.
- Adoption of microservices architecture, which uses API contracts. This feature allows companies to start monetizing their APIs via the AWS Marketplace. And the APIs can be implemented in AWS Lambda in the backend. I expect to see a lot of “data integration,” “data pipeline,” and “data marketplace” companies try out this approach.
- AWS Greengrass: Extend AWS compute to devices. This feature enables running Lambda functions offline on devices in the field. This is another great feature that is extending the meaning of a “global cloud.” Most of the use cases for this feature are in the IoT space.
- Continuous deployment for Serverless: AWS CodePipeline, CodeCommit, and CodeBuild support AWS Lambda and enable the creation of continuous integration and deployment pipelines. Jenkins and other CI tools also have some plugins for serverless, which are improving all the time.
- API Gateway developer portal: Easily build your own developer portal with API documentation. Support as per Swagger documentation.
- AWS X-Ray: Analyze and debug distributed applications, commonly used with microservices architecture. X-Ray will soon get Lambda support and enable even easier debugging of Lambda logic flows across all the AWS services and triggers that are part of your workflow.
- Your code will increasingly run closer to clients. With Lambda@Edge, Greengrass, and Snowball Edge, you can truly “deploy once and run around the globe.” This is not just scaling horizontally but scaling up or down geographically. I expect customers to leverage this feature in some very interesting ways.
- Serverless frameworks will mature and allow easy creation of simple REST applications. I also expect vertical-specific serverless frameworks to evolve, especially for IoT.
- Monitoring, logging, and debugging for serverless will improve with cloud vendor solutions as well as frameworks providing capabilities. A good example is IOPipe, which provides a monitoring and logging capabilities by instrumenting your Lambda code.
- I expect all the continuous integration and deployment tool vendors to add increasing support for serverless architectures in 2017. Automated testing for serverless will become easier via frameworks and CI tools.
- With CloudFormation and Step Functions, AWS will try and solve the versioning and discovery problem for Lambda functions.
- Mature patterns will emerge for serverless usage. For example, some very common use cases today are image or video conversion based on an S3 trigger, backends for messaging bots, data processing for IoT, etc. I expect to see more mature patterns and use cases where serverless becomes an obvious solution. Expect lots of interesting white papers and case studies from AWS to educate the market on emerging use cases.
- AWS will allow users to choose to keep some number of Lambda instances always-on for lower latency with some extra pricing. This will start addressing the latency issues that some heavy functions or frameworks entail.
- API and data integration vendors will increasing use Lambda and monetized API gateways. An early example is Cloud Elements which has released a feature that allows publishing SaaS APIs as AWS Lambda functions.
There are open-source projects like Serverless, Chalice, Lambda Framework, Apex, and Gomix that add a level of abstraction over vendor serverless platforms. These frameworks make it easier to develop and deploy serverless components.
Some of these frameworks plan to allow abstraction across FaaS offerings to avoid lock-in to a single platform. I do not expect to see any abstraction or standardization that allows portability of serverless functions. Cloud vendors have unique FaaS offerings with different implementations. and the triggers/events are based on their own proprietary services (for example, AWS has S3, Kinesis, DynamodDB, etc. triggers).
Bots, IoT, mobile app backends, IoT backends, data processing/ETL, scheduled jobs, and any other event-driven use-cases are a perfect fit for serverless.
In my opinion, any service that adds agility along with a reduction in IT operations and costs will become successful. Serverless definitely fits into this philosophy and, in my opinion, will continue to see increasing adoption. It will not “replace” existing architectures but augment them. The serverless movement is just getting started, and you can expect cloud vendors to invest heavily in improving the feature set and capabilities of serverless offerings. The serverless frameworks, DevOps teams, operational management and monitoring of FaaS will continue to mature in 2017. There are a lot of emergent trends at play here — containerization, serverless, LessOps, voice and chat bots, IoT proliferation, globalization and agility demands. All of these will accelerate serverless adoption.