An Introduction to Serverless Computing: Part 2
An Introduction to Serverless Computing: Part 2
Next we take a look at the biggest players in serverless and some projects serverless and containers gave life to.
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
Read the first part of this series here.
There are many vendors offering solutions. Let’s discuss the major offerings:
Amazon Web Services
AWS Lambda is the serverless service offered by Amazon Web Services (AWS). It is one of the first major implementations of FaaS. AWS Lambda can be triggered in different ways, like an HTTP request, a new document upload to S3, a scheduled job, an AWS Kinesis data stream, or a notification from AWS Simple Notification Service, etc. With Lambda, you can run code for virtually any type of application or backend service — all with zero administration.
Currently, AWS Lambda can support the following languages:
AWS Lambda offers all serverless features and benefits listed in the previous part of the series. In addition to those, it also offers:
Integrating with Other AWS Services
It integrates well with other AWS services, such as:
- DynamoDB for your document-storage needs.
- SQS and SNS for publish/subscribe queueing patterns, creating loosely-coupled and separated architectures.
- API gateway for providing a HTTP (REST) service.
- S3 for file storage.
- Athena for data analysis.
- Cognito for authentication.
- Cloud Watch for monitoring and logging.
- Kinesis for data streaming.
- X-RAY for troubleshooting all API calls.
Building Custom Backend Services
It can create new backend services for applications that can be triggered using the Lambda API. You can deploy and manage your serverless applications using the AWS Serverless Application Model (AWS SAM).
Bringing User's Own Code
It supports different programming languages like Node.js, Java, C#, Go, Python and Ruby. This allows users to run and deploy their custom applications within AWS Lambda.
AWS Lambda allows to run code across various AWS locations spanning all across the globe for responding to the users from the nearest location for lowest latency.
Google Cloud Platform
Google Cloud Functions is Google’s serverless service, which offers almost all the serverless benefits/features mentioned earlier. An application that runs with Cloud Functions can connect to various other cloud service offerings of Google.
Google Cloud Functions supports all the features of serverless computing that we discussed earlier. On top of those, we also get features like:
Integrating with Other Google services
It connects well with other Google services like:
- CloudSQL for database use.
- Google Pub/Sub for low latency and durable message communication between independently-written applications.
- Google Bigtable for NoSQL based data storage.
- Google BigQuery for massively large dataset analysis.
- Google Cloud Storage as object store similar to AWS S3
- Google Translation and Vision API’s
- Google Stackdriver for monitoring, debugging and logging.
Azure Functions is Microsoft Azure’s serverless offering.
Besides the pay-as-you-go model, it has one more cost-based plan called App Service. If you are already using the Azure App Service, then you can add your functions on the same plan at no additional cost. There are two versions of Azure Functions — 1.x, which is Generally Available (GA) and 2.x, which are in the preview. Azure Functions 1.x supports application/functions in following programming languages:
- Python (experimental)
- PHP (experimental)
- TypeScript (experimental)
- Batch (.cmd; .bat) (experimental)
- Bash (experimental)
- PowerShell (experimental).
Azure Function also provides all the features listed in the first part of the series along with some additional features and benefits including:
Integration with Other Azure Services
It integrates well with other Azure services, like Azure Event Hubs, Cosmos DB, Queue and Azure Storage.
Bringing Your Own Dependencies
It supports NuGet and NPM, so you can use your favorite libraries.
It provides OAuth security for HTTP-triggered functions with OAuth providers such as Azure Active Directory, Facebook, Google, Twitter, and Microsoft Account.
Azure Functions has an open source runtime.
Serverless Computing and Containers
We have learned that with serverless computing we can run applications/functions which do one thing and do it well. Apart from serverless offerings provided by cloud vendors we can package applications/functions and run them as containers. We run containers using different container runtimes and orchestrate them using container orchestrators like Kubernetes, Docker Swarm, Amazon ECS, etc.
Projects That Use Containers to Execute Serverless Applications
Container images became a prominent choice for packaging serverless applications, and container orchestrators became the preferred choice for executors. Let us list some of the projects that are using containers to execute serverless applications:
Azure Container Instances
Azure Container Instances (ACI) is the service offered by Microsoft Azure, using which we run containers without managing servers. It provides hypervisor isolation for each container group to ensure containers run in isolation without sharing a kernel. Azure Container Instances offers the fastest and simplest way to run a container in Azure, without having to provision any virtual machines and without having to adopt a higher-level service. Using ACI you can run Linux and Windows containers using the same API.
AWS Fargate is the service offered by Amazon Web Services, using which we can run containers without managing servers. It runs container top of Amazon ECS and EKS services. Basically, it is like running an EC2 instance but instead of getting a virtual machine, you get a container which is fully managed by AWS. You just need to tell the resources you need to run your application. Recently AWS has launched the support time and event-based task scheduling to run Fargate containers.
OpenFaaS is an open source project, using which we can run serverless applications on containers using Docker Swam or Kubernetes. OpenFaaS makes it easy to turn any code to serverless function using containers. Functions can be written in any language for Linux/Windows and can be packaged as a Docker image.
Kubeless is an open source project from Bitnami, which provides a serverless framework on Kubernetes. It is designed to be deployed on top of a Kubernetes cluster and take advantage of all the great Kubernetes primitives. Kubeless is often regarded as the open source serverless solution that clones what you can find on AWS Lambda, Azure Functions, and Google Cloud Functions.
Fission is an open source project from Platform9, which provides a serverless framework on Kubernetes. Fission is, like Kubless, Kubernetes-native serverless Framework. Short-lived functions can be written in any language and then can be mapped to HTTP requests or other kind of triggers. Fission operates on just the code: Docker and Kubernetes are abstracted away under normal operation, though you can use both to extend Fission if you want to. It is open source under Apache License
virtual-kubelet connects Kubernetes to other APIs and masquerades them as Kubernetes nodes. These other APIs include ACI, Fargate, IoT Edge, etc.
Apache OpenWhisk is an open-source and distributed serverless platform which executes functions in response to events. It can scale to any level using Docker containers. It supports NodeJS, Swift, Java, Go, Scala, Python, PHP and Ruby.
As the market of serverless is growing, we can expect to see new solutions emerging for serverless and containers in the near future.
Serverless/FaaS is an advancement in the way we operate our servers and the way we do compute, and we should all be excited about it. You should not underestimate serverless. You’re still going to have to learn many new things, though the steep learning curve will pay off faster and will prepare you for faster software development in the future. Be sure to properly manage the expectations, whether it’s to yourself, your peers, or your manager. The shift to FaaS essentially forces you towards a more architectural role, which requires a different kind of skill set. And never forget: serverless isn’t a silver bullet.
If we talk about quick examples, then you should not run a real web-server that supports a user interface (because of the spin-up latency) using serverless. It makes more sense only for background or batch jobs. Also, the fact that you are billed even when waiting for downstream servers (e.g., an S3 request or a database call) to respond seems a waste. Within the Lambda, if we make an API call, and it takes 5 seconds, you're billed for those 5 seconds just for waiting!
Suppose you have a system built with a microservices architecture. You create a specific operation within your solution which takes considerable computing power, with periodical and unpredictable spikes in traffic. Moreover, this operation is only activated when triggered by something else, like the registration of a user or sending an email after registering the user. That’s a perfect place to implement FaaS for that operation. Microservices doesn’t necessarily have to be the case, but it seems obvious that if you’re doing microservices then your system is probably more decoupled already and separation of a component from the rest of the system won’t be a challenge.
I hope this 2-part series gives you some good context and provides realistic expectations for working with serverless technology. Though much is different, much is still the same as well and in the end, it’s still software development. Have fun!
Opinions expressed by DZone contributors are their own.