This was my final post on the Government technology blog
The government technology landscape has shifted significantly since we made our commitment to Cloud First nearly 4 years ago. Departments have become more mature in their uptake of cloud services and with this maturity comes a need for further guidance. To support this need, we’ve added further clarification to our cloud guidance and policy and we’ll continue to expand this content in the coming months.
From Cloud First to Cloud Native
While working on the new guidance, internally we’ve begun to move away from the phrase “Cloud First” and instead begin to think in terms of “Cloud Native.” Cloud First is the policy we’ve agreed, but it’s not our aspiration.
Cloud Native is one of those terms that has a lot of different definitions, with the more narrow definition encompassing patterns for application design, deployment and operation. We use the term more broadly to include the flexible adoption of Software as a Service (SaaS) applications, which are often loosely coupled and quite task specific.
Cloud Native is not just about considering cloud before other options, it’s about adapting how we organise our work to really take advantage of what’s on offer and what’s emerging.
The need to take advantage of new cloud developments
As the world of cloud technologies continues to accelerate, we should absorb new developments into how we work. Leading organisations are rapidly embracing new tools like “serverless” computing. Some are also investing more in retraining staff so they can get to grips with these new opportunities. We need to make sure the government keeps pace.
At the infrastructure and application level we should expect our applications to be resilient, flexible and API-driven. We should have the tools and practices in place to manage and secure a distributed range of tools accessed over the internet.
We should empower everyone in an organisation to help us become more effective in technology by letting any staff member trial new SaaS applications. Our management and security practices should support this approach. We should look for an API-centric approach that will let us easily integrate new SaaS applications into the rest of our architectures.
A decade of industry growth in the public cloud, and nearly 4 years of our Cloud First approach have given us examples of teams or organisations doing these things, often within government. We need to make them our default. For example DWP Digital has moved telephony to a cloud based service, with nothing in the offices except a phone and a wide area network connection.
Unless we adapt how we adopt technologies and focus on core outcomes and principles we won’t be able to meet the growing expectations of our users’ (including our staff), and we won’t be preparing for even deeper changes that are likely to come as we deal with ever growing volumes of data, and a proliferation of devices and sensors.
What Cloud Native means for government architecture
To become Cloud Native, we need to focus on the digital outcomes we need and how to achieve them. It’s with this focus, for instance, that the National Cyber Security Centre produced the Cloud Security Principles and some guidance on protecting bulk personal data. But in the remit of security, we still have work to do in getting a better understanding of what different providers offer and where we place our trust.
To truly become cloud native, we need to transform how we monitor and manage distributed systems to include ever more diverse applications. We need to deepen our conversations with vendors about the standards that will help us manage these types of technology shifts. We need to continue to ensure we always choose cloud providers that fit our needs, rather than basing our choices on recommendations.
Over the coming weeks we’ll be blogging more about what this means in practice, and GDS will be hiring a new Chief Technical Architect to take forward this work. If you work for government, we’d like to hear your thoughts on what cloud native means to you.
James tweets from @jystewart.