talk about some really boring stuff. Interestingly, I saw someone put me in the testing track. My first thought was, woh! We have tracks? And my second thought was, hrm…testing? I don’t think so. So if you came here expecting to learn testing stuff, you should go over to Fletcher’s talk on Test Kitchen. So yeah, I’m going to hit up topics on empathy and compassion. Better run now :)
cope with my own judgmentalism since becoming a consultant I used to be really opinionated. Well who are we kidding? I’m still really opinionated. But I try not to be judgmental about things. I’ve been using Chef since 2010 in many different sized teams and organizations. I am opinionated about how Chef should be used. I’ve also been learning for years since becoming a consultant how to have opinions without being emotionally involved in outcomes. I’ve learned to look beyond circumstances
and wrong behavior and the goodness or badness of human character. When you’re judgmental, you’re busy having moral opinions about them and the rightness, wrongness, goodness of their choices. You see, here’s the problem with this: Context.
for an event, statement, or idea, and in terms of which it can be fully understood and assessed. When you’re judgmental, you’re busy having moral opinions about them and the rightness, wrongness, goodness of their choices. You see, here’s the problem with this: Context. You don’t know what someone else is going through or the limitations under which they labor.
day I woke up and realized I had no shits to give about how other people lived their life and I had better things to do than spend my time telling them how they should. I’m so much happier now. Everyone knows that this is a recurring problem on the internet though. We have several points of dissension in open source and our own Chef community on how to do things. Part of this is because we encourage people to find the right way for them instead of dictating. But not always. Once something is accepted as “the right way” it’s really hard to have discussions around alternatives and discussions get religious.
here to lecture. But I do want to spend some time talking about why people are making choices that seem suboptimal and then talk through a few decision points we’ve encountered and talked to death without achieving understanding.
asking “who does this, who likes that.” I’m not doing doing that today because what you do or like is between you and your gods. I’m not interested in exposing anyone’s beliefs or practices to the group when everyone is so opinionated. So I’m just going to talk about some scenarios I’ve encountered.
a use case regarding server names. http://lists.opscode.com/sympa/arc/chef/2012-10/msg00311.html Telling the story: A person writes into the Chef mailing list asking about hooking in a way to name servers with knife-ec2. A story about new and old attitudes and making Legacy work.
is a good idea. Most of us agree that it’s counterproductive these days. But not everyone is there yet. People will be giving servers meaningful labels for years to come.
you do is make someone feel bad without giving them anything useful. This makes the people asking for help feel defensive and can likely result in them exiting the discussion and possibly the community.
of moldy food, and it’s really frustrating for them to hear, “you shouldn’t eat moldy food, but instead grow all your food organically in your own garden or get it from your locally sourced CSA.” This is of course, excellent advice, but not going keep them from starving today.
“that’s dumb, why would you do that?” is pointless and cruel. Especially in the chef community, we pride ourselves on being nice and our hugs and helping people solve problems in ways that work for them. It makes me sad to see non- productive comments show up in discussions.
servers • terminated when misbehaving • never ssh into them • almost no one living this dream We don’t name them, we don’t ssh to them, we don’t give any shits about them at all. In reality, there are very few people who are living the dream. Most of the people in that privileged position are working for startups or configuration management companies :)
more perfect world, we understand that people are limited by constraints that we might not know. Try to understand their context and have some compassion for their situation. If You’ve managed to achieve this nirvana state with your own servers, that’s awesome.
of labeling servers and they aren’t in a position to challenge that yet. They could be championing Chef (or other things) and not want to derail the conversations with too many changes. They could have legacy issues with other apps plugging into named servers. The fact is YOU DON’T KNOW.
your own servers, that’s awesome. Instead of making others feel bad that they haven’t yet, look for ways to bring them along for the ride where they can.
Containers. You can read about LXC, Docker and containers all over the Internet, so I’m not here to explain them. Containers abstract applications away from the kernel layer.
about their tool of choice. What containers do is pretty exciting and there are myriad use cases just waiting for them out there. But just like everything else, they aren’t instant salvation. Your magic devops sparkle toy is not going to be found in this box of crackerjacks.
their tool of choice. What containers do is pretty exciting and there are myriad use cases just waiting for them out there. But just like everything else, they aren’t instant salvation. Your magic devops sparkle pony is not going to be found in this box of crackerjacks. And that’s the trap containers offer if you aren’t careful.
and template VMs. Amazing at first and then just a huge pain in the ass. Same with unmaintained kickstarts or stale AMIs. All of these provide ways to less the time to launch for a new server. But if the server you launch is an outdated piece of crap that someone has to update by hand later, you’re making work, not saving time.
Real Hardware somewhere Changeable Components OSX, Windows fml Production deploys beware Containers solve real problems for someone, but…it’s just like Heroku or NoOps or any other abstraction. Someone somewhere is managing that abstraction and still needs to care for the system. If you think this is going to magic away your troubles, let me refer you to mister To the cloud!
to come at that argument from the other side. Berkshelf has been around for several years now. It was originally created as a dependency solver for chef cookbooks. It’s acquired new functionality over time and inspired some really strong feelings in people. I love it. I could see its potential very early from my viewpoint of working within a large organization with poor communication. ! The moral of this story: intimacy vs mass production; a tale of two cities
teams worldwide infrastructure critical user base Berkshelf was created at Riot games where they’ve grown to over 1300 employees since starting in 2009. They have data centers all over the world and need to deploy frequent updates to different regions with minimal downtime. And if you think your user base is a problem, try millions of 12 year old boys angry and complaining on Reddit because their free-to-play online game isn’t working.
I was working at a large organization with a sprawling codebase. There was lots of bad chef code loose in the organization that people were copying and reusing. When I saw Berkshelf I immediately saw how it could improve quality of life issues around Chef.
gotta give a man a fish. Berkshelf was designed to take a complex tool and simplify it enough that a few admins could distribute usable content to several development teams without those dev teams needing to understand everything they’re using. When you’re a full time java developer, you don’t always have time to add a new tool to your arsenal. And many will half ass it until it’s worse than if they’d done nothing at all.
longest time I didn’t understand why people wouldn’t like it. It was so obvious to me that it solved some really serious problems for so many people who had been struggling for so long. Then there was a food fight show podcast in October of 2012 that got me thinking about why people liked it or hated it. I listened to Jon Cowie from Etsy and Jamie Winsor, then of Riot Games talk about different strategies for cookbook versioning and the discussion touched on many points about why each company used certain tools over others.
stories about how Etsy does stuff. They’re the poster child for all that’s right in the world and they’ve got all the magic devops sparkle dust. Now I’m not running down Etsy. Some of my favorite people work there and I love them dearly. But what works for them, doesn’t work for everyone, just like the problems Berkshelf is solving are not problems for everyone.
built in pain points that have been a struggle for larger teams. Etsy coped with their pain points by continuing to use roles but also built a tool called knife-spork which allowed them to lint cookbooks for forbidden configurations and enforce versioning. Riot eschewed roles for what they termed the application cookbook. This allowed them to version roles and build some complexity into them that roles didn’t support. Neither of these approaches are wrong. They are simply reflections of the personalities of the organizations to which they belong.
and configuration management. You all know I loved Chef best long before I worked here. But seriously. If your company is using Puppet and they’re not switching, just go with it. It beats the hell out of shell scripts and there are bigger battles to fight.
to give our family and friends in the community is, do what works for you. I want to help you solve your problems in ways that make sense to you. The west coast startup scene does not have all the right answers for everyone right now. Many people are forging new paths all over the world in regards to our software and tools. No need to jump off the cliff today. It’ll be there for years to come.
sascha_d
coosuke
magisystem0408
bitkey
ogaclejapan
tarotaro0129
spatial_ai_network
naoki_0531
bigmuramura
zigorou
marsee101
marchin1989
shingo_kawahara
reverentgeek
jonrohan
garrettdimon
keavy
mojombo
irinanazarova
addyosmani
vanstee
marcduiker
geoffreycrofte
malarkey
![@sascha_d [email protected] sascha bates](https://files.speakerdeck.com/presentations/69e1d9b0a7f10131c1eb06aa2e69a5d0/slide_1.jpg){kind=link}
