Tag Archives: Continuous Delivery

Azure Functions and Serverless Computing

The post “Azure Functions and Serverless Computing” appeared first on MSDN Azure Development Community.

In my previous blog post, WebJobs in Azure with .NET Core 2.1, I briefly mentioned Azure Functions. Azure Functions are usually small (or somewhat larger) bits of code that run in Azure and are triggered by some event. Azure takes complete care of the entire infrastructure of your Functions making it a so-called serverless solution. The only thing you need to worry about is your code.

The code samples for this post can be found on my GitHub profile. You shouldn’t really need it because I’m only using default templates, but I’ve included them because I needed them in source control for CI/CD anyway.

Serverless computing

Before we get into Azure Functions I’d like to explain a bit about serverless computing. Serverless computing isn’t completely serverless, your code still needs somewhere to run after all. However, the servers are completely managed by your cloud provider, which is Azure in our case.

With most App Services, like a Web App or an API App, you need an App Service Plan, which is basically a server that has x CPU cores and y memory. While you can run your Functions on an App Service Plan it’s far more interesting to run them in a so-called “Consumption Plan”. With a consumption plan, your resources are completely dynamic, meaning you’re only actually using a server when your code is running.

It’s cheap

Let me repeat that, you’re only actually using a server when your code is running. This may seem trivial, but has some huge implications! With an App Service Plan, you always have a server even when no code is running. This means you pay a monthly fee just to keep the server up and running. See where this is heading? That’s right, with a consumption plan you pay only when your code is running because that’s the only time you’re actually using resources!

There’s a pretty complicated formula using running time, memory usage and executions, but believe me, Functions are cheap. Your first million executions and 400,000 GB/sec (whatever that means) are free. Microsoft has a pricing example which just verifies that it’s cheap.

It’s dynamic

Price is cool, but we ain’t cheap! Probably the coolest feature about Functions is that Azure scales servers up and down depending on how busy your function is. So let’s say you’re doing some heavy computing which takes a while to run and is pretty resource intensive, but you need to do that 100 times in parallel… Azure just spins up some extra servers dynamically (and, of course, you pay x times more, but that’s still pretty cheap). When your calculations are complete your servers are released and you stop paying. There is a limit to this behavior. Azure will spin up a maximum of 200 server instances per Function App and a new instance will only be allocated at most once every 10 seconds. One instance can still handle multiple executions though, so 200 servers usually does not mean 200 concurrent executions.

That said, you can’t really configure a dynamically created server. You’ll have to trust Microsoft that they’re going to temporarily give you a server that meets your needs. And, as you can guess, those needs better be limited. Basically, your need should be that your language environment, such as the .NET Framework (or .NET Core) for C#, is present. One cool thing though, Next to C#, Functions can be written in F# and JavaScript, and Java is coming in v2. There are some other languages that are currently running in v2, like Python, PHP, and TypeScript, but it looks like Microsoft isn’t planning on fully supporting these languages in the near future.

Azure Functions in the Azure Portal

Let’s create our first Azure Functions. Go to App Services and create a new one. When you create an App Service you should get an option to create a Function App (next to Web App, API App, etc.). The creation screen looks pretty much the same as for a regular web app, except that Function Apps have a Consumption Plan as a Hosting Plan (which you should take) and you get the option to create a Storage Account, which is needed for Azure to store your Functions.

Create a new Function App
Create a new Function App

This will create a new Function App, a new Hosting Plan, and a new Storage Account. Once Azure created your resources look up your Function Apps in your Azure resources. You should see your version of “myfunctionsblog” (which should be a unique name). Now, hover over “Functions” and click the big plus to add a Function.

Azure Functions
Azure Functions

In the next form, you can pick a scenario. Our options are “Webhook + API”, “Timer” or “Data processing”. You can also pick a language, “CSharp”, “JavaScript”, “FSharp” or “Java”. Leave the defaults, which are “Webhook + API” and “CSharp” and click the “Create this function” button.

Editing and running your Azure Functions

You now get your function, which is a default template. You can simply run it directly in the Azure portal and you can see a log window, errors and warnings, a console, as well as the request and response bodies. It’s like a very lightweight IDE in Azure right there. I’m not going over the actual code because it’s pretty basic stuff. You can play around with it if you like.

