For government agencies, the next stage in their journey to the cloud is to learn to think like cloud natives.
Specifically, they need to think in terms of cloud-native development — moving away from big, monolithic software projects to smaller applications or even microservices that can be developed, tested and fielded using Agile methodologies. Cloud-native development also usually takes advantage of containerization, an approach that makes it easy to port software from one platform to another.
The government’s traditional approach to software “really isn’t agile in meeting customer demands,” said Chezian Sivagnanam, Chief Enterprise Architect at the National Science Foundation (NSF), speaking on a panel during the “Gov’s IT Evolution Virtual Summit.”
NSF began shifting to Agile development about five years ago. In part, the transition has been driven by NSF’s internal customers, who grew impatient with the government’s traditional development processes, in which it could take months or longer to get from requirements to delivery.
“After we have a meeting with our customers, we need to show them something concrete in a short amount of time, maybe weeks,” Sivagnanam said.
One advantage of cloud-native development is the opportunity to identify problems quickly, said David Cohn, Cloud Native Development Lead for North American Public Sector at Red Hat.
In traditional development, the long, drawn-out processes mean that developers can spend months working on a program before discovering, when stakeholders finally get involved, that it has missed the mark.
In cloud-native development, on the other hand, stakeholders are involved from the beginning of the process, and they get a chance to see incremental results in a short amount of time. If something is wrong, developers can change course quickly.
“It’s like the old adage, ‘Fail fast, and learn from failing,'” Cohn said. “You should be able to do the same with application development.”
Of course, government agencies generally do not like to think about failing — fast or otherwise. That’s one of the challenges with cloud-native development: It requires a big change in mindset.
For example, the rapid, iterative approach of cloud-native development requires a steady flow of funding, which needs to be reflected in the budget, Sivagnanam said. So stakeholder buy-in is essential.
You also need to get buy-in from your internal customers, he said. In principle, they might like the idea of having input throughout the development process, but in practice, that means they need to sit through a lot of meetings.
Cloud-native development also represents a big change for developers, Cohn said. It might make sense to take a monolithic application and break it apart into smaller services, “but how do you train developers to work this way?” he said. “How do you find talent?”
Many agencies would benefit from finding a trusted partner who has experience in this work, he said.
Both Sivagnanam and Cohn urged agencies to take an incremental approach to moving to cloud-native development, rather than trying to change everything at once. This makes it easier to work out the new processes and to get buy-in from everyone involved.
“Don’t try to boil the ocean,” Cohn said.
If you want to attend sessions like this one at future virtual summits, pre-register today!
This virtual summit was brought to you by:
