UKOUG Tech18 : See you there!

Next week is UKOUG Tech 18. It’s going to be an unusual event for me for a couple of reasons.

First up, I’m going to be in Liverpool from Mon-Wed. I can’t go on Sunday as it’s nephew #1’s birthday, but this is the first time I will be at the event for this long. Depending on who else from the company goes, I might have to work (from the hotel) on one of the days, but…

Next, it’s a pretty quiet conference for me, as I only submitted one presentation, but I’ve just been invited to a panel, so I can pretend I’ve got two sessions. 🙂

Title : Understanding the ACE Program & it’s Value
Time & Place : Room 20-21, Monday 3rd December 5:10 PM – 5:55 PM
Abstract :
Have you ever wondered what the ACE Program is about? What does it mean to those who are part of it and what is it’s value to Oracle? Have you wondered about being part of it? Come along to this session and we will answer your questions.

Title : DBA Does Docker
Time & Place : Database 2 – 1C, Tuesday 4th December 2:25 PM – 3:10 PM
Abstract : here

This will be my last event for the year, so I’m hoping it goes OK. 🙂

Cheers

Tim…

Why Automation Matters : The Series

A few months ago I decided to write a post about the lost time associated with the hand-offs between teams. It was relevant to a conversation I wanted to have, and I wanted to order my thoughts before I went into that conversation. That post accidentally became a series of posts, which I’ve listed below.

I’m not an expert at automation and I’m far from being an expert at DevOps. Theses were just a useful exercise for me, so I thought they might be of interest to other people.

I’m not sure if I’ll write any more, but if I do, I’ll add them to this page.

I’ve added an Automation category to the blog, which I’ve been using to categorise these posts, and other things like my posts about Docker and Vagrant.

Cheers

Tim…

Why Automation Matters : Technical Debt

I was going to include Technical Debt in yesterday’s post about Unplanned Work, but I thought it deserved a post of its own.

What is it? You can read a definition here, but essentially it comes down to a short-termism approach to solving problems. It can be applied to many situations, but here are two.

  • You have a bunch of applications written in Oracle Forms 6i. A new requirement comes in, and rather than biting the bullet and writing the new application in something more up to date, you write it in Forms 6i and ship it.
  • You have to build a new server, which involves manual processes for building the VM, OS and other software (app server, DB etc.). You go ahead and do it the way you always have, rather than using this as an opportunity to take a step back and start working on automation first.

In both these cases, it might actually be the correct decision to just move forward, as you may not have the necessary time and skills yet to do something “better”. It’s not the specific decision that matters as much as the recognition of the implications of that decision. By moving forward with this, you have to recognise you’ve added to your technical debt.

In the case of the development example it’s quite obvious. You now have yet another application that will have to be upgraded/rewritten in the future. You’ve added to your future workload.

In the case of the server it may be less obvious. If everything were done properly, with no human errors, you may have a beautifully consistent and perfect server, but the reality is that isn’t going to happen and you’ve just added another “non-standard” server to your organisation, that will probably result in more unplanned work later, and should immediately go on the list of things that needs replacing, once an automated and standardised approach is created.

Technical debt is insidious because it’s so easy to justify that you made the right decision, and turn a blind eye to the problems down the road.

What’s this got to do with automation? In this case it’s about removing obstacles. Improving your delivery of infrastructure and application delivery pipeline makes it far easier to make changes in the future, and one thing we know about working in technology is everything is constantly changing. I see automation as an enabler of change, which can help you make decisions that won’t add to your technical debt.

Check out the rest of the series here.

Cheers

Tim…

Why Automation Matters : Unplanned Work and Death of Productivity!

The first time I heard the term “unplanned work” it was like a light bulb switched on in my head. I’m not sure my brain even recognised the distinction between different types of work before I heard this term. It was all just work to me.

You’ve probably read the descriptions of the types of work from one methodology or another before, but just to summarise you could break it down to three types:

  • External Projects. This is project work done for your customers. Depending on where you work, your customers could be external to the company, or a different department in the company.
  • Internal Projects. This is project work done within the team to improve your situation. It could be refactoring stuff, patching, upgrades, improving your tooling and processes, or automation of tasks. You get the idea.
  • Unplanned Work. This is stuff that comes out of the blue and forces you to drop what you are doing and look at it. Maybe a priority 1 incident.

