Learning from your mistakes is important and key to building stable efficient systems, As good as that is, learning from others mistakes is even better. With that in mind, here's a list of Kubernetes mistake stories we can all learn from.
Not to kick off a religious war, but I like vi/vim since it's what my fingers learned lo those many moons ago, but I ran across this list of vim tip and tricks and I learned something new. Enjoy/discuss at leisure.
Here's a topic for discussion. Conway's Law says that organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
There's lots of evidence, anecdotal and structured, that this is in fact the case. Knowing that, how might we approach our infrastructure design, both the internal interfaces and the customer facing ones?
Getting a good night's sleep is important to health and wellness, but our customers expect things to work 24/7. What's an engineer to do to get a good night's sleep?
Here's an intro to containers presentation
Some code and the start of what I hope will be a good set of blogs.
How to insulate your users from the necessary complexity of your systems
Today's thoughts are much less serious. Courtesy of the always interesting Raymond Chen,
Pay attention to the janitor (otherwise known as the "Don't Panic" rule) and sometimes it really is the simple things.
As we journey towards rNA, fully embracing AWS and cloud, while still maintaining some presence in the on-prem world, we want to take advantage of our opportunities build on each areas strengths, abstracting where appropriate, but avoid cargo cult programing.
