Cloud 101 for Mainframe Developers

Mainframe to Cloud

Cloud 101 for mainframe development and Hybrid Architecture Wannabees!!  Introduction: We are all in a rat race aren’t we? It’s alright to say yes and the rats aren’t going to take any offense if you say yes. We are all in the race to get somewhere and achieve IT that means something to us be it personal, professional or spiritual. Do you ever think what those vagabonds seek and do they eventually achieve what they are looking for? I only want to say we all have a purpose and we all are striving to achieve it – some in a rapid fast pace – a.k.a rat race – and some slow paced like that evil conniving tortoise – putting up a bored existence with what they surrounded themselves with – who does in the end gets there, achieves its purpose and everything is normal in this whole wide world. Anyway, the purpose of this rat race – that I have been part of – deals with the race to take the zOS mainframes to the cloud. Let me document the options/choices and steps that I have considered below –   

  1. Considering Lift and shift – This would be an easier option if you are small shop managing really small work loads that has manageable batch processes running in a single thread. This is also an easy choice if you have your workloads on midrange computers like the AS400 family and not the zOS/390 family. It makes perfect sense based on the kind of industry you are with. If its a huge investment or financial services organization then you probably will stumble into a road block almost every hour making it difficult to permeate your solution through every layer of organization’s bureaucracy and decision makers.  
  2. Understanding application function and isolating smaller workloads – It is important you perform a complete inventory analysis of CICS transactions, COBOL, JCL, NSP’s, DB2 tables (and their relations), VSAM files, flat files and everything else that your mainframe house supports. Completing this exercise will help you to not only understand the complete structure and flow of applications and will provide you an opportunity to identify loosely coupled application functions that you can identify and isolate as candidates to decouple your existing tightly coupled application from.   
  3. Making the critical selection of cloud perform – Performing the second point mentioned above is critical to proceeding with choosing a cloud partner. It would have already prepared you with what you want to do and how you want to go about it. There is now a plethora of companies available who will guarantee your seamless on boarding on to the cloud platform but my personal recommendation is to chose from the top three – Amazon Web Services, Google Cloud or Microsoft Azure. [Note: And I will speak about IBM’s ICP (IBM cloud private) in a future discussion].  
  4. Understanding cloud provider’s partner network – While your organization may still be making a decision regarding what cloud perform may best serve your needs, you, your organizations decision makers might already be inundated with a partner network of these cloud providers who also make a lot of vacuous promises with their ppts and filling your ears with a utopia a.k.a shangrila-esque architecture pattern serving all your needs. Their ppts mooch on the buzz words and catch phrases that their original parent cloud provider might have coined. They might also enthrall you options such as creating API’s by screen scraping your CICS screens or putting a micro focus work bench on top of your emulator environment. I would listen to their sales pitch or give them a patient hearing. You and I both know it’s sometimes easy to have someone else do your job and shove all this responsibility to these partner networks. My personal recommendation is NO. Do not fall into these multi year traps. YOU and I repeat – ONLY YOU and Your SME’s understand your framework or jobs, your CICS transaction list or what can changes to your COBOL copybook can entail.  
  5. Building a team in the organization – You sometimes may be coming into a position where all decisions are in place, architecture patterns from business and product perspective are documented and the team is in full swing implementing the decided pattern on the cloud landscape. In this scenario, the best option is to bite the bullet, start from step 2 and understand the system better before waiting for your time to start making contributions that may make better sense to the people in the team. I know, this almost sounds like becoming Gandalf and secretly scheming, plotting, understanding everything before making your final go at the ring. Please understand that it will be all worth it!! If you are tasked with building a team – choose your friends carefully!! Many organizations with mainframe installations have never cared about taking time to create system documentation or the information that you are tasked with gathering might be scattered all over in personal files or hard copies that you may never get your hands on. This is the reason point 2 is so important. If it’s not readily available – You should be able to build it. It may appear an arduous task in the beginning but as I said earlier – It’s worth it!! 
  6. Understand your data – A larger chunk of mainframe organizations house financial, insurance, banking and other services that house applications managing your investment portfolios, your insurance and claims history and your bank accounts data. It is critical as you pave your way further driving towards a cloud solution to understand your data – where its housed, what it contains, what is the COBOL copybook that defines it, what FILE AID option you can use to filter a particular set of data and how you will eventually SORT/FILTER/MERGE them so you can build the data that you need. Take time to understand your DB2 data and document all relational attributes including information that details where else the data might be duplicated and how it is used. Evaluate cloud providers available solutions for housing your data before zeroing in on your application needs. This will also help you identify and classify the personally identifiable information (PII) that your data may secretly be giving out.   
  7. Understand your customer’s needs – You have to agree everywhere you go this is most common thing you will hear. How to make things better for the customer? You have to be customer obsessed and show it in your actions, behavior and sometime you probably need to buy their merchandise that comes in garish colors to show your obsession to the customer. It’s all a facade and it does not last. Sooner or later someone from the customer side will see through your BS and it will not be pretty. This is the prime reason for you to prepare yourself and ask better questions. If you build a cloud platform that’s not serving what the customer has asked for then neither you nor the customer is going anywhere.

 This is all the time I have for today. I will continue my thoughts into the next article and take time to discuss what we did after choosing our cloud provider. You must definitely want to come back to know who did we really chose? Trust me I will make that as interesting as the season of “bachelor” where one of the three gets our bouquet of roses!! AUTHOR: Mukesh is a cloud enthusiast with a bias for AWS. You can reach him at mukesh96@gmail.com

Cloud 101 for Mainframe Developers

3 thoughts on “Cloud 101 for Mainframe Developers

  • Pingback:cialis pills

  • Pingback:DynamoDb for Mainframe Programmers | Review N Prep

  • January 17, 2020 at 2:00 am
    Permalink

    Hi Mukesh, I like the blog as the contents resemble many cloud initiative projects. I agree with your thought process on the “Understanding application function and isolating smaller workloads”. The team must understand what they want to achieve by migrating to the

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *