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.
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
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 …
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
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 …
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.
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
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