Skip to content

US Digital Services Playbook Play 9

Jump to bottom
mattkwong-kpmg edited this page Mar 3, 2017 · 9 revisions

#Play 9: Deploy in a Flexible Hosting Environment Our services should be deployed on flexible infrastructure, where resources can be provisioned in real-time to meet spikes in traffic and user demand. Our digital services are crippled when we host them in data centers that market themselves as “cloud hosting” but require us to manage and maintain hardware directly. This outdated practice wastes time, weakens our disaster recovery plans, and results in significantly higher costs. ##Checklist

  • 1. Resources are provisioned on demand

Not applicable for this prototype. On demand resource provisioning isn’t necessary for the prototype.

  • 2. Resources scale based on real-time user demand

Not applicable for this prototype. Scaling is not required for the prototype. We have, however, set up the services/application layer to be 100% stateless and deployed to load balanced nodes -- production utilizing 4 web tier nodes. This sets us up to implement dynamic horizontal scaling in the future without the need to modify application code.

  • 3. Resources are provisioned through an API

Not applicable for this prototype. It is tied to scaling and so is not necessary for this prototype. New builds of the application are, however, deployed as Docker containers via APIs.

  • 4. Resources are available in multiple regions

Multiple regions not deployed, but we have the capability to do so using Microsoft Azure.

  • 5. We only pay for resources we use

We only pay for the Virtual Machines which are running via Microsoft Azure.

  • 6. Static assets are served through a content delivery network

Not applicable for this prototype.

  • 7. Application is hosted on commodity hardware

The application is hosted on Microsoft Azure. It is deployed in the form of Docker containers that can run on any commodity hardware.

##Key Questions

  1. Where is your service hosted?

The application is hosted with Microsoft Azure.

  1. What hardware does your service use to run?

Using Microsoft Azure for IaaS, the hardware is managed by Microsoft.

  1. What is the demand or usage pattern for your service?

Not applicable for this prototype.

  1. What happens to your service when it experiences a surge in traffic or load?

The load balancer distributes requests across the stateless application servers

  1. How much capacity is available in your hosting environment?

Azure provides the capabilities to expand as needed.

  1. How long does it take you to provision a new resource, like an application server?

About 30 minutes. Our web application is package and ready to be loaded into docker as soon as it is running.

  1. How have you designed your service to scale based on demand?

Our current design utilizes load balancers and docker swarm. As requirements grow for the service, machines could be added or removed from the swarm.

  1. How are you paying for your hosting infrastructure (e.g., by the minute, hourly, daily, monthly, fixed)?

We are charged for compute usage, storage use, and bandwidth.

  1. Is your service hosted in multiple regions, availability zones, or data centers?

Our production environment utilizes availability sets ensuring that our application tier is protected in event of failures.

  1. In the event of a catastrophic disaster to a datacenter, how long will it take to have the service operational?

Our application can be deployed quickly to new servers; setup for the application tier, due to the utilization of Docker, is minimal.

  1. What would be the impact of a prolonged downtime window?

Our production region has fail over capabilities. If a web tier node experienced a prolonged downtime window, impact would be minimal as there are three other web tier nodes being utilized.

  1. What data redundancy do you have built into the system, and what would be the impact of a catastrophic data loss?

Due to the limited scope of the prototype, the data set is mocked and can easily be reloaded if necessary. For a live system we would be able to replicate data as defined by requirements.

  1. How often do you need to contact a person from your hosting provider to get resources or to fix an issue?

This has not been necessary.

#US Digital Services Playbook

  1. Play 1 Understand what people need
  2. Play 2 Address the whole experience, from start to finish
  3. Play 3 Make it simple and intuitive
  4. Play 4 Build the service using agile and iterative practices
  5. Play 5 Structure budgets and contracts to support delivery
  6. Play 6 Assign one leader and hold that person accountable
  7. Play 7 Bring in experienced teams
  8. Play 8 Choose a modern technology stack
  9. Play 9 Deploy in flexible hosting environment
  10. Play 10 Automate testing and deployments
  11. Play 11 Manage security and privacy through reusable processes
  12. Play 12 Use data to drive decisions
  13. Play 13 Default to open
Clone this wiki locally