DEV Community: Dean Bryen

5 ways to skill up on the cloud this Christmas! 🎅🏻🎄

Dean Bryen — Mon, 02 Dec 2019 12:35:53 +0000

So Christmas is coming and December is normally a time when everyone is starting to wind down for the holidays. But the Developer Relations people of this world just don’t know when to slow down!

I’ve been amazed this morning, logging onto my computer and seeing all of the amazing content that’s being created and published EVERY day in the run up to Santa’s visit!

It turns out, that December might just be the best time of the year to learn more about the cloud! Don’t wait until January to start your new years resolution, utilise the quiet period to get up-skilled today! Here’s a few great resources fo you to check out this month!

Resources

Sign up for a free Azure account
If you want to complete some of the challenges, you’ll need an account with a cloud provider. Here’s how to get one on Azure.

1. 25 Days of Serverless

This one is brought to you by the team of Azure Dev Advocates at Microsoft. Each day, there will be a new challenge posted and you’ll be able to learn all kinds of things about Serverless technology by means of creative puzzles and fun activities.

The challenges can obviously be completed on Azure, maybe leveraging Azure Functions or Azure Logic Apps, but they’re cloud agnostic too, so you can solve them on any serverless cloud of your choice!

All you have to do is visit 25daysofserverless.com to learn all about it and find the first couple of challenges!

2. Azure Advent Calendar

Want to learn about Azure? Or maybe you’re already using Azure and want to dive deeper each day? This one is absolutely jam packed with content.

Brought to you by Azure MVPs Gregor Suttie and @Pixel_Robots You’ll get a whopping 3 pieces of content each day! Each day there’ll be 3 videos, each with an accompanying blog post. They’ll be covering a bunch of Azure topics from Azure IoT through to how to pass Azure Certifications so there’s something for everyone!

Head over to https://azureadventcalendar.com/ or their YouTube channel to get your hands on the content each day!

3. #DevDecember

So we’ve already covered some new content that you can get each day this month. But it’s been an amazing year of content already in 2019! #DevDecember, brought to you by @livelovegeek from Microsoft Azure, is an effort to share some of the best cloud content of the year, as well as some new stuff too!

I hear there’s going to be an awesome Ugly Christmas Sweater IoT tutorial!

There’s a blog post explaining everything here, and you can follow the hashtag #DevDecember on Twitter to get all the juicy content each day!

4. Devops this holiday season?

I know just what you need to get you in the Christmas spirit! Some Devops!!!

Edward Thomson from Github is going to be posting a daily blog post for you to learn more about Github Actions, their new service that allows you to perform CI/CD. As well as build, test, and deploy your code right from GitHub

To check the posts out, head over to Edward’s personal blog where he’ll be posting the content.

5. Advent of Cyber

As a cloud security advocate, how could we miss this one out! It’s not specifically cloud security related, but security is important folks! So it can’t harm to brush up on our infosec skills this winter can it?

The Cyber Advent Calendar is brought to you by TryHackMe and each day there’ll be a challenge every day, designed at beginners, in their words ‘we won’t be throwing you in at the deep end’ so it’s a fun way to get up to speed if it’s not something you’ve really invested time in previously!

There’ll be challenges released on Web Exploitation, Scripting, Networking and more! Each one is self contained so it doesn’t matter where/when you get started.

So head on over to https://tryhackme.com/christmas to get started!

So there we have it, 5 great resources to help you brush up on the Cloud this December! Here’s a final list of resources.

Sign up for a free Azure account
If you want to complete some of the challenges, you’ll need an account with a cloud provider. Here’s how to get one on Azure.
25 Days of Serverless
Azure Advent Calendar
#DevDecember
Github Actions Advent Calendar
Advent of Cyber

Happy Learning!

My Top 5 Azure Security Announcements from Microsoft Ignite 2019

Dean Bryen — Tue, 12 Nov 2019 11:21:52 +0000

My Top 5 Azure Security Announcements from Microsoft Ignite 2019

I was lucky enough to be at Microsoft Ignite in Orlando last week! The number of announcements was pretty hard to keep up with, it was relentless! And so was the sunshine, so I just went and sat by the pool and sunbathed all week! ☀️

