The Technological Wake-Up Call from the Coronavirus Pandemic

The Coronavirus pandemic has served as an unprecedented stress test for our digital infrastructure, revealing significant vulnerabilities across the board. From federal to local levels, the surge in demand on systems due to the pandemic, especially state unemployment websites, has highlighted a widespread technological unpreparedness. These systems, never designed for such massive traffic loads, have buckled under the pressure, reflecting a deeper issue than just inadequate technology. System after system experienced significant challenges. Technical failures, such as crashing websites and overloaded systems, obstructed access to critical services and financial support for small businesses and unemployed individuals. These failures were not due to the technology itself but stemmed from a fundamental lack of understanding and foresight in handling digital infrastructure demands.

The Coronavirus pandemic has laid bare the technological shortcomings of our current systems and the urgent need for a strategic reevaluation.

Small Business Administration’s Computers Crash

In an online article titled “Small business loan program stumbles as SBA system crashes” published on 04/06/2020 on Politico, Zachary Warmbrodt wrote:  “Banks on Monday struggled to assist thousands of small businesses vying for $350 billion in government-backed loans as lenders reported that a Small Business Administration system used to process the applications was crashing. The small business aid program — a crucial part of the government’s record $2 trillion plan to rescue the economy from the coronavirus pandemic — has been snarled since it was launched Friday in large part because of technical problems with the SBA’s “E-Tran” system, which banks must use to authorize the loans.” In a separate 04/27/2020 article titled” Small Business Loans Site Crashes On First Day Of Reopening” published on the National Public Radio’s website, Danielle Kurtzleben writes: “Small businesses, already hammered by the coronavirus pandemic, can’t seem to catch a break. On the first day of the reopened Paycheck Protection Program, a key lifeline from Congress, banks are reporting that the Small Business Administration’s portal is not working. Bankers told NPR on Monday that the system, known as E-Tran, would not allow them to enter loan application information that is needed for small businesses to access the program”. “We have been attempting to access E-Tran since 10:30 and have had no luck,” said Maria Amoruso, chief marketing officer at Pennsylvania’s NexTier Bank, in a midday message to NPR.”

New York Unemployment Website Goes Down

In an article posted Mar 20, 2020 on syracuse.com Rick Moriarty writes: “SYRACUSE, N.Y. -- More than 500,000 online applicants and nearly an equal number of callers a day are crushing New York’s system for filing unemployment claims as the coronavirus outbreak puts people out of work. People trying to file for unemployment benefits with the state Department of Labor are being greeted by constant crashes of the department’s website. Those who try filing over the phone are running into jammed lines”. In a similar article written for the New York Daily News. posted on March 16, 2020 titled “New York’s unemployment system overwhelmed as coronavirus pandemic shutters businesses across the state” Clayton Guse writes “New York’s unemployment website was overwhelmed Monday as the coronavirus pandemic put tens of thousands of people across the state out of work. A drastic move by Gov. Cuomo to close all of the state’s restaurants, bars, movie theaters, gyms and casinos by 8 p.m. Monday to contain the outbreak had suddenly jobless workers flooding the Department of Labor with applications for unemployment benefits. So many people tried to apply that the website crashed several times throughout the day — while the DOL’s hotline was so jammed up that callers seeking aid could not get through to someone who could handle their claim”.

Unemployment Websites Across The U.S. Keep Crashing

On March 18, 2020 in an article by Minyvonne Burke reported on NBC News “Workers who have suddenly found themselves without a paycheck because of the growing coronavirus pandemic in the United States are now dealing with another frustration — state unemployment websites crashing because of high traffic. From Oregon to New York and Washington, D.C., officials and Twitter users have highlighted the problem after the mass closing of restaurants, retail stores and other businesses as part of the effort to slow the spread of the virus. Some states are responding by staggering the days on which people apply for unemployment benefits based on the first letter of applicants’ last names”. One twitter user wrote: “I can’t login or certify for benefits. Second day in a row. It currently says ‘We are sorry, our systems are currently not available. Please come back later and try again.’”

