The Pentagon’s brewing a build-a-cloud program for defense agencies

The Pentagon’s IT agency wants to make it easier for defense organizations to create their own cloud solutions. So it’s launching a program to demystify the process.

The program, called DOD Olympus, will serve as a ready-made kit for defense agencies to launch commercial cloud solutions without the hassle. 

There are a lot of elements that go into creating a usable cloud environment in which teams and organizations can share information seamlessly, said Korie Seville, the Defense Information Systems Agency’s deputy chief technology officer for compute.

“For a lot of organizations, especially organizations with a smaller IT staff, it's really difficult to just be handed a blank cloud environment and say, ‘Go!’” he said. “You have to deal with enterprise network connectivity, you have to deal with common services that are necessary for your servers to operate, there are security concerns, there's authorizations concerns. It's just really difficult for a customer to get off the ground quickly.”

And as the Pentagon’s appetite for data increases, Seville said there is a need for a solution that gives organizations the foundation to build their own clouds. 

“And so the intent of this is to support cloud services from the ground up. So we're basically providing that bedrock, we're providing an area for customers to deploy applications and resources without having to deal with all of the getting enterprise network connectivity, standing up common services, and really letting them focus on their mission,” said Seville, who is also DISA’s senior technical advisor.

The Olympus effort is only about a month old, but it isn’t the Defense Departments first managed cloud service. The military services all have their own flavor: the Air Force’s Cloud One, the Navy’s Flank Speed, and the eponymous cArmy. But other defense agencies, such as the Defense Health Agency, don’t have anything comparable yet. 

The military services have “gone so far as to natively integrate a lot of their services, common services and capabilities directly into their platforms, and it creates a really seamless experience,” Seville said. “The challenge has been for organizations that aren't aligned in those services, it's difficult” to use very tailored services that aren’t aligned with a military branch's needs. 

Olympus, an offshoot of the Joint Warfighting Cloud Capability contract vehicle, is designed to be a more service-agnostic alternative, with the option to bring your own tools or use what’s already there, like a built-in vulnerability management service. 

“We took our Olympus product and we natively integrated it with as many of our capabilities as possible. So for example, there's native integration with our [software development, or] DevSecOps platform, Vulcan. So a customer could theoretically use that service, use Vulcan together with Olympus to create the DevSecOps pipeline from end-to-end, from code development all the way to environment instantiation, and create their own DevSecOps platform right then and there. But it's not required,” Seville said.  

The platform is also already linked with DISA’s data centers, which can make it easier for an organization to create a custom hybrid cloud environment. One of Olympus’ pilot users has DISA’s private cloud offering, called Stratus, and is using the nascent platform to expand into commercial cloud offerings. And by stringing Stratus and Olympus together, Seville said “they'll be able to natively integrate two systems” and “communicate across their shared data if they need to and really get that easy button for hybrid cloud deployment.” 

That interconnectedness with DISA facilities can help get defense organizations up and running faster. 

“We've gotten a lot of interest from a lot of different organizations from across the department. So we're open to all and, for us, it's just trying to get some folks on to the beta so that we can really tweak the service as we build out and go to ‘market’ with a solution that is exactly where the customers are looking for, instead of having to deploy a solution and then tweak it after the fact,” Seville said. 

Since the program is very new, Defense One asked some technical questions to better understand just how soon a self-service cloud-in-a-can would be available across DOD. Here’s what Seville had to say: 

What are Olympus’ first pilot, or minimally viable, products?

We are starting with what we're calling our self-managed platform, that's what's going to MVP first. And the difference is around what the customer would be responsible for, versus what DISA would be responsible for. Obviously, in the managed platform, the customer will have less responsibility, but there will be a little bit more restriction on what is able to be done in that area. The self-managed infrastructure for us is the delivery of enterprise network connectivity and common services to our self-managed tenants. So basically, the customer would would have a tenant, whether they ordered from JWCC, or another area, they would have a cloud tenant, they would connect to our Olympus platform, we would provide them the enterprise connectivity back to to the NIPRnet [or Non-classified Internet Protocol Router Network], provide their perimeter security, and also provide them the common services that are sort of integrated into the platform. Things like domain name, system capabilities, network time, certificate validation, those types of things. But then also provide the native integration for the fee-for-service add ons [so] that they can add things like Vulcan and the vulnerability management service. 