Orange County Convention Center

Oh how I wish that was true! I was busy meeting a whole bunch of people, recording some video content, and most importantly trying to keep on top of the security announcements so you don’t have to 😊

So I thought I’d summarize my top 5 Azure Security announcements for you right here! Here goes…..

Azure Security Center — Custom Policies (Preview)

Up until today, you’ve been able to leverage the recommendations, secure score and regulatory compliance checks that Security Center has built in. But lots of you probably have your own security policies and benchmarks too!

Good news! As of Ignite (in public preview) you can now create a custom initiative in Azure Policy that meets your own security requirements, and add that as a policy in Security Center. This means you can extend the coverage of Security Center to include your own assessments which will filter through to the Secure Score, Recommendations and Regulatory compliance dashboards you’re already familiar with today.

Find out more here.

Threat Protection for Azure Kubernetes Service (AKS)

Containers and Kubernetes is hot stuff right now. More and more people I speak to are looking to Kubernetes as the new standard for deploying and managing cloud native applications.

As of Ignite (In preview), you can now leverage Azure Security Center to understand the security posture and gain further insights into your Azure Kubernetes Service (AKS) clusters. This release includes three key things:

Continuous discovery of managed AKS instances
Actionable reccomendations on security best practices for AKS
Host and Cluster based threat detection analysis

Find out more here.

Azure Notebooks direct from Azure Sentinel

Azure Sentinel was announced earlier this year. It’s a cloud native Security Incident and Event Management (SIEM) service. It provides a single solution for alert detection, threat visibility, proactive hunting, and threat response.

Threat hunting is one area that I am particularly interested in. The power of finding threats in your environment is trawling through the data. Now you can some threat hunting in the Azure Portal, but to gain richer insights, and leverage a number of widely used python and machine learning libraries, many hunters are looking to Jupyter notebooks and Python to perform their hunting analysis.

This has all been possible up until today by leveraging Jupyter and the kqlmagiclibrary. However it just got a lot simpler. Azure Notebooks, a hosted Jupyter notebook service is now directly integrated with Azure Sentinel, and there are also handful of pre-built notebooks already available for you to get started, as well a larger number of notebooks you can leverage from in the Sentinel Github Community.

Find out more here.

Azure Arc — Implement Azure Security Anywhere

Azure Arc was one of the hottest announcements at Ignite this year! Seriously, go and check it out! In a nutshell, it enables deployment of Azure services anywhere, on premises, at the edge, on other clouds and it extends Azure Management and Security to any the infrastructure in those places too!

But this blog post is about security. So what security benefits does Azure Arc bring to on premises/edge/multi-cloud environments?

Access unique Azure security capabilities such as Azure Threat Detection
Centrally manage access and security policies for resources with Role Based Access Control
Enforce compliance and simplify audit reporting

Find out more here.

Password-less Authentication for the masses

OK so this is one I’m super happy about. Until last week, only customers with a paid Azure Active Directory (AD) plan could use the Microsoft Authenticator app for password-less authentication (Preview).

But now customers with any Azure AD plan can use password-less authentication. Yippee!

Also, as of 1st Nov 2019, there will be no charges for using Multi-Factor Authentication or passwordless authentication. Double Yippee!

Find out more here.

Oh and something fun to share

I thought I’d share with you one awesome infosec thing I got a chance to do at Ignite.

Microsoft created 1nter5ec7ion, a VR based escape room for Cyber Defenders wanting to save the world! Sounds more serious than it was, honest! But it was super fun, four colleagues and I had to work as team to solve a number of challenges in a 15 minute period to defeat the infamous hacker 157. It was great fun,and we escaped with 04:03 to spare! #WorldsBestCyberDefenders

I’m not sure if they’ll be bringing this to other conferences, but if they are, and you see it, you should definitely check it out!

What was your top announcement?

So that’s it! My top 5 Azure Security announcements at Microsoft Ignite 2019!

What were your favorite announcements?
Did I miss anything huge!

Let me know in the comments.

