Intelligence Community Cloud Strategies, One Year Later

Due to professional and personal commitments, I regret that I will be unable to attend the GEOINT 2024 Conference this week and reconvene with my distinguished fellow panelists from last year to continue our discourse on Intelligence Community (IC) Cloud Strategies. In lieu of my attendance, I would like to provide an update on my perspective regarding our progress as a community over the past year.

Before I begin, it is important to acknowledge that each organization within the IC is unique in terms of its mission, Information Technology (IT) / cloud / contracting strategies, funding imperatives, etc. There is no ‘single’ IC Cloud Strategy. Instead, each IC organization will implement a unique cloud strategy when and how it makes sense for them to do so. What follows is my professional opinion, based on the perspective of the organization I currently serve, the NRO.

As of today, Amazon AWS, Microsoft Azure, Oracle Cloud, and Google Distributed Cloud (GCD) are accredited for use by the IC CIO on the top-secret fabric via the C2E contract. This has been a significant accomplishment since last year. However, it is not the end of the story.

The rest of the story

After the IC CIO accredits a particular vendor's cloud offering, each individual IC organization must engineer and implement its own 'enablement' for that vendor’s cloud offering. This process might include connecting their network infrastructure to the vendor's cloud infrastructure, developing organization-specific policies and procedures for use, and creating automated provisioning and billing, etc. This 'enablement' must then be accredited by the individual IC organization, which is a lengthy and resource-intensive process. As I stated last year, the C2E contract added four new vendor cloud offerings. However, the IC did not receive a commensurate increase in personnel resources and funding required to implement these four new offerings concurrently. Instead, the work is being executed sequentially, one after another, both at the IC CIO level and within the individual IC organizations.

As of today, the NRO has enabled Amazon on the top-secret fabric, with Microsoft enablement anticipated within a month. Oracle and Google will follow later in the calendar year or early next year.

Even with enablement and accreditation, we might not be able to fully use the cloud offerings as we would like because several cloud vendors have not yet achieved parity between their top-secret and commercial cloud offerings. This is particularly true for Microsoft (where M365 E5 is not yet available) and Google (where the C2E offering is the Google Distributed Cloud (GDC) subset of the Google Cloud Platform (GCP)). Furthermore, all the cloud vendors have been slow to make a substantial number of Graphics Processing Units (GPUs) and Tensor Processing Units (TPUs) available along with Artificial Intelligence (AI) tools, models, services, and capabilities needed. More on this later.

Finally, IC organizations are discovering that the cost of implementing services in the cloud is often higher than the on-premises version of the same services. One reason for this is that due to a lack of funding (or a focus on resilience), IC organizations usually keep costs low by not engineering services to be completely redundant and not recapitalizing their infrastructure on a regular basis. Instead, they often operate their (increasingly insecure and unreliable) infrastructure well beyond end-of-life until it fails and must be replaced (thus, making the case for a capital infusion of funding easier). Cloud vendors, on the other hand, engineer their clouds to be fully redundant, continuously recapitalize their equipment, and implement capacity ahead of demand. Add to that, the cost of operating air-gapped clouds in the IC with all the additional requirements they must adhere to and the desire to recoup their capital investment. Considering all these factors, it should not be surprising the cost of implementing services in the cloud is typically higher, and securing the necessary funding is challenging when other priorities, such as cybersecurity and zero-trust, compete for scarce IT resources.

But... how much higher is the cost really? I believe that implementing cloud-centric (not all applications should be in the cloud) applications in the cloud is not significantly more costly if you take Total Cost of Ownership (TOC) into consideration. However, we have been poor within the IC at calculating the TCO of our applications because the cost centers for everything that goes into a particular on-premises application implementation are often spread well beyond the IT organization throughout the larger IC organization (think utilities, data center space, SCADA, physical security, networking, personnel, etc.). We could benefit from better expertise and tools to understand TCO and develop comprehensive business cases unique to our respective organizations for implementing cloud-centric applications.

So, let us say for the sake of argument that we have addressed everything I have discussed above, and we now have four cloud offerings on the top-secret fabric to choose from. How are we going to do that? The C2E contract requires that we compete existing cloud applications when they are transitioned from C2S to C2E and all new starts. In fact, we must report our C2E usage among the C2E vendors to Congress on a recurring basis. One approach that IC organizations have indicated they are going to take is to 'bin' their requirements into broad categories and contract with individual cloud vendors for each 'bin'. At the NRO, we have worked with the C2E vendors to help inform us on how we can best create a level playing field for them to compete for every existing and new requirement in partnership with our Defense Industrial Base. Within the next few months, we will publish contract guidelines to be followed within the NRO to ensure that all vendors are provided with an equal opportunity to earn our business.

