While offering a service or solution that still operates on-premise, on bare metal may seem as archaic and old-school as inserting a CD into a stereo to listen to music, it’s still quite common. Especially in the public sector, where many government solution providers have eschewed moving their on-premise solutions to the cloud because they either haven’t needed to yet, or are waiting to see if cloud was simply a passing fad.
At this point, it’s safe to say that the cloud is here to stay in the government. And there’s a good chance that even those solution providers that haven’t yet felt the demand signal to move their solutions to the cloud may start to feel some pain if they don’t plan to do so soon. But where do they get started? And what does moving an architecture or solution to the cloud entail?
A new service from DLT called Cloud Navigator helps solution providers find the answers to those questions. We recently sat down with the CTO of DLT, David Blankenhorn, to learn more about why solution providers should plot a course to the cloud, how they can get started, and how Cloud Navigator can help.
Here is what he told us:
GovDevSecOpsHub (GDSOH): From a priority and investment standpoint, just how important is the cloud to government agencies today? What different kinds of cloud solutions and services are government agencies investing in right now?
David Blankenhorn: If you look across today’s federal civilian government and military, you’ll see that there are multiple billion-dollar cloud contracts out there – such as DEOS, C2S, C2E, the follow-on to the JEDI contract, and the DHS IT management contract which also included cloud and cloud migration. There are also a few more billion-dollar contracts upcoming. These contracts, alone, are evidence that cloud adoption has graduated from fringe to mainstream.
What kind of cloud services and solutions are being adopted? We’re seeing all different cloud solutions getting embraced across the government, from Infrastructure as a Service (IaaS), to Platform as a Service (PaaS), to Software as a Service (SaaS).
Of those, IaaS is dominant. But with COVID-19, we’re seeing acceleration in SaaS and PaaS adoption. PaaS has terrific growth potential right now in the government as agencies start focusing on multi-cloud environments and portability. PaaS offers tremendous portability.
This is actually why we’re seeing so many impressive DevSecOps programs in the military where they’re leveraging PaaS for development and portability. Using PaaS and a DevSecOps approach to development not only increases the portability, but also the security of their applications.
Multi-cloud is most likely going to be the greatest opportunity and greatest challenge for the public sector. As you begin to adopt multi-cloud, the complexity of the environment begins to compound. Agencies need to think about how they will develop, secure and operate in multi-cloud environments.
Agencies are already challenged with implementing Zero Trust models in their on-premise and legacy environments. They’re going to want to be able to deploy Zero Trust across all of their environments, not just on-premise. They need to answer difficult questions about how they’re going to implement Zero Trust, manage and monitor these multiple environments.
Having different workloads in different environments – some virtualized and some on bare metal – makes management more difficult and complex. Solution providers that can aid agencies with these challenges will be well-positioned in the market moving forward.
GDSOH: Have all government solution providers followed this demand signal and developed cloud solutions? What are they risking by not keeping up with massive movement to the cloud?
David Blankenhorn: Not yet. Not all government solution providers have followed that demand signal. Some have been in “wait and see” mode, or they have been fortunate enough to offer solutions in areas of the IT stack that haven’t been affected yet. They’ve had the luxury to sit back and see how things settled out.
However, the IT landscape is changing and even those in the relatively protected IT niches need to figure out how they can integrate with the cloud and multi-cloud environments. They’re not going to be able to continue to operate in a vacuum. They’re going to need to start to operate with cloud platforms, data sources, security platforms, and cloud infrastructure.
“Cloud environments offer the unique ability to utilize Infrastructure as Code (IaC), the ability to programmatically assign or reassign assets, resources, and services dynamically through code. This is an incredibly powerful tool that developers can take advantage of as they begin to tease apart their tightly-coupled, on-premise architectures into a cloud environment.” – David Blankenhorn
Ultimately, their customers and end-users are increasingly adopting these cloud solutions, and their customers may ask them hard questions about how they interoperate and integrate with cloud platforms.
The risk that these companies face is that they may eventually be marginalized by solution providers that are taking the broader view. Even some of the larger companies have been forced by market dynamics to rework their strategies and incorporate these cloud technologies. That’s because they were losing business to smaller providers that were “born in the cloud.”
GDSOH: What would keep government solution providers from developing cloud solutions? What challenges are there?
David Blankenhorn: There are a number of obstacles. The most obvious is having the right technical skills, but it certainly doesn’t end there. This transition is more than just a technology change. The addition of cloud into a company’s portfolio also impacts the company finances, how it positions itself, and even how the company operates.
Transitioning to cloud services requires that companies transition from a model where they have large, lump-sum deals with rich margins to a different, monthly return model. And there are pros and cons there. The traditional model gives the company a lump sum of revenue upfront, which is great. But there’s also an advantage to the monthly recurring revenue model. While you may not be getting a lump sum of money upfront, you’re getting consistent monthly revenue over time that can make it easier, in the long run, to plan and grow the business.
That transition can be a real challenge coming out of the gate. And it impacts more than how revenue comes through the door. It has an impact on how billing occurs in arrears. Also, in this model, many of these new contract vehicles and even purchase orders may just become hunting licenses, which means that once the service provider wins the award, there is additional work to get that agency to use the cloud service so that the service provider can invoice and realize the revenue.
Aside from the actual transition, another challenge is just knowing where to start. Each cloud provider has its own unique partner program, and companies may not know where to engage with these programs. It isn’t always intuitive. And knowing which of these providers to align with based on their specific business model may not be intuitive either.
Finally, there are some solution providers that may be further along on their cloud journey, or be more “cloud fluent.” However, they may be looking for ways to take their business to the next level. They may be looking to expand their portfolio with a new or adjacent capability. Maybe they want to evolve from security to Big Data – introduce offerings in data security, data curation, or data analytics. Or maybe they just want to position themselves for a major contract or program.
It’s a spectrum – ranging from legacy providers to newer companies that were born into the cloud. Every company on that spectrum could have cloud questions or need assistance. That’s why we worked to make sure that the program that we developed – the Cloud Navigator program – gives them guidance no matter where they are on that spectrum.
Ultimately when it comes to the cloud, the shuttle hasn’t left the launchpad. They should hop on while they can.
GDSOH: DLT recently introduced something called Cloud Navigator that has a three-step process for solution providers that are looking to launch cloud solutions. What are those three steps? How does Cloud Navigator help them follow those steps?
David Blankenhorn: There are all sorts of pitfalls for solution providers regardless of where they are in their cloud journey. They need to understand where they are as a starting point, and they need a vision of what the destination might look like. As part of our Cloud Navigator program, we have developed a survey at CloudNavigator.com to establish the service provider’s starting point. The output from this survey serves as the baseline for the service provider’s current cloud readiness.
And that is essentially Step One, establishing a baseline and establishing a vision for their cloud practice. The second step is the flight plan. Once they have that vision, Cloud Navigator helps them take that vision and establish an actionable plan. It helps to point that provider towards their end cloud goals.
The flight plan that is generated by DLT is effectively Step Two, and provides the actual path providers can take to begin to execute on and grow their public sector cloud business.
Step Three involves following that flight plan, which includes active collaboration between DLT and the solution provider. Depending on where they’re starting, we’ll work with them through their flight plan and help them get started. This might mean working with them to make an introduction and begin a partnership with one or more of the cloud providers or creating detailed account plans for specific accounts or opportunities.
Depending on where they are with their cloud practice, we may help them with specialized training, support specialized account planning, or provide additional content that aids in the understanding and development of their cloud practices.
GDSOH: Creating a cloud solution often means porting a legacy, on-premise solution to a cloud-native application. What role can a DevOps and DevSecOps approach to application development play in making that process easier, faster, and more secure?
David Blankenhorn: For providers that have an on-premise architecture or solution, the default reaction is to simply forklift that existing architecture or solution onto a handful of virtual servers on a cloud provider’s platform. That often works, and it’s often the shortest path to getting the solution into the cloud.
But, ultimately, to increase scalability, efficiency, and reliability of the platform, they really need to take a cloud-native approach. That’s because there are some things that work on bare metal that don’t work in the cloud.
For example, high availability (HA) – having clusters and fail-overs in bare metal architectures – simply doesn’t exist in a cloud environment. HA is handled in a very different manner in IaaS and PaaS environments. You have to take a different approach, which changes the design patterns that need to be used.
While it may not be a terrible idea to just forklift that architecture or solution to the cloud initially, they will be missing out should they stop there and not re-architect their solution to be a cloud-native solution.
“…the IT landscape is changing and even those in the relatively protected IT niches need to figure out how they can integrate with the cloud and multi-cloud environments. They’re not going to be able to continue to operate in a vacuum. They’re going to need to start to operate with cloud platforms, data sources, security platforms, and cloud infrastructure.” – David Blankenhorn
Cloud environments offer the unique ability to utilize Infrastructure as Code (IaC), the ability to programmatically assign or reassign assets, resources, and services dynamically through code. This is an incredibly powerful tool that developers can take advantage of as they begin to tease apart their tightly-coupled, on-premise architectures into a cloud environment. This will give them greater scalability, greater efficiency, and greater reliability if they take advantage of the redundancy already built into these cloud platforms.
Also, taking a DevSecOps approach naturally dovetails into the IaC platform that the cloud providers are enabling. This allows for incredible flexibility as developers begin to reinterpret and redesign their solutions.
After the minimum-viable product has been launched, DevSecOps and IaC allow them to rapidly iterate, which is essential for customer experience and customer happiness. The providers can increase customer stickiness and customer intimacy by gaining better insight and understanding of the agencies they’re supporting and quickly incorporate unique features into their solutions.
If they choose to leverage a toolchain architecture like the DLT Secure Software Factory, they will also be able to integrate much more automated, interactive testing into the development process. This ensures that the code that is deployed not only meets the functional requirements but can scale to the cloud environment – with the right security in place. This is all integrated into the development process, allowing for the rapid deployment of new features and functionality, and even rapid roll-back in case a new version or feature doesn’t work as planned.
There is a huge upside to decoupling services from traditional vertically scaled, on-premise architectures and utilizing a DevSecOps approach by developing a new cloud-native version of an application. There is much more value to – and intimacy with – the customer, in the form of increased parity to customer needs and enhanced capability and functionality. It allows the provider to be better aligned and able to respond more quickly to the needs of the customer than the traditional waterfall approach to development which can take years to develop products and new features.
With that long of a gap between requirements and delivery, there could be a strong likelihood that the customer’s needs could change before the product is even delivered.
To get started on plotting a path to the cloud for your company, click HERE for DLT’s Cloud Navigator.