Azure Functions and Java – in a zone far far away from comfort

Why Azure? Microsoft is one of the top cloud providers in the world and many enterprises move from on premise to Azure cloud. Altkom Software has also chosen Azure for its internal infrastructure. And why Java? Java continues to be the most successful programming language and runtime environment in the enterprise around the world.

Why serverless?

Serverless has become the hottest topic in modern architecture of transactional systems so it’s good to create proof of concept project to verify how Azure Functions work with Java.

Proof of concept

Amazon has had Java support in its Lambda serverless platform for relatively long time. But what about its closest competitor?

The scenario is classical SPA application written in Angular connecting to back end services, this time those services are to be realized as Azure Functions.

World of surprises

Important note: JAVA support was clearly marked as preview so we didn’t expect it to be production ready, however it appeared to be further away from it than we anticipated.

One of the first surprises was lack of Spring support (which works so well with AWS Lambda), we had to unlearn what we have learned and start with no DI framework at all.

Another big gap was the lack of JPA support, we had to go back to the old times and manage DB connections and sessions manually, create custom repository mechanisms from scratch,

Another big omission was lacking WebSocket (theoretically there is but we were forced to use alternative solution that worked for a change).

What hurt us most of the time was the lack of proper documentation and examples for all the languages except – you guessed it – Java. Many times, we had to analyse examples for C# and try to translate, but it was not possible because there were lacking supporting features in case of JAVA.

Single JAR deployment is against the very benefit of functions as small deployment units.

Azure LDAP issues made us use different authentication mechanism.

Lack of SCP – we had to switch to SFTP to deploy our code and packages.

Runtime

Cold start of the functions hurts the performance significantly – that is well known drawback of serverless, but worth mentioning anyway.

Functions tend to freeze from time to time and required manual restarts.

Response times were from totally unacceptable (minutes) to poor (seconds), after we changed deployment zone.

Response times were much better with paid subscription – so don’t give up (at least not for that reason) when you see such slow time using your trial account.

The good

It’s working – application does everything it is expected to do so we proved for ourselves Azure Functions can work with Java backend application.

The attitude of our developers was top notch, despite roadblock after roadblock they continued to find workarounds, to make it work, without their favourite frameworks, tools and above all – proper documentation. Kudos for the team!

And to be honest that was the most important single result of this proof of concept.

Summary

It’s much easier to use C#, JavaScript or even F# than Java to develop functions in Azure environment. Java is not the first-class citizen in Azure Serverless.

Look at the durable functions for instance – the great new feature of Azure Functions, all the examples are for dotnet developers.

We hope Microsoft steps up its game and provides more developer friendly tools and documentation with examples for Java.

Hopefully when you read this article, our struggle of early adopters is going to be a distant memory.