What is the Cloud?

What is the Cloud? The oft-repeated answer to this question is “it doesn’t exist; it’s just someone else’s computer”. While this is a nice succinct way of reminding people that the hardware to run our systems has to actually exist somewhere, it’s a little too simplistic and misses part of the point why the Cloud is such a buzzword and is so successful. Above all else The Cloud is a brilliant piece of marketing.

If you think of clouds (the meteorological phenomenon) you think of something that is visible and yet intangible. It’s up there in all it’s fluffy gorgeousness, but it’s not something you’d normally touch (unless you’re mountaineering or hang-gliding or some such). The impression that is given is of something slightly remote and yet still observable; clouds are bright (we’re not visualising overcast here), attractive, stable (again, we’re not visualizing tornadoes) and sedate. We want our databases the way we want Elephants; we want to be able to ‘see’ them but we don’t want them in the house with us.

The extension of this image for many is that “The Cloud” somehow takes away all the problems that we have with trying to look after our databases in the terrestrial environment. In the ethereal environment of The Cloud, our databases are secure, 100% available, backed up, the data is kept in optimal organized state and performance is guaranteed.

Except it’s not. On the plus side, with a Cloud solution you are probably going to get all your hardware and software upgrades handled for you, you may reduce your TCO by having no physical premise to maintain and your software licensing may (may) also be handled for you[1]. Even storage issues can be (can be) sorted out in a fairly automated way; at a cost.

But you can still have an outage; it’s up to you to decide where your Standby server is going to be, even if you’ve deployed your database to the Cloud. If you co-locate your Standby in the same physical region as your Primary, you can have both taken out at a stroke.

And you do still need to have some sort of physical intervention. If you think of a database in the Cloud as analogous to a drone; it’s not safe to be left fully automated. You still need a “man-in-the-loop”; for a drone that’s to stop it wandering off into the flight path of an air-liner, firing a missile at non-combatants or simply crashing due to a technical failure. For your database, it’s to handle some of the arcane tasks of the DBA. These are reducing in number; with DevOps and automation you no longer need DDL monkeys to make structural changes, and today’s users are savvy enough to access the data themselves using all manner of interfaces. Even the day-to-day housekeeping of the data and the structure of the database can be largely and fairly reliably automated these days.

But to deal with an outage that’s caused by something within the database, or if you want to investigate the options and impact for a design change, or if your application has a performance problem; you probably need somebody to get involved. And, at that point, it’s irrelevant whether your database is in the Cloud, on-premise or a hybrid solution of the two.

The Cloud is really just a marketing tag for a particular architecture. It’s useful; for many enterprises it’s brilliant, but it is just a tool. If it’s not used properly or inexactly or without forethought and planning, it’s not going to do what you want.

Clouds offer a great deal: they do have a silver lining. But they’re also responsible for thunder and lightning, hail, tempests and all manner of chaos. In the words of the Canadian singer-songwriter Joni Mitchell

[1] this is only true for PaaS: (Platform as a Service), IaaS (Infrastructure as a Service) won’t include licensing.

About: Mark Gillis – Principal Consultant

Favourite topics – Performance Tuning, BLU acceleration, Flying, Martial Arts & Cooking

Mark, our kilt-wearing, karate-kicking DB2 expert has been in IT for 30+years (started very young!) and using DB2 for 20+. He has worked on multi-terabyte international data warehouses and single-user application databases, and most enterprise solutions in between.

During his career Mark has adopted roles outside of the conventional DBA spectrum; such as designing reporting suites for Public Sector users using ETL and BI tools to integrate DB2 and other RDMS data. He has worked extensively in the UK, but also in Europe and Australia, in diverse industry sectors such as Banking, Retail, Insurance, Petro-Chemicals, Public Sector and Airlines.

Currently the focus of Mark’s work is in Cloud migration and support, hybrid database enablement and providing expertise in exploiting the features and functions of Db2 V11.1 and 11.5.

View Mark’s blogs and tech tips. 

• Share