User Experience – A Little Rant Again

I had a bit of a negative post yesterday, and it got me thinking of these two posts.

I’ve said some of this stuff before, but I want to bring it all into a slightly different context.

Good user experience is…

Good user experience is not about forcing me to follow your atomic implementation of a feature. What do I mean by this? Let’s take look at some examples of getting it right (IMHO) from Oracle.

An Oracle REST Data Services (ORDS) web service is made up of a module with one or more templates, each with one or more handlers. We could define our service by defining a module, template and a handler separately, because that’s how the underlying implementation of an ORDS web service works. It’s fine, but it’s a bit over the top if I just want a quick little web service based on a query. That’s why we have been given the DEFINE_SERVICE procedure, allowing us to do all that other stuff in a single call (see here). For simple services this is all you need.

The database scheduler is a complex beast. We can define loads of things like schedules, programs, arguments, jobs classes, windows and of course jobs. That’s fine, but 99% of the time we just want a simple job, and the CREATE_JOB procedure allows us create one in a single call (see here).

In both cases we can choose between doing things the long/verbose way, or use the “cheat code” and do stuff in a single call. This is exactly the sort of thing I like when I’m using a feature. I want to know the flexibility is there if I need it, but if 99% of my requirements don’t, I want the cheat code so I can do what I need to do and move on. This also makes the feature more accessible to new people…

Good user experience is not…

As I mentioned above, good user experience is not about forcing me to follow your atomic implementation of a feature. Someone should take a step back and ask what would “normal” users really like? The answer is probably giving them an option to zone out and get all the prerequisites and config done for them. It’s not making them spend a weekend trying to figure out how to enable a feature, then finding it doesn’t really work properly anyway…

I’m a generalist. I have to work with lots of different products. When I open the docs and I see a list of prerequisites, and then multiple commands to actually set stuff up my heart sinks. I want a “we’ll do everything for you” option. That might sound funny because of my history, and if companies did that it would make my website redundant, but I feel we need to progress. We’ve been doing this nuts & bolts crap for too long. If I can automate it, Oracle can automate it. If Oracle can automate it, why don’t they?

I don’t want to name and shame. I’ve made some positive comments about Oracle in the previous section, but you know there are a whole bunch of Oracle things I could use as examples of what not to do. Oracle aren’t alone here. It applies to lots of other companies too.

But Tim, I want to…

I can already hear people typing their responses about their need to be in control and their obsessive configuration disorder. Shut up. I don’t care. The chances are, if you are reading this post, you are probably one of the people that can cope with all this tech, but there are many people who can’t, or don’t want to.

Won’t someone think of the children customers

I am a customer. My company is a customer. I can think of two things my company refuse to pay for because the functionality in question is unsupportable if I’m not available. Those are features we need, but won’t buy because they are overly complex for normal people to do well.

Now you can argue that cloud services will solve all these issues, but cloud adoption varies between regions, and maybe people will not pick your cloud. My company are a perfect example of that. We’ve consolidated on Azure, and although we don’t run any Oracle databases there yet, if we run Oracle on the cloud, it will probably be on Azure.

If you heard someone say, “I used to get a punch in the face every day, but now it’s only once a week. Things are good!”, you would think they were crazy. Less bad is not the same as good. I often think companies bring out tools and utilities that are “less bad” than what they had before. Not actually “good”. If you have been in the trenches, “less bad” might feel “good”, but it’s not.

I realise this is another rant, but I think it’s a subject that is worth a rant. I use a wide variety of tech from a number of companies, and some of them get on my nerves at times, because it feels like user experience is an after thought. You can’t expect everyone to no-life the learning curve for your products. I’m just saying how I feel, and I’m pretty sure I’m not alone here!

Cheers

Tim…

PS. I’m playing a bit fast and loose with the term user experience in this post, but hopefully you get what I mean…

Video : Ansible Playbooks : Roles

In today’s video we demonstrate how to use role with Ansible Playbooks.

The video is based on the following article.

You might find some useful stuff here.

The star of today’s video is Anton Els, who I first met when he worked for DBvisit.

Cheers

Tim…

Video : Ansible Playbooks : Tags


In today’s video we demonstrate how to use handlers in Ansible Playbooks.

