The cloud represents a revolutionary change. Not just in how the Department of Defense conducts its ordinary operations at home, but also in how it supports our warfighters and front-line decision-makers abroad.
In 2013, the CIA was the first Federal agency to take the plunge into the cloud, signing on with AWS as part of the Commercial Cloud Services contract. Since then, DoD and the Federal government have been quick to jump on the cloud bandwagon at a policy level. Some agencies within the DOD have already committed to a cloud-first strategy, even.
This well-intentioned, but in all likeliness, rushed effort to exploit the cloud has led to one problem that is evident in many cases across the DoD: many organizations see the cloud as the overall solution to all of their problems, exacerbating the problem they’re looking to solve.
We must be purposeful and deliberate in architecting DoD cloud environments and internal approaches to technology to ensure that cloud resources are successfully integrated with on-prem resources. Technology advocates across the DoD also need to examine the unique infrastructure requirements of the cloud to ensure that they can take full-advantage of the powerful new environments they’re building.
Otherwise, different agencies and commands across the DoD will struggle to fully leverage the flexibility and scalability of the cloud. That’s the case with these first adopters, who now have to integrate stovepiped workloads and applications across their nascent cloud environments while ensuring those cloud environments work well with existing on-prem resources.
What happens to aimless first adopters
Before we discuss the route forward and potential solutions to this problem, it is first important to explore in greater detail why a well-intentioned rush to the cloud is problematic.
In an attempt to quickly operationalize the cloud-first strategy, many DoD agencies pushed workloads to the cloud through an ad hoc, “lift and shift” approach. There were many different reasons that different elements within the DoD employed this strategy, such as a need for more resiliency in their network infrastructure or a desire to move in a new direction to better support the warfighter. Yet by acting so quickly, these early adopters are now paying the technical and cultural price that comes with moving first.
The cultural consequences have been staggering. Assuming a “lift and shift” went smoothly (not all did), many early adopters discovered internal processes could not keep up with the rapid spinning up and spinning down of cloud resources. In some instances, frustrated developers circumvented those antiquated processes to provision resources on their own timeline – a phenomenon known as “shadow IT”.
The rapid move to the cloud also meant that many network operations shops had to add cloud support to their already long list of responsibilities. When this team undertook the responsibility of stitching the cloud onto existing network infrastructure, the much-needed transformation from traditional, data center-centric mindset to DevSecOps approach stalled.
There were also significant technical consequences. In addition to shadow IT, there were cases of IP address sprawl. Developers would request significant resources for their applications, and network teams would have no visibility over what resources were actually being used by the application.
The “lift and shift” approach also gave way to the duplication of silos and fragmentation straight into the cloud. Rather than having infrastructures and workloads that could actually exploit the cloud’s full value, these organizations simply replicated their on-prem issues in a cloud environment. This lack of cohesive control by NetOps teams created chokepoints and headaches that made the cloud more difficult to use. This, in turn, negated the adaptability and flexibility that were supposed to be the primary benefits of the cloud.
How to leverage the cloud with intentionality
Organizations need to ensure they are working with the end goal in mind. That means not prescribing solutions in search of a problem, but instead building on a set of requirements that are designed to take the network to the next level.
Just as culture and technology suffered significantly in the wake of this race to the cloud, they can be leveraged to solve for the impacts.
Suggestions grounded in culture
Culturally, we need to move from merely proclaiming DevSecOps as the new standard to actually implementing strategic ideas in a way that meaningfully engages the numerous stakeholders involved. Network operations teams, DevOps teams, cloud teams, and security teams all need to work together to share ideas and think cross-functionally across the organization. Objectives of units like Kessel Run, Bespin, Kobayashi Maru, and others across DoD, can be used as a North Star.
Frankly, many NetOps and management processes also need to be re-worked to ensure development occurs in an accelerated and streamlined way. That way, developers get the resources that they need when they need them, cutting down on development timelines and improving continuous integration and continuous delivery metrics. Not only does this help the organization move faster, it also helps to cut down on the prevalence of shadow IT.
Suggestions grounded in technology
From a technology standpoint, the DoD must make a concerted effort to ascertain the requirements of the cloud environments and the desired future state before migrations actually start. This will ensure that cloud architectures can integrate seamlessly with existing on-prem networks. In particular, DoD agencies must look at the way that their applications consume and process data, and what that means for the cloud and network architecture. They must ensure that their networks are indeed “cloud ready.”
One of the chief drivers of this move to the cloud is the stated goal on the part of DoD leadership to move data closer to the tactical edge. The intent of this move is to allow for better tactical decision-making by the warfighter and front-line leadership. As with other cloud workloads, the devil is in the details. How will those environments be architected relative to domestic networks and cloud environments? How will application development infrastructures interface and interact with these tactical clouds to ensure seamless deployment of applications and updates to forward deployed forces? These questions must be fleshed out as part of the on-going experiments through the Advanced Battle Management System (ABMS) and the broader Joint All Domain Command and Control (JADC2) initiative.
Finally, at the intersection of culture and technology lies automation. We must ensure that organizations adjust their culture and processes to allow DevOps and cloud teams to move quickly. We should leverage automation to the maximum extent possible, freeing our engineers and architects to think about big problems and ask big questions, rather than engage in rote and manual daily tasks.
All of these ideas have been espoused at different levels in the DoD, yet concrete action remains disjointed and siloed across the enterprise. The time has come to share ideas and approach the cloud in a more holistic way than DoD has before. This requires leadership and engagement with industry to revolutionize the traditional DoD approach to network operations across the enterprise to realize the full potential of cloud for the warfighter.
The most important thing is that we continue to collaborate– industry and the DoD writ large – to share ideas and best practices so that we ensure that our cloud, our network is ready for the future fight.
Kelly McCormick is director of U.S. Defense and Intelligence at BlueCat.