Very good video on Kubernetes from 0 to 100 mphPlayful yet comprehensive:
I have seen a peered Mongo!https://www.mongodb.com/blog/post/introducing-vpc-peering-for-mongodb-atlas
Reading through Why we use Terraform and not Chef, Puppet, Ansible, SaltStack, or CloudFormation, you should see why immutable code is so powerful.
But I would not drop Ansible altogether…
Here are some rules to look into:
- Build it immutable – cause you can the scale easily, recover easily and have a consistent source for testing and deploying what you actually tested
- Use Terraform to create immutable infrastructure setup
- Use Packer to create images that can be deployed anywhere – AWS, GCE, Vagrant, Openstack
- Use Ansible to script changes on top of your images if needed. Ansible is not immutable by itself, but allows a cleaner reusable baseline to replace your scattered scripts
- In Ansible use modules before you script, and Roles before you duplicate earlier effort. Playbooks are your scripts replacement.
Sweet new features!
- Clusters can span regions and cloud providers (AWS, GCP)
- Setup of clusters in just 3 commands including the overlay (internal) network
- Simple Kubernetes Installation using simple yum/apt-get or simply run from the GCP platform (soon)
- Single VIP points to a load balancer that can forward traffic to federated cluster nodes across regions
Firstly take a look at this recent AWS April 2016 Webinar Series – Migrating your Databases to Aurora and the AWS June 2016 Webinar Series – Amazon Aurora Deep Dive – Optimizing Database Performance session lead by Puneet Agarwal
- Faster recovery from instance failure (X5 times or more vs. MySQL)
- Consistent lower impact on the Primary replica
- Need additional throughput (theoretically X5 times for the same resources vs. MySQL). This was achieved by decoupling the cache and storage sub-systems and spreading them across many nodes as well as performing log commit first while DB manipulation is done asynchronously.
- Using or can migrate to MySQL 5.6
- Comfortable with the Aurora I/O mechanism (16K for read, 4K for write, all can be batched if smaller)
- Get more replicas (maximum of 15 vs. 5 in MySQL)
- Prioritise recovery replica targets and set replicas with different size than the master
- Need virtually no replication lag – since replica nodes share the same storage as the master uses
- Able to decide about encryption at rest, at DB creation
- Accept working with the InnoDB engine alone
- Want to eliminate the need for cache warming
- Allow additional 20% pricing over MySQL to gain all the above🙂
Using a DE-Centralized (Master-Less) Puppet stack has its benefits for dynamic fast morphing environments.
Yet you’d still love to get all changes made to your environment recorded in a central repo.
Factor can be easily customized to ship new types of configuration information as your heart desires.
What are you using?