Allow creation of service connectors at application level

[julienbourgoin-maif]

Is your feature request related to a problem? Please describe.

We are currently using service bindings to connect our apps to a cosmosdb database.
Service bindings are created at the application level. I mean, you don't need a deployment to create a service binding.
The advantage of this approach is that you can delete and create new deployments, they will automatically have the properties given by the service binding (spring.data.mongodb.uri in my case).

With service connectors, you need to have an existing deployment, to create the connector, as the attribute --deployment <deploymentname> is mandatory (https://learn.microsoft.com/en-us/cli/azure/spring/connection/create?view=azure-cli-latest#az-spring-connection-create-cosmos-mongo)

This involve that the first time you create your deployment, your app start will fail as the database connection string is not available before you create the service connector in a second time.

It's not such a big deal until you begin to do blue/green deployment and delete the Staging deployment, because when you delete a deployment, the service connector attached to this deployment is also deleted.

My actual deployment workflow is the following:

• I find the name of my Production deployment (lets say blue)
• I create a second deployment (lets say green) with my jar file and all the required configurations
• When my app on Staging deployment has successfully started, I switch this deployment (green) to Production
• And after the switch occurs, I delete the old Production deployment (blue)

With service connectors, this workflow won't work anymore. The working one will be :

• I find the name of my Production deployment (lets say blue)
• I create a second deployment (lets say green) with my jar file and all the required configurations
• App will fail to start because of missing connection string
• Create the service connector on the Staging deployment (green)
• When my app on Staging deployment has successfully started, I switch this deployment (green) to Production
• And after the switch occurs, I delete the old Production deployment (blue)

This is impactfull because:

• I will have to wait for the app to start twice (the first time before the service connector creation where it will fail, and the second time before the switch)
• Service connector creation is long, and we need to create one each time we do a new app deployment
• As apps will fail the first time, this will pollute our logs with errors

Describe the solution you'd like

Allow creation of services connectors at the app level as it is for service bindings.
Or at least, do not delete the service connector attached to a deployment when this deployment is deleted, so that when we will recreate the deployment with the same name, the service connector is already there.

Describe alternatives you've considered

One solution would be to not delete our deployments after the switch, but to stop it instead.
By doing that, we keep the deployment AND the service connector until the next time we deploy a new app version.
We can deploy a new app version on a stopped deployment without restarting it at first.
After the new version is deployed, we can restart the deployment and the service connector will already be there.

[LGDoor]

Hi @julienbourgoin-maif, thanks for raising this issue. There're some differences of the design between service bindings and service connector, one of which is that the connections are part of the deployment properties rather than the app properties. And this leads to some changes in the usage.

For better understanding of your scenario, could you please describe more details for:

• What's the frequency of this workflow? Is it part of CD workflow or occasional manual deployment?
• As you mentioned "have to wait for the app to start twice". Is the impact from the launch time cost?

[julienbourgoin-maif]

Hello @LGDoor,
Thank for your response.

• What's the frequency of this workflow? Is it part of CD workflow or occasional manual deployment?

Every time we construct a new version of one of our microservices, we can choose to deploy it at the end of the build.
We can have dozens of deployments per day.
We also have every night some automated jobs which can make refresh of our dev environnements and means install many apps.

• As you mentioned "have to wait for the app to start twice". Is the impact from the launch time cost?

Yes, as we are still on the workflow where we delete the staging deployment after the switch, we will need to recreate a new deployment with a new service connector each time we want to deploy a new app version.

As I explained : because we have to create the deployment (with our jar file which need database connection infos) before the service connector, the app will first start without the connection string and username/password, and then fail.

We will have to wait for the deployment to be created (the app may take 1 or 2 minutes to start and fail) and then, create the service connector (around 40 sec if you use username/password, more if you use passwordless connection)

So we may loose up to 4/5 minutes for an app deployment, in addition to the normal time to deploy a new app version, which may be avoided if the service connector was already present when creating a new staging deployment (as it is for the service bindings).

The result of this is:

• the failing app will pollute my application logs with useless errors (startup errors because there is no database connection info available)
• the time to deploy a new version is very long

We are thinking to move to a new workflow where we don't delete the old version deployment after the new version app as started, but stopping it instead.
And then, the next time I wan't to deploy a new app version, the stopped deployment will still be there, and will still have his service connector (we can deploy apps on a stopped deployment). Once the new app version is deployed on the stopped deployment, we can restart it and all should work as the service connector is still there, then we switch this deployement to production and stop the old production one.

[LGDoor]

@julienbourgoin-maif Glad to see you're unblocked with the workaround. Thanks for sharing such valuable information with us. Your explanation of this scenario is extremely helpful!

To resolve this issue, we are still conducting some internal discussions for the possibilities of introducing some new design. If any progress, I'll update it here.

[SandraAhlgrimm]

Hi @LGDoor, any updates on this?

[ChenTanyi]

@SandraAhlgrimm Might you be able to tell us your scenarios about it? What would you use for different deployment?

As deployment is the smallest runtime unit. While adding service connector at deployment level, it is not hard to create same service connector across different deployment. But if the service connector is added at app level, it is impossible to connect different target in different deployment (for example, connect to staging DB at staging deployment)

[julienbourgoin-maif]

Hello @ChenTanyi

What about to let the possibility for the user to choose between app level or deployment level ?
In case the service connector is created at app level, you can't create another one at deployment level and vice versa.

The use of a staging DB is usefull if you don't switch your deployments from staging to production.
In our case, we are doing blue / green deployments and we are switching between each others, so we can't use a staging DB.

[ChenTanyi]

@julienbourgoin-maif

Yeah, it may be the most likely solution, but it would also introduce confusion when customers see creation failure in the other level. Therefore, we just want to know more scenarios to see if the app level is much better than deployment level at most case (or even Spring Service level).

Usually, if you all treat different deployments of App as multiple revisions rather than multiple environment. It is more reasonable to support App Connector rather than Deployment Connector.

And for your specific scenario, as you said before, you can just keep the deployment so that service connector would not be deleted rather than delete the deployment every time. It should be fine as deployment is designed to do re-deploy every time.

And also the deployment level have multiple independent runtime parameters, how do you deal with them? for example, the environment variables. Do you just reset everything when you re-deploy? (As Service Connector serves like environment variables)

And indeed, the re-creation problem of Service Connector is still existing no matter which level it is. We try to find solutions of it, but it still under discussion at it may related to infrastructure problem. (Service Connector needs to depend on the deployment existence, so we could not take effect during deployment creation)

[julienbourgoin-maif]

@ChenTanyi
Having the two deployments created any time is not the solution I would like, as the staging deployment for us is only usefull during a new app version deploy, to be sure that the app will start correctly, in order to not affect the production one. Once the app is correctly started and the switch from staging to production done, the old production deployment which is now staging is not needed anymore and I would like to delete it.
This is of course MY use case and other users may have a different one.

Having two deployment also requires to stop the staging one to avoid billing.

Every time I deploy a new app version on the staging deployment, I give all the informations like environment variables as they may be differents. Another example is the runtime as we are currently migrating ours apps from Java_11 to Java_17.

For the moment, we do not have implemented the fact to keep the two deployments in our deploy workflow, we are still deleting the old production deployment and creating a new one. But the day we will modify our deploy workflow to keep the two deployment, we may be facing problems if we need to change some parameters on the already existing one (cpu, memory, env, runtime, etc), I don't know if all will be updatable easily.

[ChenTanyi]

@julienbourgoin-maif

Thanks for your more information!

It makes sense just to delete deployment to avoid billing as it is just for rolling update. But in your case, it is more like a rolling update scenario. As far as I know, Azure Spring App has supported rolling update already, showed in "Plan comparison" part of pricing page. It is based on kubernetes deployment rolling update (create new pod then delete old pod after new pod ready). You don't need to do it manually, and you could change every properties in deployment as you need. Usually, you would only need to validate the update succeeded in the INT or Staging environment.

The problem is still under discussion as usual, but as it is more about user experience than technical problem. It is not so easy to make a final decision yet. So, appreciate your patience about it.

[ChenTanyi]

@julienbourgoin-maif

We are happy to add an update here. The Service Connector for Application Level is now available! And the Service Connector button in Spring Application portal page has been replaced.
You can use the portal or cli for it. Thanks!

[julienbourgoin-maif]

Hi @ChenTanyi
Thank you for the update.
This is a great news and I will try this as soon as possible :)

I will now be able to use service connectors way more easily than before and move from deprecated service bindings to service connectors !

Thanks

[SandraAhlgrimm]

Hi @julienbourgoin-maif! Is it fine for you of we close the issue?