Next to the “Save” and “Run” buttons you see a “</> Get function URL” link. Click it to get the URL to your current function. There are one or more function keys, which give access to just this function); there are one or more host keys, which give access to all functions in the current host; and there’s a master key, which you should never share with third parties. You can manage your keys from the “Manage” item in the menu on the left (with your Functions, Proxies, and Slots).

Consuming Azure Functions

The Function we created is HTTP triggered, meaning we must do an HTTP call ourselves. You can, of course, use a client such as Postman or SoapUI, but let’s look at some C# code to consume our Function. Create a (.NET Core) Console App in Visual Studio (or use my example from GitHub) and paste the following code in Program.cs.

If your Function returns an error (for whatever reason) your best logging tool is Application Insights, but that is not in the scope of this blog post.

Of course, if you have a function that’s triggered by a timer or a queue or something else you don’t need to trigger it manually.

Azure Functions in Visual Studio 2017

Creating a Function in the Azure Portal is cool, but we want an IDE, source control, and CI/CD.  So open up VS2017 and look for the “Azure Functions” template (under Visual C# -> Cloud). You can choose between “Azure Functions v1 (.NET Framework)” and “Azure Functions v2 Preview (.NET Standard)”. We like .NET Standard (which is the common denominator between the .NET Framework, .NET Core, UWP, Mono, and Xamarin) so we pick the v2 Preview.

Again, go with the HTTP trigger and find your Storage Account. Leave the access rights on “Function”. The generated function template is a little bit different than the one generated in the Azure portal, but the result is the same. One thing to note here is that Functions actually use the Microsoft.Azure.WebJobs namespace for triggers, which once again shows the two can (sometimes) be interchanged.

When you run the template you get a console which shows the Azure Functions logo in some nice ASCII art as well as some startup logging. Windows Defender might ask you to allow access for Functions to run, which you should grant.

Now if you run the Console App we created in the previous section and change the functions URL to “http://localhost:7071/api/Function1” (port may vary) you should get the same result as before.

Deployment using Visual Studio

If you’ve read my previous blog posts you should be pretty familiar with this step. Right-click on your Functions project and select “Publish…” from the menu. Select “Select Existing” and enable “Run from ZIP (recommended)”. Deploying from ZIP will put your Function in a read-only state, but it most closely matches your release using CI/CD. Besides, all changes should be made in VS2017 so they’re in source control. In the next form find your Azure App and deploy to Azure.

If you’ve selected Azure Functions v2 earlier you’ll probably get a dialog telling you to update your Functions SDK on Azure. A little warning here, this could mess up already existing functions (in fact, it simply deleted my previous function). As far as I understand this only affects your current Function App, but still use at your own risk.

Once again, find your Functions URL, paste it in the Console App, and check if you get the desired output.

Deployment using VSTS

Now for the good parts, Continuous Integration and Deployment. Open up Visual Studio Team Services and create a new build pipeline. You can pick the default .NET Core template for your pipeline, but you should change the “Publish” task so it publishes “**/FunctionApp.csproj” and not “Publish Web Projects”. You can optionally enable continuous integration in the “Triggers” tab. Once you’re done you can save and queue a build.

The next step is to create a new release pipeline. Select the Azure “App Service deployment” template. Change the name of your pipeline to something obvious, like “Function App CD”. You must now first add your artifact and you may want to enable the continuous deployment trigger. You can also rename your environment to “Dev” or something.

Next, you need to fill out some parameters in your environment tasks. The first thing you need to set is your Azure subscription and authorize it. For “App type” pick the “Function App”. If you’ve successfully authorized your subscription you can select your App Service name from the drop-down. Also, and this one is a little tricky, in your “Azure App Service Deploy” task, disable “Take App Offline” which is hidden under the “Additional Deployment Options”. Once you’re done, and the build is finished, create a new release.

When all goes well, test your changes with the Console App.

If everything works as expected try changing the output of your Function App, push it to source control, and see your build and release pipelines do their jobs. Once again, test the change with your Console App.

Working around some bugs

So… A header that mentions bugs and workarounds is never a good thing. For some reason, my release kept failing due to an “invalid access to memory location”. Probably because I had already deployed the app using VS2017. I also couldn’t delete my function because the trash can icon was disabled. Google revealed I wasn’t the only one with that problem. So anyway, I am currently using a preview of Azure Functions v2 and I’m sure Microsoft will figure this stuff out before it goes out of preview.

Here’s the deal, you probably have to delete your Function App completely (you can still delete it through your App Services). Recreate it, go to your Function App (not the function itself, but the app hosting it, also see the next section on “Additional settings”), and find the “Function app settings”. Over here you can find a switch “~1” and “beta” (which are v1 and v2 respectively). Set it on “beta” here. Now deploy using VSTS. Publishing from VSTS will cause your release to fail again.

Bottom line: don’t use VS2017 to deploy your Function App!

Additional settings

There’s just one more thing I’d like to point out to you. While Azure Functions look different from regular Web Apps and Web APIs they’re still App Services with a Hosting Plan. If you click on your Function App you land on an “Overview” page. From here you can go to your Function app settings (which includes the keys) and your Application settings (which look a lot like Web App settings). You’ll find your Application settings, like “APPINSIGHTS_INSTRUMENTATIONKEY”, “AzureWebJobsDashboard”, “AzureWebJobsStorage” and “FUNCTIONS_EXTENSIONS_VERSION”.

Another tab is the “Platform features” tab, which has properties, settings and code deployment options (see my post Azure Deployment using Visual Studio Team Services (VSTS) and .NET Core for more information on deployment options).

Functions Platform features
Functions Platform features

Wrap up

Azure Functions are pretty cool and I can’t wait for v2 to get out of preview and fully support .NET Standard as well as fix the bugs I mentioned. Now, while Functions may solve some issues, like dynamic scaling, it may introduce some problems as well.

It is possible to create a complete web app using only Azure Functions. Whether you’d want that is another question. Maybe you’ve heard of micro-services. Well, with Functions, think nano-services. A nano-service is often seen as an anti-pattern where the overhead of maintaining a piece of code outweighs the code’s utility. Still, when used wisely, and what’s wise is up to you, Functions can be a powerful, serverless, asset to your toolbox. If you want to know more about the concepts of serverless computing I recommend a blog post by my good friend Sander Knape, who wrote about the AWS equivalent, AWS Lambda, The hidden challenges of Serverless: from VM to function.

Don’t forget to delete your resources if you’re not using them anymore or your credit card will be charged.

Happy coding!

Azure Deployment using Visual Studio Team Services (VSTS) and .NET Core

Hey all,
After three years of radio silence I decided to write a new blog post *crowd goes wild*! A lot has happened since my last post. I wrote a book on Continuous Integration, Delivery, and Deployment (with JavaScript and Jenkins, mostly); got a Microsoft Azure certificate; found a new job using those Azure skills; and I got my own company on the side. Three years ago I ended with a blog series on math, but I’m not finishing that. Apologies if you were really looking forward to #4… My new focus, for now, will mainly be Microsoft Azure, Visual Studio Team Services (VSTS), and C# .NET Core. So without further delay, let’s talk about those!

Microsoft Azure

Microsoft Azure has been around for a few years now and you’ve probably heard of it. It’s the Microsoft cloud platform that competes directly with Amazon’s AWS and Google’s Google Cloud. If you don’t really know what “the cloud” is (besides the pretty hyped buzzword) I suggest you really look into it as I believe it’s the future (heck, it’s the present)! If you do not already have an account I suggest you create one. It’s free and you only need a credit card and a Microsoft email account like hotmail or outlook.

Beware, Azure is free for now. You get free credit which is valid for one month. Some services cost a monthly fee, for others you pay per use. Just having an empty Azure account is always free. In this post we’re going to host a default web application in Azure using an App Service (which, in any case, will cost you close to nothing).

Visual Studio Team Services (VSTS)

VSTS is Microsoft’s cloud version of Team Foundation Service (TFS), which is their tool for continuous integration and deployment, source control, and agile tools like SCRUM and Kanban boards. Again, if you do not yet have a subscription I recommend you create one. Just like with Azure it’s free and you need a Microsoft email address, like hotmail or outlook. For the free version of VSTS you get quite a bit of functionality, like 240 free build minutes per month and unlimited free private Git repositories (always use Git, never Team Foundation Service Control (TFSC)). With an MSDN subscription you get some extra functionality, but the free tier is good enough for this post.

.NET Core

Do I really need to explain this? For the last few years Microsoft has focused on .NET Core, an open source multi-platform subset of the .NET Framework. While it still has some issues, even in the latest .NET Core 2.1 release, it’s also pretty cool and I’m already using it for production software. It’s a bit different than the full .NET Framework, but not a lot. You may have to download and install the latest SDK, which can all be found on the .NET Core GitHub page. Visual Studio support for .NET Core starts from Visual Studio 2017, so be sure you’re up to date, otherwise you can probably follow along with a regular .NET Framework ASP.NET Web Application.

Creating a .NET Core project

So let’s put these tools together. We start by creating a new (private) project in VSTS, which is pretty simple. In fact, you probably already created one when you created a VSTS account. I kept the default, MyFirstProject. When you browse to the Code tab of your project in VSTS you can initialize your repository (at the bottom of the page) with a README.md file and a .gitignore file (choose Visual Studio).

Initialize a repository in VSTS
Initialize a repository in VSTS.

You can copy the link or clone directly into Visual Studio on the next page in the right upper corner under the “Clone” button. I’m assuming you know how Git works, so I’m not covering that here.

Once you have the repository locally we can start by adding some code. Since we’re focusing on deploying to Azure using VSTS it doesn’t really matter what code you have, so just create an ASP.NET Core Web Application in Visual Studio 2017. You can pick a regular Web Application (which will use Razor View Pages by default) or a Model-View-Controller project, whichever you fancy. Once the default web application template loads you can commit and push it to your Git repository and we can start the fun!

Azure App Services

For the next step we’re going to mess around in Azure a bit. Log in to your Azure portal and find your App Services. Simply click the “Add” button, pick a “Web App” and hit “Create”. On the next page you can set some settings for your web app, such as the URL at which your app will be hosted (which always ends at .azurewebsites.net).

New Azure Web App
New Azure Web App

You’ll also have to create a resource group or pick an existing one. A resource group is simply a way to group certain resources for a quick overview. For example, you can have a separate resource group for dev, test, acceptance and production or for your customer portal and your internal tools, it’s all up to you.

The most important setting here is the App Service Plan/Location. This is basically a server that you pay for. A new plan is generated for you, but you can create your own as well. You have different price tiers with different hardware specifications and Azure functionality, like CPU, memory, custom domains, staging slots, and daily backups.

The location of your plan determines where the server is physically located. For me, in the Netherlands, West Europe is ideal because I know it’s in Amsterdam. Just go with the default Standard S1 plan. Even if you don’t have free credits you can delete it after you’ve read this blog post and it will only cost you like $0.03, so don’t worry about costs.

Setting up deployment from Azure

For now we’re staying in Azure. You’ve probably seen the “Build and Release” button in VSTS. That’s where you can create new build and deployment pipelines, which is great, but also a bit of work.

A build pipeline can automatically build and test your software after a push to Git. This includes restoring NuGet packages, minifying and bundling any HTML, CSS and JavaScript you might have, executing task runners and basically anything you’d ever need to make your software build and run. When your latest commit is built and tested VSTS can create an artifact for publication.

The deployment pipeline can download the artifact from a build pipeline and put it in Azure (or on your own on-premise servers). The trigger for a deployment is usually that a build has succeeded, but can also be a push to Git or a manual trigger.

When you’re building and testing your software automatically this is called Continuous Integration (or CI) and when your software is also automatically deployed this is called Continuous Deployment (or CD). There’s something in between, which holds off the deployment until a user explicitly presses a button and gives the “okay” sign, this is called Continuous Delivery. When you’re doing both CI and Continuous Delivery and/or Deployment you’re doing “CI/CD”.

Let’s set this up with pretty much a single button click. You’ve got two options in Azure. In your Web App, either configure deployment from the “Deployment options” menu item or use the newer “Deployment Center (Preview)” which, as the name suggests, is still in preview.

Deployment options in Azure
Deployment options in Azure

Deployment options

It’s really so simple I’m not even sure if I should walk you through the next steps. Click the “Deployment options” menu item and simply fill in the options you want to use.

Deployment settings in Azure
Deployment settings in Azure

And that’s that. If you now browse to the Deployment options in your Web App you’ll see that Azure now shows all your commits. If you push a new commit to your repository you can even see the build status in Azure because Azure linked it to your VSTS account.

Continuous deployment in Azure
Continuous deployment in Azure

When deployment is done, browse to your Azure website (for me that’s imunique.azurewebsites.net) and behold, your website is up and running! Try changing something on the homepage, push it to Git, wait a few minutes, and see your website get updated.

Deployment Center (Preview)

My guess is that Microsoft is planning to replace the “Deployment options” with the “Deployment Center (Preview)”. If you have already set up CI/CD with the Deployment options you’ll see your commits in here too. For the purpose of this blog we’re going to “Disconnect” (button in the top menu).

Now go to the Deployment Center (Preview) and you should see various source control options, like VSTS, Github and Bitbucket. It’s a little more visually appealing than most Azure panels. So pick VSTS and continue. Next, you have to pick a build provider. I have zero experience with Kudu, so pick “VSTS Continuous Delivery” (which somehow isn’t the default).

Deployment center in Azure
Deployment center in Azure

In the next panel you can pick your VSTS account and repository. Unfortunately, at the time of writing this blog there seems to be a bug here which prevents me from picking an account. It worked in the past and the Azure team said they have fixed the problem in an upcoming release (which is pretty often)… So try it our yourself as this may work for you!

Anyway, if you continue, Azure creates a build pipeline and a deployment pipeline in VSTS! Now that’s pretty cool. It gives you complete control over your builds and deployments as you can tweak them however you like. At the same time the Deployment Center now shows you which builds have been deployed.

Pipelines in VSTS

So browse to your VSTS and check out the build. The user interface isn’t always intuitive, but you should be able to find it. You can edit the build and click around a bit. You shouldn’t need to change it, but you can.

VSTS build
VSTS build

The deployment is a little different. There’s just one build for every piece of code, but there can be multiple deployments, for example for your entire DTAP street (dev, test, acceptance, and production). Azure created a release with a single environment, “Dev”.

VSTS release
VSTS release

You can change the deployment in the “Tasks” for that environment (either click the Dev tile or select Tasks in the upper menu). The tasks look kind of similar to the VSTS build and can be (completely) different for each environment. Mostly, your tasks will be more or less the same and you’ll only have some values that differ per environment. You can use “Variables” for these different values, but that’s out of the scope of this post.

It’s also pretty easy to clone an entire environment (including it’s tasks and variables). Just hover over the tile of the environment you’d like to clone and a “Clone” button will show up. Click it and you get a new environment that’s exactly like the one you cloned. Further setup of builds and releases is out of scope of this post, but you can click around if you like.

When you’re done playing around simply delete the release and the build pipelines (in that order). Also make sure you disconnect the deployment in the Azure Deployment Center.

Deployment from Visual Studio 2017

Finally, let’s switch back to Visual Studio. You can do the exact same thing in Visual Studio. Right click on the project you want to release (which is your web project) and choose “Overview” in the drop down menu. In the page that opens go to “Publish” (in the menu on the left).

Here you can publish or set up your CI/CD. Click the “Start” button under “Continuous Delivery” and you can once again choose a VSTS subscription and an App Service (it creates a new App Service by default, but you can also select an existing one). Simply clicking the “Ok” button will have the same outcome as what we did in the Deployment Center. It will create a new build and deployment pipeline that is also visible in your Deployment Center. Pretty cool!

Going back to the Publish page in Visual Studio, you can also just publish directly. This is pretty useful if you want to release something to Azure right now. Simply click the “Start” button under “Publish”. You can now either create a new Azure App Service or pick an existing one. Just follow the wizard and your application will be published to Azure directly, without a build or deployment pipeline. Be careful though, your local build will be deployed, which will often be different than a build from the build server.

Wrap up

So there you have it! Deployment was never this easy! In just a couple of minutes we’ve created an application, put it in source control, and deployed it to the cloud, ready for the world to see (you can restrict access, but that’s out of scope). In the past it could take you hours to set up a new server (or days and even weeks if you still had to order one), but this alternative is a lot faster and cheaper.

The next step is using ARM (Azure Resource Management) templates to automatically create App Services and other Azure resources. Check out my post on ARM templates to get started.

Don’t forget to delete your App Service and your App Service plan or you’ll be charged for them!

Good luck and happy coding!