Azure Pipelines - Adding CI/CD from GitHub to Azure Functions ⚡

Dean Bryen — Mon, 17 Sep 2018 00:00:00 +0000

Last year Azure Devops was released. The CI integration with GitHub looked neat, so I thought I’d try it out for some serverless apps.

So here’s how I went about configuring a very simple setup!

Pre-requisites:

An existing Azure Function App — (Tutorial)
A GitHub repository with your function code in. If you don’t have one, you can fork my Super Simple Function repo and follow along.

Let’s start out with the Azure Pipelines Plugin from the GitHub Marketplace.

Let’s go ahead and set up a plan.

Azure Pipelines is free for both public and private projects, and public repositories even get 10 parallel jobs for free too. So, unless you need multiple parallel jobs for your private repositories, which we most definitely don’t for this tutorial, you can select the free plan .

Go ahead and install the marketplace app, and log in to your Azure account. You should be redirected to the Azure Devops portal. You’re now ready to setup Azure Pipelines for our serverless app! 😀

First, go ahead and select your repository, I’ll be using my functions-simple repository.

Pipelines will now analyse the git repository and recommend a starter template. This may differ depending on your application, and feel free to play around here. But I’m just going to select the ‘Starter Template’ as we’ll be scrapping this and writing our build pipeline from scratch.

This is where the magic starts to happen. You define your build pipeline as code, by creating a YAML file calledazure-pipelines.yml . We’ll write ours in a moment. But let’s first understand why that’s awesome.

You place your azure-pipelines.yml file at the root of your repository.
Upon a push to your linked GitHub repository, Pipelines will trigger a build, which will follow the steps and configuration outlined in azure-pipelines.yml
So you can keep your build pipeline configuration right beside your application code and version controlled in GitHub.

So what does the azure-pipelines.yml file for our build pipeline look like?

Agent Configuration

The first section of our YAML file defines the agent pool which will be running our jobs. These are the hosts that run our build steps for us. Here we have decided to use Hosted Linux Agents running Ubuntu.

pool:
  vmImage: 'Ubuntu 16.04'

Build Steps

Next, we need to define our build steps. Our build will have three steps.

Run an npm install
Create a zip archive of our code
Publish our build artifacts for our release pipeline to pick up

Of course in a real environment you may run mocha to perform tests, do some static code analysis, or use tools like funcpack to improve cold starts. All of these are easily achievable within pipelines too. But for the purpose of simplicity, we’ll stick to these three steps.

First up, we run npm install using the script step. Pretty self explanatory.

steps:
  - script: |
      npm install
    displayName: "npm install"

Secondly, we create an archive of our code using the built in Archive task.

- task: ArchiveFiles@2
    displayName: "Archive files"
    inputs:
      rootFolderOrFile: "$(System.DefaultWorkingDirectory)"
      includeRootFolder: false
      archiveFile: "$(System.DefaultWorkingDirectory)/$(Build.BuildId).zip"

Scripts enable us to run command line scripts on the agent hosts, tasks are extra functionality that is either first party from Azure Devops or in the marketplace. Here we are using the ArchiveFiles task to package up our code. We can also reference some useful variable that Azure Devops provides us here, you can see we are using these to identify the $(System.DefaultWorkingDirectory) and $(Build.BuildId) to both locate our code and save it with a meaningful name.

Finally, we add a task to publish our build artifact.

- task: PublishBuildArtifacts@1
    inputs:
      PathtoPublish: '$(System.DefaultWorkingDirectory)'
      name: 'drop'

Here, we are putting our artifact into the DefaultWorkingDirectory with the name of drop . We’ll be picking this up from there in our release pipeline when we deploy to Azure Functions.

And that’s all there is to our build pipeline! Our azure-pipelines.yml file that defines our build pipeline is finished, the final file should look like this:

pool:
  vmImage: 'Ubuntu 16.04'
