Why Automation Matters : Reducing the Cost of Failure

Recently I watched a video called The Future of Faster Enterprises by AWS Enterprise Strategist, Miriam McLemore. I think its a really good video, even if you don’t care about AWS or cloud in general. There is a wider message there.

One of the points Miriam raised was “Reducing the cost of failure”, which sparked a conversation between myself and a colleague. When you’re trying to improve the way you work, you are going to have to try new things. Not all of those things are going to work out. The important point is you try them, see if they work for you. If they do great. If they don’t, you throw them away and move on. Reducing the cost of failure is a really important part of encouraging the culture of experimentation needed for continuous improvement.

Recently I wrote a post called you have to keep working just to stand still. Now add to that the work required to move your company forward and I think you’ll see why any barrier to progress is a problem.

So what factors affect the cost of failure? Here are a few.

  • Lack of automation. If humans are involved in providing infrastructure, it’s going to increase the time it takes to set things up (see lost time), and they will get disgruntled when you ask them to throw it away 2 hours after you’ve got it. You need to be able to build and burn kit rapidly to have any hope of experimenting. This is why the focus on the automation part of flow in DevOps is so important, for both business as usual and experimentation.
  • Bloated waterfall process. If your company expects a detailed plan of action before you so much as fart, you are going to fail. You have to be agile. I’m not using the term agile in the, “I’m too lazy to plan”, sense. I mean proper agile.
  • Time. Your company has to value progress and be willing to allocate time to it. You can’t rely on the fact Beryl and Bert go home every night and no-life their way through learning something new, so the business can reap the benefit of it for free. Yes that happens, but companies that rely on it will fail.
  • Be accepting of failure. I’m not talking about being happy to be rubbish. I’m not talking about being accepting of failure in well defined business as usual (BAU) work. I’m talking about being accepting of failure during experimentation. Not everything will work. Not everything will be the right solution for you or your company. You have to be willing to try and fail or you will fall at the first hurdle.

Check out the rest of the series here.

Cheers

Tim…

Video : LAG and LEAD : Problem Solving using Analytic Functions

Today’s video gives a quick demo of the LAG and LEAD analytic functions.

There is more information about these and other analytic functions in the following articles.

The star of today’s video is Gwen (Chen) Shapira of Kafka fame!

Cheers

Tim…

Enterprise Manager Cloud Control 13.3 Vagrant Build

A little short of a year ago I knocked up a Vagrant build to prepare an environment for practising Cloud Control 13.3 installations and upgrades. This just automated the creation of the environment and installation of the database, ready for me to start playing around with the Cloud Control bit. At the time I released these articles.

I didn’t mention anything about the Vagrant build as it didn’t do much more than build the database, so it didn’t seem worth mentioning. It was just a convenience for me.

More recently someone pointed it out on Twitter and I made a note to myself to “finish it off” and make it do a full silent build, then kind-of forgot again.

A few days ago I had a self-induced problem with our Cloud Control server, and I realised I didn’t have the best plan of action for a complete rebuild scenario. I had backups, so I didn’t need to do a rebuild, but that doesn’t stop me wanting to be able to do it, so I did the following things…

I scripted a silent build of the work environment we use. I put together a general article to show how to do a silent build of a simple installation too. If you’re interested you can see it here.

I wrote some EMCLI scripts to do most of the tasks I needed for a complete rebuild. We already use EMCLI for some of the stuff, like jobs, but I filled in the gaps where I had been a bit lazy. Those are all checked into a company Git repo, and they are quite specific to what we need, but there are some basic EMCLI examples available here, if you are interested in getting into EMCLI.

Finally, I made my Vagrant build a fully automated Cloud Control 13.3 build on Oracle database 18c. According to the certification matrix, Oracle 19c is not yet certified for the repository database (but someone on Oracle-L said this certification is imminent). If you are interested in playing around with Vagrant, you can find it here. I’ve managed to get away with 6G of memory, but that makes it chronically slow. The more memory you can throw at it the better. πŸ™‚

I didn’t really expect to be revisiting this stuff a year down the line, but it was born out of necessity, or at least necessity for my peace of mind. πŸ™‚

Cheers

Tim…

Video : Ranking using RANK, DENSE_RANK and ROW_NUMBER : Problem Solving using Analytic Functions

