Deployment in 2015 and beyond

Things to deploy with:

    - puppet - http://puppetlabs.com/puppet/what-is-puppet
    - salt - http://docs.saltstack.com/en/latest/topics/
    - ansible - http://docs.ansible.com/
    - vagrant - https://www.vagrantup.com/

Traditional approach has been linux based style of installation and then configuration. Generally with something like puppet.

New Approaches

The newer approach is to keep full copies of the entire server architecture in which you can build a full machine and cut over a new machine and turn off the old machine. A lot of this has to do with routing to different instances of live instances.

Tools

   - horoku https://www.heroku.com/ or 
   - docker https://www.docker.com/
   - openshift - https://www.openshift.com/
   - juju - https://juju.ubuntu.com/
   - The goal of this is to get away from location.

More and more people are building applications separated out from the persistent disk, in the sense that you can run it on some other machne.

    - For example you might treat your application differently from your mysql database.
   - One of the problems with congress forms (EFF), a piece of software that pulls out the forms of congress.  It actually pulls out the form in a browser.  But the problem was dealing with captchas.  Needed people who were filling out the captcha to get back to the original form.  
   - Once a machine has a unique state it becomes a single point of failure.
   - A goal is actually to not rely on a single location.  Local state collects on applications such as Wordpress.
   - State of the running code needs to be able to handle multiple locations.
   - You have to do basic analysis of code migration to avoid potential conflicts with database schemas etc.
   - From the perspective of wordpress developers, should they be thinking of different ways of deploying plugins.
   - Civicrm deployment.  Do we need to change the architecture to modify the framework to handle the implementation of the framework to remove the GUI based management.
   - You could conceivably have a manifest file to manage the various extensions.
   - Salt can create a sub-category for chains of different implementations (for example multiple plugins for a given wordpress).
   - Radical Designs: handles plugins by keeping all of the plugin list of all wordpress plugins

Docker acts as an overlay for an entire network of servers that can create a set of process groups. It basically manages the spaces of the differnt containers. It's also desigened to create a degree of fault tollerance.

Additional Tools

- https://github.com/googlecloudplatform/kubernetes
- https://coreos.com/ - linux distro for managing massive distributions.  Core os thinks of all servers as a single place to manage running (init) processes.  Can work as a node balancer style model.
- Unikernels (super geeky) https://queue.acm.org/detail.cfm?id=2566628
    - http://www.openmirage.org/

There is a white paper on this crap, read the google omega scheduler https://research.google.com/pubs/pub41684.html and mesos https://mesos.apache.org/

The current recommendation from Ted is to pass on the current generation of these things. Security gets really weird in these deployed environments.