Skip to content

Instantly share code, notes, and snippets.

@michaellihs
Last active February 21, 2017 12:43
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save michaellihs/b6c38898ad8a98dcd7c183238592166c to your computer and use it in GitHub Desktop.
Save michaellihs/b6c38898ad8a98dcd7c183238592166c to your computer and use it in GitHub Desktop.
Summary of cfgmgmtcamp 2017

cfgmgmtcamp 2017

http://cfgmgmtcamp.eu/

Keynote - Is CM a solved problem?

  • 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

Resilient Systems require resilient people @HannahFoxwell

Slides

  • 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

Monoliths, Myths and Microservices

  • 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)

Cloud Native in the Enterprise @DonnieBerkholz

  • 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

Patrick Debois

  • 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...

Chef Friends Dinner

  • 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

Implementing Infrastructure as Code

@kief

see https://www.youtube.com/watch?v=uAZzbQyuo7o&list=PLBZBIkixHEidnVKFIxogd3Qf-ai3RKTJ_&index=9

Configuration Changes don't have to be scary - Testing with Containers

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

BOSH

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

Test-Driven Development for Ops

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

Introduction to kubeadm - Luke Mardsen

CI isn't a solved Problem

@cyclidci

Further Resources

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment