Tag Archives: Functions

Azure Functions for Java developers

I had great fun yesterday presenting at the Sydney Serverless Meetup on the currently in-preview support for Java on Azure Functions. Rather than throw the slides up somewhere online I thought I’d write a blog that covers the content with the added bonus of giving you the option to dig into items in more detail.

First some background

I started with a bit of an overview of Azure Functions and why it is we have two runtime versions (because two is better than one, right?!) Actually, there are two versions because the new v2 runtime is designed from the ground up to be cross-platform as a runtime and developer experience, along with providing much better language (.Net, Java, Node, etc) and Binding extensibility. Azure Functions offers great productivity benefits, but you need to understand a bit about the basics to get going. Key items covered included:
  • Open Source – you can find everything the Functions team does on GitHub. Have a bug or feature request? File an issue (or even better… submit a PR 😍)
  • Triggers – control how Functions are invoked (on a schedule, on a HTTP request, on a new queue message).
  • Bindings – remove integration complexity by using Bindings to declaratively connect to input and output data sources.
  • Proxies – build clean REST APIs over Functions or other APIs without the need to setup and run a separate API gateway service.
  • Local Developer Experience – Functions development work (v2 runtime) can be done on Linux, Mac and Windows using whatever IDE you are used to. Java developers can build Java-based Functions locally using Eclipse, IntelliJ or Visual Studio Code
  • CI/CD – Functions support a rich set of CI and CD solutions
  • Monitoring – Application Insights is your go-to default experience but you have other options for your business logic use, particularly in v2 with the flexibility of the Logger design in .Net Core.

The Java story for Functions

At the time of the presentation (and this blog) the Functions team was actively working towards the General Availability (GA) of Java support for Functions. This work consists of two items: (1) the Java Worker that does the heavy lifting with the Functions Host of running the actual Java Functions you write; (2) the Maven Plugin that enable developers to quickly create, package, debug and deploy Java-based Functions. You can see from the Worker repository how the team is working at the very core of Java to enable the language as a first class citizen on the Function runtime. This is not simply invoking java.exe 😜. I demonstrated how you can create Functions using a Maven Archetype and then develop and test your business logic locally in IntelliJ with Maven. The main Docs site has the full details on how you can do this, so I won’t reproduce it here – go and try it out for yourself. If you need to import libraries as part of your solution you can add them to the pom.xml like you would in any standard modern Java project. We talked about scenarios where Java Functions might make sense in your world. Scenarios discussed included:
  • Modernise cron / batch / background jobs – you may have handed these to the ops folks in the past to write or run – now you can bring them into your development team’s SDLC.
  • Move @Scheduled Spring Boot or ExecutorService workloads out of other code into a stand-alone execution context.
  • Simplified event-based programming – remove the need to have polling logic in your code.
  • Develop “Microservices”.

But that’s not all…

If you order now you get a free set of steak knives! No… wait… wrong context! But… actually… *almost*. Microsoft has been working with Azul Systems to provide support for Java on Azure using Azul’s Enterprise builds of the OpenJDK. The benefit of this, as announced recently, is that Java workloads on Azure using Azul will benefit from free LTS support after January 2019.

Developing your own Bindings

I rounded out the evening by talking about how you can extend Functions capabilities by leveraging the new extensibility model for Bindings. Unsurprisingly this is very well documented on GitHub by the team, along with examples. We covered that these extensions are developed using .NetΒ but can be consumed by any language bolted into the Functions runtime (which is awesome as a Binding provider – write once!) I even threw together a very simple example of writing a text file to a cloud storage container that used an output binding to upload a blob where the Binding did the heavy lifting of connecting to the provider and writing the file! No more plumbing code mixed in with my business logic 😎!

Useful links

Here are the raw set of useful links from my slides:

Audience questions

I managed to get through most of the questions on the evening – for those that I didn’t here are the answers.
  • Gradle support: unofficial right now – I’m waiting on official support advice.
  • Concurrency limits for Functions: official documentation on parallel execution.
  • Max execution time in containerised Functions: on a Consumption-style Plan in Azure: 10 minutes; otherwise indefinitely!
So, there we have it – what a great story for Java developers wanting to do more event-based programming! Happy days! 😎
Tagged , , , , , ,

A Year with Azure Functions

“The best journeys answer questions that in the beginning you didn’t even think to ask.” – Jeff Johnson – 180Β° South

