Standardisation improves collaboration

The evolution of cloud computing has also catalysed a parallel evolution in software architecture – the progressive disaggregation of applications into smaller components or building blocks. The inherent qualities of mainframe servers were naturally compatible with monolithic application designs and architectures, where the entirety of an application’s coding was packaged and run as a single unit.

Distributed client-server systems and browser-based web applications started the process of applications being broken down in modular architectures that split functionalities across elements. Cloud platforms like AWS that originally only offered data storage and computational power started to introduce what has become a broad ecosystem of services, from managed database and analytics services to container runtime environment and serverless functions.

The fact that a cloud environment escapes the complexities added by differences in hardware and operating systems makes this standardisation possible.

At the same time, code frameworks and libraries, such as the popular JavaScript examples of Angular and React, gained traction. Code frameworks and libraries also standardise chunks or modules of code for common user-facing functionalities.

The result has been increasing granularisation of applications on both the front and back-end. And these small blocks have been standardised, much like Lego. Granular enough to allow for them to be put together in a myriad of different ways to achieve the desired end result.

It is key to adopt standardisation in software development, and the option to give colleagues direct access to a cloud environment where work is being done, means team members can share their work and support each other far more efficiently.

This quality of cloud development has led to new and improved forms of collaboration between development teams. It has gone a long way towards paving the way for DevOps – the unification of development, testing and operations as a single team with the same end goal – reliable, highly available and high-quality software that delivers for the workforce, patient or citizen.

Cloud, and especially cloud-native development, helps foster a DevOps approach to software development. Developing in the cloud, for the cloud means that a similar environment will be used across the lifecycle of an application, from development and integration to testing, deployment and production. This helps reduce the number of bugs and other issues that can reveal themselves in production and fosters a DevOps culture.

Cloud and cloud-native development don’t necessitate a DevOps approach. And not every DevOps organisation or software development teams that work to less formalised DevOps methodologies and principles only build cloud-first software. However, cloud development and DevOps processes are a natural alliance.

Sticking to DevOps principles and methodologies is made easier by the standardisation of cloud services and unification of development, testing and operations environments. And, likewise, cloud-native development benefits from standardised, repeatable and automated DevOps processes that shorten deployment cycles as part of a CI/CD pipeline.

Measuring the performance of a DevOps initiative is key to understanding both the benefits and where there are strengths/weaknesses. Substantial research has been carried out by the DevOps Research and Assessment (DORA) report, state of DevOps 2021. Through six years of research it has identified four key metrics that indicate the performance of a software development team: 

• deployment Frequency — How often an organisation successfully releases to production
• lead time for changes — The amount of time it takes a commit to get into production
• change failure rate — The percentage of deployments causing a failure in production
• time to restore service — How long it takes an organisation to recover from a failure in production.

You can apply these practices using any of the public clouds.

For any service to be put in front of the healthcare workforce, citizens and patients, it has to meet the Digital Service Standard by the UK Government Digital Service, a set of 18 criteria that have to be considered.

One of the criteria is that all new source code is made open and published under an open-source licence.

This goes hand in hand with the UK Government Digital Service tenth design principle: make things open: it makes things better. If you encourage teams to code it is open and thus easier to work on it with others. You don't need to give them special access or make complicated business arrangements.

This is enabled by using cloud-based code repository services such as GitHub and Gitlab that offer free service packages to host code and provide the means for code to be commented upon and open-sourced.

Each organisation must publish its code in the open including any infrastructure as code but must not include any sensitive details within their code such as personally identifiable information, usernames, and passwords, or IP addresses.

Infrastructure as Code (IaC) is the management of infrastructure (networks, virtual machines, load balancers, and connection topology) in a descriptive model, using the same versioning as the DevOps team uses for source code. In a similar way to the principle that the same source code generates the same binary, an IaC model generates the same environment every time it is applied. IaC is a key DevOps practice and is used in conjunction with continuous delivery.

Infrastructure as Code enables DevOps teams to test applications in production-like environments early in the development cycle. These teams expect to deliver multiple test environments reliably and on-demand. Infrastructure represented as code can also be validated and tested to prevent common deployment issues. At the same time, the cloud dynamically provisions and tears down environments based on IaC definitions.

Teams who implement IaC can deliver stable environments rapidly and at scale. Teams avoid manual configuration of environments and enforce consistency by representing the desired state of their environments via code. Infrastructure deployments with IaC are repeatable and prevent runtime issues caused by configuration drift or missing dependencies. DevOps teams can work together with a unified set of practices and tools to deliver applications and their supporting infrastructure rapidly, reliably, and at scale. The use of Infrastructure as code is strongly encouraged with cloud-agnostic IaC languages preferred such as Terraform or Ansible. However, in some cases it may be preferred to use a cloud vendor IaC cloud software development kit such as AWS cloud formation or Azure PowerShell if the agnostic provider doesn't have the feature available, but you may need to migrate this code over once the feature is available.

Quality assurance in software testing is defined as a procedure to ensure the quality of software products or services provided to the customers by an organisation. Quality assurance focuses on improving the software development process and making it efficient and effective as per the quality standards defined for software products. Quality Assurance is often known as QA Testing.

At a high level, we need to make the distinction between manual and automated tests.

Manual testing is done in person, by clicking through the application or interacting with the software and APIs with the appropriate tooling. This often requires someone to set up an environment and execute the tests themselves, and it can be prone to human error as the tester might make typos or omit steps in the test script.

Automated tests, on the other hand, are performed by a machine that executes a test script that has been written in advance. These tests can vary a lot in complexity, from checking a single method in a class to making sure that performing a sequence of complex actions in the UI leads to the same results. It's much more robust and reliable than automated tests – but the quality of your automated tests depends on how well your test scripts have been written.

As a part of the delivery of a cloud application, both automated and none automated testing should be carried out to provide confidence that a service will provide high levels of confidence the service will meet availability needs for the NHS workforce, citizens, and patients.

These tests include:

• application Acceptance testing (functional and non-functional)
• security testing (penetration and vulnerability)
• performance testing (load testing and failover testing)

Application acceptance tests are formal tests executed to verify if a system satisfies its business requirements. They require the entire application to be up and running and focus on replicating user behaviours.

Security testing

Your security test or IT Health Check should aim to provide assurance that your organisation’s external and internal systems are protected from unauthorised access or change, and they do not provide an unauthorised entry point into systems that consume your or others' services.

The services that are hosted within the cloud should be tested to provide further assurance that no significant weaknesses exist on the network interfaces, management dashboard access, or via the service that is hosted within the cloud that could allow one service to intentionally or unintentionally impact the security of another.

Performance testing

Performance tests check the behaviours of the system when it is under significant load. These tests are non-functional and can have various forms to understand the reliability, stability, and availability of the platform. For instance, a test could be observing response times when executing a high number of requests or seeing how the system behaves with a significant load of data.

Performance tests are by their nature quite complex to implement and run, but they can help you understand if new changes are going to degrade your system.