Our [minimally viable product] is one cloud provider because our beta customer is in that cloud provider, and then we'll actually expand out based on customer demand. From a beta perspective, we have our beta capability, which they can go to our website at hacc dot mil to sign up to be a beta customer. And then based on that data list, that'll tell us where we need to expand from a cloud services perspective and from a cloud provider perspective to extend forward.

We'll be in one CSP to start. We’ll expand out to the others as customer demand dictates. And it'll be our network connectivity, boundary protection, and our basic suite of common services to start.

What will the beta customer experience be like?

Customers would log into their portal, they would basically [connect] on this platform, and then Olympus engineers and our operations team would work with the customer to onboard them, essentially onboard their infrastructure, so that they can take advantage of our security services, take advantage of our common services, and be integrated into the environment. And then for our fee for service, the customer during the onboarding process would have the option to say, ‘Hey, I'm gonna want Vulcan as part of my capability.’ 

This is an emerging capability. So what we want to do with the beta customers is work them through this process and gain feedback.  And ultimately, we're going to use that feedback to further refine the onboarding process so that when we do go to market, we have a really robust process that customers find it easy to move through. 

And then as far as experience wise, from the customer perspective, our broker team and our engineers are basically dedicated to helping customers get started in this capacity. So we have not only our engineers that can help, but customers also can opt in to utilizing some of our professional services staff to help them.

When will this come out of beta?

We are looking to get into beta at the end of the third quarter of this calendar year. I'd say fall of this year, we're looking to get our beta started or an MVP started. As far as getting out of beta, that is a timeline that is a little extended out. We are working on the funding model and the customer charge model for the service. So it'll be in beta until we figure out the cost model and get that switched over. But the firm timeline for going to beta, we're looking at in the third quarter calendar year '24.

Are there any limitations on where or who can use Olympus?

Any departmental resource or organization that wants to use the capability, we're more than welcome to work with. The limitation is going to come down to the limitations of public cloud. 

On the commercial cloud side, our pilot is starting in Azure, for example, as our first [cloud service provider]. So you're limited to the four regions that are available for that CSP within the government backbone. So it's not necessarily restricted to regions for the customer, it's restricted to regions or the available CSPs.

Is it for all classification levels?

We're starting at IL 5 [controlled but unclassified environment]. But we will look at customer demand and figure out if there is a desire to go to IL 6 [secret] or above. 

Does the platform use automation?

Yeah, automation is an integral part of Olympus. Even such that the platform itself is actually built almost exclusively as infrastructure-as-code managed by our Vulcan DevSecOps tool suite. We're a very ‘eat our own dog food’ organization, so we actually use Vulcan to deploy Olympus as the platform. We also take great pains to make sure that our common services platform is as serverless as possible. So we're really pushing for that infrastructure mutability and the ability to fully automate infrastructure management for our common services platform. 

For a customer service prospective, customers have the ability to utilize our DOD cloud infrastructure-as-code templates to get them started, if they're in a self-managed environment, and they actually have the ability to utilize Vulcan to deploy those infrastructure-as-code baselines to basically create their own managed environment, if you will. And then as our managed environment, or managed side of Olympus, becomes part of the roadmap and we start to iterate on that solution, there's a lot of automation and a lot of self-service built into that managed platform for customers to be able to basically just focus on their app, focus on their their mission, focus on their application, and let us take care of the infrastructure problem set. 

Any final thoughts?

We are really trying to walk away from that five year, 10 year plan set in stone. What's most important to us is that we're providing a solution that meets the needs of the warfighter. They know their mission better than we do. So we operate all of our products on an iterative development roadmap, and that requires feedback from our customers, which is why we're pushing really hard on beta testers. 

And we're not going to set that 10-year roadmap. That doesn't change when the mission changes. We have our Northstar. But outside of that, we are working with customers, working with the department to build a solution that meets the warfighter’s needs.