ORDS : Migration of Legacy Configuration – Why You Shouldn’t Do It!

 

Just in case you didn’t get the memo, the installation and configuration of ORDS has changed in version 22.1 onward. As well has the changes to the command line, there is also a different structure for the configuration files. ORDS gives you an option to migrate your existing configuration from the legacy format to the new format, which is good right? Maybe not…

Let me start by saying, there is absolutely nothing wrong with doing this conversion if that’s what you want, but I’m going to explain why it’s a bad idea from my perspective. You are allowed to disagree, and I would like to hear your reasons, but I’m going to explain why I think you shouldn’t do this…

Build Scripts

We run ORDS using Tomcat in Docker containers. Each instance gets one or more ORDS containers. There is a load balancer in front of ORDS to handle CA certificates etc.

Every time we have an update of ORDS, Java, Tomcat or SQLcl, we build a new image, throw away the old containers and create new containers from the new image. As a result, it’s really important we are able to rebuild everything cleanly. The Docker image build is essentially our build script. Even if you don’t use containers, I would suggest you have a build script for everything. You want to be sure that in a nightmare scenario, you can rebuild everything quickly and cleanly.

What’s this got to do with migrating the old configuration? What is your build script? Build and configure in the old version of ORDS and convert the config to the new version? I don’t think so. IMHO you need to invest a little time and create new build scripts using the new version of ORDS. You can’t rely on a bunch of commands you ran in an old version of the product…

But we have a complex build!

I can hear the cries of, “but we have a complex build, so the conversion is easier!” If you have a complex build, replacing it is even harder should something go wrong, so having a version controlled build script is even more important for you than people with simple builds. I wouldn’t be happy about going live with something I couldn’t rebuild. Added to that, the time and effort of getting to grips with the new command line will teach you more about the product, which allows you to support it better.

Web Service Definitions

As I’ve said before, the changes for ORDS are mostly around installation and configuration. Your existing web service definitions will work just fine. They are stored in the database, and will remain untouched by the upgrade. You still need version controlled scripts for their definitions, but you shouldn’t need to run any of them when upgrading ORDS.

So when I’m talking about the migration of config, I am not talking about your web service definitions. I’m talking about the installation and configuration of ORDS at the top-level.

Conclusion

I completely understand why this conversion option exists. Someone will want to use it and giving people choices is typically a good thing. I just don’t think people should use it.

Remember, my thoughts are based on my experience of using ORDS, and I understand that can be a very limited view point. I would be interested to know if someone has a compelling reason why my view on this is wrong. It’s unlikely what you say will alter the way we use ORDS, but it’s always good to know of different approaches, because you never know when they will come in handy in the future…

Tim…

Author: Tim...

DBA, Developer, Author, Trainer.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.