NHS Cloud principles

(Be part of the revolution with cloud)

Design your service to fit your cloud deployment type (IaaS, PaaS, FaaS or SaaS), do not try to heavily modify the cloud infrastructure to fit the needs that an on-premise infrastructure requires as this will lead to a sub-standard and inefficient platform. The Cloud can create improvements in service performance, scalability, agility (ease of change), cost reduction, and security. However, you must architect services for the cloud to obtain these benefits.

(Private networks create barriers to people whom need you the most)

Where external connectivity is required to connect your service to another using an internet connection by default will provide more accessibility and operability. As an internet connection can reach a wider audience and can be much more cost efficient and flexible than a private network. All Internet connectivity will require a security perimeter being in place which will include a firewall with a default of implicit deny on all ports unless opened to gained access to service. Monitoring of inbound and outbound connections and audit logging of access to the platform is required by default for security and optimisation insights, and where required DoS protection will need to be in-place for national services or local services which have a public interest.

(Defence, it's everyone's responsibility)

Designing services in the cloud and building with the NCSC 14 cloud security first principles is a must to cover all principal security concerns. Using specialist skills and capabilities that can be provided by security architects and also using managed cloud security services are a must. Your cloud hosted service architecture must be based on a clearly defined security architecture that implemented a defence in depth architecture and is proportionate to the risks and must be reviewed and proven using penetration testing carried out by a CHECK approved provider at key project milestones. Automated security testing should be built into your software release cycle using secure DevOps practices.

(Get smarter and faster within the cloud)

Cloud enables automation of a number of events, improving both your system’s stability and the efficiency of your organisation. Where possible Automated Everywhere within your cloud hosted solution from deployments using CICD tooling which brings together Infrastructure as Code (IaC) for creating hosting environments and deploying infrastructure changes including security policies and access, GIT for source code management and deployment pipelines (branching, merging, version control), automated functional, none functional and security testing (including vulnerability, and when confident chaos testing) to automated and auto scaling to meet the demands being placed on the service. Allowing this to happen allows more time for development and improvements on the service and lowers the resource allocation required for operational activities.

(Allow small changes to not impact big systems)

Cloud services should ideally be designed in a way that reduces inter-dependencies. The components within your solution need to be loosely coupled to avoid changes or failure in one of the components from affecting others. Loose coupling between services can also be done through asynchronous integration. It involves one component that generates events and another that consumes them. The two components do not integrate through direct point-to-point interaction, but usually through an intermediate durable storage or API gateway layer. This approach decouples the two components and introduces additional resiliency. So, for example, if a process that is reading messages from the queue fails, messages can still be added to the queue to be processed when the system recovers.

(Favour managed services, scalability and flexibility and don't sweat the small stuff)

Cloud cost optimisation will be a re-occurring activity and is the process of reducing your overall cloud spend by identifying mismanaged resources, eliminating waste, and reserving capacity for higher discounts. As services constantly evolve it is key to constantly record metrics including time series to allow informed decisions around cost efficiencies and planning of scaling activities based off historic events, trends and future predictions while also making sure that your service right sizing computing services to scale when required.

(Everyone within your business needs to know about the cloud revolution, grow our own and reap the rewards)

Cloud can mean significant changes in culture within an organisation for commercial, financial and not just technical staff. This new cultural approach should not affect the overall IT organisation, but it will require a substantial transformation of the operations department. It must be more independent in planning and spending capabilities. More people skilled on provider management, as well as capable in architectural cloud service integration, will be required. The capability to manage a hybrid environment will be essential to avoid an internal siloed model and the consequent wasting of resources. Providing training or up-skilling plans for resources throughout the organisation, allowing people time to attend training, is a key part to allowing the NHS to adopt and grow cloud technologies and complementing methodologies.

(Be part of the community for sharing ideas, design and concerns… sharing is caring)

Creating, contributing and attending communities of practices around cloud technologies and methodologies. Allowing the collaboration of the organisations people whom work around cloud technologies with other groups of people who have a common interest in a specific cloud technology or business domain is key to allow for cross collaboration of Ideas, learnings and knowledge. Allowing people within your organisation to collaborate regularly to share information, improve their skills, and actively work on advancing the general knowledge of the domain is key in adopting cloud and not falling into pitfalls that have already happened with other NHS and healthcare organisations and reducing the duplication of effort when designing, building and operating cloud based systems. A by-product of this is allowing subject matter experts to cross pollenate organisations to allow best practice to be adopted and share key learnings.

(If you like it, put a label on it)

The importance of cloud tagging is increasing. Considering that more and more NHS and healthcare organisations rely on cloud services, this doesn’t come as a surprise. While the cloud offers many advantages, it has also introduced new challenges within multiple cloud provider accounts or multiple cloud provider environments get easily complex, and many organisations struggle with getting visibility into their distributed cloud environment. In order to overcome these obstacles, NHS and healthcare organisations must implement effective cloud tagging policies. These may include standardising naming and cloud tagging conventions for your cloud resources to understand its reason for being provisioned and the associated meta data around the cloud resource which may include environment type (dev, test, production), service name, and creator details to name a few. You can't over tag your cloud resources.

(Migrate, adopt, native, repeat..)

Migration of your infrastructure to the cloud is only the first step and not the end product within the NHS and healthcare adoption cloud adoption framework. Cloud technologies are forever evolving and cloud technologies are being released on a daily basis. Organisations need to use the cloud platforms, services and technologies as a platform to become cloud native with the benefit of consuming rather than building and maintaining services. Over time your services which you build will become commoditised and your cloud services must be continually re-assessed to see where efficiencies can be made as new technologies can be bought rather than built as they get released by the cloud service providers.

(It's ok to lock in but don't get locked out..)

Due to the vast nature of cloud services, there are many policies, procedures and options that limit the way that underlying cloud providers and services are adopted. As a result, solutions that are hosted within the cloud can become over complicated to build and complex to maintain and as a result become inefficient. One of these areas that offers a lot of miss guidance is vendor lock-in with solutions having to adopt an additional layer of abstraction from the cloud service provider to offer a means to migrate. Understanding the level of vendor lock in and creating an exit strategy from a cloud service is a must. This is because it's ok to use a particular cloud vendor’s native capabilities as long as you are aware of the risks involved and how to migrate to another provider.