Skip to content

From Java into the sea of Azure: An introduction to compute services

Photo by Farano Gunawan on Unsplash

Nowadays, if you think about how you want to deploy your microservice, a container comes to mind.

This implies packaging it as a container image, the lowest common denominator to distribute your application so that it can be easily run independent of the host environment.
All you need is a container runtime or something building on top of one. There are many systems fulfilling that requirement, all with their own benefits, drawbacks, and use cases.

For this article, we want to focus on ways to specifically deploy Java applications in the cloud, more concretely, Microsoft Azure. Some even build the container images for you to focus on the code.

Again, several options exist depending on your needs or possible existing deployments. When first looking at them, you may be overwhelmed and wonder what kind of service you should use.

Microsoft provides several resources to help you choose a compute service solution, including a flow chart.
In the following, we will break down the choices based on a reduced flow chart focusing on containerized applications and managed services. Furthermore, selected unique features and use cases for each service are described.

A flowchart giving an overview on the selected Azure compute solutions described in this article.

Azure Container Instances

If the goal is to run a given container image as fast and simple as possible, Azure Container Instances (ACI) is the way to go.
There is no need to set up any VM or wait for the provisioning of a fancy higher-level Azure service. Billing is done in seconds for resources requested by your containers.

ACI is best used for isolated workloads running a limited time, like one-off tasks or build jobs, that do not require orchestration features such as auto-scaling, load balancing, or seamless container upgrades.
Multiple containers can be deployed as a container group, sharing a lifecycle and resources.

Another great use case is quickly bursting other compute resources in times of unexpectedly huge demand. For example, it is possible to automatically spin up additional service instances in ACI instead of scaling your Azure Kubernetes Service node pool, which would take a few minutes.

Azure Kubernetes Service (AKS)

Kubernetes is the de facto standard for container orchestration. Many vendors/providers offer their flavor, but usually, they are certified by the CNCF to conform to the required APIs.

Microsoft’s AKS is a managed Kubernetes solution running in the cloud. Azure reduces the operational overhead, usually with a self-hosted Kubernetes cluster, by handling (or at least supporting) monitoring and maintenance.
Furthermore, access and identity management via Entra ID (formerly Azure Active Directory) is possible. AKS can also be deployed in existing virtual networks and, therefore, be integrated with other Azure services.
You pay per cluster per hour and for the nodes (VMs) assigned to the AKS cluster.

Use AKS if you need the orchestration capabilities of Kubernetes, want to migrate an already existing cluster to the cloud, or want to (at least partially) avoid vendor lock-in while benefiting from a managed service.
If you require an OpenShift cluster instead of a managed Kubernetes, there is also Azure RedHat OpenShift.

Azure Container Apps

Azure Container Apps is built atop AKS but abstracts away all of Kubernetes while still offering tools like KEDA (scaling), dapr (building blocks for developing distributed applications), and envoy (proxy for microservice communication).
Because there is no infrastructure to configure or maintain Azure Container Apps, it counts as a serverless platform.

Besides continuously running your microservices deployed as containers in a scalable way, it is also possible to configure jobs that run on a schedule or based on occurring events and exit when their work is done.
Examples are cron jobs or jobs executed for each new message in a queue like Azure Service Bus.
The event-driven functionality is realized using special scaling rules evaluated at a given polling interval. Continuously running apps can also be scaled to zero based on such rules, for example, if there is insufficient demand. Instances that are not processing anything are idle and incur fewer costs, but when an application is scaled to zero, no usage charges are billed.
The consumption-based plan is billed by a second and is increased by the number of HTTP requests sent to your containers once the monthly free grants are exceeded.

Choose it if you want to fully focus on your applications and leave concerns about your infrastructure behind.

Azure Spring Apps (formerly Azure Spring Cloud)

As the name implies, this service is specifically geared towards Java Spring Cloud applications but also supports the .NET framework Steeltoe. The reason is that Steeltoe is quite similar to Spring Cloud and integrates with its infrastructure components. Furthermore, both frameworks are backed by VMWare.

In contrast to the previously described Azure services, Azure Spring Apps allows you to deploy your applications as JARs or even source code (leveraging kpack) instead of requiring pre-built container images.

Like Azure Container Apps, Azure Spring Apps helps you concentrate on your business case, specifically for Spring applications. It has a built-in configuration server and service discovery capabilities using Spring Cloud Config Server and Eureka (sometimes called Spring Cloud Service Registry). There also is a separate Enterprise tier using commercial VMWare Tanzu components, extending the Standard tier by further managed services, such as a fully managed VMWare Spring Cloud Gateway and an API portal.

Although Azure uses Spring’s config server and Eureka, apart from that, the focus lies on integrating native Azure Services in the best possible way with the Java/Spring ecosystem.

Azure App Services

The main use case for Azure App Services is HTTP-based services like web apps or RESTful API implementations.
They offer built-in load balancing and high availability at a global scale. In addition, various identity providers have integrated authentication and authorization capabilities.

Another great feature of App Services is deployment slots, which can be described as a staging environment that is used to deploy and validate your new application version before easily swapping places with the previous production build. This approach eliminates downtime as your service is already fully started and scaled.

If you need to host some web applications, APIs, or backends for mobile apps, Azure App Service is a good choice. Yet, it is better to look at the other offerings for full microservice architectures.

Azure Functions

Although Azure Functions are unsuitable for running Spring applications, they can be a fitting replacement in some cases, such as for small event-driven workloads that should be tightly integrated with Azure-native services.
For example, one can easily configure a function by annotations so that it is triggered each time a blob is added to a storage account and then writes some output to Cosmos DB.

At first glance, Azure Functions seems promising, but due to my recent experience, I urge you to consider if it is worth using it carefully.
One of my main concerns about Azure Functions is that the usage as a truly “serverless application platform,” which is just paid consumption-based, is severely limited compared to the Premium plan, which implies fixed monthly costs. Luckily, this will change shortly with the introduction of the so-called Flex Consumption plan.

Additionally, the Azure Function SDK for Java didn’t feel mature due to several issues that are out of the scope of this article. There also are differences regarding the supported features between the available programming languages (C#, Java, JS, Python).

If you are developing Azure (Durable) Functions on an ARM-based Mac, you may run into trouble executing your functions locally due to an error loading a library.

Conclusion

Ultimately, there is no “best” service choice for all circumstances.
Usually, it boils down to finding a good match for your team’s skill set, the overarching system or project goal, and the existing environment or specific requirements only satisfiable by specific services.

For example, if you have a bunch of experienced Java Spring Boot developers, it is better to stick with it and use Azure Spring Apps or App Services even if the application to be built seems like a good fit for Azure Functions.
If you plan to build up a full environment including several utility services like a repository or build servers, and you want to host yourself in a scalable way in addition to your microservices, AKS is a good and flexible choice.

The purpose of this article was to serve as a first overview and give an impulse for further consideration by discussing selected features instead of the usual service characteristics.
For a more common and structured comparison before diving into the documentation of each service, refer to the following Microsoft Learn pages:

It’s time to build!

When it comes to modernizing your business infrastructure, cloud solutions like Microsoft Azure offer excellent reliability, scalability, and security. Our team of certified experts at &amp can help you leverage the full potential of Azure by providing custom solution architecture services that cater to your unique needs. Whether you need to migrate your existing workloads, develop new applications, or manage complex data sets, we are here to help. Get in touch with us to learn more about our services and how we can assist you in implementing the best Azure solutions for your business.