steps:
  - script: |
      npm install
    displayName: "npm install"
  - task: ArchiveFiles@2
    displayName: "Archive files"
    inputs:
      rootFolderOrFile: "$(System.DefaultWorkingDirectory)"
      includeRootFolder: false
      archiveFile: "$(System.DefaultWorkingDirectory)/$(Build.BuildId).zip"
  - task: PublishBuildArtifacts@1
    inputs:
      PathtoPublish: '$(System.DefaultWorkingDirectory)'
      name: 'drop'

You can delete the starter template in the browser, and replace it with your YAML file that will be similar to that above. Then click ‘Save and Run’. this will prompt you to commit your azure-pipelines.yml to the linked GitHub repository. Add an optional commit description and then click ‘Save and Run’ again.

Release Pipeline

So now we’ve built our build pipeline and published our build artifact. We now need to create a release pipeline to deploy our application to Azure Functions. Unfortunately, Release pipelines don’t support YML today. So we’ll be creating this in the GUI.

Firstly, click on Releases under the Pipelines heading in the Devops Portal and then click the ‘New’ button.

We’re going to be using the ‘Azure App Service Deployment’ Template , so we’ll select that one, and then hit ‘Apply’.

You can give your stage a name if you wish. So I’ve named mine ‘Deploy to Azure Functions’

Next, we’ll need to configure the tasks that we want to perform as part of this stage within the release pipeline. We’ll click on the ‘1 job, 1 task’ link in within our pipeline to get these set up.

You’ll be warned that our App Service Deployment task has some missing settings. Let’s fix these up.

First of all, we need to authorise the connection between Azure Devops and our Azure Account where our function app lives. If you’re logged into Azure Devops with the same account that you use for Azure, you should be able to select the relevant subscription from the drop down menu. Once selected, click ‘Authorise’. You will get a pop up, asking you to log into your Azure account and authorise, in the background, this is creating a Service Principal with a contributor role, that allows Azure Devops to deploy to the Function App in your Subscription.

Make sure you’ve set the App type to ‘Function App’ and then you should be able to select your function app from the pre-populated drop down under ‘App Service Name’.

We’ll leave the Package or folder field with the default value of $(System.DefaultWorkingDirectory)/**/*.zip , this is where it’ll grab the published artifact of our build pipeline from.

Head back over to the Pipeline tab in the portal. Next, we need to tell our release which build artifact we want it to deploy. So click on ‘Add an artifact’.

Here, we are configuring our artifact with the settings of our build pipeline. Simply complete the form using the pre-populated drop down menus and selecting the values for the build pipeline that we created earlier.

So now we have an artifact, and some steps to perform for this release. We now need to setup a Continuous deployment trigger. This will tell Azure Devops when to run our release. Go ahead and click on the Lightning Bolt symbol next to our artifact.

We can tell the service to create a release each time a new build is available, which will be each time we commit to our master branch thanks to the GitHub CI integration we setup earlier. So check the box to enable the Continuous Deployment trigger.

Testing

And there we have it, we now have a GitHub CI integration with our build pipeline, which upon completion will trigger our continuous deployment to Azure Functions via our release pipeline.

To check this works, Edit something in your function code, commit this to git and push to your linked GitHub repository. Sit back, and watch the magic happen…

Note: If using my functions-simple example, you can simply change the response body of /hello/index.js to something different.

If you click on Builds, you should see in that upon pushing to GitHub a new build has started. Clicking on that specific build will provide a summary of the build. Once completed, you should have a big green check mark!

If you want to dive deeper into the steps, you can click on the Logs tab and see each step of the build and exactly how long each one took, and if you click onto one of the steps, you will see the raw logs from the underlying agent when it was running that build step.

Once our build is complete, our Continuous deployment trigger should have been fired and our release pipeline should have kicked off. Click ‘Releases’ on the left hand side to see how our pipeline is getting on.

Here you will see that the release pipeline has been triggered, and you should see our stage ‘Deploy to Azure Functions’ highlighted green with a check mark to indicate there was a success.

Now you can execute your Azure Function and see the changes that you made have taken effect. Happy Days!

Woohoo

And that’s it, you now have CI/CD setup for your Azure functions using Azure Pipelines, directly from a push to your GitHub Repository 😀