COBOL: A Wrongfully Convicted Programming Language

In an article written for The Verge on April 14, 2020 titled “Unemployment Checks Are Being Held Up By A Coding Language Almost Nobody Knows” Makena Kelly incorrectly blames the COBOL programming language as the culprit for many of the unemployment systems inability to respond to the enormous spike in user traffic resulting from the coronavirus outbreak. It is not surprising that the author would come to that conclusion when the different state officials she interviewed believe the problem is the programming language and not how their systems are designed.

COBOL: A Falsely Accused Programming Language, Guilty Only by Association.

 

The Cobol Comments Made by State Spokespersons

To better understand why COBOL is incorrectly considered the culprit we need to analyze several comments made to the author by different spokespersons for various states.

  • “A survey by The Verge found that at least 12 states still use COBOL in some capacity in their unemployment systems. Alaska, Connecticut, California, Iowa, Kansas, and Rhode Island all run on the aging language. According to a spokesperson from the Colorado Department of Labor and Employment, the state was actually only a month or two away from “migrating into a new environment and away from COBOL,” before the COVID-19 pandemic hit.”

  • “LITERALLY, WE HAVE SYSTEMS THAT ARE 40 YEARS-PLUS OLD” “Some state governments, like California, have contracts with outside vendors. California’s Employment Development Department has long-standing contracts with IT vendors that are “well-versed in the programming applications of COBOL,” according to a department spokesperson. Others rely on their own staff programmers, like New Jersey, Colorado, and Rhode Island”.

  • “‘We currently have 3 COBOL programmers, and like other states, our system is undoubtedly taxed by the increase in claim volume,’ a spokesperson for Rhode Island’s Department of Labor and Training told The Verge”.

  • “Only one full-time programmer maintained Colorado’s COBOL system before the novel coronavirus outbreak, a spokesperson for the Colorado Department of Labor and Employment told The Verge. ‘We are bringing another back to help for just the pandemic programming.’”

  • “Earlier this month, New Jersey Governor Phil Murphy made a plea for more COBOL programmers to help maintain the state’s unemployment system during a press conference. ‘Literally, we have systems that are 40 years-plus old, and there’ll be lots of post-mortems,’ Murphy said earlier this month. ‘And one of them on our list will be how did we get here where we literally needed COBOL programmers?’”

It is obvious from the emphasis and reference throughout the article to COBOL by state spokespersons that one would assume the main problem can be attributed to a programming language first developed in 1959. It is one thing for a writer to conclude incorrectly that a programming language is the culprit but is disturbing to think people who may have influence on how a state’s resource are allocated simply do not understand why their systems are failing. Throwing the wrong solution at the wrong problem can be very costly. As the coronavirus has demonstrated that cost may not be limited to only money.

 

WHY THE PROBLEM HAS NOTHING TO DO WITH COBOL

 

It’s The Design And Nothing But The Design

I think we can safely assume that before the Coronavirus and the increase surge in people filing for unemployment the COBOL programs in question were working just fine.  A spokesperson for the Colorado Department of Labor and Employment told The Verge that prior to the outbreak of the Coronavirus they only had one full-time programmer maintaining their COBOL system and because of the virus they were bringing back another programmer to do the pandemic programming. Obviously their system worked prior to the pandemic. During the pandemic, New Jersey Governor Phil Murphy made a plea for more COBOL programmers to help maintain the state’s unemployment system. One can assume New Jersey’s state unemployment system was also working fine prior to the pandemic and we can than directly attribute to the virus the extra surge in user traffic that is causing issues with these systems. If those same systems were working prior to the virus then it is probably a good thing there is a shortage of COBOL programmers because the programming language is not and never was the problem. It is the architecture that is the problem. There is a big difference between a system’s hardware architecture and the programming language used to implement that architecture. Hiring more programmers to fix a program that already works is nothing more than an excuse for not having to deal with what really is the problem, and that problem has nothing to do with a programming language.

