Azure Functions for Java developers

Published on
Reading time
Authors

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 😎!

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! 😎