Skip to content

Instantly share code, notes, and snippets.

@d6y d6y/ss16-morning.md
Last active Mar 18, 2016

Embed
What would you like to do?
Scale Summit 2016 - morning

Breaking down barriers (11am, room: Water)

  • e.g. between ops and developers
  • ops view: we have a DR system, we can't just add in the latest thing even though it's great for developers. Can seen like we are always saying "no". Need to expose ops perspective.
  • how does a team become more transparent?
  • do teams need to be integrated? Is siloed better?
  • " inception deck ", on a new project, what keeps each team up at night?
  • bank view: putting up checklists, because face to face communication has failed. But then just finger pointing when things go wrong.
  • if communication is hard between teams, why isn't it one team? Focus on delivery, not roles. "we copied Spotify, basically "
  • maybe read some books on negotiation skills
  • socialise, put names to faces
  • ops adopting tech, and selling it to tech teams
  • manage the team output, not the means. An argument against standardising.
  • ownership and who is on call, leads to responsible choices?
  • internal talks: so teams learn about what else is going on, what concerns are, demands, needs, etc.
  • empathy. Remote teams should meet.

Is the general purpose OS holding us back? (12pm, room: Earth)

  • CoreOS... Updates don't seem so great
  • SystemD ... Seems great
  • Upstart with Ubuntu "one of there most horrific thing ever"
  • Atomic
  • Commercial "boxviews" (doesn't really seem to give benefit for running up JAR)
  • runtime.js (stripped out unikernel that runs node)
  • debugging? e.g., of "bluejeans"
  • Brian Cantor talk: make containers crash hard and use memory debugging
  • mdb sweet software, allows you to dive into most things.
  • also dtrace
  • Lumos https://linuxcontainers.org/ - recommended
  • Alpine for testing - http://alpinelinux.org/ (becaus you can stop/start quickly changes how you use autoscaling)
  • Experiment: running https://openresty.org/ on Alpine
  • e.g., when testing or running on your laptop with many microservices, it pays to have containers you can bring up and shutdown in second or sub-second.
  • OSV
  • Idea of JVM being closest to something that could "just run", but see docker/oracle licensing; JVM has traceability etc
  • Erlang VM
  • Pony+LLVM(+LLDB inside of it if you want)
  • Why get rid of stuff? attack service, size, launch time.
  • Related: https://www.joyent.com/blog/unikernels-are-unfit-for-production
    • Cost of learning: arcane new tech to get into production vs. what you're developing in. E.g., 30 seconds to build a container is adding cost and complexity (two systems:your developer OS and the production deployment system)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.