Today’s video is a run through ranking data using the RANK, DENSE_RANK and ROW_NUMBER analytic functions.

There is more information about these and other analytic functions in the following articles.

The star of today’s video is Chris Saxon, who is one of the folks keeping the masses up to speed at AskTom.

Cheers

Tim…

Technology : You have to keep working just to stand still!

This is a topic of conversation that has come up a lot recently, both at work and whilst updating the computers for family members, so I thought I would write something down.

I don’t think people realise how much work it takes to stand still in the technology world.

When we think about the pieces that make up your typical on-prem web application running on virtual machines, what does standing still mean? To me it means the following.

  • Database : A regular patching cycle for the database and the operating system it sits on. Also, upgrades/rebuilds as required.
  • Application Server : See database.
  • Web Layer : See database.
  • Load Balancer : Regular patching of the appliance, and replacements/upgrades as required.

Now multiply all that up for all the projects you are working on. That represents a substantial amount of work, whether you call is Business As Usual (BAU) or Internal Projects. What’s worse, there is no “visible benefit” from this work. Most users won’t have a clue it is happening, as they won’t get a new screen or a new widget to play with. It’s pretty much invisible, but it has to happen, just to remain static.

At this point I can hear people saying, “But standing still is literally doing nothing, so what are you talking about?” Well, if today I have a fully patched system using supported versions of all software, to stand still I have to remain on a fully patched system using supported versions of all software. If that means upgrades or rebuilds of kit, so be it.

Remember, if I do nothing at all, I’m no longer standing still, I’m moving backwards!

Think about that for a second. To stand still I’ve got to learn all the new stuff so I can upgrade to 19c and get long term support for my databases, even if I didn’t want to. Same goes for other products. Even if I use none of the new features. There is a big investment needed by a company, and for you personally, just to stand still. Now breaking new ground, well that’s a whole different ball game… πŸ™‚

So what are the solutions:

  • It helps if you recognise the problem in the first place. Far too many people think doing nothing is standing still, when it’s not.
  • Automation will help you stay on top of things. Reliable and repeatable processes make keeping things up to date a lot simpler. Automated testing is the icing on the cake here.
  • Cloud? Platform as a Service (PaaS), when it is done right, can help you keep on top of things. Having a service where you don’t have to worry about OS, DB and app server patches, because it’s all handled by the platform is a big bonus.

Cheers

Tim…

Some related posts:

Dbvisit Standby 9 Installation on Linux (and Vagrant)

The folks at Dbvisit recently released version 9 of their Dbvisit standby product.

It’s been a while since I last played with the product, so I downloaded the free trial and gave it a whirl.

I have to admit I forgot just how easy it is to work with. It feels pretty much like “unzip and go”. The result of my playtime was this article.

I also knocked up a Vagrant build, so I can easily recreate it. You can find that here.

I stuck to a basic configuration of a single instance primary (node1) and standby (node2), with the console on a separate VM (console). If you want to try something more exotic, or you are using Windows, you can get more information from the Installing Dbvisit Standby documentation.

Cheers

Tim…

PS. This isn’t a sponsored post. I’ve known the folks at Dbvisit for years so I keep an eye on what they are doing.

Video : Multitenant : PDB Snapshot Carousel in Oracle Database 18c Onward

In today’s video we take a look at the PDB Snapshot Carousel feature, introduced in Oracle 18c.

I also have a Multitenant YouTube playlist.

There’s a lot more information about this feature and other multitenant functionality in these articles.

The star of today’s video is Nassyam Basha. πŸ™‚

Cheers

Tim…

Video : Multitenant : Proxy PDB in Oracle Database 12.2 Onward

In today’s video we demonstrate the Proxy PDB feature, introduced in Oracle database 12.2.

I also have a Multitenant YouTube playlist.

There’s a lot more information about this feature and other multitenant functionality in these articles.

The star of this video is Anton Els of Dbvisit fame. I recorded this video last week and picked Anton for the “.com”, then they go and release Dbvisit Standby 9. Coincidence or conspiracy? πŸ™‚

Cheers

Tim…

PS. Mike, I’ve downloaded version 9 and I’m going to give it a run through… πŸ™‚