The video is based on the following article.

You might find some useful stuff here.

The star of today’s video is Tanel Poder, who thinks he’s at the bow of a Viking ship by the look of it. 🙂

Cheers

Tim…

Technology Evolution : What does “the best” even mean?

I was watching a Twitter thread develop, where people were discussing which of two pieces of technology were “the best”, and I found myself thinking of evolution and selection pressure. I’m going to speak in simple terms, so I apologise in advance to folks with an education in this stuff, who are irritated by my simplifications…

Selection Pressure

Organisms evolve because of selection pressure. There is something about their environment that makes certain changes advantageous. Take the case of the peppered moth. To cut a long story short, it was a pale moth. Being pale was good camouflage as the places it hung around were a similar colour, so predators found it hard to spot them. Any mutations that made a peppered moth darker, made it more likely to be spotted and eaten, so mutations that caused the darker moths were unlikely to get through to the next generation. If you get eaten, you are less likely to breed. So there was a selection pressure in favour of being a pale peppered moth. Then along came the industrial revolution, which covered trees and walls in soot. All of a sudden, being pale made it easy for predators to see you and reduced your chances of breeding. Any moths with a mutation causing a darker colour were at an advantage, were more likely to breed, and quickly the predominant colour of peppered moths in industrial regions changed. The selection pressure was now for darker peppered moths.

In contrast, alligators have remained relatively unchanged since before the extinction of the dinosaurs. Sizes vary, but they look pretty much the same. Why? They are already the perfect design for their lifestyle, so there is no selection pressure forcing a change. If some new mutation happens, but it doesn’t give an advantage that affects the alligators chances of breeding, it’s unlikely to spread through the population. The selection pressure is low for the new mutation.

So what’s this got to do with technology? I’m hoping that’s simple for you to see.

If you invent a really smart bit of technology, but it has no major advantages over the existing technology out there, it’s unlikely to obliterate its competitors. Even if there is a technical benefit, that benefit has to be sufficiently large to make people stand up and take notice.

When we look at the database market, relational databases are the alligators. They are really well suited for the role they play. Every time a new non-relational engine comes along, it’s easy to get excited and think of it as the RDBMS-killer, but they are typically targeting different problems. The biggest threat to a specific relational database at the moment is other relational databases…

Survival of the Fittest

When people read “survival of the fittest”, they often forget that “fittest” relates to ability to breed and pass on your genes. The male peacock has stupid tail feathers that slow it down and put it at a higher risk of predation, but the peahens are all about the crazy tail feathers, so the physical disadvantage of the crazy tail feathers is a breeding advantage. Effectively the “least fit” for survival becomes the “most fit” for breeding…

But what about the peacock’s tail feathers in technology? There are a number of factors that make a technology attractive apart from technical excellence, so it’s not always “the best” that wins. For example:

  • Brand : I guess this is the obvious one. Apple is a premium brand. People will often spend extra money for a technically worse product because of the attraction of a brand. There is a reason companies spend big money on advertising and promoting their brand.
  • Community Support : If a product has a vibrant community, where it’s easy to get answers and support, it will be more attractive than a product with bad support and a weak community. Why intentionally put yourself at a disadvantage?
  • Staffing : It doesn’t matter how good a product is, if you can’t get staff with those skills, it’s probably not a great idea to base your future on it. This can be a problem for new technologies, but it also goes for old technologies that are falling out of favour. I wouldn’t be starting a new project using COBOL, even if it were well suited to the task.
  • Cost : There is a reason Android phones have a bigger market share than iPhones. They are cheaper, and therefore more attainable. Cost should be judged on total cost of ownership (TCO), not just the headline price tag…

I know this post has rambled a lot, but coming back to my original point, when I hear someone arguing about technical merits of a product, I find myself wondering if that’s actually relevant at all. Maybe it’s only a small fraction of what really matters…

Cheers

Tim…

PS. The first picture is a crocodile, not an alligator. I know they are different, but I liked this picture… 🙂

Video : Ansible Playbooks : Files and Templates

In today’s video we demonstrate how to use handlers in Ansible Playbooks.

The video is based on the following article.

You might find some useful stuff here.