I thought with the announcement at Build 2017 of the preview of the Functions tooling for Visual Studio 2017 that I would take a look back on the journey I’ve been on with Functions for the past 12 months. This post is a chance to cover what’s changed and capture some of the lessons I learned along the way, and that hopefully you can take something away from.

In the beginning

I joined the early stages of a project team at a customer and was provided with access to their Microsoft Azure cloud environment as a way to stand up rapid prototypes and deliver ongoing solutions.

I’ve been keen for a while to do away with as much traditional infrastructure as possible in my solutions, primarily as a way to make ongoing management a much easier proposition (plus it aligns with my developer sensibilities). Starting with this environment I was determined to apply this where I could.

In this respect the (at the time) newly announced Function Apps fit the bill!

The First Release

I worked on a couple of early prototype systems for the customer that leveraged Azure Functions in their pre-GA state, edited directly in the Browser. I’m a big C# fan, so all our Functions have been C# flavoured.

After hacking away in the browser I certainly found out how much I missed Visual Studio’s Intellisense, though my C# improved after a few years away from deep use of the language!

We ran some field tests with the system, and out of this took some lessons away.

I blogged about Functions with KeyVault and also on how to deliver emails using Functions with SendGrid.

At this point I also learnt a key lesson: Functions are awesome, but may not be best suited to time-critical operations (where the trigger speed is measured in milliseconds or low seconds). This was particularly the case with uncompiled Function Apps (which at the time was the only option).

I wrote a Function to push a sythentic transaction into our pipeline periodically to offset some of this behaviour. Even after multiple revisions we’re still doing this certain activities such as retrieving and caching Graph API access tokens.

Another pain point for us at this juncture was the lack of continuous deployment options. Our workaround was a basic copy / paste into a VSTS Web project held in Git repository in VSTS.

Around the end of our initial field trials Functions hit GA which was perfect for us!

The Second Release

I now had a production-ready system running Functions at its core. At this stage we had all our Functions in a single App because the load wasn’t sufficient to break them out.

Our service was yet to launch when the Functions team announced a CI / CD experience using the ‘Deployment Options’ setting in the Azure Portal.

We revved to a second release, using the new CI / CD deployment option to enforce deployments to a production App Service Plan. We were still living with on-demand compilation which we found impactful at deployment time as everything had to be restored and recompiled.

The Third Release (funproj all round!)

Visual Studio 2015 tooling was announced!

Yep, we used it – welcome to funproj Revision (3) of the codebase!

About now, one of my earlier blogs on sending email came back to haunt me as I began to (and still do periodically) receive emails from people clearly trying out my sample code!

Ah… the dangers of writing demonstrations that have your real email address in the To: field.

One item we’ve done with each major revision of the Functions code is to publish a new App Service Plan and use this is as our deployment target. We paramaterise as much as we can so we can pre-populate things like Service Bus connection strings. Our newly deployed Functions are disabled and then manually cut over one at a time until we’re satisfied that the new deployment is in a happy state. This n-1 Function App will live for a couple of weeks after initial deployment with its Functions disabled. This was all decided before deployment slot support which may change this design πŸ™‚

We have a Function we can run that checks that all your environment variables are setup in a new App Plan – hopefully in future we’ll get this automated away as well!

Additionally, if we have a major piece of code changing, but not sufficient for a major revision, we’ll do an Azure-level backup of the App before we run the deployment so we have a solid recovery point to return to if need be.

Function runtime versioning

We had one particularly bad day where our Functions started playing up out-of-the-blue. It turned out that an unintended breaking change had been made by the Functions team when they did a new release.

The key learning from this experience for us was that our production Function Apps always run a known-good version of the runtime which is set as a specific version by setting the FUNCTIONS_EXTENSION_VERSION to something like ‘1.0.10576’ rather than ‘~1’ which means ‘latest non-breaking 1 release’.

We run our development App Services using ‘~1’ however, so we can determine periodically to update our production runtime to the latest known good runtime version so we don’t lag too far behind the good work the Functions team is doing.

Our other main issue during this revision was that our App Plan stopped being able to read the x509 cert store for some reason and our KeyVault client started failing. I never got to the bottom of it, but it was fixed through deploying to a new Plan.

Talking Functions

I was lucky enough to get to talk a bit about the solution we’d been building in early February.

The video quality varies, but here it is if you’re interested.

Hello Compiled Functions… oooooh Application Insights! (Rev 4!)

Compiled Functions? Sure, why not?!

The benefit here is the reduced startup times produced by the pre-compiled nature of the solution. The only downside we’ve found is deployments can cause transient thread-abort exceptions in some libraries, but these are not substantial and we deal with them gracefully in our solution.

