Tuesday, January 22, 2019

Azure @ Enterprise - dealing with retired services is tough

Though there are so many advantages with cloud, there seems some problems due to vendor lock in.  Especially if we invest on vendors specific technologies. Below is one such scenario occurred in my day job related to Azure.

Story of Azure ChatBot

One of our clients who is in highly regulated industry was very much skeptical about cloud. After long time periods they were convinced into Azure. One reason could be the long term relationship with Microsoft. They started to use Azure with all the enterprise gates. In fact the Azure @ Enterprise series in this blog actually originated from dealing with those gates. 

Beginning of last year, we started to develop a chat bot demo. The idea was to integrate the chat bot into one of the big applications as a replacement to FAQ. Users can ask questions to bot thus avoiding obvious support tickets in the future.

Things went well. We got appreciation on the demo and started moving to production. About half way, things started turning south. The demo chat bot application used Bot SDK V3. It had voice recognition enabled which allow users to talk to it and get the response back in voice. During the demo we used Azure Bing Speech API. But later before the production, we got the notice that the service is obsolete and will be retired mid 2019. Another surprise was the introduction of Bot SDK V4 which is entirely different that Bot SDK V3. Something like AngularJS v/s Angular.

Retirement of Bing Speech API

As per the announcement, the service will no longer work after 15 Oct 2019!! We need to migrate to Speech Service.

They already given the details on how to migrate.

The sad part is that, soon after the announcement, we are no longer able to create Bing Speech API resource in the Azure portal. We were just started to test the application in development subscription.

Another problem is the out of the box incompatibility of new Speech Service with Bot SDK V3. Bing Speech API and Bot SDK V3 are compatible and easy to integrate.

Impacts

It was easy from Microsoft, but developers gets into trouble. Many internal & client meetings happened. Lot of time spend to do assessment on migration. Finally decided to contact Microsoft to get exception. 
Then the next phase of efforts started. Raising support tickets, meetings with Microsoft and luckily since our client is big for Microsoft, we got exception to create the Bing Speech API resource in new subscriptions.

If it was a startup, the decision might have been taken quick but might not get the Microsoft support as what we got. But for bigger enterprises, its a tedious job to get decision. Wasting time which was reserved for achieving features. The budget changes, delays etc...

Bot SDK V4

The problem is not ended there with Bing Speech API. Even if we decide to go with the proposed Speech Service which replace Bing Speech API, the Bot SDK V3 is not compatible out of the bot. So need to upgrade the Bot SDK to V4 as well.

With SDK V4, Microsoft changed the programming model of bots. Its almost rewrite of V3 code when upgrade to V4. Also Bot SDK V4 is only available in .Net Core. What if an enterprise is not ready to take .Net Core? Yes it can happen and happening for us. Again so much efforts.

Another problem seems the Bot SDK V4 is not compatible with Bing Speech API. Even with our exception, we cannot migrate to SDK V4. Both the upgrades has to happen together to make sure that the application is not breaking in the process. 

I am always a proponent of CI/CD pipeline. But here, since the application is having the pipeline with 'build on check in '  & 'deploy on success' enabled, there could be disturbances.

Further thoughts

We are not alone in the planet who were hit with this issue. But still need to think about future on how to handle the scenario.

What if it happens during the maintenance phase of application?

Now there is a active development team for the project. There could be time when the application is complete and expected to run for long. In that situation, if changes like this comes which cause application to fail, what is the guarantee Azure is giving?

Budget for future

Normally when the application is built, it goes to maintenance mode with less budget. What if there is not enough budget at later time to rewrite the application on these breaking changes? Seems we need to let the app into its fate similar to how we abandon the satellites in space.

Summary

We survived because the client is a big shot for Microsoft. If you are big enough to influence Microsoft, go to Azure proprietary PaaS. Else think twice and thrice.

Simple solution is to use vendor independent technologies. For example containers for web apps and APIs, Scala for analytics. That will help to host application in our own data center, if clouds became expensive or vanished in future.

No comments: