Lower Your Operational Costs
With serverless, you only pay for what you use, when you use it. Even for applications that have a sustained use, the generous serverless "free tier" may prove more cost effective than running on traditional servers or containers. With serverless, the responsibility of maintaining server or computer infrastructure is off-loaded to the cloud provider. With economies of scale at play, you enjoy the lower costs vs running/maintaining your own compute (on-premise or in the cloud).
Enable Better Software Design and Cost-Per-Functionality Visibility
With serverless, the OS or the host is abstracted from the application. Engineers cannot make an assumption about the host or use any of the host features. This drives a more portable design that is not tangled with the underlying compute infrastructure. Additionally, it's easy to price each function based on its footprint and it usage. This too drives a leaner and more performant design as running costs associated with each function or functionality are readily available.
Functions are great for short running workloads. One common use case is to use functions to house your APIs that are used by your mobile and web apps. The inherit stateless, request-response nature of web apps requires your APIs to be stateless while providing a response in a short period of time. Although functions can run for longer periods (5 minutes or longer depending on the provider) the costs quickly add up and we do not recommend a large-scale deployment of functions with execution times over 40 seconds. Additionally, functions are best when their footprint (memory consumption, number of dependencies, etc.) is low.
For longer running workloads, applications with larger memory footprint, and latency sensitive workflows we recommend containers. Thanks to container-orchestration made available as a service (AWS Fargate and Azure Container Services), running your own container loads is easier than ever. The cloud provider manages the hosting, scaling, and orchestration -- you just provide the containers to run.
One thing to keep in mind with functions and containers is the level of abstraction from the host. If you require native OS functionalities (for example, your existing code is using legacy DLLs or other native libraries) then you may need to look at hosting your code on traditional servers, or refactoring your code.
AWS or Azure? I want to bet on the right horse.
Both AWS and Azure provide competitive serverless offerings and you can rest assured that both are great options. While AWS does enjoy a wider usage(1), there are other things to consider when selecting the right cloud provider and stack: your existing stack, skill set, wider cloud usage by other BUs and sister companies, pricing and availability of specific components, etc.
Vendor Lock and Use of "Bleeding Edge" Technologies
While serverless is one of the newer kids on the block, it is far from "bleeding edge". The technology has been around for years, and many companies run production workloads using serverless. While AWS lambdas and Azure functions are indeed different implementations of the same concept, due to the fact that serverless provides no access to the OS, the code is inherently more portable. For this reason, migrating a serverless function to another cloud provider, a Docker container, or traditional server is normally a straight forward process. Lambdas and Azure functions as containers provide very little in a way of functionality that is exposed to your application code. This drives your engineers to write leaner code that is inherently infrastructure or host agnostic.
(1) Microsoft lumps their Azure product line with Office 365 and other products, together forming their "commercial cloud". It is true that overall the platform is doing well and is growing, however how much of it can be attributed to Azure is not public knowledge.
While our clients come from every corner of the globe, we have developed a set of options and solutions for our Canadian clients which take into account the Canadian data residency requirements.