As an example, we had previously seen Function cold start times some times up to 15 seconds. We now rarely see any impacts, some of which is the result of lessons we’ve learned along the way, coupled with the compiled codebase and the hard work the Functions team is doing to continuously improve their platform.

Early on in the life of our solution we had looked at Application Insights as a way to track our Function App performance and trace logging. We abandoned it because we ended up sometimes writing more App Insights code than app code! The newly introduced App Insights support, however, does away with all of this and it works a treat:

Functions App Insights

Unfortunately as part of the move here we also dropped Visual Studio 2015 support which meant we dropped the ‘funproj’ project layout. As Compiled Functions now give us local design time benefits we didn’t get before, it’s a good trade-off for my mind.

So… revision 5 anyone?!

We’re not here yet, though once the Visual Studio 2017 tooling hits GA we’ll probably look seriously at moving to it.

Ideally we’ll also move to a more fully testable solution and one that supports VSTS Release Management which we use for many other aspects of our overall solution.

Gee… sounds like a lot of work!

This might sound like a lot of busy work, but to be honest, the microservices we’re running using Functions are so small as to be easy to port from one revision to the next. We make conscious decisions around the right time to move, when we feel that the benefits to be realised are worth the small hit to our productivity.

Ultimately our goal is a shown below (minus the flames of course!)

That’s a wrap!

The Functions team is open in their work – ask them questions on Stack Overflow http://stackoverflow.com/questions/tagged/azure-functions

Raise your issues and submit your PRs here: https://github.com/Azure/Azure-Functions

Happy Days πŸ™‚

Tagged , ,

Azure Functions: Access KeyVault Secrets with a Cert-secured Service Principal

Azure Functions is one of those services in Azure that is seeing a massive amount of uptake. People are using it for so many things, some of which require access to sensitive information at runtime.

At time of writing this post there is a pending Feature Request for Functions to support storing configuration items in Azure KeyVault. If you can’t wait for that Feature to drop here’s how you can achieve this today.

Step 1: Create a KeyVault and Register Secrets

I’m not going to step through doing this in detail as the documentation for KeyVault is pretty good, especially for adding Secrets or Keys. For our purposes we are going to store a password in a Secret in KeyVault and have the most recent version of it be available from this URI:

https://mytestvault.vault.azure.net/secrets/remotepassword

Step 2: Setup a Cert-secured Service Principal in Azure AD

a. Generate a self-signed certificate

This certificate will be used for our Service Principal to authorise itself when calling into KeyVault. You’ll notice that I’m putting a -1 day “start of” validity period into this certificate. This allows us to deal with the infrastructure running at UTC (which my location isn’t) and avoid not being able to access the certificate until UTC matches our local timezone.

b. Create Service Principal with Cert Authentication

This step requires you to log into an Azure Subscription that is tied to the target Azure AD instance in which you wish to register the Service Principal. Your user must also have sufficient privileges to create new users in Azure AD – if it doesn’t this step will fail.

At this point we now have a Vault, a Secret, and a Service Principal that has permissions to read Secrets from our Vault.

Step 3: Add Cert to App Service

In order for our Function App(s) to utilise this Service Principal and its certificate to access KeyVault we need to upload the PFX file we created in 2.a above into the App Service in which our Functions live. This is just as you would do if this App Service was running a Web App but without the need to bind it to anything. The official Azure documentation on uploading certs is good so I won’t duplicate the instructions here.

Watch out – Gotcha!

Once you’ve uploaded your certificate you do need to do one item to ensure that your Function code can read the certificate from store. You do this by adding an Application Setting “WEBSITE_LOAD_CERTIFICATES” and either specify just the thumbprint of your certificate or put “*” to specify any certificate held in the store.

Step 4: Function App KeyVault and Service Principal Setup

a. Nuget Packages

Accessing KeyVault with a Service Principal in Functions requires us to load some Nuget packages that contain the necessary logic to authenticate with Azure AD and to call KeyVault. We do this by adding the following to our Function App’s project.json.

b. KeyVault Client CSX
Now let’s go ahead and drop in our KeyVault “client” that wraps all code for accessing KeyVault in a single CSX (note that this is mostly inspired by other code that shows you how to do this for Web Apps).

Step 5: Use in a Function

As we’ve encapsulated everything to do with KeyVault into a CSX we can retrieve a secret from KeyVault in a Function using a single call once we’ve imported our client code.

Happy (Secure) Days!

Tagged , , ,