The government needs to be more like Netflix

To truly benefit from shared services and the cloud, agencies should be building a repository of "microservice" business routines.

cloud processes (Omelchenko/

When it comes to digital infrastructure, Netflix's scale and efficiency is staggering. Imagine the following: 19.1 percent of the entire U.S. internet bandwidth is consumed by people streaming Netflix video content every night. In 2016, it was estimated that Netflix delivered one billion hours of content, per month, to a customer base of 135 million subscribers across 190 countries.

By many accounts, unauthorized password-sharing means there are actually 2.5 viewers for every legitimate Netflix subscription, bringing the real number of viewers closer to 300 million – almost equal to the entire population of the United States. To state this as a business proposition: Netflix is equipped to support the possibility of 300 million people requesting instantaneous video streams, to 300 million different devices, in 300 million different locations, around the world, simultaneously.

If you assumed it would cost a fortune to do this, you would be wrong. In its most recent annual report for 2017, Netflix revealed that its entire technology and development spend was only $1 billion. That's not pocket change, but it is roughly equivalent to just 9 percent of the company's revenue. This is profoundly low for what is primarily a technology company, particularly when measured against the enormity of the service Netflix provides.

Meanwhile, the federal government's well-known slow adoption of new technology makes it look like an old Blockbuster video store by comparison. The U.S. government's known IT spend is approximately $92 billion a year. To put this dollar figure in context, our government spends more on IT than the entire U.S. Postal Service collects in a year ($70 billion) and only about 4 percent less than the total annual revenue of Boeing ($96 billion), the 76th largest public company in the world. Now that is real money.

Historically, most attempts to reduce the government's IT spend have focused on the reduction of duplicative systems and the need to create more shared services among agencies. For instance, the Government Accountability Office in 2011 reported that the government had no less than 622 Human Resources Management systems, costing about $2.4 billion, when many of them could be collapsed into a shared service for use across multiple agencies. More recently, the focus has been on a shift toward cloud computing, and the promise of paying for IT infrastructure as a service, closely measured to actual consumption, only after the fact.

The brilliance of Netflix's massively efficient IT is that the company has cracked the code on the very thing the government seeks -- through a marriage of both shared services and cloud. Under the leadership of Adrian Cockcroft, Netflix made a fundamental architecture decision to deploy cloud-based "microservices" that are provisioned via a "serverless" cloud execution model. Simply put, Netflix broke up monolithic bespoke software applications by isolating independent modules of common business routines and then positioned them in the cloud, where they consume zero resources until called by core applications.

Once invoked, these microservices -- with the magic of cloud serverless technology -- can expand and contract instantly like a balloon, spinning up only for the short duration of their execution. Once the execution is complete, they collapse back to an almost-zero footprint.

The special sauce to this architectural approach is that these routines can be called by multiple independent applications – meaning that once created (or procured), an entire universe of applications can take advantage of these provisioned routines. Because microservices are separate from the core application, they can be managed and owned independently, where they can be obsessively enhanced and improved, greatly reducing the complexity of updating functionality in a monolithic application with all its interdependencies.

To abruptly shift the metaphor, it's like the invention of loaner shoes at the bowling alley -- but in this case, every bowling alley in the world has access to the same shoes, at almost no cost.

In practice, many common routines are perfectly suitable for microservice deployment. At the Department of Housing and Urban Development, where we are currently developing a proof of concept, it's possible to create a series of microservices for the purpose of processing mortgage insurance applications. As just one example, it's possible to build a microservice that exclusively provides applicant income verification. When the core business software reaches the point in the process, where the application needs income verification, it calls the appropriate microservice through an API. The microservice performs its function, returns a result, and then shuts itself down. The cost of any single transaction could be fractions of pennies.

Now let's think of this in the context of a shared service. That same income verification microservice can likely provide identical functionality for a myriad of core applications across the government -- the Department of Agriculture's extremely similar Farm Loan guarantee process, for example. Imagine a repository of basic microservices routines like credit card transactions, "do not fly" list look-ups, "do not pay" lists, address verification, and credit checks.

Simple microservices could ultimately be followed by more-complex but also commonly needed routines and managed at a government-wide level -- or at the very least, at an agency level. If executed properly, the government could effectively build a shared service of re-usable microservices for consumption enterprise-wide, to be managed in a single repository. Suddenly, the government would find itself with a highly economical portfolio of extremely inexpensive functionality that could be shared far and wide.

To state it another way, agencies would be free to develop the unique core of their business systems, but the shared services component would be the specific calls to common functions maintained in a well-managed repository.

Bifurcating development this way is an architecture decision, but as seen by Netflix, it greatly reduces costs in many categories. It reduces the cost and complexity of maintaining monolithic bespoke applications. And it reduces the cost of IT consumption, as the microservices are infinitely elastic and use resources only at extreme levels of efficiency. Perhaps most importantly, it creates the opportunity for a large number of systems, anywhere in the government, to share specific common routines, in an on-demand basis. A relatively small staff could manage a large portfolio of common application routines that could be re-usable, across the entire government.

Netflix's pioneering approach to these new architectures and cloud services are no longer cutting edge. They are available to everyone, including the federal government. Frankly, these new approaches are the digital equivalent of Henry Ford's optimization of the assembly line for manufacturing. In cases when it's appropriate for the government to build its own solutions, creating a microservices and shared services consumption model can help reduce costs and accelerate the delivery of new solutions. It's truly the time for the government to get on board with this highly efficient, cost-reducing approach to information technology modernization.

Note: The authors are principal consultants supporting GSA's IT Modernization Center of Excellence focused on Cloud Adoption. The content of this article is their personal perspective only and does not reflect an official government position. The program's overall accomplishments and latest updates associated with the Cloud Center of Excellence can be found at the Centers of Excellence website.