Some people add a forth type of work.

  • Updates and Changes : I prefer to think of these as part of External or Internal projects, but depending on the size you may break them out to a separate category if it helps you handle them.

The first two are planned work, since they are both projects, where you should have an idea of the resources required and the time they will take. This is true of the updates and changes too. As the name suggests, unplanned work is unplanned. 🙂 You can add some slippage time into your projects to allow for interruptions by unplanned work, but ultimately you never know if it’s going to be enough.

So what’s this got to do with automation? Well to put it bluntly, when you do stuff manually you are going to screw up and have inconsistencies between your environments. Later you will do something that you’ve done “a million times before”, knowing exactly how long it’s going to take, it will fail and you’ll lose a bunch of time trying to figure out what went wrong and how to fix it. While you are doing that, all the work you should have been doing is not happening and the list of people screaming at you is getting longer by the minute.

It can easily get to the point where you are constantly firefighting, bouncing from one problem to the next, and never make any headway with your projects. Welcome to the world on unplanned work, population you!

I’m not trying to make out automation is 100% guaranteed to prevent unplanned work, but there are a whole bunch of cases where it’s going to reduce the incidence of problems, or make resolution of those problems simpler.

Check out the rest of the series here.

Cheers

Tim…

Why Automation Matters : Can’t the cloud do it for you?

One of the comments on my previous post in the series mentioned using the cloud may solve a lot of these issues, implying you don’t have to bother with your own automation. Cursed with the ability to see both sides to any argument, I both agree and disagree with this. 🙂

Cloud providers bring a lot to the table as far as automation is concerned. Firing up new VMs and containers is really simple, and of course platforms such as RDS and the Oracle Autonomous Database family take over many of the operational aspects. So I can forget about automation right? Not so fast…

We typically see demos of cloud services that involve clicking buttons on web pages and it all works and looks great, but it’s not the way we really want to work. We want our infrastructure as code, and you can’t check button presses into your version control. 🙂 Also, if we are promoting self-service in the company, the last thing we want to do is give everyone access to our cloud account.

The cloud providers have got our back here. They allow us to use CLIs, web services and tools like Terraform to define whole chunks of infrastructure based on their services. You can use these tools to create your own self-service portals within your company. But that’s a new bunch of stuff you have to learn to become effective using this platform. It hasn’t freed you up from having to think about automation completely. It’s just altered your focus.

What’s more, a cloud provider will not be able to provide every solution you need, configured exactly the way you want it. They may provide many of the building blocks or platforms, but you are still going to have to do some of the work yourself, whether it’s application configuration or change management. All of this still needs to be automated if you want to live up to the infrastructure as code mantra.

We also have companies at various stages in the cloud journey to consider. Some companies are still not considering cloud. Some are part way through the journey. Some will almost certainly be running in mixed environments, made up of on-prem and multiple cloud providers for a long time, or even forever? Automation allows you to abstract some of the working parts, giving you some consistency in these mixed environments.

I think this all comes down to levels. You may never have to install or patch a database again, but that isn’t the whole story as far as automation is concerned.

Check out the rest of the series here.

Cheers

Tim…

Bulgarian Oracle User Group (BGOUG) 2018 : The Journey Home

It was a 03:00 start, which is never a good thing. I got down to reception to meet my fellow travellers and we started on our trip to the airport. As we walked out of the hotel we were greeted by a lite scattering of snow. It was clearly visible on some of the mountains the day before, but it was quite a surprise to see it here, especially as I left my balcony door open for the whole of my stay…

The drive to the airport was quick, as there was very little traffic. The baggage drop and check-in queue for Lufthansa was pretty large, but fortunately I had checked in online and I was hang-luggage only, so I walked straight to, and through, security. That left me with over an hour before the flight.

The flight from Sofia to Frankfurt was pretty easy. I had an empty seat next to me, so I got the laptop out and started to write two presentations I’ve got to give at work.

I was expecting the layover in Frankfurt to be about 70 minutes, but it turned out is was nearly 5 hours, because I didn’t read the itinerary properly, so I logged into work and cleared down all the crap that collected during the two days I was away.

The flight from Frankfurt to Birmingham was about and hour and went pretty smoothly. Once again I had an empty seat next to me, so happy days!

Getting through security was pretty quick, then I was in the bounciest taxi ride ever to get home, and that is was my last international conference of the year complete.

