-
Notifications
You must be signed in to change notification settings - Fork 0
dft street manager spike 0010 hosting
The purpose of this spike is to compare hosting providers based on our knowledge of project requirements and DfT preferences to draw a conclusion we can present to DfT for Beta hosting. It does not cover Alpha.
See Service Needs page for a more detailed list of currently-understood service needs.
- Service portability is an important consideration
- Data residency - UK:london (or potentially EU:dublin) region
- Single region, but multi-zone (eg eu-west-2a, eu-west-2b, eu-west-2c)
- A persistent, managed relational datastore (preferably PostgreSQL; assume 3TB)
- Persistent, mid/high-tier block storage (eg EBS; assume 600GB)
- Object storage (eg S3; assume 0.5TB)
- Slow object (eg Glacier; assume 5TB)
- Data transfer out (assume 500GB/month)
- Atleast 1 external load-balancer, atleast 2 internal load-balancers
- High/low network separation (eg a means to expose a frontend to the public, but ensure the API/DB stays private)
- A robust-but-simple, fully automated CI/CD pipeline.
-
DfT Preferences:
- DfT preference is SaaS over PaaS over IaaS (we should aim to avoid VMs)
- Mainstream tech choices
- Solution should be portable
-
Costings are for provider comparison only, NOT proposed project costing (may feed into this later)
-
IaaS costings should be based on an assumed solution, consisting of:
- Three load-balancers (one external, two internal - probably makes no difference for costing purposes)
- Two instances of a single Web application (2core, 4GB RAM)
- Two instances of a single API application (2core, 4GB RAM)
- Two instances of a mapping application service (2core, 4GB RAM)
- Fully-managed DB instance with HA redundancy/replication (eg Postgres RDS; 2cores, 8GB RAM, 2.5TB storage)
- Block storage of 600GB, medium/high-tier (eg EBS)
- Fast blob object storage of 0.5TB (eg S3)
- Slow blob object storage of 5TB (eg Glacier)
- 500GB/month data transfer out
- Single region, but multi-zone
- Use on-demand monthly pricing for now - we'll also cost price reserved instances, but later
- See evaluation spreadsheet for evaluation criteria.
The provider evaluation worksheet is available within the google shared drive: https://docs.google.com/spreadsheets/d/1KtiZccLLgMs9Bb1ozlITqvZGm9QdT-6KFpa6C1D6pTE/edit?usp=sharing
Offers a Standard environment and a Flexible Environment, Standard offers better scalability but more constraints (more detail here).
- Python 2.7, 3.6
- Java 8
- Node.js
- Go 1.8
- Ruby
- PHP 5.6,7
- .NET
- Custom runtimes
- Python 2.7
- Java 7,8
- PHP 5.5
- Go 1.6
Amazon PaaS service.
- PHP
- Java
- Python
- Ruby
- Node.js
- .NET
- Go
- Docker
Amazons serverless computing offering for on demand usage.
- Node.js
- Java
- .NET C#
- Python
Azure PaaS offering.
- .NET
- Node.js
- PHP
- Java
- Python
- Static HTML
Azure serverless on demand computing.
- .NET C#,F#
- Node.js
GDS managed PaaS using CloudFoundry.
- Go
- Node.js
- Java (and other JVM-based languages such as Scala)
- PHP
- Python
- Ruby
- Static HTML/CSS/Javascript site
- A compiled binary
- Docker images (limited support)
The programming languages we use in the application may be restricted by the hosting choice, affecting our decision. Ideally we want to use one or two languages maximum, and due to the client side mapping requirements we will need significant Javascript on the front end. DfT have not mandated a language choice.
Main common languages supported by PaaS offerings are Java, Node.js and Python (excluding PHP).
Frameworks: Dropwizard, Spring boot, Play
Advantages:
- Popular and well known
- Many libraries (including Geo)
- Static typed and pre-compiled, easy to test and automate finding issues/lint problems
Disadvantages:
- Heavy JVM, not good for FaaS
Frameworks: Express, Koa, Sails
Advantages:
- Quick and easy to pick up
- Javascript, so would allow single language for client/web/api code across stack
Disadvantages:
- Dynamic typed and runtime compiled, errors only found at runtime
Frameworks: Flask
Advantages:
- Used by Land Registry (note: code re-use may not be possible as they are not open source)
Disadvantages:
- Dynamic typed and runtime compiled, errors only found at runtime
- Node JS - pure Javascript stack, using Express JS for both web and api applications. Has the advantage of easy integration with GDS resources and style guide, single language. Potential issues around the dynamically typed language and lack of OOB metrics offerings. Example Node SOAP API here
- Node JS Web and Java Dropwizard/Spring Boot API - Javascript on the frontend, Java on the backend. Good access to GDS resources via Node, uses Java for the more complex logic with static typing and access to all Java libraries. Issues around using multiple main languages (complexity and deployment). Note there is a requirement to support SOAP endpoints for legacy messages which Spring Boot is a better fit than Dropwizard, example code here
- Java play/dropwizard/spring boot - pure Java stack, using one or more frameworks (e.g. Play for frontend, Dropwizard for API). Only Javascript for client side mapping. Good static typing, metrics, testing and library access, lots of experience in team and company in developing and deploying Java applications. Issues around using GDS resources (GDS templates for play out of date and dropwizard for UI is clunky).
- Python - pure Python flask stack. Only Javascript for client side mapping. Advantage is this is the same stack as Land Registry. Potential issues around the dynamically typed language and lack of OOB metrics offerings