I did cover the Service Connector in one of my previous articles briefly. Still, I strongly feel it deserves a dedicated article since a recently announced passwordless connection opens a new potential dimension for Jave developers. It will be two parts articles, at first, we will look at the basics of Service Connector with a sample Spring Boot app. In the second part, we will explore the usage of passwordless connections with Service Connector.
As I always do, I will take the wisdom from Microsoft documentation for the introduction of Service Connector.
“Service Connector helps you connect Azure compute services to other backing services. This service configures the network settings and connection information (for example, generating environment variables) between compute services and target backing services in management plane. Developers use their preferred SDK or library that consumes the connection information to do data plane operations against the target backing service.”
There are various ways on Azure to connect apps with backing services, and I have already covered a variety of ways with different application platforms so far.
We will see how Service Connector would work differently and where it could be better than the others.
Azure Service Connector
Service Connector isn’t available for every compute services yet, so it’s vital to double-check which platform you’re using or planning to use. At the time of writing (Oct 2022), Azure Service Connector is available for the services below.
I will use Azure Container Apps as a platform to test a Service Connector with Spring Boot and PostgreSQL for the target backing service.
Go to Spring initializer and create an app with dependencies,
Spring Data JPA. We will rely on the Autoconfiguration of Spring Data JPA without a single code, that Spring Boot will fail to start if provided PostgreSQL information is improper.
We have to enable all the Actuator endpoints to see the properties injected by Service Connector. Open the
application.properties and add below.
Use Cloud Native Buildpack to create a container image hassle-free.
$ pack build eggboy/postgres-sc:0.0.1 --builder paketobuildpacks/builder:base --buildpack paketo-buildpacks/java-azure --env BP_JVM_VERSION=17 --publish
az CLI to deploy on Container apps.
$ az containerapp create -n postgres-sc -g containerapps-rg \
--image eggboy/postgres-sc:0.0.1 \
--environment *** \
--cpu 1 --memory 2.0Gi \
--ingress external \
It’s so easy to set up and go with Container Apps with container images. Next, Run the
az CLI to create a PostgreSQL database.
$ az postgres server create \
--resource-group sandbox-rg \
--name postgres-jay \
--location westus2 \
--admin-user *** \
--admin-password *** \
The basic setup is done at this point. Before we start the actual test, I’d like to explain one thing quickly. The previous deployment of Container Apps created 0 replicas, meaning you should manually scale it out to 1 minimum replica to start our sample app.
But before we scale out to 1, don’t forget the app won’t start properly without the connection information of PostgreSQL. Now, go to Service Connector on the Azure portal, and create a connection. Service Connector has a developer-friendly discovery UI that you can browse through different subscriptions and services depending on your choice of Service type. Client type is interesting, where you can choose the language of your client code. How this will change the behavior of Service Connector will be discussed shortly.
Next is to choose which username and password to connect to the PostgreSQL database.
The default firewall blocks all incoming requests when we create a database on Azure. Service Connector has a nice developer-friendly feature that can automatically open the firewall for apps on Azure Container Apps.
Once the service connector is created, you can spot two things that stand out on the screen. First is “Validate” which validates your configuration of connection information with username and password. Second is the attributes like “
spring.datasource.password” which should look familiar to Spring developers. The name of attributes is where the Client type “SpringBoot” comes into effect.
In short, Service Connector injects environment variables that Spring Boot can understand and trigger the autoconfiguration of Spring Data JPA with PostgreSQL. If you choose other languages as Client type, it will use the different name of an environment variable. Documentation provides the complete list of environment variables per each language — https://learn.microsoft.com/en-us/azure/service-connector/how-to-integrate-postgres
Looking at Log Stream, you can verify that the app is running after the service connector is created.
We can double-check with Spring Boot Actuator.
By now, you should understand the basic concepts of Service Connector.
Service Binding is one of the key features that any PaaS platform provides but in its unique way. For example, Red Hat’s Service Binding Operator is one of the best examples of how service binding can be done in a Kubernetes native way. Similarly, Azure Service Connector is Microsoft’s way of approaching the service binding for its Azure services. With Passwordless connections that will be covered in part 2, the Service connector could be the most popular choice of Service Binding for Azure PaaS services.