Rapid App Development with Azure Spring Cloud Enterprise

Cahlen Humphrey's
Published in
7 min readFeb 18, 2022


Enfuse recently had the opportunity to preview the new Azure Spring Cloud Enterprise offering — a joint offering from Microsoft and VMware. While Azure Spring Cloud has been available for some time now and can be very helpful for smaller organizations, the enterprise version brings some much needed features. In this blog post we’re going to be expanding on some of the features within the enterprise offering that we’ve found to be the most valuable.

Spring Starters

If you’re already an engineer that has been working with Spring Boot for a while, the advantage of using starters to bootstrap your application is nothing new. To everyone outside of that bucket, you can think of starters as traditional libraries where objects are autoconfigured with minimal user provided configuration and automatically made available to you as an engineer to inject within your application classes. Starters are only one ingredient within a technical stew which enables rapid application development.


Starters require minimal configuration. The most common methods to configure your spring app are

  • application.properties and application.yml within your apps classpath
  • Environment variables

There are number of different ways that Spring allows you to configure your application, but the above two are the most widely used.

The enterprise solution for Spring app configuration is a Spring Config Server. Effectively the Config Server is a REST API used as a layer between your application in runtime and the repository where you choose to hold your configuration. Usually, but not always, this repository ends up being a Git repository. This allows you to version and organize your application configuration, and also to update and refresh your applications configuration during runtime.

But someone needs to set this up. Someone needs to ensure that there are multiple instances of the config server and that there is a routing proxy in front of that. Someone needs to ensure that it is secure. Someone needs to make sure they’re behaving correctly. This means DevOps and managed services support, which directly translates into wasted dollars and time that could be spent towards innovating.

Azure Spring Cloud Enterprise have built the Spring Config Server into their platform with the enterprise offering. With minimal configuration, typically just a URI pointing to your repository, and a 1-click deployment — you’re off and running. The service is managed by Microsoft so you don’t have to hire outside of your app engineers.

Spring Cloud Gateway

Ensuring routes, security, and high-availability is paramount in any well defined enterprise platform. Spring Cloud Gateway is similar to Spring Config Server in terms of needing good managed services resources to monitor, configure, and deploy the gateway. Typically there are multiple instances of your gateway lying in your desired region or zone that is closest to your users. API gateways are also vital to ensure that your underlying applications are highly-available. If you only have one instance of your app deployed, and that crashes, you’re dead in the water. To make sure that your apps are always available, you’ll have to layer your API gateway so that it’s able to handle app crashes. The default round robin communication between your app instances and the gateway usually takes care of this.

There are many more reasons why Spring Cloud Gateway is a must have, but they’re out of the scope of this post. The important part here is that Azure Spring Cloud Enterprise provisions Spring Cloud Gateway at the click of a button. It’s a managed service so you don’t have to worry about upgrades, uptime, or a managed services to to make sure it’s healthy.

Monitoring, Logging, and Alerting

MLA is often overlooked in the beginning of projects. Typically with rapid app development, we scratch out a POC (proof of concept) and then move that into a more stable MVP (minimal viable product) that can be deployed within a production environment. All to often if we’re deploying these applications within kubernetes clusters or vanilla cloud foundry, we’ll only get system metrics, which doesn’t help us diagnose issues within the application except for the occasional stacktrace.

Rapid app development and deployment, in the context of Enfuse, means that we focus on MLA from day one. Note that Azure Spring Cloud Enterprise isn’t just for services or backend API’s, we can also use it for data intensive app scenarios. In this situation we couple the apps to Azure Events Hubs easily using a starter. This allows our applications to be more reactive. We can then create a data path through our processor applications that do all the heavy lifting — number crunching, ML/AI model scoring, and general high performance computing. What happens when we get a volume of data being processed that we never scoped for? What happens if someone sends a piece of data through the pipeline that doesn’t conform to our processor’s data types?

With Azure Spring Cloud Enterprise MLA has never been easier. With the addition of a few common starters and the enabling of Spring Actuator health endpoints we can open up the entire application’s metrics to the built in MLA that’s offered. This allows us to see any custom metrics we want, and we can also establish thresholds that will trigger alerts based on what metrics the app is producing. These alerts could trigger auto-scaling or send an email to an off-hours support engineer to let them know we’re seeing heavy traffic, but there is no worry because temporary auto-scaling will be triggered.

To emphasize the importance of built-in MLA let’s take a step back and discuss the alternatives. Traditionally Splunk has been used to fill this gap, but Splunk is an expensive tool and may lack the features you expect. More often than not we’re seeing customers request ELK (Elastic, Logstash, Kibana) clusters for MLA. While the ELK stack is feature rich, it’s not immune to criticism, and it’s not simple to setup and configure. Setting up an ELK stack in an enterprise setting is anything but trivial and takes a lot of experience in infrastructure, DevOps, and engineering contribution. It’s also not easy to find folks who are experienced doing this which makes your path of least resistance, and in many cases your only option, to hire a professional services firm that specifically focuses on these sorts of managed services. This is extremely expensive and time consuming.

Insights, tracing, discovery, alerting — it’s all taken care of by Azure Spring Cloud.


Permissions can be the bane of our existence. They’re one of those things that you just wish you didn’t have to do. So when a service comes along and makes permissions easy to figure out and customize it means a lot. Like anything else in technology, we expect a turn key solution and the ability to drill down to get as granular as we need. With IAM and AD integrated into Azure Spring Cloud Enterprise we can easily define groups and attach roles and users to them. Then we can easily attach any prebuilt policy, or custom rule, to these roles as well.

With one simple contributor permission we can onboard our engineers so that they can start deploying apps to Azure Spring Cloud Enterprise within the same day. You can’t get more rapid than this.

Where do we go from here?

At Enfuse we’re particularly excited about the gaining attraction of data driven apps. We’ve been building data driven apps and data pipelines for years in AWS, GCP, and Azure. Building your application in a data driven manner means that at some point your data is going to be evaluated or scored against a ML (Machine Learning) model. The location of that trained model can differ upon use case, but typically it’s either embedded within a service app or a processing pipeline app.

There are a few key points that make this complex and difficult

  • Ensuring latest models are trained using clean, healthy, valid data
  • Ensuring trained models can be validated in a canary or blue/green pattern
  • Implementing newly trained and validated models within processor applications automatically in a continuous manner

The work alone established by the three points above can take some time even with the most experienced data scientists and software engineers. But in a project outside of Azure Spring Cloud Enterprise it can take much much longer than expected.

Why? Data driven apps and data pipelines are essentially black boxes without the correct infrastructure and MLA. As a stakeholder or product owner you’re placing a lot of trust into your engineers or partner you’re working with to deliver these applications. That trust can’t be established without transparency into the apps and pipelines. Auto-scaling data driven applications should be done not necessarily based on hardware metrics alone, but also need to take into account the volume and frequency of features that your scoring. With built in MLA and infrastructure that Azure Spring Cloud Enterprise provides we literally get to skip a lot of these steps.

This results in our engineers and data scientists working with the data hands-on to identify and extract critical data elements that can be used in data driven applications immediately. This isolates them from infrastructure and means that they can focus on what they’re good at on day one.

How to get your hands on it!

Microsoft and VMware recently just announced the public preview offering of Azure Spring Cloud Enterprise. You can test run the enterprise offering here.

Enfuse also has a partnership program if you or your organization is interested in the potential adoption of Azure Spring Cloud Enterprise within your own organization. Our team is entirely comprised of labs trained engineers that specialize in data intensive and data driven apps using TDD and Pair Programming. We build applications with your engineers so that they learn best practices not only when dealing with Azure Spring Cloud Enterprise, but also how to build data intensive and data driven applications. You can reach us by sending an email to info@enfuse.io.

Originally published at https://enfuse.io.