Originally published on Medium
Although the cloud has revolutionized the way we manage applications, many companies still view their systems in terms of servers — even though they no longer work with physical servers. What if you take the concept of servers out of the equation and begin to think of cloud-based applications as workflow, distributed logic, and externally managed data stores? This report examines the new Serverless approach to operations.
Like many trends in software, there’s no one clear view of what Serverless is. For starters, it encompasses two different but overlapping areas:
- Serverless was first used to describe applications that significantly or fully incorporate third-party, cloud-hosted applications and services, to manage server-side logic and state. These are typically “rich client” applications — think single-page web apps, or mobile apps — that use the vast ecosystem of cloud-accessible databases (e.g., Parse, Firebase), authentication services (e.g., Auth0, AWS Cognito), and so on. These types of services have been previously described as “Backend as a Service” or “BaaS”.
- Serverless can also mean applications where server-side logic is still written by the application developer, but, unlike traditional architectures, it’s run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a third party. One way to think of this is “Functions as a Service” or “FaaS”. AWS Lambda is one of the most popular implementations of a Functions-as-a-Service platform at present, but there are many others, too.
Despite the name, it does not actually involve running code without servers. The name “serverless computing” is used because the business or person that owns the system does not have to purchase, rent or provision servers or virtual machines for the back-end code to run on.
With Serverless comes the following:
- No server management (no need to manage any form of the machine)
- Pay-per-execution (never pay for idle)
- Auto-scale (scale based on demand)
- Function as a unit of application logic
Serverless pattern encourages development focus on well-defined units of business logic, without premature optimization decisions related to how this logic is deployed or scaled. As a result, development focus is on a single function or module rather than a service with a large surface area. Serverless frees the software developer from deployment concerns and allows them to focus on factoring the application following logical encapsulation lines.
A typical example is an image uploaded to a file store, this event calls a serverless function which creates a thumbnail and stores this thumbnail back into the file store as well as recording the thumbnail location in NoSQL databases. The insert into the NoSQL database could then trigger further functions. This thumbnail creation function only runs on demand and the only cost incurred is how many times the function is invoked. The function will scale out in real time if many people are uploading images and then scale to zero once they are done.
However, the downside is that system monitoring and debugging becomes difficult and is based on logging available from the service, vendor lock occurs especially when leveraging events from other services, while the serverless compute may be cheap the other services may not be, also deployment mechanisms and IDEs are not typically prepared to manage serverless functions.