Is ‘Serverless’ Architecture Ready for Prime Time?

There’s been a lot of attention paid to ‘serverless’ architecture, during a recent lightning talk at Intelliware I discussed what ‘serverless’ means, its advantages over other architectures and whether it’s mature enough to support production use.

‘Serverless’ refers to an abstraction layer over your traditional server-based architecture, where all server-side logic and state is managed. This does not mean that there are no servers at all, but rather these servers do not need to be managed or maintained, which makes the term ‘Serverless’ ambiguous. Better terms for this type of architecture are Function as a Service (FaaS) or Backend as a Service (BaaS).

Before going any further I would like to take a look at how we got here.

Back in the early 2000s, developers had to work with physical servers. These servers usually required a great deal of resources and physical space for racking and cooling. They needed manual updating, were often unable to handle multiple production environments, offered only slow iteration / deployment cycles, and could live for years, meaning replacements were unlikely due to the high initial outlay.

Once virtual machines became available, they provided vast improvements over physical servers such as support for multiple production environments, flexible life times, quick deployment, and offering the benefits of immutable production which allowed for experimentation and easy replacement.

Recently, containers became a production-ready solution, taking virtualization even further. Discrete applications were able to be moved into lightweight virtual containers hosted on physical or virtual machines. Infrastructure dependencies were abstracted away providing focus on app-specific dependencies.

Containers ultimately paved the way for serverless architecture. Instead of managing all the infrastructure yourself, you can now find various service providers who will do all the heavy lifting.

Keep in mind, however, that ‘serverless’ is often used to describe two overlapping areas: Function as a Service (FaaS), the focus of this post, or Backend as a Service (BaaS).

  • BaaS refers to third parties managing the server-side logic and state in the cloud
    • Includes services such as user authentication, push notifications and file storage
    • Used by rich client web/mobile apps via cloud-accessible services such as Firebase, Auth0, Parse and Heroku
    • The business logic lives in the client
  • FaaS refers to the running of back-end code without managing server systems or server applications
    • Running back-end code without managing server systems or server applications
    • Server-side logic still written by application developer and encapsulated in a function
    • Function source is uploaded to FaaS provider (e.g. AWS, GCP, Azure)
    • Function execution is triggered by event types defined by the provider
    • Executed in stateless compute containers
    • Container may only last as long as the function invocation
    • Function is unit of deployment

There multiple FaaS providers such as Google Cloud Platform, Amazon AWS Lambda and Microsoft Azure. Amazon leads with its FaaS solution AWS Lambda, the service executes the code only when needed, is scalable, requires zero administration, and can run code for almost any type of application, on high-availability, compute infrastructure.

The model for AWS Lambda is straightforward: write the function in any of the AWS Lambda provided languages such as JavaScript or Java, zip it, upload it to AWS and execute.

The function execution is triggered by event types such as database reads/writes, and can interact with the data sources that emitted the events (e.g. AWS file store service, S3). You can also specify the function resources, such as RAM and temporary disk allocation.

To deploy the full ‘Serverless’ solution for a web applications a service is required to manage incoming HTTP client requests. Amazon created AWS API Gateway to meet this need. This service manages incoming HTTP requests to the application and is resolved by triggering AWS Lambda functions.

So, is ‘serverless’ architecture mature enough to warrant adoption?

There are downsides, as there are for most things, including:

  • Complex and time-consuming integration testing
  • Debugging the code is very difficult
  • There can be latency issues if you have multiple lambdas running in series
  • The level of control is less fine-grained

But, consider the benefits:

  • Less server management
  • Ability to iterate based on functions rather than application
  • Only pay for computing time
  • Includes abilities such as auto-scale, monitoring, load balancing and caching
  • Pushes for the micro-service architecture of applications
  • Offers function versioning for CI/Prod
  • The Lambda and endpoints become easily disposable
  • It can piggyback off the AWS infrastructure

Overall, it seems that FaaS is a great solution for projects that require fast iteration cycles and that consider removing most infrastructure maintenance in order to focus mainly on product development. It is still an evolving technology, stay tuned for future improvements and tooling.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply