The Fairway Technologies Blog


The CTO’s Quick Guide to Serverless

In No Comments

Serverless is the next evolution of cloud computing. You good? Seriously, I’m sure you’re busy, but let’s see if we can get you up to speed and talking about Serverless in your next meeting. Fair warning—"Serverless” is a catchy and clever term that comes with hype and some confusion. Let’s take the next 10 minutes to clear a few things up and get you rolling with Serverless.

You know the cloud; it has provided infrastructural outsourcing through economy of scale and technology improvements for quite a while now. Infrastructure as a Service (IaaS) offers outsourced networking, storage, virtualization, and servers. Platform as a Service (PaaS) adds the runtime, middleware, and operating system to the mix. The cloud is “pay-as-you-go” and you rent compute capacity rather than buying your own machines. There’s no more resource procurement, capacity planning or patching, which leads to reduced labor and resource costs, along with reduced risk, increased flexibility of scaling, and shorter lead time. I know that you know…

So, the cloud has been good to us, but even an elastic, outsourced infrastructure has servers (virtual or physical) that need to be allocated, provisioned, set up, shut down, and managed. When we could be focused on software logic, data integrity, and security, we still spend time and money on servers. Software as a Service (SaaS), with hundreds of outsourced business offerings like Office 365, Atlassian Cloud, Salesforce Cloud, and GitHub, removed some of the remaining server management (and SDLC) burden, but Serverless takes us a step further. Still with me?

Does Serverless mean that servers go away? Nope, but Serverless shifts server management entirely over to providers so we don’t need to worry about servers anymore. How so? Well, Serverless is an aggregate of techniques and technologies which are grouped into two areas—Backend as a Service (BaaS) and Functions as a Service (FaaS). Let’s dig in some more.

BaaS may already be familiar. If you have avoided custom code and self-hosted server-side logic in favor of a cloud-based component—which provides a highly-available backend that can be set up with barely any configuration and can scale almost infinitely—you have a Serverless architecture in place. For example, BaaS services like Auth0 and Amazon Cognito provide fully-featured authentication and user management. Google Firebase and AWS DynamoDB are popular Serverless NoSQL options. Mailgun outsources email processing and Stripe, which provide the infrastructure required for online payment systems, are BaaS services.1 Not to be confused with SaaS, but modern applications integrate with third-party services through an API often enough that BaaS hardly gets the recognition that it deserves. After all, BaaS is one half of the Serverless equation, but maybe outsourcing application backend components (their hosting and coding) completely is just too practical to drum up excitement.

On the other hand, FaaS is as exciting as BaaS is commonplace. FaaS is a new way of deploying custom server-side business code to an environment, which can auto-scale and auto-provision, and execute your code when an event is triggered. That’s the buzz. AWS Lambda (which seems almost ubiquitous with Serverless at times) is the leading platform, but there are also Microsoft Azure Functions, Google Cloud Functions and others. Individual functions may be written in JavaScript, Python, Go, any JVM language or .NET language. They are event-triggered per an HTTP request, scheduled task, message added to a message queue, or provider-specific events like an S3 file/object update. FaaS code that’s triggered per an HTTP request has the feel of a microservices architecture where infrastructure concerns (machines, VMs, containers) are no longer in the picture. FaaS is inherently stateless which facilitates the auto-scale and auto-provision based on load. There are resource limits per invocation for memory and disk usage, and execution duration is capped (e.g. Lambda limits processing to 5 minutes), but FaaS meets the need for the majority of backend processes. Some people are concerned with FaaS’s startup latency and “cold starts” (initializing a function with a new container or host process rather than using a previous event instance). Others talk about immature tooling around monitoring and debugging, and whether or not FaaS platforms integrate particularly well with the typical development cycle—though technical advances will likely address any real concerns in due time.2 There’s more to it, but that’s FaaS from 10,000 feet.

And that’s Serverless—two new forms of infrastructural outsourcing—where managing server hosts and processes is somebody else’s problem. With BaaS, the application components are entirely outsourced to a third-party. With FaaS, all you need to worry about is writing the code/function; everything else is handled for you. The cloud trend of doing things cheaper and faster continues while your focus can shift toward custom software development (that’s the logic, security, and data I mentioned earlier) and away from the infrastructure that makes it run.

Thanks for reading—I hope it was worth the time. Enjoy your next meeting and I hope "Serverless" comes up.

1 I’ve seen cloud-hosted email and payment services being referred to as SaaS rather than BaaS. This may be because they existed before the term Backend as a Service was coined, but if there’s another reason why SaaS is a more appropriate categorization, let’s discuss. Heck, S3’s file/object storage is BaaS in my book.

If current processing constraints or the lack of monitoring, testing, and debugging options are a deal breaker, you might pass on FaaS and give containers a try instead. You aren’t familiar with containers? Containers aren’t Serverless but maybe that’s a pre-meeting huddle for another day.


New Call-to-action
New Call-to-action