An equal opportunity, really!? What about existing C2S (AWS) applications? Good question. For years, we have installed hundreds of mission applications in AWS. For existing applications, we are encountering several challenges in transitioning them. First, many of these applications were developed using specific AWS APIs or services. To transition these applications to another vendor's cloud offering, the applications will need to be refactored. Second, the original development teams or contracts for these applications have long since moved on or ended. As a result, any savings we might accrue from moving these applications will be consumed by the development costs of refactoring them. Third, in many cases, significant mission outages will be necessary to affect the transition. Finally, we continue to build out a development pipeline that allows development on the low side and operations on the high side. This pipeline requires an accredited means to move development code and other assets from one fabric to another. To date, we only have that capability with AWS. If we are to effectively compete amongst all the vendors, all the vendors need to have a similar capability.

In the future, we will ensure that all new systems developed keep transportability in mind and that we utilize containers and similar technologies to make that easier to achieve. For existing applications, that might be too costly to implement.

Now some miscellaneous items...

Multi-Cloud or Multiple Clouds

Last year, I spoke of building 'multi-cloud' mission applications. Recently, IC organizations are using the term 'multiple clouds' to describe their cloud strategy. My use of the term 'multi-cloud' and the example I gave of a mission application being composed of services from multiple clouds was meant simply to illustrate that in C2E, we can if we choose to, use best-in-class APIs, algorithms, services, etc., in any of the vendor’s cloud offerings to develop new mission applications, and that it was a mission advantage to do so. This is why we did C2E in the first place, to provide the IC with the ability to access the incredible talent and innovation in private industry to create mission advantage for the IC.

Whether we call it 'multi-cloud,’ or 'multiple clouds' is irrelevant – we WILL be using two or more cloud offerings and on-premises applications daily. Imagine that the 'application' is our desktop itself. The desktop might be an Azure Virtual Desktop (AVD) running Windows. Our productivity suite might be Microsoft M365 or Google Workspaces (not available on C2E GCD). In our browser, we might access mission applications installed in Amazon AWS or on-premises. Likewise, in our browser, we might access personnel, budget, and other enterprise applications in Oracle Cloud. And finally, we might access Large Language Models (LLMs) like Gemini in GCD. You can create any number of scenarios that combine C2E cloud offerings and on-premises capabilities – we are 'multi-cloud' or 'multiple cloud' today and will continue to be in the future. Given that, we need to optimize the communications links between each of the C2E cloud offerings and our on-premises capabilities.

Cloud Exchange

Last year, I spoke about the need to create a 'cloud exchange' at the IC level to enable the exchange of data between the C2E cloud offerings in a frictionless and performant manner. However, as I indicated earlier, each IC organization has unique needs, and an IC-level cloud exchange is not desirable at this time. Instead, the NRO is building a cloud exchange for our own use. This will create an optimum network path between the C2E cloud offerings and our on-premises capabilities, making our use of any of them frictionless and performant.

Remote Locations

We still have a remote location problem. In our remote locations, we have the requirement to be able to operate (perhaps in a degraded mode) autonomously. While we can improve communications lines to increase bandwidth and reduce latency to these remote locations, we must also plan for the event that our communications lines are completely cut off. The C2E vendor offerings, to date, do not have robust offerings that will address this requirement – we need better options.

New Data Centers

As I indicated earlier, we will always have a need for on-premises capabilities - not all applications are cloud-centric due to any number of engineering or cost factors. To satisfy that need, and to get out of aging data centers, the NRO is building multiple new data centers that will meet modern data center specifications and provide the ability to run the data and power-hungry applications of the future.

Artificial intelligence

I spoke earlier that the C2E cloud offerings have limited GPUs, TPUs, and AI tools/models available today. To address the immediate need for AI research and prototyping at the NRO, we are creating a research and development environment that will consist of hundreds of GPUs. This will allow us to train models and ground them in our mission. Eventually, these models will be used for operational inferencing, and it is our intention to run them in C2E once the needed AI capabilities are available there.

?

In closing, I believe it has been a productive (albeit slow) year in advancing the goal of using C2E to help build mission capabilities. The future of C2E is bright and I look forward to seeing how the IC creates mission advantage at the speed of cloud!