As followers of the blog will know, this year has been problematic for me from a conference perspective. It’s especially disappointing when my travelling curse hits my favourite conference of the year.

Thanks to everyone from BGOUG for letting me come for the 8th time. Thanks to the people who came to my sessions. The turnout was great, and it certainly lifted my spirits! Sorry I wasn’t able to get more involved on the first day, but at least everything went well on the second day. See you again soon!

Cheers

Tim…

PS. Here are the other posts from this trip.

 

Bulgarian Oracle User Group (BGOUG) 2018 : Day 2

I woke up feeling a little dodgy, but much better than the day before. I even got down to breakfast.

The first session of the day for me was “Oracle Database infrastructure as code with Ansible” by Ilmar Kerm. I’m pretty early on in my Ansible journey, so it’s good to see what other people are doing with it. I had a long conversation with Ilmar after the session, and was joined by Oren Nakdimon, which meant we missed the next block of talks.

Next up I went to see “So, my query plan says ‘Table Access Full’ – what happens next?” by Roger Macnicol. There was some stuff I knew, some stuff I’d written about and forgotten, and some stuff I will pretend I always knew, even though secretly I didn’t. 🙂

After lunch I went to see “Upgrade to Oracle Database 18c: Live and Uncensored!” by  Roy Swonger. In addition to speaking about the options to upgrade to 18c, he also covered some 19c stuff, and did a live demo of upgrading from 11.2 to 18.3. Funnily enough, this is exactly what I’ll be doing on Monday for one of my systems. 🙂 I spent the whole of the next block speaking to Roy about a bunch of different things, including upgrades of course. 🙂

From there I went to see “Oracle Exadata – Laying the foundation for Autonomous Database” by Gurmeet Goindi, which was a run through of Exadata and In-Memory features, amongst other things, and how they have been used as a platform for the autonomous database cloud service to be built on.

From there it was on to a panel session where we were discussing our opinions on Autonomous Systems. I think this was a funny session, and I feel like I was doing a sales pitch for autonomous databases at some point. 🙂 I think the word autonomous is a big sticking point in the heads of some of the audience. I don’t really care what it is called. I care more about what it can do.

From there we went to get some food, but I has to duck out quite early because tomorrow is a 03:00 start again for me. Fingers crossed.

Thanks for all the folks at BGOUG for inviting me again. This was my 8th visit to the conference. I wish I hadn’t been unwell at the start, but it was good that I managed to get involved today!

See you all again soon!

Cheers

Tim…

Bulgarian Oracle User Group (BGOUG) 2018 : Day 1

I got out of bed at about 11:00 feeling dreadful. Just before 12:00 I headed down to do my first talk at 12:30. The projector really didn’t like my laptop, so I had to present from Krasimir Kovachki‘s laptop, which meant no live demos. The presentation loses a lot without the demos, but I think it went OK considering.

I took some paracetamol, then grabbed some food and went outside to eat it in the cool air. Pretty much as soon as I moved inside I felt hot and bad again. I went to my room, puked and then it was time for my second presentation.

The second session was all demos, so I was rather worried about the projector situation. It was in a different room and luckily the projector played ball, so I was able to do the session I was expecting to do. I think the combination of adrenalin and paracetamol worked quite well, as apart from feeling a little giddy, I was OK.

Pretty soon after my second session ended, the adrenalin subsided and I felt terrible again, so I went back to my room.

The evening after the first day of the conference is the appreciation event. There’s usually good food, drinks, entertainment and an opportunity for me to join in with some Bulgarian dancing. I didn’t make it out of my room. 🙁

Sorry for being so rubbish! Fingers crossed I will feel better for day 2 and actually be able to get involved in the conference properly.

Cheers

Tim…

Bulgarian Oracle User Group (BGOUG) 2018 : The Journey Begins

It was a 03:00 start, which is stupid. I vowed never to do this again, but there wasn’t really a sensible alternative.

The taxi ride was fine. I got to the airport in plenty of time and it was pretty empty. I walked straight through security and had 50 minutes to get myself together, which basically meant a coffee and diet coke breakfast.

The flight from Birmingham to Munich was scheduled for 1:45, but I think it took a bit less than that. The plane was pretty empty, so there was room to spread out. I nodded off a few times, which is not that normal for me, but I still felt like I’d been punched in the face when I landed in Munich.

