This is a part of my “Journey with Azure” series
I have always been fascinated by managed services and serverless computing. It started with my first startup PureMetics, where we used AppEngine and BigQuery to built an Analytics product. Because both AppEngine and BigQuery were fully managed services, A single person (Abhishek Nandi) was able to build the entire tech for it. Later on when Abhishek & I were building Odiocast, we used other managed services to keep things simple. FireBase, AWS Lambdas and other services allowed us to worry more about the product rather than worry about Devops as a 2 person startup.
The logic is simple when you have the best technology companies willing to be your Devops team, at a cost, why would you say no? You would then have time to focus on what makes your product different. Also since all of the providers are running at scale, they get to reap scale benefits which they pass on to you. Today I am practically running a side project for almost nothing on GCP and my next project is also going to be close to free on Azure.
Managed services abstract out service management and scaling. They vary from just abstracting out the basics like infrastructure i.e Infrastructure as a Service (IaaS) providers like AWS EC2, to abstracting out all details i.e Functions as a Service (FaaS) like Azure Functions
Depending on your needs you can pick services between the 3 abstraction types: IaaS, PaaS & Faas
Azure Functions take abstraction to a whole new level with Bindings. With Bindings, Azure Functions allow you to connect a bunch of services without writing additional code for it. It achieves this by abstracting out the service like Table Storage, Queue Storage etc and providing you objects to refer to the service. With Bindings, you are actually writing the least amount of code to connect 2 services. More on this later.
While AWS Lambda was the pioneer in FaaS, almost all service providers now have equivalents. Personally, Azure Functions are the most interesting service for me because of the additional abstraction layer it provides via Extensions and Logic Apps.
Head over to the Azure Portal and select Create a Resource (1) and then select Serverless Function App (2)
Next the next Blade you can name your app (3), select subscription (the billing account) and the hosting plan and OS amongst other things. These are important choices. For example, Python is only available on Linux, and Linux is only available in a few regions. The important option here is the hosting plan (4). You have 2 options here:
If you are just starting up with Azure Functions, Consumption plan is the way to go.
Press create, this will take a while. The portal will first validate things and then close the blade. Don’t worry this is normal.
You will need a notification pop up which would state that the deployment is in progress.
Side note: One thing you start noticing is the options/flexibility Azure Functions provides. You will see in the next step too.
Once the deployment is done head over to the Functions Resource, you will see the following screen
Go ahead and click on new functions. Depending on the options you selected you will see different options. For my selected options I see the following
Once again for this tutorial, I will select VS Code, post which I am shown two options, publish using VS code or via the Deployment Centre. I will select Direct publish
This then gives you the steps to install the following dependencies
Once all of them are installed, we need to move over to VS Code to get started. Open up the Azure panel on VS Code (1), You will see a Functions section, with your subscription plan and your functions plan, select it (2)
Lastly, click the new Functions button (3) . Now VSCode will first ask you for a location and then will ask you to initialise the project, yes is the obvious selection. VScode will take you through a wizard to create your functions app,
For now, just remember triggers are events which cause the function to run, we will take a deeper dive into trigger later Next VSCode will open up the function file index.js, if you don’t see a folder like I do below, open the folder you created during the steps above
Now you should see your folder like this
Two files which are important are the function code in index.js and the function.json file which defines the bindings for this function.
This is the code of your function. The arguments of the function vary based on the type of trigger you are using. The HTTP trigger will have a context object and a request object. Azure Functions use the context object to communicate with your function. For example, if you had an output binding you would refer it via the context object using context.bindings.<name of binding>.
In case of the HTTP Trigger we also get the http request as an argument.
This Json file defines the input and output bindings of your function. In case of our example, both of them are going to be HTTP bindings. More on bindings later.
To run your function press F5, Your console in VSCode will show something like this
If you call the URL without any request parameters you will get the following message
Just pass a name as a get parameter, like this: http://localhost:7071/api/HttpTrigger?name=Ravi
Function are great at doing stuff when something happens, a trigger. They are ideal for microservices or workers which do a particular job. Here are a few examples
Triggers at the simplest are events which trigger your function to start. They may also have information with them. A HTTP trigger, as we saw above, has the http request data passed to your function, a queue trigger will have the object from the queue. They are passed as arguments to your function. As such a function can only have one trigger but can have multiple input bindings.
Bindings allow your function to connect to various resources without the need of writing a lot of code for the service. Without bindings, you would need to add the SDK of the service you want to use, write all the boiler plate for it and then start using it, with bindings, Azure Functions do the heavy lifting for you. As mentioned above, bindings are available for you to use via the context objects.
When you declare the binding you will need to define the following:
The rest of the parameters depend on the type of binding you are using. If you are using Tables or Queues, for example, you need to provide the storage account, and the name of the Queue or Table you want to use.
Here is an example of a function.json file. Here I am reading a queue which has a list of JSON objects, the function then reads in the individual objects and pushes them to the output-queue-individual queue and it’s metadata to output-queue-meta.
When you are developing locally, the connection string is best defined in the local.settings.json file.
For a complete list of possible triggers and bindings refer this document.
You now know enough to get started with Azure functions.
Originally published at ravivyas.com on March 23, 2019.
Create your free account to unlock your custom reading experience.