COBOL Normally Run On Mainframes

COBOL programs are typically and understandably associated with mainframes. Mainframes have and continue to be used in banking, finance, health care, and government. In an article published in April of 2016, titled “Questioning the Cost Performance of Mainframes” computereconomics.com estimated the costs for a high-end mainframe server to be in excess of $750,000. Mid-range servers costs between $250,000 and $750,000. Low-end servers cost below $250,000. In September 12, 2019 Yahoo Finance reported the cost of a custom built IBM z15 mainframe ran anywhere from $250,000 to $4 million. Mainframes in themselves are very expensive to buy and to maintain. Some mainframes can not be bought but can only be rented and those rental fees can be very steep. Many of the state unemployment systems that failed during the Coronavirus pandemic run on mainframe servers. Mainframes that also run programs written in different programming languages including COBOL. Mainframe systems that would have crashed under the Cornoavirus load regardless of the programming language used, because the failure had nothing to do with the programming language itself. In the next section we will look at why trying to meet the increase demand placed upon a mainframe system, as what happened during the pandemic, was simply too cost prohibitive regardless of the programming language.

Vertical Scaling Verses Horizontal Scaling

There are two ways to increase a system’s performance. One way is to perform vertical scaling which means adding more resources to a device or server. This can include adding more memory, processing power, and/or storage capacity. Conceptually a mainframe (a souped-up machine) is a form of vertical scaling in that it uses a “bigger is better” strategy. Mainframes take the concept of vertical scaling to its upper limits by already starting out as powerful machines. Although mainframes are very powerful and expensive machines what happens when a mainframe is not powerful enough? Eventually a machine no matter how expensive will hit a limit to how far it can be scaled vertically. In contrast, horizontal scaling is about adding more individual servers to the system to increase overall performance. Google, Amazon, Facebook, and Twitter are successful at handling large spikes in user traffic because they employ a horizontal scalinge architecture. A strategy that also uses autoscaling to automatically add new server nodes to handle any increases in traffic and automatically removes server nodes as traffic diminishes. In horizontal scaling the preference is to use inexpensive off-the-shelf machines or even cheaper minimalist custom servers to further a “more is better” strategy. The difficulty in employing a horizontal scalable architecture with mainframes is that each additional mainframe you slap in as a node would be very costly and in most cases, cost prohibitive. That is if you can even find one in time to slap-into your network.

Summary  

As a real world stress test the Coronavirus has shown that as a society we are ill prepared to operate efficiently in a digital world. The Coronavirus not only caught the medical industry unprepared, many of our local, state, national, and even international institutions were caught technologically unprepared. The failure on the part of educational platforms, unemployment systems, and federal websites to handle the demand placed upon these systems are good indicators we need to rethink our understanding of technology and how we plan to employ technology in the future. Obviously the successes of companies such as Google, Amazon, Facebook, and Tweeter to handle a much larger traffic load than what was placed on any of these systems tells us that the knowledge to handle compute intensive processes or large surges in user traffic has yet to fully penetrate our society. The Coronavirus is one of life’s wake up calls that tell us we have to do better or life itself will quickly bite us and bite us hard.

 

Suggested Reading:

 

No, You Don't Need To Throw Away Your Mainframe!
Mainframes are too costly an investment to simply discard. Yet, because they are expensive, they are not the ideal solution for handling large spikes in traffic, as was evident during the pandemic. This article is about compromise—compromise when a purist solution becomes too cost-prohibitive. We turn to Design Patterns to provide us with a "have your cake and eat it too" solution. In other words, how to keep your mainframe and extend its capabilities too.

 

Contact Us

Address

7823 Tommy Dr. #34
San Diego, CA 92119, USA

Phone Number

+1 (619) 248-2949

Video

Person interacting with the concept of what is a microservice architecture.
A Netflix Guide to Microservices