Serverless Computing With Azure Functions

While I was working on Cloud computing and other similar technologies, I somehow stumbled upon this new thing that I had not heard of before (quite a few weeks ago) and I found it really interesting to watch about it, to learn, and to share my own understanding of this technology with you guys. I will try my best to keep the main idea as simple as possible, but explain everything from A to Z in an easy manner, that it will feel as if the concept was always in your mind.

 

Thus, let us begin with the first initials about serverless computing and how it all began.

 

How it all began…

 

If you guys have been into the IT and programming geekiness for the past few years, you must have witnessed how things changed, from physical machines to virtualization, to containers, and all the way to what we now call serverless computing. Whether this new tech trend comes down the stream, as I mentioned, or perhaps someone else knows better, as to how this all began is not the question or the topic of concern. The main thing is that we now have this other topic to cover before we are actually start-up and design the Applications. You will see, in this post, how one way of deploying applications has pros and cons, and how serverless comes up to solve the problems — or ruin everything. There are some pros to serverless computing, and there are obviously a lot of cons to serverless computing.

 

The buzz word of Serverless computing didn’t take long, because we now have the Internet and one new thing from the west, reaches the east in no time at all. The question to ask is, “Do we understand what they wanted us to?” And this is the question that I am going to address in this post of mine, so that all of us really understand the purpose, need, and reason of serverless computing today.

 

I am going to use Azure Functions, to explain the usage, benefit, and “should I” of serverless computing. The reason I chose Azure was that everyone was already covering a lot of amazing Lambda stuff, so I didn’t want to do use that, also I am working on Azure a lot so I thought this is it.

 

Understanding the term, “Serverless”

 

The primary focus of ours is to explain the term, “Serverless”, Azure usage would just be to give you an overview of how that actually works in the real world.

 

 

Figure 1: A simple yet clear difference in traditional vs serverless approach toward server management. 

 

The picture above was captured from this blog, and it provides a very good idea of the difference between what we use, and what Serverless offers. But this does not mean that the image above provides a 100% true and the only difference in both worlds, sometimes the differences boil down to zero; such as in the cases, where you are going to use architectures such as cloud offerings. In such scenarios, the total difference in the cost is how you selected the subscription. As we progress in the post, I will also draw a margin line in many other aspects of this methodology. Keep reading.

 

Just like the term cloud computing was mistaken for various reasons, and for various acts, the term of serverless is also being mistakenly understood as a platform, where the Servers are no longer needed. As for Cloud computing, you might want to see, Cloud Computing explained by Former IT Commissioner, and try to consider the fact that we are in no way understanding the technology the way it is meant to be understood. The same is the result for serverless, when I tried to search for it on Google, I even saw computer devices being dumped into the dustbin; which triggered me, that people are so not understanding the term itself. For example, go here, Building a Serverless API and Deployment Pipeline: Part 1, and try to just see the first image, and please remember to come back as soon as possible. You will get my point. Finally, I mean no offense to anyone being mentioned in this paragraph, if you are the target in either one of the link, kindly get a good book or contact me I will love to teach you some computer science.

 

 

Figure 2: Just in the case that blog post is not accessible or the author takes the image down, I just want to show you the image. Still, no offense, please.

 

So, what exactly is Serverless computing? The basic idea behind this is to remove the complexity of the time taken to manage the servers, not the servers themselves. In this scenario, we actually use a framework, platform, or infrastructure, where everything, even the booting, executing, and terminating of our application is managed by the provider itself. Our duty only is to write the code and the magic is based on the recipe of the provider. Just to provide you with a simple definition of Serverless computing, let me state

 

Serverless computing is a paradigm of a computing environment in which a platform or infrastructure provider manages booting, scheduling, connection, execution, termination, and the response of the programs without needing the development teams to manage the control panel.

 

Phew, that wasn’t so tough, was it? Rest of the stuff, such as pricing models, languages or runtimes provided, continuous deployment, or DevOps is just a bunch of extra topping that every provider will differ in the offerings. That is one of the reasons, I did not include any statement consisting of anything about the pricing models, or the languages to use — whereas, in this post, I will use C#… I am expecting to write another post that will cover Python or other similar interpreted languages.

 

Benefits of Serverless architecture

 

If you migrate your current procedures, and communicators, to a serverless paradigm you can easily enjoy a lot of benefits, such as cost reduction, freedom from having an operations team to manage a full-fledged server, and much more. But at the same time, I also want to enlist a few of the disadvantages of Serverless computing, at the end of this section.

 