The star of today’s video is Dan Norris, who is looking to the heavens for inspiration. 🙂

Cheers

Tim…

Video : Ansible Playbooks : Lists and Loops

In today’s video we demonstrate how to use lists and loops in Ansible Playbooks.

The video is based on the following article.

You might find some useful stuff here.

The star of today’s video is Øyvind Isene, who took a break during coffee time to let me film this clip.

Cheers

Tim…

Operating Systems for Oracle Databases (Poll Results Discussed)

I put out some questions on Twitter a couple of days ago, asking about the operating systems people were using for their Oracle database servers.

As with all these polls, we have to discuss some caveats. Most of the people that follow me are from the Oracle community, so that puts a heavy bias on the outcome. The questions relate to Oracle databases, which also influences the results. Someone may choose one distribution to run Oracle workloads, and a different distribution to run non-Oracle workloads. We also have to remember the sample size is small. Despite this, I’m going to discuss the results as if this were a representative sample of people, even though I accept it may not be. 🙂

This was the first question I asked.

Which operating system are you using for your Oracle Databases servers?

You’ll notice I totally forgot to include Windows, which was a shame because it would have been nice to see that. My main focus was to see how many people were still holding on to the traditional UNIX systems. There was a really strong showing for Linux over UNIX, which was hardly surprising. Every year the dominance of Linux is increasing. A few years back a lot of big companies were still using the traditional UNIX systems, but I guess a lot of people have got sick of spending that sort of cash, and some have probably switched to buying Exadata kit instead. I cant say I’m surprised by this result.

Something I’ve said repeatedly over the years is you should stick to the operating system that is the most popular, as that is the one that is going to get tested the most. There is no point in purposely making yourself a minority IMHO. Having lived through the death of Oracle on Tru64 and HP-UX, I wouldn’t dream of using anything other than Linux now.

This was the next question.

For Linux users, which Linux distro are you using for your Oracle database servers?

Over 65% of the folks picked Oracle Linux, and about 27% picked RHEL. The fact this is a poll about Oracle database servers no doubt added to the skew in this result. Oracle have done a good job of promoting Oracle Linux, and the fact it is free probably helps a lot. I thought Oracle Linux would be the winner here, but I’m not sure I expected it to be by this much. Personally I wouldn’t run on anything other than Oracle Linux by choice. Remember, this is what Exadata uses, and this is what Oracle Cloud uses.

I suspect some of the people that picked “Other” were speaking about non-production systems. Perhaps I should have made it clear I was thinking about production, not test labs…

This was the final question.

For Enterprise Linux users, which version of Oracle Linux and/or RHEL are you using for your Oracle database servers?

It’s good to see that nobody is owning up to OL5/RHEL5. There are still a few things lingering on OL6/RHEL6, but I guess those are probably running old versions of the database.

OL7/RHEL7 is still the most common version, but I guess a lot of this is down to the long lifespan of database servers. I suspect many of these servers were provisioned some time ago. I’m hoping most new deployments are using OL8/RHEL8.

So nothing really that surprising about the outcome of this batch of questions. Pity I didn’t include Windows in the first question. Maybe next time…

Cheers

Tim…

Video : Ansible Playbooks : Introduction

In today’s video we’ll introduce Ansible Playbooks.

There’s quite a lot to cover, so this is only one of several videos covering playbooks. The video is based on the following article.

You might find some useful stuff here.

The star of today’s video is Bailey, who has been known to associate with Connor McDonald at times…

Cheers

Tim…

Video : Ansible : Installation and Configuration

In today’s video we’ll cover the installation and configuration of Ansible.

The video is based on the following article, and will be the first in a series of videos.

You might find some useful stuff here.

The star of today’s video is Neil Chandler, who took time out of his busy bathroom schedule to record this clip.

Cheers

Tim…

Death of the DBA… Again…

If you’ve followed the blog for a while you will know I’ve revisited this topic several times since I first wrote about it in 2007. Here are some links if you want to go down memory lane.

I think I’ve been pretty consistent with my opinion on this subject, but I still get people misunderstanding the argument, so I’m going to try again, without revisiting the contents of all those previous articles.

What is a DBA?

This means something different in each company and each person I speak to.

