Well .. no! “Not yet”, at least ;-).
Let me be clear: this post is NOT a recommendation that you should use Docker for your OnPrem Customer’s production environments. Not at all. This is merely a blogpost about the fact that I wouldn’t mind Microsoft to officially support Docker as an alternative to an NST deployment.
If you don’t care about the “why” below – just upvote here ;-): https://experience.dynamics.com/ideas/idea/?ideaid=daf36183-287e-e911-80e7-0003ff689ebe
Just imagine you would be able to continuously upgrade your customers. This has actually quite an impact on your daily life .. on anything that involves a life of a partner: from support to customer deployment to hotfixing, to release management, … .
Let me give you a few examples – and I’ll do that with some extreme numbers: either we have 300 customers, all on a different versions – or we have 300 customers all on the same version:
In a way, you need to be able to support all product releases on all versions of Business Central (or NAV) that you have running at your customers – it doesn’t make any sense to support a version that isn’t running at any customer, does it ;-)? If a customer is running v13 of your product, you need to be able to hotfix it, and roll out the fixes to one or more customers with that same version.
Even more – not only, you’d have to keep track of all the versions/releases/customers – you need to manage the hotfixes, and bump it to all versions/releases necessary (a hotfix in v13 might be necessary in 14, 15, .. as well) .
On the other hand – if everyone would be on the same (and thus latest) release: everyone can be treated the same, and hotfixing is easy, rollout is easy, administration is easy. Simply because there is only one product release to maintain (you start to get why Microsoft is pushing us to the cloud, right? ;-)).
In order to facilitate this in Git/DevOps, one way is to create (and maintain) release-branches for all supported releases. On top of this, you have to maintain for all these branches a dedicated branch policy, build pipeline, artifact feed and what not .. . Good luck doing that for 300 different versions.. .
I think we can all agree that our support department would be so much relieved if they would only have to support 1 version/release, right? All bugfixes/improvements/features/tooling/… are just there.
The easier we are able to upgrade a customer to the next runtime of Business Central.. the more customers WILL be on the latest Business Central and version of our product .. the easier it is to manage our product .. The easier it is to support our product .. The easier our life is. It’s a simple fact. No science needed here …
Upgrading an OnPrem customer
You might know my opinion on “code customizing AL” – if not, you can find it in this post. In a way – for me – “code customizing AL is evil” ;-). So .. In that perspective, I’m going to assume we are all on extensions/apps .. and all we have to do is manage apps at customers.
In terms of upgrading – we would upgrade apps to new version of apps, which is quite easy to do. You can prepare all upgrades in upgrade codeunits, so in a way, when prepped correctly, upgrading is just a matter of installing a new app the right way (by triggering the upgrade routine). I will not go into how to do this.
But that’s not all …
We also have to upgrade the platform, the runtime. Not the client anymore (thank god ;-)), but still all the NST’s and other binaries we have installed. At this point, it’s still quite manual: “inserting DVD and start clicking”. I know it’s scriptable .. heck, I even created a function once to “easily” upgrade an existing installation by calling the “repair” option from the DVD (you can find the script here), but honestly, in a world with Docker …
The Docker Dream
Just imagine – all you do to install an OnPrem Business Central customer is to install a real SQL Server for the database, and use the docker images provided by Microsoft for the NST. Why only the NST? Well, that’s the part that needs to be upgradable like every single month.
But when on Docker, you know how easy it is to set up a new environment, right? How easy would it be to upgrade, to set up UAT environments in other versions, to “play” with localizations, .. . Well, as easy as we know already by using Docker – but applying this to a production environment would really eliminate the complexity to upgrade continuously.
Honestly, I think this is the missing link to be able to implement full “continuous upgradability” for OnPrem customers.
We already do this …
Call me nuts – but for our internal database, which is completely our own concern, we already have this running as a proof-of-concept. And it has been running for so many months without one single problem :-). I shouldn’t say this, but it has been making upgrading and maintaining this particular environment (with +20 apps) so much easier that we are really wondering “why not” for customers. We won’t, obviously, but still … we dream ;-).
If you agree with me, then you also agree with Tobias Fenster, who has created an idea on the ideas-site which you can upvote – please do! If you don’t understand a single thing about Docker or what impact it could be for us – than just take my word for it and still upvote it here: https://experience.dynamics.com/ideas/idea/?ideaid=daf36183-287e-e911-80e7-0003ff689ebe