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