If you want to dive deeper, head on over to the Azure Devops Documentation. Where you can build on the what we have done here to include multiple environments, release gates, project management and much more!

Azure Functions ⚡ A Developers Guide to Key Features

Dean Bryen — Mon, 17 Sep 2018 00:00:00 +0000

How to get started with Azure functions

The past year of my life as a developer has been focused on diving deep into Azure Functions. Now that I’ve had the chance to come up for air, I wanted to share a few of my lessons to help other developers on their serverless journey.

I’ve identified a few of my favorite features that has made developing with Functions as a Service (FaaS) a lot easier. Please hit me up in the comments with your feedback — I’d love to hear what features would help improve the next year of your life as a serverless developer.

Simple & Native Developer Tooling

While I’m a huge fan of the Serverless framework, their Azure support isn’t fantastic. The framework currently only supports Functions and it’s done via a plugin, which makes it feel a little like a second-class citizen. While I have high hopes for their components project — that’s for another blog post.

At first, I was crying out for an equivalent framework for Azure — and there still might be an argument for this approach. But as I dug deeper into functions, I’ve become the #1 fan of Visual Studio Code.

With VScode, I’ve found it pretty seamless to get done everything from within the tool. This comes down to a couple of things:

VSCode Extensions and Functions v2.0 Local Runtime

Anyone who has used VSCode will be familiar with the extension ecosystem — and the the functions extension for VSCode is solid. The extension relies on azure-functions-core-tools which is a simple command line tool, so you can run the Azure Functions runtime locally. As an added bonus, the CLI can also be used independently of the VSCode extension.

The v2.0 runtime of Azure Functions is open source and runs on .NET Core. This means that what you install on your local machine — whether Mac, Linux or Windows — is the exact same runtime as you get in the Azure Cloud. No emulators or simulators trying to mimic the behavior of the cloud provider.

Using a combination of the local runtime and the extension, you can create a function project, add some functions, test and debug them locally, and then publish them to Azure — within just a few clicks or commands. Once it’s running, you can simply stream the logs directly from the function running in Azure to your terminal in VSCode.

Function Bindings

Sadly, when people talk about serverless it often centers around Functions as a Service (you mean a bit like this blog post, Dean? 😛).

FaaS is just one piece of a serverless application or architecture. If you really want to make any application that’s worth talking about, it’s likely that your Functions will need to integrate and communicate with a ton of other services and systems. It could be as simple as accessing a storage container or writing to a database — either way, you can’t achieve much with just FaaS.

Azure Function Bindings offers developers a simple way to integrate with a bunch of services. This is great for a couple of reasons. First, changing the database no longer requires developers to edit our business logic that sits within our function code — we can just update the binding configuration. Secondly, it just makes your code much simpler.

Bindings come in two flavors

Input — these happen before your function code is executed
Output — these happen upon completion of your function code.

There’s a vast number of bindings supported, and I use quite a few on a regular basis. To get started, here’s a quick and easy example that demonstrates how to use the CosmosDB bindings.

One of the really nice features is that ability to configure our bindings right alongside our function code in a function.json file. Here’s our input binding to fetch a document from our CosmosDB collection via it’s id.

{
    "name": "cosmosDBInput",
    "type": "cosmosDB",
    "databaseName": "MyDatabase",
    "collectionName": "MyCollection",
    "id" : "{id}",
    "connectionStringSetting": "myCosmosDBAccount",     
    "direction": "in"
}

To interact with the binding, we just reference it by name with some super simple code below. I’m using Javascript, but any of the supported languages can achieve the same.

module.exports = function (context) {   
    let data = context.bindings.cosmosDBInput;
    context.log(data);
    context.done();
};

We can also do something very similar for an output binding. Below is how you could write a single document to a cosmosDB collection.

First, we need the binding configuration in function.json

{
    "name": "puppyData",
    "type": "cosmosDB",
    "databaseName": "MyDatabase",
    "collectionName": "MyCollection",
    "createIfNotExists": true,
    "connectionStringSetting": "myCosmosDBAccount",     
    "direction": "out"
}

Next, we can simply use that binding within our function code:

