- Core functionality of CM (templates, files, packages...)
- Auxiliary tooling (binary storage, credentials management...)
- Self-contained binary for CM distribution
- Self-healing, masterless setups
- Actively enforcing state by disallowing changes to config
- Provisioning of Distributed systems as an unsolved problem
- Resilience is a set of skills that can be learned
- Changing people to learn a new culture is a long process --> you can not fix everything with engineering
- "Well of Despair" - ambitious and positive at the start, but soon fear that we are not good enough
- Emotional cycle of change: uninformed optimism, informed pessimism, the well of despair, hopeful realism, rewarding completion
- resilience: recovering quickly from difficulties
- Protective factors
- External locus of control (this is impossible) vs internal locus of control (this is impossible right now - so I'll take some steps to understand it better)
- Culture of trust and autonomy leads to resilience, top down leads to well of despair
- How can we help others to build resilience
- caring, listening and supporting
- Resilient teams
- support each other, trust people and give them autonomy, provide a sense of purpose
- be optimistic & confident in the face of setbacks
- build a community -> all support each other
- My own resilience
- meditation -> become more aware of yourself and people around you?
- take breaks (only concentrate 90mins - 2hrs)
- observer your thoughts and rephrase them (I am stressed --> I feel stressed bc of)
Question: autonomy vs. support
- coaching - lead them through problem solving
- Go with Monolith first, later move to Microservices -> componentize your application and split later
- ask yourself: do you really have a scaling problem?
- Mind you still have to manage your data tier for your microservices
- data tier needs to be "self service"
- Question: how many of the 12 factors have you actually achieved?
- Which problems do you have in the organization
- CI / CD, IaC, monitoring, logging, cloud...?
- treating logs as event stream?
- Microservices won't fix your cultural and orgnizational issues
- Read Martin Fowlers article upon microservices
- Kelsey Hightower: 12 fractured applicaion https://medium.com/@kelseyhightower/12-fractured-apps-1080c73d481c#.n6ttm3ya4
- Habitat can listen to a artifact depot and deploy a new package whenever something changes (including dependencies)
- digital transformation == blind men and the elephant
- software company, digital transformation... => we want to become faster
- diversity of languages in open source projects: 1995: 80% used 3 different languages... nowadays... => level of fragmantation => shadow IT (do whatever you want) => how can you cope with that
- there is no single "new stack" instead there is an infinite array of stacks
- putting legacy app in cloud => you just increased the points of failure, cause putting a non-resilient app in an evn that requires resilience
- doing containers alone is not sufficient - at some point you have to manage them --> Today: Kubernetes is clearly the answer
- DevOps mindset: get yourself into the business, don't waste time discussing technology
- if you depend on something reliable that ends up in defined state: bash is not the way to go (unmaintainable mess)
- Q1 2015: 30 % of asked people: no plans with containers while adoption is only 14%
- reason 1: we don't see the business benefit
- reason 2: we have to people to handle the tech
- Q4 2016: 60% claim to run containers
- still very small percentage of stuff running in containers
- Experiments with Containerization start on premise and then go public
- Even Google puts containers in VMs to provide privacy and security / isolation
- State of container orchestration tools is very low (3%)
- 451alliance.com/Apply.aspx
- Services might be expensive, but think about the people running it --> way more expensive!!!
- on mobile devices: everything is a service - no chance to install your own software anymore
- "Serverless" is more like "Function as a Service"
- PubNub Blocks - real time messaging service --> run your code on the edge node, they provide
- just deploying a function does not give you a application (you need database...)
- Nice to have someone running your services --- but big risk when not available --> if it doesn't fit your purposes --> you're screwed
- Promise Theory - Principles and Applications by Mark Burgess
- idea of making promisses (to your customers) - how can this be verified in a services world?
- promise does not guarantee an outcome
- I have to assume that something goes down
- conditions should be part of your promise
- Dialog with customers
- public post mortems
- explain what are strenghts and weaknesses with your technology so that customers can adopt their solution
- go public! Slack...
- CF is very opinionated and hence limited in customization
- For companies with "less" skills, CF is a good way to get a private cloud
- OpenShift provides more flexibility but needs more expertise
@kief
see https://www.youtube.com/watch?v=uAZzbQyuo7o&list=PLBZBIkixHEidnVKFIxogd3Qf-ai3RKTJ_&index=9
Andy Henroid
- Testing as a great use case for containers - security does not matter here
- running test in containers is significantly faster than running in VMs (40 - 50 secs faster)
- container images are way smaller than vm images
- pre-build containers with tooling inside (Puppet, Chef, ...)
- Restrictions with Containers
- Multi-Processing is no problem in testing (despice recommendation to have only a single process run in container)
- make a "full VM" out of a container - e.g. start systemd
- sacrifice security in containers for testing
CAP_SYS_ADMIN
- Link tools (e.g. Puppet Agent) from one container into the other --> saves time & space
Justin Carter
- CPI concept as a killer feature of BOSH
- BOSH as a "huge" tool in oposite to small unix tools
- Basic Concepts:
- Predictability - whole state is described declaratively
- Repeatability - indempotency and completely versioned
- Self-healing
- Nomad: conatiner orchestrator by HashiCorp
- cloud config: configuration of the underlying cloud
- should make deployment independent of infrastructure
- deployment manifest: configuration of the deployment
- references certain configuration from cloud config
- Nomad for providing real time feedback on the deployment process of BOSH
- Jobs Spec
- Templates --> where on the VM the rendered templates should be placed
- links --> define services provided and consumed by a job, so that other jobs can consume a service provided by a job
Thomas Krag - EclecticIQ Kerim Satirli - OnlinData
- Description of the TDD Workflow for Ops
- Usage of RSpec as the basic Framework for testing
- RSpec for testing Packer image builds
- only build new version of image, if tests pass
- Minikube https://github.com/kubernetes/minikube for local test deployment
- kubeadmin - tool to install Kubernetes on Clusters / bootstrap clusters
@cyclidci