Banking software firm tiptoes off to the cloud with MariaDB after $2m Oracle licence shocker
- Reference: 1605013450
- News link: https://www.theregister.co.uk/2020/11/10/mariadb_migration/
- Source link:
The banking technology services company is moving its loan risk management system to MariaDB's DBaaS [1]SkySQL , with a heritage in the open-source MySQL family, hosted on the Google Cloud Platform, a transition set to be complete in the next month.
After starting as a DBA for FNI, Bryan Bancroft told us that the DBaaS concept is not a threat to the role per se but instead frees up some time for more high-value work.
The FNI lead database administrator and architect told The Register : “About 40 or 50 per cent of my work beforehand was patching and maintenance, so [moving to DBaaS] has really cut down a lot of that overhead work by DBAs. Once we're actually in the cloud, it's really a shift to focusing on improving the database performance as opposed to just keeping the systems healthy.
"My plans post-transition? We have a lot of old setup work, stored procedures, and odd database designs that we really have slated for, and now have the time to address." FNI has already been running on MariaDB on-premises in virtual environments after it migrated away from Oracle because of what it saw as unreasonable licensing requirements.
The credit decision application, which is one of the products FNI sells to its banking clients, was created in Oracle on an on-premises rack setup for high availability, running in Java, attached to front end web applications with database access.
Bancroft said: "The biggest issue came from virtualising on site. We are running databases on an [VMware] ESXi host. Even though we'd only provision a certain amount, Oracle was charging us for the underlying hardware that the databases are running on, which was causing skyrocketing costs as CPUs were replaced and upgraded over time and we started getting that extra cost per core."
The problem in moving to a virtual environment with Oracle licensing was [2]well documented at the time . For FNI, as costs per core hit $47,500, total licensing fees for the Oracle 11g database reached almost $2m, prompting it to look at its options, it told us.
The initial move to MariaDB saved 80 per cent of database costs, but it did come at a price. FNI's DBA team had to rewrite its automated jobs and backups, as well as enterprise data warehouse loads.
Bancroft said: "All this ingrained code that was sitting there for 15 years on Oracle that some people here have no idea what it's doing? What the hell is this actually doing? We had to look at that and say, 'OK, how do I turn this into something that's going to run on MariaDB?'"
About a year's worth of development work for a team of three or four DBAs, was a lot cheaper than continuing to pay the Oracle licences, he told us.
But the investment has now also paid dividends in smoothing the transition to the cloud, Bancroft said. "On our actual cloud transition, we're going from MariaDB to MariaDB, same version, which has simplified a lot [of work], other than having to run uploads of databases a couple times when we found kinks and small differences."
FNI started the transition to its cloud database in June, and is set to finish next month. As well as performance, which Bancroft said will help the company remain competitive, the DBA chief said MariaDB was easier to manage.
"In an established Oracle system, [it was] was kind of like an insurmountable black box; there [were] a lot of things that just went wrong. And, of course, Oracle Support was never, helpful for solving any of our issues. And it was kind of just struggling to keep that running. MariaDB is running off of MySQL branch: it's understandable, it's manageable, it's not trying to hide things behind the scenes," Bancroft said.
We have asked Oracle to comment. ®
Get our [3]Tech Resources
[1] https://www.theregister.com/2020/03/31/mariadb_skysql/
[2] https://www.theregister.com/2016/02/24/oracle_vmware_license_headache/
[3] https://whitepapers.theregister.com/
Re: Nice ending
"Hahahaha"
That's Oracle's reaction when they successfully pull off these kind of licensing-lock-in deals. All the way to the bank...
Database in the cloud - wonderful!
I'll take a look at it...
It's nice to read about the successes...
It's nice to read about the successes rather than the failures. Sounds like they were given the stakeholder support to do a proper job also.
Re: It's nice to read about the successes...
If only more management listened to their DBAs and IT departments...
I'm not sure why anyone is using Oracle for anything but legacy databases at this point. The competition is so much cheaper and is in most ways faster and easier to use. Additionally, Oracle is terrible to deal with, I'd rather pull out my own fingernails than talk to Oracle support.
"I'd rather pull out my own fingernails than talk to Oracle support"
Oracle will also be happy to do that for you, however, you will have to sign this additional support contract first...
> Oracle will also be happy to do that for you, however, you will have to sign this additional support contract first...
And the small print will explain why you are down one kidney in the process.
TPC
This is not actually true.
Prior to China, Oracle dominated the TPC-C benchmark with SPARC and 11g. Yes, SPARC.
"OceanBase" has put an end to that.
I don't speak Chinese, and I can't read the documentation. However, second-best is still what you have to use when you really, really need it.
http://tpc.org/tpcc/results/tpcc_advanced_sort5.asp?PRINTVER=false&FLTCOL1=ALL&ADDFILTERROW=&filterRowCount=1&SRTCOL1=c_tpmc&SRTDIR1=DESC&ADDSORTROW=&sortRowCount=1&DISPRES=100+PERCENT&include_withdrawn_results=none&include_historic_results=yes
not difficult to optimize cost for Oracle in VMware
I did it back in about 2007-2008 time frame. When I was hired the company was undergoing an Oracle audit. They were licensed for Oracle SE One, however their DBA consultants had installed Oracle EE. I pushed to move to SE but manager didn't trust me yet, assured us after we paid the fees everything was all cleared up. The following year we had another audit and we failed again. This time I was able to lead the charge to move to Oracle SE. Which at the time(I assume still now) has a per socket charge (max 4 sockets in a system) rather than per core.
So of course moving to Oracle SE was huge, as it turned out really the only reason the consultants installed EE was their monitoring system used partitioning, which of course hit us with another license breach. I recall buying new CPUs for our Oracle systems going from high speed 2 core (better licensing for EE) to lower speed quad core (better licensing for SE). I ran into a limitation on the DL380G5 systems that we had our system boards were too old to run quad core not even HP knew at the time (they later updated the spec sheets to reflect that), they replaced the boards and installed the new chips.
From a VMware perspective we did two things - we limited where we used Oracle (didn't allow it to run on just any VM host), and we also ran our DL380G5s with a single socket, cutting licensing further. This officially wasn't supported by VMware (ESX 3.5) at the time though I believe their intention was they didn't support running a single cpu, I had no doubts a single quad core cpu would work fine. VMware sold licenses at the time in pairs of sockets so we used 1 socket license on one system and one socket on another saving costs even more. (in hindsight perhaps this was a VMware license violation I never looked into that aspect). We never ended up needing VMware support, and Oracle had no issues with our new setup. I remember specifically having to educate our Oracle rep(s) on the licensing of Oracle SE being per core. Our production OLTP servers ran on physical single socket DL360G5, partly because I wanted no performance impact from VMware, but also because Oracle's support policy at the time was "reproduce on physical hardware before we support you in a VM". Didn't need that extra risk for the production OLTP. That and we just had VMware standard, so no VMotion, no HA etc. Just basic hypervisor.
Obviously Oracle SE has far fewer abilities than Oracle EE, the biggest one we missed at the time was Oracle Enterprise Manager with the query reports. Though at the time (10gR2 I think??) you were still able to install OEM on SE. It was easy to install and delete in the case they came to audit again(they did not). Newer versions of Oracle from what I could tell made it impossible to install OEM on SE (or at least it wasn't dead easy like it was back then).
Though I'm sure that Oracle SE is very cost effective and far easier to migrate to than MariaDB - not only that Oracle SE has much more abilities than MariaDB even.
Unfortunately there is nothing in the MySQL world in 2020 that comes close to those Oracle query reports I had access to in 2008. Our DBA does log many queries and can run query reports but it is a very time consuming process and can have quite a lot of overhead (if your not careful your query logs can be multi GB per hour easily which means query reports can take hours to get results back). I have used tools like ScaleArc and Heimdall which are MySQL aware proxies which come with real time analytics, though they are limited in that they can just see the queries and the response times, they can't get the in depth metrics of what is going on inside the DB for a given query.
I do get tons of internal metrics on each MariaDB server we have even query response times(can't see WHAT queries just # of queries at given response time thresholds), probably 200-250 metrics per server per minute or something. But still pales in comparison to the internal query level metrics available in Oracle in real time.
In a more modern world if I needed to run Oracle on a larger scale in VMware I'd build a dedicated VMware cluster for nothing but Oracle DB. Run the apps on other servers, limit licensing impact. I did run a very small Oracle system at my current org for many years it was for our vCenter 5 backend database. Given the choice was MSSQL, Oracle, or IBM DB2, the internal vCenter DB cannot scale very high at all. For me the choice was obvious, running Oracle on Linux. I used named user plus licensing(so not per CPU or per core) on Oracle SE and it was dirt cheap just a couple hundred a year or something. Eventually retired it almost 2 years ago after finishing migration to vCenter 6.5 on VCSA which uses an internal Postgres database.
Had many conversations over the years with Oracle they never cared about auditing us(I was ready regardless). Though we did undergo our first VMware audit last year, and we failed. I wasn't aware we couldn't move 3 nodes of essentials plus licensing from our UK office which had permanently shut down to our California office. The licensing was only in use for a few months but still had to pay the fees(which was buy a new essentials license which we used for 1 month before transitioning to Enterprise plus licensing as I retired some older systems from our primary datacenter and gave them to our HQ office with the VM licensing intact).
Fortunately we didn't get hit with a VMware audit a couple years earlier, the VAR that sold us our licensing for our datacenter stuff in EU bought everything in the U.S.(through HP) and shipped it to EU, would of had to pay probably more than 10x the fees for that, though that location for us was permanently closed 2 years ago (moved systems to U.S. for EU customers), then the business decided to close all EU operations entirely last year.
Having a region lock on a license code is just so stupid. I can understand region locks for things like on site support(had to jump through a lot of hoops(too many and took too long) to ship our HP gear from Amsterdam to the U.S. and get it under support again), but otherwise makes no sense to say you can't use this license code you bought in the EU on a U.S. system even though the EU system is permanently shut down. Not as if this was a site license, just a one off license purchase.
Nice ending
"We have asked Oracle to comment"
Hahahaha