JASON SUTTIELOVING LEGACY

LOVING LEGACY:THE RMB & FNB STORY 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.

The Little Black Sheep

Here is our story:

LETS RECAP: AGILE & DEVOPS JOURNEY IN FNB/RMB

DEVOPS

AGILE

DevOps is an extension of Agile, and at FNB / RMB we have widely adopted the Agile Philosophy. At FNB / RMB our belief is that DevOps is the immunization for the enterprise disease that is:

THE SILO SICKNESS.

THE SILO SICKNESS: DEVOPS IS THE IMMUNIZATION FOR THE ENTERPRISE DISEASEFor us DevOps is many things, and more of what we do in Agile. Its starts with empathy; where Ops understand the workings of Dev, and Dev understanding the workings of Ops. Its 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

EMPATHY COLLABORATE OPTIMISE MEASURE

DEVOPS IS THE IMMUNIZATION FOR THE ENTERPRISE DISEASE

THE SPINE MODEL: NEEDS VALUESPRINCIPLESPRACTICESTOOLSAs I have spoken about in these talks before, in our Agile and DevOps journeys we have adopted the spine model philosophy. Where we start with the identifying the NEEDS >> VALUES >> PRICIPLES then we look at the PRACTICES and then ultimately the TOOLS. Today I’ll be telling you a story that emphasizes that the tools that support our DevOps need

NEEDS

VALUES

PRINCPLES

PRACTICES

TOOLS

NEEDS

VALUES

PRINCPLES

PRACTICES

TOOLS

THE PHOLOSOPHY:THE SPINE MODEL

THE TARGET: LEGACY

Appropriate legacy reduction strategies and execution thereof was our target

THE REALITY:PHYSICAL MACHINES

So we 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

DEVOPS APPROACH:THE ASPIRATIONS

Our aspirations are to use modern DevOps strategy for a modern approach. A different strategy is needed 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 APPLYING THE SPINE MODEL.

WITH WHAT DID WE INTEND ON DOING IS WITH? A GREAT TOOL CALLED PUPPET.

THE PUPPET STORY: The team from RMB went to visit the team from infrastructure at FNB. So what we saw on that 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 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 Legacy being a complete different animal needed a complete different treatment.

OUR LITTLE BLACK SHEEP, LEGACY.

THE ZOOKEEPRS:

What was required from these keepers was for developers 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 cover the full domain. Application Support will be involved and support throughout the entire process. 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.

SENSE OF HUMOR FAILURE

CODE BLUE IN THE ZOO:

So this day, it was a DNS issue. A server had fallen down and effected one of our databases. 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 tested. 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 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? Isn't this the server we just 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.

HIGHLIGHTING: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.

THE END

LEGACY: DEALING WITH THE BEHAVIOR OF HUMANS