module.exports = function (context) {
      context.bindings.puppyData = { 
        id: 1,
        name: "Rover",
        breed: "Great Dane",
        address: "Big Dawg House, Paw Lane, London"
      };
      context.done();
};

If you’re using Functions, you’ll want to use Bindings .

Built in HTTP Trigger

After working with other cloud providers, it was always necessary to spin up some form of an API Gateway in addition to my function so I could serve web requests over HTTP.

I’m all for API Management and Gateway services — they can bring a lot of value to your APIs. But for some use cases they’re a little bit overkill, especially if you just want to invoke the function over HTTP natively.

With Azure Functions, this feature comes out of the box. You just need to provide your function a HTTP Trigger, and then you can invoke it straight from the web.

Don’t panic — this doesn’t mean just anyone and everyone can now invoke your function. You have the ability to select one of three levels of authorization for the HTTP Invocation: anonymous , function or admin. The latter two requires a key to invoke the function via the web.

Just like bindings, we can have our HTTP trigger’s configuration alongside our code in the function.json file — and it looks just like bindings. Here’s an example of what your file may look like:

"bindings": [
    {
      "authLevel": "anonymous",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    }
]

Now you can simply reference the HTTP Trigger in your code via it’s name req. One interesting thing to note — the HTTP response is actually just using the http output binding.

Function Proxies

While the HTTP trigger gives you a simple invocation over the web, what if you need something a little more than a HTTP Trigger — but a bit less than a full blown API Gateway?

Function Proxies provide developers the ability to have a lightweight API gateway — right within your Function App. Similar to both triggers and bindings, the configuration resides alongside your code in a proxies.json file. In it’s simplest form, a function proxy configuration will look something like this:

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "proxy1": {
            "matchCondition": {
                "methods": ["GET"],
                "route": "/api/{test}"
            },
            "backendUri": "https://<AnotherApp>.azurewebsites.net/api/<FunctionName>"
        }
    }
}

In this example, we are simply routing our proxy to a function as the backend. Function Proxies also support things such as request and response overrides, so you can manipulate the HTTP requests in the same manner as most enterprise API gateways.

Function Proxies are rally handy for a couple of things, especially 1) avoiding issues with cross-origin resource sharing (CORS), and 2) mocking out your API responses.

Avoiding CORS issues

I build a lot of Single Page Apps (SPAs) that I host in Azure Blob Storage. Whenever I connect them to my functions, I usually encounter a CORS error since they’re hosted on different domains.

There’s a couple of ways to fix this. One option is to update the CORS settings in your Function App to accept the storage container’s domain. Or … you can simply use Function Proxies for both your Functions and your Azure Blob — so you’re basically putting them on the same domain. No more CORS errors. TADA!

To use Function Proxies to avoid CORS issues, just put the URI of your storage container as the backendUri of your proxy configuration. Here’s an example:

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "proxy1": {
            "matchCondition": {
                "methods": ["GET"],
                "route": "/"
            },
            "backendUri": "https://myserverlessapp.z6.web.core.windows.net/index.html"
        },
        "proxy2": {
            "matchCondition": {
                "methods": ["GET"],
                "route": "/media/{*restOfPath}"
            },
            "backendUri": "https://myserverlessapp.z6.web.core.windows.net/media/{*restOfPath}"
        }
    }
}

Mocking out API responses

Azure Functions Proxies also provides a simple way to mock responses for your API. You can basically create a Function Proxy, don’t give it a backend URI, and then you use the requestOveride feature to return your mocked response. Over to you front end dev! Here’s an example:

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "proxy1": {
            "matchCondition": {
                "methods": ["GET"],
                "route": "/api/hello"
            },
            "requestOveride" : {
                "response.statusCode": "200",
                "response.body": "{ \"message\": \"Hey There\" }"
            }
        }
    }
}

What’s your thoughts?

I’m hoping you’ve enjoyed learning about these features — they’ve certainly made my experience as a developer using Azure Functions more enjoyable.

What features are making life easier for you? What features are on your wish list for Azure Functions? I’d love to hear from you in the comments below, or connect with me on Twitter at @deanbryen.