Cost model

 

OK, let me talk about the most interesting question in the mind of everybody perhaps. How is this going to change the way I am charged? Well, the answer is very relative to what you are building, on what platform you are building, and how many customers do you have, plus how they interact with your application. So, in other words, there is no way we can judge the number of charges you are going to pay with this. In the following sections, I will give you an overview of another special part in serverless programming, that you can use to consider the pricing model for your application.

 

NoOps

 

Do not be mad at me for adding a new term in computer science; if it has not yet been added there. Now let me get to the point where I can explain the concept of resolving the teams, such as development, operations, etc., and then getting to a point, where you can enroll “serverless” to the environment. In modern-day computing, we have, let’s say, implemented DevOps and we need to have a mindset where our teams are working together to bring the product to market for users. A DevOps typically has the following tasks to be conducted,

1. Planning and startup, user stories, or whatever it is being called.
2. Source control or version control
3. Development; any IDE, any language
4. Testing; there are various tests, unit testing, load testing, integration testing, etc.
5. Building; DevOps support and encourage continuous integration
6. Release; same, continuous deployment is recommended

From this, you can see that the developers only need to work in a few areas, Planning, Development, and Building. Version control systems should be managed by the IDE and timers should be set to them to control when the versions or updates are checked in each day, updated versions must be released into the market by operations teams, etc. However, since now in the field of Serverless, we do not have to “release the software” to the market, and we also do not need to manage any sort of underlying server if our application is web-based, thus we can somehow remove the operations team, or include them in the development team as Application developer team. I read a research guide a few days ago, naming DevOps – Ops as AppOps, but however, I would like the term of NoOps, because the considerations of them being a simple operations team are removed and they now work with the application development team, focusing entirely on the code, and the performance or uptime of the application, instead of the servers or virtual machines.

 

So, let’s count the purpose of NoOps in this field,

1. Planning and startup, user stories, or whatever it is being called. (Not included)
2. Source control or version control
3. Development
4. Testing; I can strikethrough this one as well.
5. Building; DevOps support and encourage continuous integration (Not included)
6. Release; same, continuous deployment is recommended (Not included)

Clear enough, I believe. Before we get into another discussion, let me tell you why I think these are the way they are; why did I cut a few in the list.

 

Planning and Startup

 

First of all, planning and startup in this do not make any sense at all. Please see below, the section in which I am talking about the “when” to select serverless architecture, that section will depict when you should use serverless approach over the current “modern” approaches. Once you have gone through that, you will understand, that in the serverless arch, the planning is done beforehand.

 

Thus, there is no need to again sit around, and have the kanban board messy once again. If you are going to work on that board again, please go back and work in a DevOps environment, serverless is not for you. As mentioned below, serverless is for the programs that do not run for 4-7 hours, but just for an instance, each time they are called and they are entirely managed by the infrastructure provider.

 

Version control

 

Since this is directly targeted towards the development or the core portion of your application, this is a part of serverless architecture design. Almost every serverless platform that I have seen as of now, uses version control services or provides best practices of DevOps; I know. Azure Functions provide you with features that you can use to update the source code of your function, Amazon Web Services’ Lambas allow you to use GitHub, same goes for almost all; have a look at Google’s microservices service, they support GitHub based deployment of Node.js applications and then manage how to run them.

 

In the cycle of development of a serverless application, this can come as the first step after every first cycle.

 

Development

 

Yes, although we removed the servers and other IT stuff from the scene, we still need developers to write up the logic behind the application.

 

Testing

 

The reason that I left this option active in the current scenario was, that if you are using version control and then you are deploying the application’s code to the server, my own recommendation and DevOps also, would be to test the code before going to the next step, as it might break something up ahead.

 

In the serverless arch, we are allowed to use source controls, so, before forwarding the code from there to the server, why shouldn’t you run some tests? In the serverless arch, we don’t have to worry about the servers, but sure we do need to worry whether the code ran, or did it just break all the time?

 

In a serverless architecture, we do not technically build a full-fledged, or full-featured application that takes care of everything, instead, we simply write an “if this then that” sort of application. If you understand the concept of the “Internet of Things”, then you can think of a serverless application as the hub that manages the communication and responds to an event; message; request. In such cases, it is not required to implement every test possible, instead, we can perform simple tests to ensure that the code does not break at the arrival of request, and at the dispatch of a response. These are just a few, top of my dumb piece assumptions and suggestions, based on what your serverless application does, you might need other tests, such as pattern matching or regular expressions to be tested against.

 

