To ensure this contingency plan is possible, it is important to consider vendor and platform specific concepts and tooling. A range of providers use similar concepts and tools to abstract the platform/vendor specific APIs and provide a unified API to provision services, examples of these tools are listed below.
Example providers include
- Amazon Web Services (AWS)
- Google Cloud Platform (GCP)
- Microsoft Azure (Azure)
Example of open IaaS (Infrastructure as a Service) offerings (fully provider independent)
- OpenStack - Rackspace (https://www.openstack.org/marketplace/public-clouds/)
- Apache CloudStack (https://cloudstack.apache.org/)
Examples of abstraction tooling
- Terraform (https://www.terraform.io)
- Salt-Cloud (https://docs.saltstack.com/en/latest/topics/cloud/index.html)
- Libcloud (https://libcloud.apache.org/)
IaaS offerings have limited suitablility for contingency due to increased complexity in setup of the platform, their primary aim is to elimate all vendor lock-in, however in a contingency situation taking on some low risk vendor lock-in (eg managed Redis on AWS) would enable a faster completion of the contingency plan without significantly hindering further hosting moves afterwards.
As previously noted by GDS, AWS is highly suitable to fulfill short-term needs, this is an important factor in any contingency plan (https://gds.blog.gov.uk/2012/01/24/hosting-the-beta-of-gov-uk/). These points also apply to NICEs hosting requirements. Additionally AWS have had a significant head start on GCP and Azure and arguably have a more complete range of services and a larger community of resources and tooling. In the interests of simplicity the rest of the document will focus on moving to AWS as part of a contingency, while discounting any unique AWS components or services which we could not easily migrate to a new supplier.
NICEs requirements can then be considered in terms of the following components
- Compute
- Storage
- DNS
- Load balancing
Currently NICE make extensive use of manually custom configured compute instances.
Nearly all compute instances can be generalised to
- Web - nginx/iis
- Caching - memcached/redis
- Database - SQL Server/MySQL/RavenDB
- Search - FAST/Elasticsearch
These instances would all move cleanly to AWS EC2.
It is worth noting that AWS and Azure provide further levels of abstraction by offering managed services that include caching (Redis/memcached) and database (MS SQL Server/MySQL). While using these services potentially reduce portability, the managed aspect of these services do make them preferable.
Instances requiring additional configuration include
- Legacy NICE website
- Intranet
Due to the legacy nature of these services moving them will require exporting the VMWare image from Rackspace and importing them to a new provider. AWS support importing of VMWare images (https://aws.amazon.com/ec2/vm-import/).
Further information https://aws.amazon.com/ec2/
NICE does not currently make use of storage only services, however certain EC2 instances with low I/O requirements would make use of Elastic Block Storage (EBS).
Further information https://aws.amazon.com/ebs/
NICE manage nice.org.uk and various subdomains, particularly on the nhs.uk TLD. Currently NICE use GoDaddy for DNS which does not have a API. Making use of AWS Load Balancing services will likely require moving DNS to a provider with an API or AWS themselves.
Further information https://aws.amazon.com/route53/
Currently NICE are supplied vendor specific load balancing solution (F5 BigIP), vendor 'iRule' configuration is platform specific and not portable. This configuration would have to be translated to the new service providers configuration dsl, ideally through a unifed API for future portability. To increase portability in the future with either public clouds or custom setups, load balancers should be split and configured per service.
There are two options for load balancing
- Use provider specific managed services
- Use compute service to run custom load balancing software
Advantages
- Choice of software to perform load balancing Disadvantages
- Complex setup to achieve high availability
- More complex to support
Advantages
- Easier to manage
- Less chance of failure
- Easier to automate with unifed APIs Disvantages
- Generic service may lack useful features
While either option would provide a suitable service, a Elastic Load Balancing (ELB) service should be the first approach for speed and ease of setup. Where a more advanced solution is required a compute solution using HAProxy, NGINX or apache could used alongside ELB for specific services.
Octopus Deploy is currently hosted in the NICE Manchester offices and will continue to work as expected in the cloud. Automation of Tenticle installation, registration with Octopus Server and instance role configure will remove the need for any manual configuration.
Currently networking is pooled together for all services with 3 VLANS admin, dmz and data with Rackspace. When embracing the cloud and it's flexiblilty benefits, is worthwhile considering moving to a flat network or per service VLANs and instances. This removes networking dependency between services, allows services to be moved individually and finer grained firewalling to improve security per application/stack.
AWS can either support flat networking (provided as standard) with Security Groups for instance firewalling or VLAN based networking with Virtual Private Cloud (VPC) with Network ACLs or a mixture of both.
Amazon documentation provides a comparision between Security Groups and VPC Network ACLs http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html#VPC_Security_Comparison
Initially using one subnet and Security Groups to protect instances would allows for faster transfer of services without adversely affecting security compared to the current Rackspace VLAN setup.