Here are your options — 9 Serverless services for your projects

There are more options than just the big three (AWS, Azure & Google Cloud)

I’ve been immersed in the world of serverless for quite some time now. It’s generally my go-to for quick implementations and getting things that need to be done, well, done.

While there are perks, it does come with its own special set of pitfalls.

Then there’s the task of selecting the right IaaS (Infrastructure as a Service) for the client/boss/project. There’s the obvious like AWS Lambda, Azure functions, and Google Cloud functions — but they’re not the only ones and there are other options out there with their own set of perks.

Without further ado, here’s a quick dive into Serverless and the options to have.

What is ‘serverless’?

Serverless is a term used to describe a computing model in which the cloud provider is responsible for executing code in response to events, and the user doesn’t have to worry about managing and scaling servers. In a serverless model, the user simply writes and deploys their code, and the cloud provider automatically runs and scales it. This can make it easier and more cost-effective to build and run applications since the user doesn’t have to worry about managing and scaling servers.

In a nutshell, it is a way of doing things where you don’t have to worry about stuff like managing and scaling servers. Basically, you just write your code and the cloud provider takes care of running it and making sure it works well. It’s kind of like a magic trick — you don’t have to worry about the hard parts, and it can save you a lot of time and money.

What are the perks of serverless?

• Cost-effective: Because you only pay for the resources you use, serverless can be a more cost-effective option than traditional server-based models. This is especially true for applications with variable or unpredictable traffic levels, since you won’t have to pay for idle capacity.
• Easy to use: With serverless, you can focus on writing and deploying your code, without having to worry about managing and scaling servers. This makes it a good option for developers who want to quickly build and deploy applications without having to worry about the underlying infrastructure.
• Scalable: The cloud provider automatically allocates resources in response to changes in demand, so your application can scale up or down as needed. This can help ensure that your application can handle large amounts of traffic without downtime.
• Flexible: Serverless allows you to easily integrate with a wide range of services and technologies, making it a versatile option for building applications.
• Portable: Because you can use the same code across multiple cloud providers, it’s easier to switch to a different provider if needed. This can give you more flexibility and control over your cloud infrastructure.
• Secure: Cloud providers offer robust security measures to protect your code and data, which can give you peace of mind when building and deploying applications.

And the cons of serverless?

• Cost prediction: Because you only pay for the resources you use in a serverless model, it can be difficult to predict costs. This can make it hard to budget for applications, especially if they have variable or unpredictable levels of traffic. For example, if you have an application that experiences a sudden spike in traffic, you could end up paying more than expected.
• Control: In a serverless model, the cloud provider is responsible for managing and scaling the infrastructure. This can mean that you have less control over the underlying hardware and software, which can make it harder to troubleshoot problems and optimize performance.
• Learning curve: There may be a learning curve for developers who are not familiar with it. This can make it harder to get started with serverless, and you may need to invest time and resources into training your team.
• Cold start: Because serverless functions are typically run in a “serverless” environment, they may take longer to start up than traditional servers. This can result in longer wait times for the first request to a function, which can be a problem for applications that require low latency.
• Dependency management: In a serverless model, it can be harder to manage dependencies between different functions and services. This can make it more difficult to build and maintain complex applications.

9 Serverless options

Here’s a quick list of 9 serverless options that are currently available on various platforms such as AWS, Azure, Google Cloud, and others you might not be aware of.

In general, these serverless services all have a pay-per-use pricing model and auto scalability. After a bit of digging, I’ve narrowed down what each service does differently from the other.

AWS Lambda

The differentiating feature of AWS Lambda is its integration with other AWS services, such as Amazon S3 and Amazon Kinesis. This allows you to easily build and deploy applications that use these services, without having to worry about managing the underlying infrastructure. This feature makes it easy to build and run scalable applications and services that use a variety of AWS services, which is a key advantage of using Lambda.

Azure Functions

One thing that makes Azure Functions different is that it support for custom bindings and triggers. This allows you to easily integrate your functions with a wide range of services and data sources, including services that are not natively supported by Azure Functions. This feature makes it easy to build and run flexible, scalable applications and services that can integrate with a variety of different services and data sources, which is a key advantage of using Azure Functions.

Google Cloud Functions

Google Cloud Functions supports background functions and network triggers. This allows you to run your functions in response to events from non-HTTP sources, such as Cloud Pub/Sub or Cloud Storage, and to trigger your functions from network events, such as incoming packets on a specific port. This feature makes it easy to build and run flexible, scalable applications and services that can react to a wide range of different events and triggers, which is a key advantage of using Google Cloud Functions.

IBM Cloud Functions

IBM Cloud Functions supports OpenWhisk and Apache OpenWhisk. This allows you to run your functions using the OpenWhisk runtime, which provides additional capabilities and features, such as support for packaging and distributing your functions as Docker containers. This feature makes it easy to build and run flexible, scalable applications and services that can take advantage of the capabilities of OpenWhisk, which is a key advantage of using IBM Cloud Functions.

OpenFaaS

OpenFaaS allows you to write your functions in any language that can run in a Docker container, which means that you can use languages and environments that are not natively supported by other serverless platforms. This feature makes it easy to build and run applications and services that use a wide range of different languages and technologies, which is a key advantage of using OpenFaaS.

Serverless Framework

Serverless Framework supports multiple cloud providers.

The Serverless Framework allows you to write your functions and deploy them to a variety of different cloud providers, including AWS, Azure, Google Cloud, and more. This means that you can use the same tooling and workflow to build and deploy your applications and services, regardless of the cloud provider you choose. This feature makes it easy to build and run cloud-agnostic applications and services that can run on any supported cloud platform, which is a key advantage of using the Serverless Framework.

Fission

Fission has faster cold-start times.

Fission uses a hybrid architecture that combines the benefits of serverless computing with the performance of container-based computing, which allows it to achieve faster cold-start times for your functions. This means that your functions can be ready to handle incoming requests more quickly, which can improve the overall performance of your applications and services. This feature makes Fission an attractive option for applications and services that require low-latency, high-performance computing, which is a key advantage of using Fission.

Knative

One unique feature of Knative is its support for deploying and running serverless applications on top of Kubernetes. Knative uses Kubernetes objects and APIs to manage and scale your applications, which allows you to use Kubernetes tools and ecosystems to build, deploy, and manage your serverless applications. This means that you can use the same tooling and workflow for your serverless applications as you do for your other Kubernetes-based applications, which can simplify your overall development and deployment process. This feature makes Knative an attractive option for organizations that are already using Kubernetes, and that want to use Kubernetes to manage their serverless applications as well, which is a key advantage of using Knative.

OpenWhisk

OpenWhisk is an open-source serverless computing platform that enables you to run code in response to events and automatically manages the underlying compute resources for you.

With OpenWhisk, you can build and deploy applications and services quickly and easily, without worrying about the underlying infrastructure. OpenWhisk supports a wide range of programming languages and environments, and it offers a rich ecosystem of tools and libraries that you can use to build and deploy your functions. OpenWhisk is based on Apache OpenWhisk, which is an open-source implementation of the OpenWhisk platform.

OpenWhisk also allows you to write your functions in any language that can run in a Docker container, which means that you can use languages and environments that are not natively supported by other serverless platforms. This feature makes it easy to build and run applications and services that use a wide range of different languages and technologies, which is a key advantage of using OpenWhisk.

Where to from here?

This is just a surface dive piece into the world of serverless and microservices. Stick around for future articles on the topic. I’m looking to do more deep-dive pieces (possibly with code samples) and architectural structures.

But that’s for another day. For now, thank you for reading.