I repeat this is the most important part of serverless programming. I cannot put more effort into saying this, but you get my point, if you are a team and you are going toward the serverless paradigm to lift the response rate, then you first of all need to ensure that the program will be resilient to any input provided to it and will not break at all. Even if there are some issues, how does the program respond to those errors?

 

Building

 

I removed that step, but I could have also left that as it was. There are reasons for this, because, the infrastructure may provide you with support to publish built programs. We are going to look into Azure Functions, and Azure supports publishing built programs that execute, instead of scripts that are to be interpreted each time that function has to execute.

 

But in many cases, you do not need to take care of, or even worry about the build process, since the functions are small programs and they don’t require much of the stuff that typical applications require. You can easily publish the code, and it will execute in a moment. Serverless providers allow interpreted languages to be used as the scripts too, such as Batch files, you can also use Python scripts or PHP files. But again, every provider has their own specification for this, Azure Functions support any kind of program that you can write, or build, you can upload it on the server and they will host it and your users can connect to it next time they send a request, or interact with the application; mobile, web or any other IoT based device.

 

Release

 

Submitting the code out to the version control is the only release we are going to worry about.

 

Winding up the basics

 

Although what I covered, just scratched the basics about serverless architecture, and there is a lot more to it than just this singular concept of what to do, and what to leave out. But going any deeper into the rabbit hole might be confusing and might get us off-track as per this post’s structure. So I will not go down, but just for winding us the basics, let us go through a few things.

1. Do not consider the serverless architecture as a replacement for your current physical servers or container-based environments. Serverless is just used to take the events and then trigger another server or virtual machine to act on that event, with the provided data. Nothing else.
    
2. Before going serverless, you and your team must understand one fact: “It is your duty, to test the code, and the validity of your code, and it is the duty of your platform provider, to ensure that the code runs the way it is intended to be run on the runtime intended.”
    
3. Pay a lot of attention to testing, testing, testing. I repeat, other than development if there is something that needs to be done, it is testing.
    
4. The payment plan, in many cases, differs from one and another. Sometimes you might choose a monthly plan, sometimes if your users are not in thousands, then you can select the plan where you only pay for the time your function is executing; only for resources used.
    
5. Microsoft Azure Functions provide full support for various languages and runtimes, you can use C#, then you can as well choose JavaScript, there are other methods of writing the function code, such as using Python and PowerShell. You can also upload the compiled code and then run it. In other words, if it can execute, it can be a function.
    
6. One final thing, a function is only a program or handler, that runs for a small-time (10ms-1.5s), if it takes more than that, then it will raise other errors and you would face other problems as well. Always keep the function code short, and as soon as possible terminate it by triggering other services or passing the data on to other service handlers, such as you can trigger the function from an IoT hub and then use other services such as SMS or SMTP services to send notifications and before sending notifications to close the function, by only triggering those services and passing the data.

In many ways, this architecture can help you out. But if used badly, it would be like shooting yourself in the foot. In my own experience, I have found that architecture can create a lot of problems for you as well, and it might not always be as much help as you think. So, use wisely.

 

Azure Function example

 

I didn’t want to write a complete guide on serverless architecture, because I might have other posts coming out on this one as well, so let us go a bit deeper and have a look at the Azure Functions feature and see how we can write minimal serverless functions in Azure itself.

 

So in this example, I am only going to show you a bit of the example that can be used to show you how functions work, in future posts I might cover the HTTP bindings to the functions, or other stuff such as DevOps practices, but for this post let me keep it really short and simple and cover the basics.

 

Basic function file hierarchy

At the minimum, a function requires an executable script (in any runtime), and a configuration file that specifies the input/output binding of the function, timers, or other parameters that can be used for the proper execution. That function.json file controls the execution of the function, it takes all the configuration settings, such as the accounts or services to communicate with. So for instance, in a simple timer-based function the following files are enough to control the function itself,

 

 

The code in both the files is as the following one, 

using System;

public static void Run(TimerInfo myTimer, TraceWriter log)
{
    log.Info($"C# Timer trigger function executed at: {DateTime.Now}");
}

 The JSON configuration file has the following content, 

