Source: Daily Host News' blog
This is the first of a four-part series on an introduction to serverless computing and Azure Functions. In this part, I would be covering an introduction to serverless computing and Azure Functions - while also covering the very advantages of running code functions on a serverless platform.
What Really Is Serverless?
To start with, serverless is all the talk around cloud computing these days, and wrapping your heads around this new model in cloud computing (yeah, been around since 2017) might seem confusing - at first.
Then again, "Peace, be still". Serverless is just another word, as serverless doesn't necessarily mean architectures without server infrastructures, it only depicts architectures using less server infrastructures. Think of serverless as a WiFi connection, the term wireless - Wireless Fidelity - doesn't inquire that there are zero wires in the infrastructures leading to a WiFi connection. It just literally means that there are few wired connections that have been put into place.
Source: @azurefunctions
In this article, I'll be talking more about the Azure Functions stack and also get you in sync with the amazing benefits of running a serverless architecture like Azure Functions. More importantly, I'll be diving more into the Azure Functions service offering, and subsequently get you to build a serverless app before the end of this article (this would be covered in the next part though).
To start with, serverless can basically be described as a Functions-as-a-Service (FaaS) platform where you get to deploy some functions of your code, or software projects, separately in the cloud and get charged only when requests that aree being put through to these functions get processed (when the functions return responses, literally).
That is, you only pay for the time when your block of code (function) runs, which is due to the Azure Functions Consumption Plan (I'll come back to this later).
Source: Chsakell's blog
Meaning, Azure would only charge you for the function being run (even if you have a million functions deployed) which would be in direct response to the request from the users of this function. Consider this a micro-pricing plan. Cool, ain't it? 😉
As a refresher, functions - generally - are reusable blocks of code that perform specific tasks. Now, Azure Functions are simple event-driven ways to run these blocks of code (normal functions) in the cloud. Yeah right, this was nearly impossible in the early days of cloud computing.
Source: Towards Data Science's blog
Azure Functions are event-driven, in the sense that they require specific triggers or actions to be put to work before they return outputs (could be HTTP GET requests, in this sense). Just as normal functions would behave, a function would need to be invoked or triggered from a state of inertia before it becomes active.
Advantages of Azure Functions
At this point, it is pertinent to highlight the many advantages of going the serverless route over provisioning a normal virtual machine, and managing accordingly, while working with functions. With Azure Functions, you can write code logic in any language of your choice and you also get an automatic scaling of your function, that is, there are no servers to manage on your end.
Well, listed below are a few of the advantages Azure Functions have over provisioning virtual machines while working with functions.
• Moderate Infrastructure Scaling: With Azure Functions, you get charged only on the requests processed by your functions. Why do I keep iterating this point? "Suppose you've provisioned VM servers and configured them with enough resources to handle your peak load times. When the load is light, you are potentially paying for infrastructure you're not using. Serverless computing (like Azure Functions) helps solve the allocation problem by scaling up or down automatically, and you're only billed when your function is processing work." Which in turn, helps save cost.
• Driven by Events or Triggers: Azure Functions are event driven, as stated in the paragraphs before this. Azure Functions get executed in direct response to events (triggers), which could be just a single trigger or call to submit an image or body of texts to an API.
There's an approach in serverless computing which helps simplify a function definition by allowing you to declare bindings (to indicate where the data attached to your function is coming from) which could be either an input or an output. Input bindings could also be called triggers, since they help in making sure your functions come alive (start running).
With this input/trigger binding, you essentially don't need to write a script to watch queues nor storage, you only focus on writing function code that work. A trigger binding can definitely be configured to perfectly suit your needs. As an addition, an output binding determines which part of your functions your data would be sent to. You configure a trigger as part of the function definition.
This approach simplifies your code by allowing you to declare where the data comes from (trigger/input binding) and where it goes (output binding). You don't need to write code to watch queues, blobs, hubs, etc. You can focus purely on the business logic.
While serverless logic always make sense while working with functions, there are a number of disadvantages to working with Azure Functions which would be discussed in the following part.
In addition, we would also be building and deploying a function code to the cloud using Azure Functions, for a practical look into serverless.
TL;DR?
• An Azure Function is MAINLY useful for deploying blocks of code (functions, that perform specific tasks) in the cloud, while ONLY paying for requests processed by these functions. Shikenah 😉
See you on the other side. Cheers! 😺
Latest comments (0)