Earlier in 2021, I wrote an article on the big mistake I thought IBM was making by only offering their container-native version of Db2 (db2u) on RedHat OpenShift.
Well, that article and tirelessly asking questions of EVERY IBMer I could get to listen to me (seriously, I could hear eyes rolling when I asked for the umpteenth time) has finally worked! At the IDUG Db2 European Conference in December both Piotr Mierzejewski (Executive Director Development Db2 Distributed, Db2 Big Sql and Data Virtualization) and Les King (Director, Hybrid Data Management Solutions) announced that db2u will be coming to Amazon EKS and Azure AKS in the first half of 2022. There is no printed statement yet that I can refer to, nor is there a more solid date. This doesn’t quite meet my initial requirement of wanting to run db2u in a Rancher implementation, but when I talked to the platform team at work, we’re looking for workloads to try on Amazon EKS, so the moment it becomes available, I’m ready to do a POC on it and hope that in 2022, I can get my production databases running on it!
Also, if you have a platform you’re anxious to get db2u on, let me know and I can get you connected with people at IBM who are deciding what’s after AKS and EKS.
I want to thank my readers for helping me keep the pressure on IBM. This gives me hope that IBM is moving in a direction that makes sense to make sure the very strong and modern features of Db2 are more known and understood in the market.
I can’t wait to get my hands on db2u and really put it through its paces!
Thanks for this post Ember. Indeed seems IBM is reacting in a positive way to Cloud trends with this decision.
QQ: can you write a post why your company didn’t choose migrate to Amazon Aurora (Global Database) service instead?.
Hmm, that does spark a blog idea, but not specifically addressing Aurora.
In your earlier blog post you had written about being ‘native of cloud’ and in this blog post you mention DB2u being a “container-native” database.
Curious to know, what according to you is a “container-native” database ?
This is a great comment and an interesting question. I need to better define what I mean by container-native, both for readers and for myself. I think some of the aspects are included in the more detailed definition of cloud-native that I offered in the original post on db2u. However I think there are some portions of that definition that would not apply. The main thing I’m thinking of is the use of more than one container. It is really easy to just spin up a container and install db2. I can and have done it in just a few lines in a docker file. But really having separate containers for separate purposes. For example, I know that db2u includes a separate container for LDAP, which makes a lot of sense. I would also say that a container which minimizes layers/size is fairly core to what I would consider “container-native”. Anyone can build a container with 25 layers, but reducing those and making the container efficient is part of a container orientation. I think better defining this is a task for me as I dig into db2u in the first half of 2022 and discover what it does and does not (but maybe should!) do differently.
Great article and looking forward to see and hear more of db2u for Azure.