Patch Me Now or Patch Me Later with Cloud Database as a Service

While public cloud PaaS and IaaS services offer tremendous capabilities in terms of elasticity and flexibility, they come at a cost in terms of operational control and software lifecycle management.  While this applies to nearly all public cloud DBaaS services we will discuss Oracle E Cloud Exadata as a specific use case.

These custom (or highly customized COTS – commercial off the shelf – i.e. Oracle’s Enterprise Business Suite) are very sensitive to OS, Grid Infrastructure and RDBMS software changes/upgrades and patches. The bare metal nature OCI/Azure Exadata services require bare metal ‘upgrades’ (Oracle legacy Sun servers, firmware to run ‘Top of shelf routers and NIC’s,’ firmware to run the I/O cells… Does anyone like ‘flashing firmware’ on a mission critical system? Bueller, Bueller…Bueller…

The issue becomes critical when typical PaaS services roll through with ‘automated patches’ – whether you want them or not or even if your app stack is incompatible with the new upgrades… There is also the added ‘adventure’ of patching firmware on OCI/Azure Exadata offerings that are based on quite a bit of proprietary Oracle bare metal. To that point even Oracle does not offer a ‘PaaS solution’ for customized (and they all are) EBS stacks even though there are easily 20K plus EBS enterprise level installations world-wide and the official word from Oracle is they will fully support EBS 12.x until at least 2035. The Oracle EBS/OCI solution is in fact based on IaaS systems and a bunch of scripting that ‘simulates’ on premise. Silk technology and Silk DBaaS services can do this more efficiently and cost effectively with far less chance of “automated patching incidents”.

Here is a snapshot of OCI’s Exadata PaaS service maintenance schedule. It seems like OCI is channeling Henry Ford (who famously said customers can choose whatever Model T car they want – as long as it’s black). OCI Exadata’s maintenance patches are happening on their schedule, whether you want/need them or not…

As you can see there are a few configurable options but most notably there is no option to opt out of auto-patching.

These types of automated fleet patching in the cloud have grown somewhat infamous for:

1. Being disruptive and cumbersome – truly one size does NOT fit all.
2. The actual automated processing itself is sometimes untested and buggy. For instance, an automated patch will roll through and reboot all the machines in a cluster – without checking to see if the last patched server came up or not. In a previous life before I joined Silk, I was personally involved in a situation where a major fintech company took a large outage because of these patching procedures…

And again, while cloud-based RDBMS systems can greatly benefit from advanced AI and BI analytics that are native to the cloud, the older RDBMS technology of Oracle is best done on an IaaS platform where the application specialists and DBAs have more control of the environment.

For these reasons, a number of large organizations have resorted to repatriation. That is moving their recently migrated applications back to on-premises. In fact, there are some that claim that up to 25% of cloud-based enterprise migrations are ripe candidates for repatriation.

The reasons are typically cost, patching management, and lack of customer control of the environment — especially when things go south—after an ‘automated patching event’…

This is where the Silk Cloud DBaaS services can help. First, Silk will provide as good as, or better, I/O performance as many on-premises Exadata systems — at significantly lower costs. Moreover, Silk offers operational features that allow experienced DBAs and administrators to implement their typical on-prem DevOps methods with little change. The de-duplication and volume cloning capabilities of Silk make things like refreshing lower regions with fresh new production data very easy to do.

But a major draw of Silk Cloud DBaaS offering is that there will be, in fact, a human being that will actively collaborate and work with your enterprise’s team to apply critical patches in the least impactful way. This is along with 24/7 health and performance monitoring from the Silk Cloud Data Platform itself. Not quite ready to patch? Just call your Silk dedicated DBA and tell them to delay the patch another week. Try doing that with any other cloud PaaS offering! On the flip side – do you need a security patch urgently? Silk’s team will get right on it – I doubt the cloud will change their patch schedule on your account.

The public cloud is something of a mixed bag of benefits and frustrations. The data proximity of PaaS-based and other IaaS-based solutions like Silk allow organizations to fully leverage AI and BI analytics in a way they could not if the data stores were on-prem. And at the same time, most automated cloud DB services aren’t flexible enough to properly run and keep running an Oracle custom application.

Silk can provide best of breed I/O performance both in terms of latency and throughput. Silk also provides very flexible data services such as de-duplication, zero-footprint snapshots, and volume re-mapping integral to the product. Coupled with Silk’s DBaaS service offering, you get superior cloud I/O performance, DevOps functionality like on premise infrastructure. And a human you meet with a regular basis to discuss, schedule and possibly re-schedule patching and upgrade activities.