In some companies it can mean a basic operations job. Install, patch, check backups and run scripts that other people send to you. All of these tasks are easily automated on-prem, and essentially don’t exist on the cloud. If this is the role you do, and this is all you do, you are going to have a bad time unless you gain some new skills. In other companies it can mean something completely different. My official title is “Lead DBA”. What do I do? Just off the top of my head:

  • DBA work with Oracle, SQL Server, MySQL.
  • Administration of middle tier stuff like WebLogic, Tomcat, NGINX etc.
  • I look after the load balancer configuration for a big chunk of the back-end business systems, including writing iRules in TCL.
  • Support for a few proprietary 3rd party apps.
  • Docker/containers.
  • APEX and ORDS. I’m the worlds worst APEX developer (see here), but I have to look after it, and support the APEX developers.
  • I don’t do much traditional development in this company, but I provide support when people have SQL and PL/SQL questions, because I’ve done that for a minute. 🙂
  • I’m increasingly being drawn into automation using shell scripts, Ansible, Terraform, Liquibase etc.

I’ve already got rid of some of the operational aspects of my job. Over time I’m hoping more will go, but that mostly depends on external constraints holding me back. Even if my involvement with databases stopped completely, I can still remain busy. Am I saying my role is what a DBA should be? No. I think my position is a little more extreme than some. I’m saying DBA is a title that various people and companies use, but it doesn’t really mean anything now. It can be anything from basic operations to “Do Bloody Anything”.

When is it going to happen?

For some companies it already has. Some companies will hang on to the old ways until the bitter end. It won’t happen overnight, but if it is not happening already in your company, what you are likely to see is a gradual drop in operational tasks as they get automated. This allows either the same number of people to cover more systems, or less people to do all the current work.

If you are seeing pieces of your role disappearing, you have to do something else to add value!

But person X disagrees with you!

That’s fine. This is only my opinion and you don’t have to agree, but please check the context of what people are saying. Often the responses to my comments include mentions of performance tuning and diagnosing architectural issues. I have consistently said the “operations DBA” role would go. The job that focuses on the basic grunt work. There will be a continued need for people who can diagnose and solve performance problems, both in the databases and in the application architecture. Moving to the cloud won’t magically cure all performance issues, and some would say they will increase the number of issues. You can still deliver architecturally crap solutions on the cloud. You can still do bad database design and write bad applications. Good people will always find a home, provided they don’t stick rigidly to the past.

You also have to look at the person making the comments. If someone is a performance consultant to the stars, but identifies as a DBA, they are probably going to take these comments personally and hear me saying they are redundant, which I am not. If someone runs a DBA as a service company, they won’t like the sound of this and will go into defensive mode.

I’ve been a regular DBA for most of my working life, and I’ve watched the job evolve. You may have a different experience, and that is fine, but I speak to a lot of people, and I think my opinion on this subject tracks pretty well with what is happening out there.

You are really talking about the cloud aren’t you?

Not. Automation is the thing that is removing the need for the operational DBA and basic system admin roles. Even if your company is in cloud denial, it doesn’t mean they won’t want to take advantage of automation. The cloud makes some things easier from an automation perspective, because the cloud providers have done some of the leg-work for you, but automation existed long before the cloud…

What should I do?

When you know, please let me know so I can do it too. 🙂 Seriously though, keep your mind open to new opportunities, and if you get a chance to try something new, give it a go. Nothing is ever wasted. Some people will gravitate to the data and analytics side of things. Some to development. Some to the architectural end of things. In all cases, there is a lot to learn and the less you know when you start, the harder the journey will be, so get learning whatever you like the look of…

Cheers

Tim…

Update 1: In social media comments, some people have mentioned the term “Data Engineer”. To me a data engineer needs to understand data, and requires and understanding of the development process. I’ve met some operational DBAs that can barely string together a SQL statement. These types of operational DBAs have a lot to learn before they can consider themselves a data engineer. A DBA can become a data engineer, but being a DBA does not mean you are a data engineer.

Update 2: Don’t get distracted by the name DBA. I don’t care about the name of the role. I’m talking about the function the person is performing. If they are performing basic operational tasks, whatever they are called, they need to start getting some new skills.