I had about 80 minutes between flights, but I managed to walk the wrong way a couple of times… I met Francesco Tisiot at the boarding gate, and we chatted a bit before it was time to get on the plane.

The flight from Munich to Sofia was scheduled for 1:45 again. I was meant to have an aisle seat, but the plane had an extended business class, so my seat was reassigned at boarding to one further back in the plane, and a middle seat. 🙁 I nodded off a couple of times again, so I survived OK.

BTW: The middle aged guy in front and to the right of me was looking at pictures of semi-naked young women on his phone. When did that become a normal thing to do on public transport?

We arrived at Sofia on time and made our way pretty quickly through security, where we were met by Gianni Ceresa and Christian Berg. Soon after Roger MacNicol turned up and we headed to the minibus, where we found Julian Dontcheff. We then started the drive to Pravets.

Once at the hotel I dumped my stuff, grabbed some food, said hello to some more people who had turned up, then went back to my room to veg out for the afternoon. It would have been nice to do something useful, but I was too tired.

There was a speaker dinner in the evening, but by that time I was feeling pretty dreadful, so I gave it a miss in favour of sleeping more.

Cheers

Tim…

Why Automation Matters : Continuous Improvement and Buying Time For Yourself

In previous a post I talked about lost time associated with manual processes and hand-offs between teams, but in this post I want to look at time from a different perspective…

One of the big arguments I hear against automation is, “We don’t have time to work on automation!” If you don’t think you have time now, how are you going to make time when you have to deal with another 10, 100, 1000 servers? I don’t know about you, but every week I have to deal with more stuff, not less. If I waited for a convenient opportunity to work on automation, it would never happen.

I think a lot of this comes from a flawed mindset as far as automation is concerned. There seems to be this attitude that we have to get from where we are now to a full blown private cloud solution in a single step/project. Instead we should be trying to incrementally improve things. This idea of continuous improvement has been part of agile and DevOps for years. It doesn’t have to be great leaps. It can be small incremental changes, that over time amount to something big.

As a DBA we might think of these baby steps along the path.

  1. Stop doing GUI software installations. Instead focus on silent installations of software. This is probably the easiest thing a DBA can automate because Oracle have done all the hard work for you. Silent installations of most Oracle products are really easy. What’s more you can put your scripts into Git and you have a proper record of what you did. It’s surprising how many people have no record of what they did and how they did it!
  2. Stop doing GUI database creation. Just like the silent installations, Oracle has done all the hard work for you here. You can use the DBCA in silent mode and once again put your scripts into Git.
  3. Once you’ve got 1 & 2 sorted you can start thinking about scripting post installation and post DB creation tasks including patching and other operational tasks.
  4. Once that’s all running, you have some basic automation in place, which you can improve over time, you might want to try out some alternatives, like switching from shell scripting to something like Ansible.
  5. Once you’ve got some stable and reliable automation, you can start trying to integrate it with your System Administrator’s build and patching processes.
  6. At some point you might want to make some of these operations self-service, so users/developers don’t even have to ask you anymore, they initiate the automation themselves. You will still be responsible for creating and maintaining the automation, but you don’t have to be there 24×7 to manually run the scripts.

If all you have time to do is steps 1 & 2, you will still have saved yourself some time, as you can start a script and do something else until it finishes. That could be working on improving your automation. Added to that you’ve improved the reliability of those steps of the process, so you won’t have to redo things if you’ve made mistakes, or live with those mistakes forever.

I understand that company politics or internal company structure can make some things difficult. Believe me, I run into this all the time. I can build whole systems with a single command at home, but at work I have to break up some of my automation processes into separate steps because other teams have to perform certain tasks, and they haven’t exposed their work to me as a service. As frustrating as that can be, it doesn’t stop you improving your work, and maybe trying to gently nudge those around you to join in.

Remember, each time you save some time by automating something, invest some of that “saved” time into improving your automation, and automation skill set. Over time this will allow you to take on more work with the same number of staff, or even branch out into some new areas, so you aren’t left out on a limb when everything becomes autonomous. 🙂

Check out the rest of the series here.

Cheers

Tim…

PS. Continuous improvement (Kaizen – Masaaki Imai – 1986)

“Kaizen means ongoing improvement involving everybody, without spending much money.“

“The starting point for improvement is to recognize the need. This comes from recognition of a problem. If no problem is recognized, there is no recognition of the need for improvement. Complacency is the archenemy of Kaizen.”

Exit mobile version