post-template-default,single,single-post,postid-10,single-format-standard,ajax_fade,page_not_loaded,,qode-title-hidden,qode_grid_1300,footer_responsive_adv,qode-theme-ver-16.2.1,qode-theme-bridge,disabled_footer_bottom,wpb-js-composer js-comp-ver-5.4.7,vc_responsive


LOVING LEGACY: Legacy in the RMB / FNB context

Legacy is a reality in the banking industry, no different in FNB/ RMB, and it’s on this topic that I would like to tell you a story about Legacy.

First, lets recap on the Agile & DevOps journey in FNB/RMB: DevOps is an extension of Agile, and at FNB / RMB we have widely adopted the Agile Philosophy. Here our belief is that DevOps is the immunization enterprise disease that is Silo Sickness.

For us, DevOps is many things and more of what we do in Agile. Its stats with empathy; where Ops understand the workings of Dev, and Dev understanding the workings of Ops. It’s the collaboration of Ops and Dev, and the optimization & automation of all things at can be atomized. What’s important is to measure, and see the effects of these changes in Ops to Dev, and vice versa.

As I have spoken about in these talks before, in our Agile and DevOps journeys we encourage the philosophy around the spine model.

Where we start with the identifying the NEEDS >> VALUES >> PRICIPALS then to look at the PRACTICES and then ultimately the TOOLS. Today I’ll be telling you a story that emphasizes that the tools always make it back to the need.

Legacy is always the target at FNB/RMB, and that’s why its so important to be dealing with legacy appropriately. So we all still have physical machines, they come in all flavours and colours and are called by all sorts of different names, but we have them. And this is, unfortunately, a day to day reality.

In a DevOps approach to this; our aspirations are to use modern DevOps strategy for a modern approach. The strategy for Legacy in a DevOps world, basically different animals require different treatments. So we set off on our journey of optimizing Legacy, and we were very intentional on the outcome; to bring Legacy into the DevOps space.

How were we intending on doing this? By allying the spine model. With what? A great tool called Puppet. The story about Puppet; the team from RMB when to visit the team from infrastructure at FNB. So what we saw on tat visit is that they puppetized large amounts of infrastructure but they hadn’t puppetized the application layer.

This made us think; what if we could puppetize the entire stack up to the Application Layer?

Proof of concept was was applied on FX application that proved to us that we could use puppet in that way. After prototyping, we had to put zoo keepers in place to look after all these different kinds of animals and that of the one we call our little black sheep, Legacy.

What was required from these keepers was for Dev to write the code, and then work with the environment managers to produce the puppet code that would take care of the Application layer. Then it would be the responsibility of the System Administrators to write the puppet code for everything below the Application Layer. Then, we put all the code together to give a full piece. Application Support will be involved and support throughout the entire process.

Even if you are focussing on the tools and technology in DevOps. You can’t forget about the behaviour of people. The change in technology that DevOps brings is equally profound as the change people need to make in the way they work

– Jason Suttie

So what have we done since then?

Since we applied the zookeeping process is rollout puppet across infrastructure and we are currently puppetizing our Commodity App.

But during this process we had an interesting experience and this is the story I would also like to share with you.

At RMB we have a something call a Code Blue. What this is what is called when there is a system breakage. Code Blue then brings a bunch of people in a room, and between teleconferencing and scratching of heads we try and understand what is broken and how to fix it.

So this days Code Blue, it was a DNS issue. A server had fallen down and effected the database.

The System Administrator diagnosed the problem, made the manual changes to the database server, tested it; it was working.

System Admin then called the user, confirmed it was fixed and test.

Minutes passed, a call back came from the user that it was still broken.

Everyone was very confused, and as the System Administrator looked at the the server the configuration was set back to its original state.

Confused, System Admin made the manual changes again, tested it, called the end user advised the system was working and that it had been tested and retested.

A few minutes later, unamused, the user called again, and the system was again not working. Everyone in the room as just as unamused and confused, when someone from the pack asked; what server is this exactly? Oh? Isnt this the server we had puppetized?

So puppet was doing exactly what it was supposed to, so every 30 min it set back to configured settings. Back to what it should be.

Amusing story now, but at that point felt like a sense of humor failure.

So I want to highlight the fact;

Even if you are focussing on the tools and technology in DevOps. You cant forget about the behaviour of people. The change in technology that DevOps brings is equally profound as the change people need to make in the way they work.