Once you start on the automation path it becomes progressively easier to automate new things because you will build up a collection of stuff you can tweak to create the new stuff. Here’s an example…
A little while ago I did a hands-off build of 18c RAC using VirtualBox and Vagrant (here). I had to solve a few little problems, but for the most part it was piecing together a bunch of stuff I already had, like silent installations and database creations, so no big drama. Probably the most complicated thing was deciding how I wanted to organise things, which I’m sure will change over time…
Fast forward to a few days ago when I wanted to play around with 18c Data Guard. I actually took the RAC build and used that as the basis of this little project. Obviously some things were chopped out and some things were added, but a lot of it was just reused, which saved a bunch of thinking and hassle.
Once I had the 18c build working, a couple of changes in the config files and I had a 12cR2 build up and running (here). Some config file changes and a couple of minor scripting changes and I had a 12cR1 build up and running. You get the picture.
Of course you will occasionally have to do something that constitutes a step change, or you will decide to take a completely new approach* and have to go back to basics, but a lot of the time you are only a tweak away from the next automation.
Check out the rest of the series here.
* I’m playing around with Ansible at the moment, so maybe I’ll end up redoing these using Ansible. Maybe not. We’ll see. 🙂
I wanted to try something with Oracle 18c Data Guard, so I thought I might as well create a hands-off build of it using VirtualBox and Vagrant, much as I did with my recent hands-off RAC build.
I did the 18c build and figured I might as well do 12cR2 and 12cR1 builds too, as they were pretty similar. I could have done them as a single build with a few tweaks to sort out the differences, but I couldn’t be bothered. 🙂
Along the way I noticed I hadn’t done a 12cR2 data guard article, so I did these.
We are constantly told there is a shortage of people coming into the tech industry, and those that do don’t show the diversity we would like to see. At the same time I see a lot of snobbery in the technology industry, and I wonder how much of that has an impact on the number of people coming into the industry.
The tech industry is all about fads. Everyone wants to work with the coolest tech, the most job-worthy tech, or the tech that will survive the longest. There is some snobbery about this, but that’s not really what I’m thinking of. I’m thinking more about the snobbery associated with job roles. I’m going to list a few job roles.
- Web Designer
- Database Administrator
- Product Manager
- System Administrator
- Project Manager
- Business Analyst
- PC Support
I could go on, but let’s leave it there. As you were reading down that list were you classifying the type of job role relative to how technical you think it is? Were there any that made you think, that’s “not really IT”? If you weren’t I would be really surprised.
I’ve had conversations about this a few times over the years. In many cases the attitude I’m met with is, you’re not really in IT unless you write code, or something to that effect. I’ve certainly been guilty of this at times. I thought I’d got past it, then in a recent conversation two people mentioned they had never had the desire to be developers, but had built careers in the tech industry and I found myself rather surprised. Part of me still holds on to that idea that everyone in technology has at some point been interested in development, yet this is clearly not the case.
The fact the tech industry is made up of so many diverse roles means there is something for everyone, but somehow not everyone sees a home for themselves in the tech industry. I wonder if this tech snobbery is part of the problem. If we promoted the wider aspects of the tech industry, perhaps it would be attractive to more people.
Just a thought…