{
    "bindings": [
        {
           "name": "myTimer",
           "type": "timerTrigger",
           "direction": "in",
           "schedule": "0 */5 * * * *"
        }
    ],
    "disabled": false
}

What their purpose is, let me clarify the bit about it in this post before moving any further.

 

Note

 

In another post, I will clarify the meaning and use of the function.json file, and what attributes it holds. For now, please bear with me.

 

An executable script

The executable script can be C#, JavaScript or F#, or any other executable that can run. You can use Python scripts as well as a compiled executable script.

 

Configuration file

 

The function.json file has the settings for your function. The above-provided code was a very basic one, the complex functions would have more bindings in them, they will have more parameters and connection names or authentication modules, but you get the point.

 

In the file, the name and direction of the binding are compulsory. However, other settings are based entirely on the type of binding being used. For example, HTTP triggers will have different settings, timer triggers will require different settings, and so on and so forth.

 

Executing

 

Azure provides the runtime for almost every executable platform, from PowerShell to Python, to JavaScript, to C# scripts (the above-provided code is from a C# script file) and all the way to other scripts, such as batch, etc. Runtime also supports native executables — and this part I yet have to explore a bit more to explain which languages are supported in this scenario.

 

I will not go into the depths of this concept, so I will leave it here, anyways the output of this function is as,

2017-02-03T17:35:00.007 Function started (Id=3a3dfa76-7aad-4525-ab00-60c05b5a5404)
2017-02-03T17:35:00.007 C# Timer trigger function executed at: 2/3/2017 5:35:00 PM
2017-02-03T17:35:00.007 Function completed (Success, Id=3a3dfa76-7aad-4525-ab00-60c05b5a5404)
2017-02-03T17:40:00.021 Function started (Id=a32b986c-712e-4f30-84c9-7411e63b5356)
017-02-03T17:40:00.021 C# Timer trigger function executed at: 2/3/2017 5:40:00 PM
2017-02-03T17:40:00.021 Function completed (Success, Id=a32b986c-712e-4f30-84c9-7411e63b5356)
2017-02-03T17:45:00.009 Function started (Id=c18c0eef-271d-4918-8055-64e3f31f953a)
2017-02-03T17:45:00.009 C# Timer trigger function executed at: 2/3/2017 5:45:00 PM
2017-02-03T17:45:00.009 Function completed (Success, Id=c18c0eef-271d-4918-8055-64e3f31f953a)
2017-02-04T10:27:54 No new trace in the past 1 min(s).

The timer trigger keeps running and keeps logging the new events and processing information. You will also consider, that this is the same output that Node.js or F# programs would give you, the only difference in these 3 (only 3 at the moment), is that their runtimes are different, the binding and input/output of the functions is managed entirely by Azure Functions itself and developers do not need to manage or take care of anything at all.

 

Wrap-up

 

Since this was an introductory post on serverless programming and how Azure Functions can be used in this practice, I did not go much deeper in the explanation of the procedures of writing function applications. But the post was enough to give you an understanding of the serverless architecture, what it means to be serverless and how DevOps transition to NoOps. In the following posts about serverless, I will walk you around writing the serverless applications and then consuming them from client devices; Android, or native HTTP requests.

 

Finally, just a few things to consider:

1. If your functions take a lot of time to execute, such as 1 minute, or even 30 seconds, then consider running the application in a virtual machine or App Service. A function should be like a handshake negotiator, it should take the data and pass the data to a processor, it must not be involved in processing and generation of results.
    
2. Your functions should be heavily tested against. I am really enforcing a huge amount of tension on this one, as this point needs to be taken care of. Your functions are like the welcomers, who warmly welcome the incoming guests to your servers. If they fail in doing so, the data may never come back (data being your users; events, or anything similar).
    
3. Functions follow the functional programming concepts more, so, in functional programming, the functions are not stateful. They are stateless, meaning they do not process the data based on any machine state, attribute, property, or the time at which they are executed. Such as, a function add, when passed with data input of “1, 2, 3, 4, 5”, will always return “15”, since the process only depends on the input list.

As we start to develop our own serverless APIs and applications, we will also look forward to more ways that we can develop the applications, and write the application code in a way that does not affect the overall performance of our service.

 

Nonetheless, even if not being implemented in the production environment, serverless is a really interesting topic to understand and learn from a developer’s perspective as you are the one taking care of everything and there are no cables involved.