See the table of contents for my other blog posts from the conference

@kai5263499

Containers

• Represent complexity
• lots of components
• notes help manage complexity – write down what doing
• were not designed to be secure. Were designed for developers to have a feel of a greenfield system
• just a set of processses
• developers and ops have different goals. Need different images for debugging vs prod

Tips

• Log and audit what is in the images. Logging smokes out bad practices. Can’t prevent password, but can catch it at build time
• Prod image should come from CI/CD pipeline
• Add forensics info to labels. Ex: git hash. Pretend the cloud is down. Can you explain what is in your image
• Scan image regularly. The base image will become vunlerable over time. Scan hashes and layers of image
• Build own scratch image or ami so know what is in it. This is hard, but then you know what is in it
• Monitor what running to ensure what you intend
• Config as code
• Use read only mode in container where possible. Hard to break the container
• Can tag so only data from specific pods can send certain data. Emerging tech. No standard yet
• Can taint workers and only certain pods can run

Antipatterns

• Allowing a broad set of system calls. Makes hard to find atypical patterns. Also broadens attack surface
• Hypervisor shims – limit what can do
• Chaos engineering – keeps you honest. A pod running for months and behaves differently on next start is hard to track down.

Cloud maturity

• Access contol which can push
• execution logs
• images from a build system
• version controk docker configs
• tagged packets from pods and continuous image scanning

Links: https://www.selikoff.net/2019/03/07/devnexus-2019-containing-the-cloud-wes-widner/

My take

Lots of information. I learned a lot. I also realize how much I’ve forgotten about Kubernettes since i last poked it.

See the table of contents for my other blog posts from the conference

@venkat_s

We are problem solvers

Programming languages

• For communication
• Expressive and fluent code
• Uses about 15 languages. Not fluent in any of theM
• Quadrants – static vs dynamic. Strong and weak typing. Ruby gives a lot of warnings because strongly typed.

“All problems in computer science can be solved by another level of indirection” -David Wheeler

• procedural – pointers/references
• object oriented – polymorphism
• functional – lambdas

Imperative vs declarative

• more important than OO vs functional.
• Functional programming is declarative programming with higher order functions
• imperative is easy to write but harder to read
• functional is easy to read. Harder to write partly because we spent so many years writing in imperative style
• Imperative gets harder as problem gets more complex
• need to focus on both imperative and functional. Hybrid languages
• lazy execution does not survive mutability. Dont work around compiler errors!

Future – will care more about async than running in parallel. Want to be able to make async without changing structure of code. Kotlin and JavaScript do this now. Java will in a few years with fibers

Changing mind is important. Not whimsickly. But to make progress

Wisdom is realizing there are no absolutes

My take

Great start to the day. I like how so many languages were compared. With humor too. I like how Venkat does a mix of slides and live coding/notes. I really like that he acknowleges that it is ok for things to feel hard