TopPodcast.com
Menu
  • Home
  • Top Charts
  • Top Networks
  • Top Apps
  • Top Independents
  • Top Podfluencers
  • Top Picks
    • Top Business Podcasts
    • Top True Crime Podcasts
    • Top Finance Podcasts
    • Top Comedy Podcasts
    • Top Music Podcasts
    • Top Womens Podcasts
    • Top Kids Podcasts
    • Top Sports Podcasts
    • Top News Podcasts
    • Top Tech Podcasts
    • Top Crypto Podcasts
    • Top Entrepreneurial Podcasts
    • Top Fantasy Sports Podcasts
    • Top Political Podcasts
    • Top Science Podcasts
    • Top Self Help Podcasts
    • Top Sports Betting Podcasts
    • Top Stocks Podcasts
  • Podcast News
  • About Us
  • Podcast Advertising
  • Contact
Not in our directory?
Add Show Here
Podcast Equipment
Center

toppodcastlogoOur TOPPODCAST Picks

  • Comedy
  • Crypto
  • Sports
  • News
  • Politics
  • True Crime
  • Business
  • Finance

Follow Us

toppodcastlogoStay Connected

    View Top 200 Chart
    Back to Rankings Page
    Software How-To

    Arrested DevOps

    Arrested DevOps is the podcast that helps you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness.

    Advertise

    Copyright: © Copyright 2013-2021 Arrested DevOps

    • Apple Podcasts
    • Google Play
    • Spotify

    Latest Episodes:
    Discovery with Julia Evans Nov 16, 2016
    Show notes

    Bridget chats with Julia Evans, a software developer at Stripe who lives in Montreal, writes a blog about what they learn, and makes paper zines and comics about it. Bridget's framing is that of everyone Bridget knows, Julia is the most excited about learning, so the topic is discovery: what to learn, how to find it, and how to ask for help. At Stripe, Julia works on making programs run on the company's AWS instances and making that easier for developers. The cold open is Julia's story of running out of inodes, and vowing to tell the world you can.

    The CAP Theorem, Reconsidered

    Julia has been trying to understand distributed systems in a way that maps to a real system. Stripe cares about both consistency and availability, though some systems can be a little less consistent than others. They say it took a long time to get the CAP theorem even with a math degree. Strong consistency means linearizable, meaning all the actions in the system can be put on a line, which is a very strong property, and availability means people can use the database. Because networks partition, you can't have both at once. Bridget cites Katie McCaffrey's point that you don't get to choose to skip partitions, and Julia adds garbage collection pauses as another way a system goes quiet. Bridget mentions the Juliet pause Bridget saw running HBase, where a system decides the other side is dead and kills itself.

    At Strange Loop, Julia told Martin Kleppmann they were confused about the CAP theorem, and Kleppmann said not to pay attention to it, since there are more interesting things to say. Julia read Kleppmann's paper, A Critique of the CAP Theorem, the night before. It proposes thinking about what happens to reads and writes when the network is slow: a linearizable system has slow reads and writes, a weaker causal consistency has fast reads and writes, and some intermediate models have slow writes and fast reads. That is a richer model than CAP's two scenarios but not a complicated one, and it describes a replicated database that writes to a primary and reads from a secondary, which CAP doesn't help you reason about.

    Discomfort as a Guide

    Julia mostly doesn't read papers. They go to Papers We Love in Montreal, listen, and ask dumb questions, and they read a paper when someone hands over a printed copy. What motivates them is a feeling of not understanding: "I got all the words, but I still don't really understand what's happening." They spend time being uncomfortable about how well they understand something and asking why, and with CAP the answer may be that the theorem isn't the answer to their questions, not that they're missing something. Bridget says people in tech are drawn to things that sound like answers.

    Service Discovery at Stripe

    Julia is on the team that owns service discovery, didn't set it up, and wrote the blog post after giving an internal talk to solidify their own understanding. If you lose instances, you don't need service discovery, since load balancers do health checks. It matters for registering new nodes. Before, Stripe used Puppet to write a configuration file on an HAProxy load balancer listing the nodes, which was slow and toilsome. Consul runs an agent on each host that reports what it is running to the Consul servers, which hold a database you can query.

    The interesting part is consistency. Consul is strongly consistent, so it sometimes says it is having a leader election and gives no servers, and "Consul was like too consistent." For service discovery, "a lot of the time you don't really care if your results are exactly right. You just want to be mostly right." So Stripe uses Consul Template to generate an HAProxy configuration file every minute, which stays in place if Consul goes away, so the worst case is a slightly old list of servers. HAProxy does a graceful reload, forking so the old process handles old connections. Health checking happens in the load balancer, separately from Consul.

    Blogging, Asking Questions, and Working Remotely

    Julia started blogging at the Recurse Center three years earlier, writing a post every day about what they learned, joking it was a media strategy to get a job, and it worked. Their rule was that it doesn't have to be perfect. Bridget appreciates that they say what they don't know, and Julia says it matters at work too: when they joined the team they didn't know how the service discovery cluster worked, and now they do and can work on it responsibly.

    Most of Julia's team, and most of the teams they've worked on for almost three years, is remote. They are aggressive about asking questions. When they joined a data infrastructure team, on the plane back from San Francisco they interrogated people about every noun they didn't understand, from HBase to Spark to YARN. They use Slack, sometimes schedule a Hangout, and visit San Francisco, and once gave a colleague who set up the cluster a list of questions. They think it helps the person who built it to hand a system off, since it's bad to be in charge of something forever, and Bridget says being territorial won't get you promoted.

    Zines and Comics

    Julia describes a zine as a tiny magazine about something you love. In 2014 they were giving a PyCon talk about Linux debugging tools, and people asked what to read afterward, and the links didn't get read. Inspired by a movie about riot grrrl and fanzines, they wrote a zine about strace to hand out at the talk. Bridget saw copies at DevOpsDays New York. They made a second zine in September about Linux debugging tools.

    For comics, someone suggested a cute drawing at the top of the service discovery post, and Julia drew it on a six-hour flight. The person said the post was much easier to understand from the drawing, which works as a summary tool. They also drew the eight steps for setting up a new web service at Stripe. On Twitter, images communicate more, and a comic on /proc took off. The inodes comic came from running out of them once. Every inode lives in a flat numbered array on disk, and Bridget notes it's possible to run out. Julia says everyone has a day when they learn that, and it's better if it's when they read an adorable comic than while troubleshooting.

    Containers and Hype

    Julia's interest in containers is about making infrastructure easier for Stripe developers, and they find the Kubernetes hype frustrating. The appeal is a uniform infrastructure where every box is configured the same and all the special snowflake configuration lives in the container, so that setting up a new service is less work. Containers have been very successful on the desktop as a developer tool, but people conflate that with production, where it is less clear. Utilization makes sense as a business reason, though 99% is too high, and going from 20% to 80% would be reasonable. Bridget asks what business problem you're solving.

    How to Stay Excited About Learning

    Julia says they became more excited about learning at the Recurse Center, with 12 weeks to learn whatever they wanted, and got stuck learning things all the time. Bridget notes their employer lets them stretch, unlike places that just want you to ship. Julia says asking questions is a skill, and that "I don't understand" is not a very good question. They try to understand it a bit alone, then describe how they think it works to someone and ask them to check their understanding, and they wrote a blog post on asking questions. They also have an unshakable confidence that they can figure things out, and think "I haven't taken the time to learn it" and not "this is too hard." Learning one thing at a time adds up, and "no one has ever anointed me the expert of anything." Their comfort limit is the Linux kernel code.

    Bridget takes the opportunity to talk about CFPs, and Julia says the first conference talk they gave was at PyCon Canada, after the person who runs Montreal Python told them to submit, and they said someone had already talked on the topic. The organizer said it didn't matter, and both talks turned out to be great.

    Distributed systems, service discovery, load balancing: Service Discovery at Stripe

    Community & Event Stuff

    If you have an upcoming conference you would like to see promoted on ADO, you can fill out the handy form at arresteddevops.com/conf

    Upcoming conferences

    For any devopsdays, try the code ADO2016! It should get you 20% off.

    • DevOpsDays Berlin Nov 16, 2016 - Nov 17, 2016
    • DevOpsDays Brazil Nov 18, 2016
    • DevOpsDays Warsaw Nov 22, 2016 - Nov 23, 2016
    • DevOpsDays Paris Nov 28, 2016
    • DevOpsDays Sydney Dec 1, 2016 - Dec 2, 2016

    Open CFPs

    • DevOpsDays Baltimore - closing on Dec 12, 2016
    • ChefConf 2017 - closing on January 18, 2017
    • Velocity San Jose until Jan 10th
    • Monitorama - May 22-24 - CFP opening soon

    Check Outs

    Julia

    • A critique of the CAP theorem: https://arxiv.org/pdf/1509.05393v2.pdf

    Bridget

    • Catchafire - matching volunteers with skills to orgs that can use their skills
    • Minnesota Literacy Council - look for your local literacy org to teach English, math, civics, and more to immigrants & refugees

    chatting with pauly comtois Nov 05, 2016
    Show notes

    The week the Cubs won the World Series, Pauly Comtois finally comes on the show, after Matty kept saying they should do this eventually. Pauly is the VP of DevOps at Hearst Business Media and a former VP of Operations at Chef, where Matty works now. The conversation is about driving a DevOps transformation across a company made of independent business units, and about staying an engineer while doing it. Pauly opens with the line Pauly returns to at the end: "As a great conductor, I don't know how to play every instrument, but I know how they should sound and how they should sound together."

    From the F-117 to Ten Business Units

    Pauly's background is varied. Pauly worked on the F-117 stealth fighter in the Air Force, then moved into telecom and satellites, did development, got roped into being a network engineer because the company didn't have one, and then moved back to development and operations. At Silverpop in Atlanta, Pauly started digging into DevOps, after some cultural and tooling transformations, and found Chef, after starting with a few other tools, some homegrown. Pauly then bumped into a Chef employee at a bar in Seattle who said they were looking for an ops leader, and moved the family to Seattle, where Pauly spent about three and a half years as VP of Operations at Chef, talking to customers at different maturity levels. Hearst Business Media has 10 business units going through transformations to agile, lean and DevOps, and they hired Pauly as VP of DevOps. Pauly tried to talk them out of the title. Pauly's job for the last two years has been building a DevOps community across ten islands that interact mainly at the senior leadership level.

    Unique Snowflakes

    Matty says that's common, and relates a story from a Chef customer's private community where someone asked why a person from another business unit was telling them something. Pauly says the first hurdle was building trust with each unit, since a VP title can be menacing, and the second was the belief that DevOps works everywhere else but not here because "we're a unique snowflake." Pauly's response was "you're incredibly unique, just like everybody else": where humans are involved there is a limited set of emotions, and those shape culture. Drawing a ten-circle Venn diagram showed more overlap than they expected, in language and tools if not process. The magic, Pauly says, was seeing people help each other who hadn't known each other a week earlier, including during outages, for no reward beyond paying it forward.

    Matty says it's more facilitating a community than building one, since a community forms out of humans and you can stymie it but not force it. Matty shares the opposite: at a previous employer, a bank, Matty and later colleagues at Apartments.com found they had worked on the same product one floor apart, dev and ops, without ever meeting. Matty also quotes Sascha Bates that every snowflake has six sides.

    Don't Make a Framework Into Dogma

    Pauly agrees with Matty's "don't take a framework and make it dogma," and admits to originally going in looking for economies of scale, which was the wrong approach, so the choice of tools came off the table, since business units have the context. One level up, Pauly looked at common SDLC approaches, without change for change's sake: work that is cyclical, with a fixed start and end each year, may not need agile at all. Big bang plans like everyone being 100% agile and in the cloud by August were dropped, since it's like throwing someone in an icy pond instead of teaching them to swim. Instead they changed processes iteratively, with DevOps principles underneath, like turning up the water on the frog. Facilitation is guiding, not dictating, and some people won't come along.

    Make the Easy Path the Right One

    Matty tells of a sysadmin asking how to make developers follow a process, and Matty's answer was to make the right way the easiest way, which the book Switch validated. Change annoys people because learning a process isn't their job. Pauly says ops people are so mired in daily brushfires they don't do fire prevention, so you show the investment makes their life easier, and they join organically. Matty says a cultural change has users, and the UX of that change matters, so put yourself in the ops person's shoes, and that "Everything's a product."

    Pauly's principle is to work with the downstream work center in mind, since every customer in the value stream matters, and if work has to be sent back that is waste, measured as percent complete and accurate. Matty says the easiest waste to hammer home is people's time, and that, as Damon said, we should just call it common sense.

    Value Stream Mapping

    Pauly says the value stream mapping workshops turned out to be the most powerful tool, because everyone is in the room at once. Pauly adds that most of the time what someone cares about isn't the root cause, so you dig as with five whys, since "fixing the output doesn't fix the cause": Pauly compares it to giving a cough drop to someone diagnosed with lung cancer. Pauly's example is a color the customer wanted blue that was never specified, fixed each time, while the feedback loop from product never improves. They use Little's Law for efficiency ratings, and numbers on lead time, process time and percent complete and accurate, which confirm what people already feel. Matty says decisions from the gut are reactive, like the screaming customer versus the quiet one buying less, and that data doesn't have to be numbers, and Pauly says use your gut, but don't fly at night with no lights, or stare only at instruments.

    Pauly says every workshop has one person with folded arms who rolls their eyes, and "that person should have representation." Matty recalls a proof of concept where a skeptic turned out to be the biggest champion, telling stakeholders to go buy it. Pauly says being a facilitator means letting that person be heard, and that they may either join or opt out, and leaving is a fine outcome. Pauly also cautions against forcing the top engineer, the Brent, through a transformation, which hurts the organization and the person. Matty recalls Adam Jacob saying most people want to do good work and haven't had the opportunity for a long time, that some people just don't want to be on the bleeding edge, and that change agents have to think like salespeople and understand drivers, as in Adam Jacob's talk on the five love languages of DevOps and the Bill Joy episode.

    Conferences and Speaking

    A listener, Michael Lombardi, asks whether companies should pay employees to attend and speak at conferences. Pauly says employees should get paid T&E and not take PTO, with common sense, and got the business unit leaders to go to the DevOps Enterprise Summit, which was an aha moment for them. Pauly has stopped going to purely technical conferences where Pauly doesn't gain anything. Pauly worries paying people to speak could push an agenda, and describes a DevOps conference in New York that was a day of sales pitches. Matty says DevOpsDays are strict about vendor pitches, and tells of a manager who offered a cash bounty per talk, which only rewarded people who were already speaking. Pauly says pushing someone terrified of speaking hurts quality, and a blog post is another medium, and Matty adds a podcast. Matty warns that an engineer who speaks constantly becomes a better speaker and a less awesome engineer, unlike a full-time evangelist. Both suggest bringing back an internal blog post or brown bag, and rotating who goes so no one becomes a conference pariah.

    Staying an Engineer

    Matty loves seeing a big-muckety-muck VP in a customer's Slack talking about attribute precedence. Pauly loves being an engineer, and says that if the role doesn't allow building, Pauly will create an open source project. Pauly has to speak engineers' language, and when visiting a business unit and offered an office, Pauly sits in the queue with everyone else, because engineers can put on a show for a day but then start complaining across the walls, and that unvarnished view is the real world. Pauly works with CTOs, CEOs of business units and new engineers, and says the exposure is incredible.

    Matty admits to over-engineering a Go application for the DevOpsDays website partly to keep chops up. Pauly says it's less about street cred, since developers will sniff out bluffing quickly, and more like speaking Spanish: saying hola gets you a torrent of Spanish, so you have to understand how it works. Pauly tells of building an elaborate Lego train and Arduino plan to wean a son off a sound machine when Pauly's wife suggested turning it down a little each night, and the domain name was already bought. Pauly points to Adam Jacob, who never stopped loving technology, as a guide.

    Pauly's checkouts are the DevOps Enterprise Summit talk, which will be delivered as a story about middle managers in a transformation, and DevOpsDays Kansas City, and Pauly is starting a blog called DevOps Therapist next year.

    • Switch: How to Change Things When Change Is Hard
    • Little’s Law
    • Dan Pink: The puzzle of motivation (aka "the Drive TED talk")
    • The Five Love Languages of DevOps
    • “As a great conductor, I don’t know how to play every instrument. But I know how they should sound” - Pauly
    • Pauly is launching a new blog in 2017 at http://www.devopstherapist.com/

    Community & Event Stuff

    If you have an upcoming conference you would like to see promoted on ADO, you can fill out the handy form at arresteddevops.com/conf

    Upcoming conferences

    For any devopsdays, try the code ADO2016! It should get you 20% off.

    • DevOpsDays Cape Town Nov 7, 2016 - Nov 8, 2016
    • DevOpsDays Nashville Nov 10, 2016 - Nov 11, 2016
    • DevOpsDays Berlin Nov 16, 2016 - Nov 17, 2016
    • DevOpsDays Brazil Nov 18, 2016
    • DevOpsDays Warsaw Nov 22, 2016 - Nov 23, 2016
    • DevOpsDays Paris Nov 28, 2016
    • DevOpsDays Sydney Dec 1, 2016 - Dec 2, 2016

    Open CFPs

    • DevOpsDays Baltimore - closing on Dec 12, 2016
    • ChefConf 2017 - closing on January 18, 2017

    Check Outs

    Pauly

    • Pauly is speaking 9:30a.m. Wednesday the 9th at DevOps Enterprise Summit 2016 or check out the live stream!
    • Pauly's talk at DevOpsDays KC

    Matt

    • MarkdownToPDF
    • Errors Azure Throws
    • Chicago Cubs win the World Series!

    DevOps in the Windy City with Jeff Smith, Jerry Cattell, and Sameer Doshi Oct 24, 2016
    Show notes

    Matty, a Chicago native who has worked in the city's IT world for about 20 years, gathers three local DevOps people to ask what makes technology and DevOps in Chicago different. The idea came from something J. Paul Reed said on the show after DevOpsDays Chicago in 2014, that the companies there were doing real things and not "Uber for kittens." Jeff Smith manages site reliability engineering at Grubhub, where Jeff has also been the DevOps cheerleader for about two and a half to three years. Jerry Cattell is VP of engineering at a small, fully remote medical startup, and an organizer of the Chicago DevOps meetup and DevOpsDays Chicago. Sameer Doshi is a DevOps architect at kCura, a legal e-discovery company moving from an on-premise product to a hybrid and SaaS offering. The recording happens during Game 5 of the Cubs and Dodgers series, and Matty gives score updates throughout.

    A Small World

    All four have crossed paths before. Matty traces how Classified Ventures, the company behind cars.com and apartments.com, is connected to Grubhub through people who left HomeFinder. Jeff recalls meeting Grubhub's CEO at a Twitter meetup around 2007 and turning down the startup for a safe job at Accenture. Jeff adds that Chicago feels like a really tight community where you keep running into the same people, so it doesn't pay to burn a bridge on the way out.

    Sameer moved from Boston and New York, including a stint at Citi, and found a work culture that felt like a family. On starting at kCura, Sameer looked through the Outlook directory and recognized Matty and Trevor from the podcast. Jerry grew up in Miami, worked for FedEx swapping out computers for Y2K in tropical places, and spent four or five years in the Bay Area, through the crash. When Jerry's wife got an opportunity in Chicago around 2003, all that could be found online was banks, until Orbitz stood out. Jerry notes the meetup gets hosts, sponsors and speakers whenever it wants. Jeff says that in upstate New York there was information hoarding, and in Chicago people were humble, cognizant of imposter syndrome and willing to mentor.

    Midwest Pragmatism

    Matty says the Midwest adopts things after they hit the West Coast and then the East Coast banks, and that Chicago has very traditional IT and a lot of startups with little in between. Jeff says it comes from Midwest practicality: the region isn't interested in the brand-new shiny, it's about "solving actual problems. And generating revenue." Businesses here have straightforward models, like delivering food and taking a slice, and Jeff tells the team to ask, "How does this help us deliver food better?" Jerry counters that innovation still comes out of Chicago: Graphite was developed at Orbitz, and Gogo had just presented Foremast at the meetup, a tool to automate Spinnaker pipelines. Matty calls it pragmatic innovation, like Etsy's, solving a real itch. Sameer adds that this leads to an iterative approach, where you can share work in progress and get "this is great progress" and not "you've got a long way to go." Jerry says the solutions from Netflix and Google look cool but aren't the scale of problem Jerry deals with.

    Jeff reminds the audience that big, slow institutions are still bringing in revenue, and that people from them at DevOpsDays feel left behind. Jeff's message is that you may not be able to move as fast as others, but that doesn't mean you have to sit still.

    How the Conversation Has Changed

    Matty says that two years ago at DevOpsDays Chicago the story from traditional companies was "this will never work here," and now it's "this is really hard and we're not moving as fast as I wish we were," which is a sign you can do something about it. Jerry says the meetup, held downtown at 5:30, still misses suburban companies, though they post videos.

    Jeff says DevOps doesn't have to be a top-down transformation: pair with the developer you work with most for half an hour a day, or have lunch with the team for the service you support. It spreads, and exposure between teams reveals "learned helplessness" on both sides, like developers who don't have access to log aggregation or ops people who restart the same service every night. Jeff tells of visiting the NOC, hearing a PagerDuty alert for a Splunk log velocity threshold, and turning it off on the spot, and getting donuts. Sameer says it's also middle-out, with a central team establishing practices and engineers deciding on their own to speed up deployments, and describes an ideal of engineers deploying to production with supporting people embedded on the team.

    Matty says wherever you work, part of your organization is already doing this. Matty adds that a mandate from a Fortune 10 CIO won't magically create DevOps, and that managing sysadmins means being the person who says "I know you can think of 100 reasons why this won't work. For a minute, let's just pretend it will." Sameer spent five years implementing config management at Citi, sometimes tracking changes quietly when told to just get it done. Matty tells the story of learning Chef out of spite when told it would take a year and tens of thousands of dollars in training, and says that's not recommended.

    Chicago Companies Doing Interesting Things

    Jerry names Gogo, Hyatt, which is moving website work to Docker, Braintree, DRW, which is doing a lot of bare metal DevOps, and ThoughtWorks. Jeff likes the way Hyatt is building a startup-like DevOps culture inside a big company, and Jerry says US Foods, around for 100 years, began with a single new application. Matty warns you have to avoid "bimodal" as an end state, and points to Target's dojo, which starts small but is for everyone. Jeff treats bimodal as a transitional state, and says that a pilot makes other managers say they want that. Matty says pilot it, stack the deck, and beware that people want the magic button, which was the point missed in the 10 deploys a day talk. Matty adds McDonald's, Walgreens, Hyatt and the Mercantile Exchange, which need velocity with safety. Sameer adds that Morningstar rotates developers through ops teams, and Jerry adds 1871, the incubator. Jeff says the startup challenges Jeff took part in felt very Midwest: less about technology, more about the minimum viable thing.

    Matty ends by noting that Chicago's DevOps meetup has the best URL, meetup.com/devops, which to Matty means Chicago invented DevOps.

    • ADO episode at devopsdays Chicago 2014 with J. Paul Reed
    • Jerry started his career swapping out computers for Y2K in tropical locations. Nice job to have!
    • Most sportsball talk on any episode of ADO to date!
    • “You may not be able to move as fast as others, but that doesn’t mean you have to sit still” - Jeff
    • Conversations Matt has had with local folks in the past two years have changed from “this will never work at my company” to “ this is really hard, and we aren’t moving as fast as I would like us to be”
    • 1871 - Chicago incubator
    • Chicago DevOps Meetup
    • 2016 Chicago Tech Madness Bracket

    Companies doing cool devops in chicago

    • Kcura
    • Grubhub
    • Gogo
    • Hyatt
    • Braintree
    • DRW
    • ThoughtWorks
    • US Foods
    • McDonalds
    • Walgreens
    • CME Group

    Community & Event Stuff

    If you have an upcoming conference you would like to see promoted on ADO, you can fill out the handy form at arresteddevops.com/conf

    Upcoming conferences

    For any devopsdays, try the code ADO2016! It should get you 20% off.

    • DevOpsDays Ohio Oct 31, 2016 - Nov 1, 2016
    • DevOpsDays Madison Nov 2, 2016 - Nov 3, 2016
    • DevOpsDays Bangalore Nov 4, 2016 - Nov 5, 2016
    • DevOpsDays Cape Town Nov 7, 2016 - Nov 8, 2016
    • DevOpsDays Nashville Nov 10, 2016 - Nov 11, 2016

    Open CFPs

    • A lot of devopsdays CFPs closing soon - see devopsdays.org/speaking

    Check Outs

    Jeff

    • Neptune.io
    • Netflix’s Winston
    • Chicago DevOps Book Club

    Jerry

    • DevOpsDays Chicago videos
    • Spantree Vimeo - a Meetup recording company that also does tech consulting

    Sameer

    • Edmund Lau’s Effective Engineer a great, fast read that’s made big differences in day to day life (reminds me of Time Management for System Adminstrators)
    • Can’t wait for Halloween and the finale of the web series Edgar Allan Poe's Murder Mystery Dinner Party
    • OMG I’m loving http://armviz.io

    Matt

    • Storm Trooper Whiskey Decanter
    • Hamilton in Chicago!
    • Westworld on HBO

    The Art of Monitoring with James Turnbull Oct 02, 2016
    Show notes

    Don't forget to check out the book itself! The Art of Monitoring.

    Back in the day, James also wrote a book called Pro Nagios 2.0.

    Three stages of monitoring maturity:

    • Manual, user-initiated, or no monitoring (aka Bridget’s example of “we know things are broken because the customer calls us to complain”)
    • Reactive
    • Proactive

    "You will eventually get to CPU, memory, and disk, but a lot later after you start with the things you should really care about" - James

    "Too much monitoring is binary - this thing either works or it doesn’t" - James

    Also mentioned:

    • Large-scale cluster management at Google with Borg
    • RFC 1149 IP Datagrams on Avian Carriers - IETF

    Community & Event Stuff

    Where we’ll be for the upcoming fortnight

    • Matt is getting married at the Jim Beam distillery on Saturday
    • Bridget will miss the bourbon wedding as she’s heading to Joe’s family reunion followed by GOTO Copenhagen.

    If you have an upcoming conference you would like to see promoted on ADO, you can fill out the handy form at arresteddevops.com/conf

    Upcoming conferences

    For any devopsdays, try the code ADO2016! It should get you 20% off. Also now works on O'Reilly Security conference.

    For more DevOps awesomeness, check out the Chef Community Summit, October 26th and 27th in Seattle, WA. This Open Space event provides a great opportunity to connect with the DevOps Community and Chef Engineers over two days of engaging sessions and hallway discussions. Bring your ideas, passion and excitement for Chef and DevOps to this highly interactive event. Go to summit.chef.io to register for this awesome event and use the code ARRESTEDDEVOPS to get 10% off your ticket!

    Open CFPs

    • A lot of devopsdays CFPs closing soon - see devopsdays.org/speaking
    • OSCON's CFP closes Oct 25

    Check Outs

    James

    • Skyliner.io
    • Jason Dixon
    • Vote, but not for Trump

    Bridget

    • Cloud Foundry Summit is going on in Frankfurt right now
    • honeycomb - explorable operations metrics from Charity Majors
    • MicroBadger - for docker image inspection Liz Rice & Anne Curry at Microscaling Systems

    Trevor

    • Windows Server 2016 is GA!

    Matt

    • InSpec has shipped 1.0! You can check it out at http://inspec.io/ InSpec is compliance as code – a human-readable language for automating the continuous testing and compliance auditing of your entire infrastructure. You can also use it to verify if your servers and applications are configured correctly.
    • Self-promotion: working on a shareable theme using hugo for podcasts. Check it out at github.com/mattstratton/castanet

    DevOpsDays DFW 2016 Sep 14, 2016
    Show notes

    Trevor records a "supershow" at the very first DevOpsDays Dallas, combining Arrested DevOps with the Food Fight Show and Software Defined Talk, so the panel is a mix of hosts, organizers and audience. Nathen Harvey co-hosts Food Fight, Coté (Michael Coté) does Software Defined Talk and works at Pivotal, and Michael and Annie Hedgpeth are two of the organizers. Michael is a software architect at NCR working on DevOps for its hospitality group, and Annie is a new cloud automation engineer at 10th Magnitude, Trevor's employer. Dillon Culpepper, a developer at Code Authority who works in .NET and Azure, is an attendee. The show opens with Coté noting that "if you're up on your myth, heroes always get brutally punished."

    Building a First DevOpsDays

    Annie says they had a little over 300 people, with everything going off without a hitch, and they wanted to be Texan but different from Austin, which has a huge DevOpsDays. Annie adds that many attendees were new to DevOps, and there were people around to mentor them. Michael says the reward is realizing the months of work helped people change their lives, and when Nathen asked on day one who was at their first conference, people stood up. The show-of-hands exercise, repeated for the recording, gives about 20 of 100 who had been to a DevOpsDays before.

    Michael tells how the organizing came about: a local group called DevOps Live decided on a DevOpsDays, and Michael had read an old email from Doug Ireton about a conference open space where a bullet point said DevOpsDays needs more women organizers. Annie was looking at a career transition, and Michael suggested organizing, since Annie "can organize a conference." Annie became the sponsor liaison and raised money from about 25 sponsors. Michael watched the kids on Wednesday nights during Annie's sponsor meetings, and three weeks in got a text asking if Michael wanted to handle speakers and emcee.

    One Track, Many Backgrounds

    Nathen was adamant about a single track. When you have choices, you go where you're comfortable, and Nathen heard people say they never would have gone to a networking automation talk, but they got a lot out of it. Michael, who had only been to Austin's multi-track event, mixed technical and culture talks on purpose and picked speakers from networking, security and development backgrounds. It's about empathy and common ground for faster delivery, and Nathen adds: "Imagine a DevOps conference where there was a dev track and an ops track." Dillon, who normally focuses on Microsoft subjects, found the exposure to different speakers surprising and delightful.

    A Local Community Event

    Nathen says the first DevOpsDays in a city is special because the community has two days to gel, and 90 to 95% of the audience lived within 40 miles. Coté says a lot of business and IT happens in North Texas and few people know it, and likes talking to "normal people doing normal things," since heroes are heroic and that gets boring. Trevor says the weekend brought a first: Dillon recognized Trevor from the podcast, which recalled the experience of meeting people Trevor admired, and it was the first conference where Trevor felt past imposter syndrome and unafraid to share thoughts.

    Audience members share their reactions. Reuben Garrett, a Unix sysadmin at IBM SoftLayer, attending a first professional conference, wanted more technical talks but was glad for JJ's Ignite on introverts at conferences and a talk about empowering women in tech. Jean Bennett had been to many conferences but never a DevOpsDays, and the single track and open space worked well even though Jean isn't very technical. Jean is "a talkative introvert." Clay Schroeder of CBRE brought nine people, which would have been hard in Austin with travel and hotels. Michael says at NCR only a small group gets sent to conferences on planes, and this one had no hotel and an inexpensive ticket. Annie says leftover sponsor money can go back into DevOps Live to keep the community going.

    Local Celebrities and First Talks

    Michael says the mix of speakers, including Franklin Mosley, whose security talk was a first at any conference, made the event more engaging than an all-heroes lineup, since the authenticity engaged the audience. Trevor says DevOpsDays is a great place to give a first talk, and that Trevor's was at ChefConf after about three weeks of Chef work, which was much more intimidating than a smaller venue would have been. Nathen says "you should build local celebrities within that meetup" instead of flying in people with name recognition.

    Confusion, Learning, and Empathy

    Coté values meeting people who think differently about obvious things, and says it's fun to sort out the confusion on both sides. Coté recalls introducing Scrum at BMC around 2003 or 2004, when as a snarky young developer Coté figured they were replacing nothing, since nothing existed. Nathen says some attendees ended the first day asking what exactly DevOps is, and the answer on stage was that it's a journey, not something you finish after 18 months. Dillon found the most clarity in open spaces, since people shared similar problems and Dillon heard three or four different valid answers.

    Michael and Annie stayed up until midnight after the kids went to bed working on InSpec profiles and pull requests, and Michael realized that "when you know something and you become the expert, you start to forget what it's like to learn it, and you lose empathy for people." Watching Annie struggle with something obvious to Michael made Michael a better change agent. Trevor says teaching others Chef while still green did the same for Trevor. Michael adds "you kind of don't learn empathy until you come across somebody who's disagreeing with you."

    Getting Your Boss to Come

    Michael asks how to get bosses to attend, and Coté says to figure out their motivations and goals, and either free up their barriers or be persuasive that unless management is involved it won't work at scale. Coté suggests giving them permission to attend, getting them on a panel like a hot dog on a string, sending them recorded talks, and writing up your conference notes as things to do here, not just what happened, and being ready for homework. Nathen suggests inviting managers to speak at a meetup to say what keeps them up at night, and points to books like The Phoenix Project as an audiobook and Mark Schwartz's book on business value, at 98 pages, and the DevOps Enterprise Summit. Annie suggests finding three or four of the boss's pain points and solving one in a DevOps way with a tiny project.

    An audience member asks when you reach success with DevOps. Nathen gives the definition that Adam and Nathen use: "DevOps is a cultural and professional movement focused on how we build and operate high-velocity organizations built from the experiences of its practitioners." Nathen isn't sure all of NCR is bought in, but Michael is doing DevOps, and they treat it as planting the flag. Michael cites Toyota Kata: on Monday, set a target two weeks out in the direction of the goal state, like having lunch with someone to ask their pain points and mapping them to what automation could solve, and then create win after win. Nathen ends by saying that when you reach a milestone, stop to market and share it across the organization, and that you'll feel like you're telling the same story again and again, which is fine, since you're telling it to fresh ears.


    Fireside Chat with Bryan Cantrill Sep 14, 2016
    Show notes

    Bridget sits down with Bryan Cantrill, CTO of Joyent and self-described agent provocateur, and lets the conversation wander from containers to open source economics to production empathy to computational literacy and, eventually, climate change and WarGames. They never settle on a title, and Bryan ends by apologizing for the "random tour" through disconnected things. The cold open sets the tone: "we're a couple of apathetic Xers," for whom a sense of community is something you make fun of on The Simpsons.

    The Floppy and the Skeuomorph

    Bryan has just come from HashiConf, where the guest gave the closing keynote and, for the first time, used a physical prop: a 3.5-inch floppy disk to make a point about hardware virtualization. Bryan explains that the disk is a skeuomorph, like the save icon or the fake wood grain on a station wagon, and says "I do think that VMs are skeuomorph." Your VM has a floppy controller, and these legacy devices have no place in a modern container architecture. Worse, Bryan says, provisioning containers inside virtual machines on hardware wastes resources, "and this can't last forever."

    Containers on the Metal

    Most containers today run inside VMs, a layer people don't see, and Bridget raises the objection that unprivileged containers may not be production-ready without another security layer around them. Bryan is up front that this is talking one's book: SmartOS and Triton have run containers securely on the metal for over a decade, with zones designed to be completely isolated. Bryan contrasts that design center with Linux, where "containers" are really namespaces and cgroups that cut across the system. The guest draws a parallel to ZFS and DTrace, designed to be production-ready on day zero, and says the difference between a facility at birth and later is the scope of features, not readiness.

    Bridget concedes that Linux won, and Bryan refines it: what won is the Linux binary interface. Because that is settled, Joyent implemented a Linux system call table for SmartOS, so a Linux stack can run in a Triton zone and looks like a VM but is a container on the metal. Bryan notes that FreeBSD and Windows have done something similar, including Bash on Windows, a phrase Bryan never expected to hear in a sentence. The guest believes open source has won an unconditional victory, and everything in the container ecosystem, from Kubernetes to Docker Swarm to BOSH, is open. That is why Joyent implemented the Docker Remote API, to have Docker without the Docker engine, and why Bryan wants an API separate from its implementation, so people can compete on the engine.

    Forks, Agendas, and Open Thinking

    On the rumored Docker fork, Bryan says people shouldn't talk about forking, they should do it or not, and suspects some who talk are goading others. The guest would rather see de novo implementations of a stable Docker Remote API than a fork of the engine. Bryan advises people not to get swept up by vendors with an agenda: the people ginning up a fork have a solution in search of a problem, not a problem to solve. Bridget raises Red Hat's downstream patches, and Bryan says "I am a much stronger believer in incompetence than malice," since there are 20,000 issues on those repositories. Bridget adds that taking a patch is like adopting a free puppy.

    Bryan says Joyent open sourced its stack almost two years earlier and found it wasn't enough, because the design discussions were still in hallways and chat rooms: "we actually need to be open sourcing our thinking, not just our code." Their answer was requests for discussion, or RFDs, written in an RFC style, which anyone can search to see the Triton roadmap. Customers read them and react to specific numbers. Bryan thinks design discussion in GitHub issues is an anti-pattern, since an issue gets closed and the valuable discussion is buried.

    Foundations

    Bridget says the Cloud Foundry Foundation is valuable because employees of competitors pair on the open source project. Bryan, who is involved with the Cloud Native Computing Foundation, says it is still finding its footing and it can't be the Kubernetes Foundation: "If we are the Kubernetes Foundation, then we have failed." Bryan wants the CNCF to have as public a mission as it can, contrasting a nonprofit with a public mission and an industry consortium, and says its constituents should be the people running and contributing to the infrastructure, not the vendors that paid for a seat.

    The GitHub Resume and Paying for Open Source

    Bridget respects companies that pay employees to write open source, including Joyent. Bryan objects to the GitHub resume because contributions to a fork don't show up on your activity. SmartOS and Illumos Joyent are GitHub forks of Illumos, so Bryan's own history looks empty. Bridget says paying people means they can write open source all day, then go home and not write more when exhausted.

    Bryan says we're deep into what Bryan called supply-side open source a decade earlier, where infrastructure comes from companies dedicated to it, and asks how you monetize it. The guest thinks the era of proprietary software will be completely over, using ZFS as an example of a substrate where duplicated effort is over. In Bryan's view, people won't pay for the software, but for running a cloud, a service or metal, and for support: they will pay "for the ability to pick up the phone in the middle of the night and call for an upgrade that has gone sideways." Bridget says Cloud Foundry customers pay for integrations they could build but don't have time to. Bryan adds that if you intend to be the one who picks up the phone, it pushes you to make the software as reliable as possible, and to invest in debuggability and observability.

    Production Empathy

    Bridget mentions a blog post by a Joyent engineer on a storage disaster, and Bryan says the details matter. Bryan doesn't think every software engineer should carry a pager, since it's like trying to train a dolphin with a shock collar, but does think "everyone needs to develop production empathy." Software engineers underestimate the stress of a working system that stops working while everyone asks why you can't turn back time. Bryan says that during an outage the personality types separate, and operators keep a cool head, while the dev mindset loses its mind. That makes Bryan a developer at heart, one who immediately goes to the worst case. Bridget suggests DevOpsDays organizers are often ops people because running live events is operations, with no do-over, as the event technology work of Bridget's spouse shows, and Bryan says if things go right nobody notices, so lighting and sound crews rarely hear thanks.

    Bridget connects this to Simon Wardley's pioneers, settlers and town planners, placing the host in settlers mode caring about day two. Bryan says people have a preferred mode but can learn the other's empathy. Bryan tells of being told someone complained that Bryan talks about production too much, a complaint that, in Bryan's view, denigrates the people responsible for keeping systems up, since everything ultimately has to boil down to production. Bridget: "Otherwise, we're just making toys."

    Computational Literacy and Who Gets Access

    Bryan takes the 40-year view and says we're doing well, since so much software simply works, and that "computational thinking has to become literacy," a way to think analytically, not necessarily to code. The guest says there's a bifurcated economy, and the dividing line is how much you're participating in this revolution. Bridget pushes back that there are systemic barriers, citing computer science professors hassled by campus security because they're Black. Bryan agrees and adds that Bryan's inner-city magnet high school needed an IBM investment of millions for a computer lab, while online courses and the cloud now cost far less, though you still need quality instructors.

    Bridget says DevOpsDays Minneapolis had 700 people, and with sponsor support they donated about 10% of the surplus to local initiatives, including a job training center run by the American Indian Council whose graduates move from fast-food jobs to data center jobs. They talk about how "the world does not need another dating app" and how Bryan's marriage began on Match.com. Bryan says climate change is going to be kind of exciting, as a grand unifying engineering challenge, and describes deep optimism given how close the Cold War came and how the best minds were briefly in government.

    History, WarGames, and Container Summit

    Bryan is an unapologetic Xer, and tells how a young engineer at Joyent who hadn't seen WarGames got demerits from the company's online demerit system until the engineer watched it, and afterward said it was a really good movie. The guest adds that Back to the Future is in the canon for millennials and WarGames isn't. Bryan also finds people are interested in history, which we don't teach, and Bridget says it involves rivalries like the split between Cray and Control Data in Minneapolis. Bryan recommends a book on the CDC 6600, with its parallel execution units and rotating Gatling gun, which is in the show notes.

    Container Summit began as a marketing event disguised as a conference, Bryan says, and they took it on the road to have conversations with local technologists in front of local technologists. In smaller cities, people turn out for events, unlike in the Bay Area, and Bridget says about 135 people came to the Minneapolis one. The last topic is Joyent's acquisition by Samsung and Bryan's trips to Suwon, where, Bryan says, a baseball game in Korea is amazing and defies description.

    Bridget sits down for a classic fireside chat with Bryan Cantrill (Joyent), ranging from containers to social justice to lawn care.

    • Container Summit
    • Design of a Computer: The Control Data 6600 by J. E. Thornton

    photo credit

    Community & Event Stuff

    If you have an upcoming conference you would like to see promoted on ADO, you can fill out the handy form at arresteddevops.com/conf

    Upcoming conferences

    For any devopsdays, try the code ADO2016! It should get you 20% off. Also now works on O'Reilly Security and Velocity conferences.

    • Devopsdays.org has dates announced for Sydney - Dec 1-2

    Open CFPs

    • A lot of devopsdays CFPs closing soon - see devopsdays.org/speaking
    • OSCON's CFP closes Oct 25

    Devopsdays Chicago 2016 with Nell Shamrell-Harrington, Jill Jubinski, and Michael Stahnke Sep 12, 2016
    Show notes

    Matty hosts solo, recorded live in front of an audience on the second day of DevOpsDays Chicago, the third year the show has taped there. Matty's panel is Nell Shamrell-Harrington, a software engineer at Chef from Seattle, Jill Jubinski, a community evangelist and recruiter at IBM by way of its Blue Box acquisition, and Mike Stahnke, a director of engineering at Puppet. Matty, an organizer, says this was the smoothest of the three events, and then worries about having jinxed it. The episode's cold open is Mike saying most of the DevOps advice Mike takes comes from 90s music, and Nell adds the TLC song about not chasing waterfalls as advice for anyone getting started.

    Themes of the Conference

    Nell saw a strong emphasis on humanity and technology and how they aren't so different. Mike saw open space after open space come down to testing: "testing all the way down." Jill says a constant theme is that "technology is hard, people are harder." Matty recalls Adam Jacob's keynote on humane systems, context and thriving together, and Jill's morning talk on DevOpsing recruitment, which included a game of guessing whether a recruiter or an engineer said each line, where the answer was always both. Matty also liked a line from Nell's talk on refactoring that what software does matters more than what it was intended to do, and Nell adds that "the only source of truth is when you execute the code itself."

    Testing and the Long Road to CD

    Matty says test-driven infrastructure has only really been possible for about three years, and can't remember how cookbooks got written before Test Kitchen. Nell says Nathan Harvey, Nell's boss, suggested that to teach TDD to sysadmins, you point out they already test: when they configure by hand, the first thing they do is log in and check it worked. Testing is the same thing, faster and more reliable than a human. Nell sat in an open space on applying the testing pyramid to infrastructure code, where people from Chef, Puppet, Ansible, sysadmin and app dev backgrounds showed the principles are the same whatever the tool.

    Matty says people at infra-code vendors are in a bubble where table stakes aren't table stakes for everyone. Mike describes conversations where people know the outline of a transformation plan, but every bullet is a journey that can take nine months or a year, and people who read about 50 deploys a day don't have 50 tests yet: "just because you know the roadmap doesn't mean you can actually drive." Nell recommends what Martin Fowler calls the strangler method, adding tests around one small part of a legacy mess until the new well-tested application strangles the old one.

    Matty tells of a bridge in Louisville that was built on top of an old bridge, which let the old one fall away once the new one was strong enough, as a metaphor for keeping the old thing until the new is ready. The host connects it to shims and temporary bridges, which product owners hate, and to Jeff Smith's Ignite about Dungeons & Dragons DevOps: you fight level one monsters first, and learn to write a Git commit message before the 50-deploys-a-day dragon. Customers want to manage their Hitachi storage before they've written a recipe to install a package. Mike finds writing the tests "way, way harder than writing the software," and has mad respect for test automation engineers. Matty says writing the tests makes the code easier, since you've done half of it.

    Matty ties this to time to first delight, Matty's own term, which Andrew Clay Shafer calls mean time to dopamine: people have to experience results, since you can't talk them into it, and if you're selling against something that gave them a dopamine hit, as Adam Jacob would say, they will argue with math.

    Empathy for Recruiters

    Mike says it was the first recruiter talk Mike had seen at a DevOpsDays, and it was great. Jill's goal for 2016 was to speak at an engineering conference, and this was the third talk toward it, after Monitorama, where the topic was Taylor Swift and open source, and Boston. Jill wants to spread empathy for recruiters, and says the good ones are not rare. Mike says Puppet grew from 35 people when Mike arrived to 470 and couldn't have without recruiting and hiring pipelines. Nell praises Chef's in-house recruiter, who also trains interviewers, since some questions engineers are used to asking are actually illegal. Jill says to rely on recruiters for that, and for diversity, since they understand the market, while engineers assess the technical side.

    Matty says engineers can be arrogant about everyone else's job, assuming sales or marketing or recruiting is easy. Mike calls it Dunning-Kruger, "The more you know, the more you know you don't know." Why do recruiters get a bad rap? Jill says there are internal recruiters who are ingrained in the culture, and external ones who work on commission and fill seats without knowing the companies. Jill's advice to companies big enough is to "get an internal recruiter and I promise you it will change your life." Jill has gotten emails pitching a DevOps engineer role, and Nell one pitching an administrative assistant job. Matty says the reason we hear about it is that we live in a bubble, and IT people get complained about on Facebook. Making fun of recruiters is lazy, and Mike loves fake internet points.

    Jill says recruiters often lack effort as well, and should know their audience, since spamming LinkedIn is wrong for engineers but works for marketers. Matty sometimes replies to recruiters offering to tell them what is wrong with their job description, and about half the time gets a response saying let's talk. Jill runs messages by engineer friends for honest feedback.

    The Event Itself

    Nell, who is hard of hearing, enjoyed the party at the bowling alley with card games, since it wasn't a loud bar. Jill liked the close venue compared with Boston, where a larger stage felt disconnected from the audience. Mike was thrilled with the deep dish lunch on day two, and Matty recalls that in the first year a speaker got mobbed with questions and missed the pizza.

    Three first-timers in the audience share feedback. Mark liked the networking and hearing how companies integrated DevOps, and wished open spaces were organized more tightly. Yasser, a developer, preferred the non-technical talks and suggested speaker ratings. Mike says DevOpsDays went through an arc where culture talks pushed out tools talks and now a few technical talks are coming back, and non-technical talks travel better since they're relevant even if you're not on that technology. Matty recalls two people at the first Chicago, one from a smaller company saying it seemed like it was for big companies and one at a big insurance firm saying it was for small ones, after the same event. Dongmin Liu, also a first-timer, says the non-technical part is the harder one, because it's not about technology but how you package it to convince other teams.


    Operationalizing Open Source with Michael Hedgpeth and Doug Ireton Aug 30, 2016
    Show notes

    This is the show's first experiment with a guest host. Michael Hedgpeth of NCR, who is working on DevOps in the company's hospitality division and worked with Matty on bringing Chef into NCR, takes the host chair, and Matty and Bridget are the guests, alongside Doug Ireton, a Senior AWS Chef Engineer at 1Strategy. Michael proposed the show after catching part of Doug's ChefConf talk on operationalizing open source in the enterprise, and realizing there were questions for all three of them. Bridget, who does tech advocacy for Cloud Foundry at Pivotal, opens with the line that comes back later: people contribute to open source out of passion, but they "also like to sleep. And see their families."

    Nordstrom's Four-Year Journey

    Doug was the unofficial go-to person for open source questions at Nordstrom, a setup that needed no formal committee or title, just people who care, as Doug tells it. Doug's main takeaway is that "culture change takes time": it took about four years to go from open source contributions being allowed to open source being the default for fast-moving teams. Doug walks through the timeline. In 2008 the only open source they used was Red Hat Enterprise Linux and nobody went to conferences. They bought Chef in spring 2012, and in fall 2012 a VP said contributing is part of using open source, and employees signed an intellectual property agreement. In 2015 developers wanted to contribute to React.js, which required a contributor license agreement, and getting Facebook's approved took about four months, a lot of back and forth from legal and two VPs' approval. By 2016 the Google corporate CLA, for Kubernetes contributions, was signed in a week.

    Doug says the close relationship with legal never developed, and wishes it had. Leadership approval was in place, but the VP first approached sent the request to another VP who then left, and Doug suspects a non-technology company's legal team may not focus on differences between licenses.

    From Config Management to Everything Else

    Michael asks how starting with Chef led to open source in core development. Doug says Nordstrom is a big company, Doug's team never used Kubernetes or React, but leadership came to see that open source lets you move faster instead of a six-month vendor selection, and app teams co-evolved with the Chef users. Bridget says it isn't only for frontend teams, and that if a vendor tells you their platform is the only thing, you should ask whether it's built out of open source. Michael says for a Microsoft organization like NCR, the world of many tools instead of one umbrella is a big shift, and Chef helped them take baby steps toward being community members.

    Matty says the same holds for IBM shops, with the old joke that nobody got fired for buying IBM. Matty describes going to a vendor with a problem and being told they don't quite have it, then buying the closest thing anyway and taking on tech debt, as with a BizTalk system that could have been a small open source tool. CIOs love "single throat to choke," but buying everything from one vendor doesn't mean it works together.

    Standardization Versus Freedom

    Michael says NCR wants to standardize for efficiency, which runs against the open source idea of letting teams pick the best tools. Bridget says a well-composed platform like Cloud Foundry isn't opposed to devs using small tools, as long as choices are open and compatible. Doug uses Netflix, where most teams use Java because there is a paved road, but you can choose something else and support it yourself. People resist standards from a central architecture team that reads white papers and talks to vendors, and accept them from architects embedded on dev teams who write code and support production, and Nordstrom's API teams have moved to Go and Node.

    Matty says the best way to get people to do something is "to make the thing you want them to do to be the easiest way to do the thing they want to do," not "thou must." Matty advises a customer to think about the result they don't want, such as an artifact that enables remote logging, instead of policing how people write infrastructure code, and notes that in a huge enterprise, standards have to get vague as you move up. Michael's takeaway is that "standardization is great when it enables freedom," and that Chef works that way for NCR, since it made adding HashiCorp Consul easy. Bridget adds that organizations adopt Netflix OSS like Eureka and Hystrix because good, battle-tested tooling gives an incentive to choose the tried-and-true path.

    Open Source and Hiring

    Doug's talk argued that an open source stance affects hiring. Several engineers said they looked at Nordstrom's GitHub profile before interviewing, and Doug says "your GitHub organization is your organization's resume in the open source world." They were able to hire someone from Chef primarily because they contributed, and it helps retention too. Doug ran a Twitter poll asking whether people would work for a company that didn't allow open source contributions: 68% disagreed, 25% were neutral and 7% agreed. Bridget says companies building on open source can't expect it all to be written in people's spare time, and should pay employees to contribute. Doug adds that private forks become untenable quickly.

    Internal Community, Vendors, and Pull Requests

    Michael asks when paying for help with open source makes sense. Michael describes the open source workflow of running it, Googling the error and running it again, and Matty says the important part is then sharing what you learned so the next person doesn't repeat it. Companies with healthy internal communities look just like public ones, behind the firewall, and Matty can tell what wiki software customers use from referral links to ADO episodes. Michael says the relationship with Chef morphed from support to consulting, which helped with thinking strategically about who talks to whom, and gives an example of a colleague in Prague who disagreed with how Michael did Chef, and Michael told the colleague to go with it, which was freeing.

    Michael asks whether relying on a vendor for support of an open source tool is unhealthy. Matty says the vast majority of Chef users don't pay, and that if all a vendor sells is support, it isn't a sustainable business, because you'll eventually get better at the product than they are. Matty adds that with closed source, support might be all you get and you can't stop paying. Bridget says Cloud Foundry has contributors like IBM, HP, Swisscom and GE, and Pivotal contributes about 65% of the commits, and that a free 60-day trial of the commercial product lets people try it before paying. So "I can't install it from GitHub, so I can't cut a PO" is a straw man. Matty says if a customer has to spend a week standing up infrastructure to see what a tool does, the vendor has failed, and the goal is time to first delight. Bridget says Andrew Clay Shafer calls it "mean time to dopamine." Bridget also says look at the community around a project, like the US government's 18F building cloud.gov on open source Cloud Foundry, with Terraform scripts on GitHub. Doug pushes vendors to hand over a Terraform script or CloudFormation.

    Doug says enterprises new to open source respond to bugs with "the vendor should fix that," but they have unique insight into the problem. Doug found a bug in Supermarket that could be fixed in five minutes, and it was merged within an hour, versus filing a support ticket that takes two and a half weeks. Michael says Chef support once demonstrated the same lesson by opening a GitHub issue, submitting the PR and reporting back with a link. Doug has also been on a closed-source project where the vendor said it might get to a fix in six months, after millions were paid. Bridget likes subscription models because vendors care about churn, and Matty says the dirty secret is that "Renewal time is the best time to ask for anything from your vendor."

    Freemium and Build Versus Buy

    Michael asks about the freemium model like Chef Automate. Matty says that in Chef 11 you had to reinstall everything to drop the enterprise version, whereas since Chef 12 and through Automate, the core is open source and everything around it is a wrapper, and "you want that premium thing to be sticky because it's valuable, not because it's in the way." Michael asks whether the answer is instead to build a Jenkins pipeline and Elasticsearch cluster in-house. Bridget's answer is that it depends, but the fallacy in organizations with smart people is thinking they must master everything down to chip fabrication: "you should only build the things that make a differentiating business value for you." At DramaFever, they didn't build their own CDN, and when the Akamai bill was high, they prepared to go multi-CDN and it turned out Akamai would negotiate. They did build a Docker, Packer and Chef-based platform, since it let them stand up a K-drama site or a horror site from the same image.

    Matty says there's no reason to run your own email, and that "modern DevOps, we're all about coulda, not about shoulda." Pay someone to do the thing you'll never do again, like setting up a cluster once every five years, but not to write automation you'll change. Matty recalls dev leads at Apartments.com who wanted to write their own authentication for an internal customer service app when they were a Microsoft shop with Active Directory, and calls that hubris and resume-driven development. Doug adds that consulting is most useful when the consultants partner with you and you dedicate engineering hours, and that paying for Chef was worthwhile for the support and the add-ons customers expected, like a web UI. Matty ends with an example: at Chef they didn't write their own search provider, they use Solr and Elasticsearch.

    Matt and Bridget chat with Michael Hedgpeth (NCR) and Doug Ireton (1Strategy) about organizations adopting open source.

    Checkouts

    Michael

    • DevOps Days DFW on September 15 & 16 - I’ll be speaking
    • Toyota Kata book
    • PBS SpaceTime

    Doug

    • Habitat for application automation
    • Adam Jacob’s DevOps KungFu talk

    Bridget

    • Coté on “the ROI on devops/agile/etc”
    • BWCA is part of Superior National Forest. The National Park Service is 100 years old this year and National Forests are different than parks!
    • The West Wing (streaming on Netflix), because it’s election time.

    Matt

    • Wakatime - fitbit for programmers
    • Homeland!!!

    Image credit: https://flic.kr/p/3V99c8

    Community & Event Stuff

    If you have an upcoming conference you would like to see promoted on ADO, you can fill out the handy form at arresteddevops.com/conf

    Upcoming conferences

    For any devopsdays, try the code ADO2016! It should get you 20% off. Also now works on O'Reilly Security and Velocity conferences.

    • Devopsdays.org has dates announced for Sydney - Dec 1-2

    Open CFPs

    • A lot of devopsdays CFPs closing soon - see devopsdays.org/speaking
    • DevOpsDays Madison, Detroit, Cape Town, and Nashville open until August 31
    • DevOpsDays Berlin open until September 1
    • DevOpsDays Bangalore open until September 4
    • DevOpsDays Ghent open until September 6

    Where we’ll be for the upcoming fortnight

    • Bridget - Canoeing with no phone or internet, and then Velocity NY/devopsdays NY.
    • Matt - DevOpsDays Chicago Aug 30-31

    Application Configuration with Tim Gross and Adam Jacob Aug 01, 2016
    Show notes

    Tim Gross (Joyent) and Adam Jacob (Chef) independently started solving the problem of how to put applications in control of their own configuration. They discuss Habitat and ContainerPilot, to the edification of Matt and Bridget.

    Checkouts

    Tim

    github.com/joyent/containerpilot and example applications at github.com/autopilotpattern

    Adam

    habitat.sh

    Bridget

    The Art of Closing - open source maintainer advice from Jessie Frazelle

    Badass by Kathy Sierra

    Matt

    DevOpsDictionary.com - I’m having a bit too much fun contributing to it.

    Community & Event Stuff

    If you have an upcoming conference you would like to see promoted on ADO, you can fill out the handy form at arresteddevops.com/conf

    Upcoming conferences

    For any devopsdays, try the code ADO2016! It should get you 20% off.

    Open CFPs

    • Devopsdays.org!!!
    • DevOpsDays Singapore open until August 15
    • DevOpsDays Ohio open until August 26
    • DevOpsDays Madison, Detroit, Cape Town, and Nashville open until August 31
    • DevOpsDays Berlin open until September 1
    • DevOpsDays Bangalore open until September 4
    • DevOpsDays Ghent open until September 6

    Where we’ll be for the upcoming fortnight

    • Bridget - SpringOne Platform in Vegas Aug 1-4
    • Matt - in Chicago. I am boring now. But you should all come see me at DevOpsDays Chicago Aug 30-31...a few tickets left, ADO2016. Plus now with extra Adam!

    devopsdays Minneapolis 2016 Jul 30, 2016
    Show notes

    Bridget records a live panel in front of a studio audience at DevOpsDays Minneapolis, largely improvised. The panelists are Charity Majors, who founded Honeycomb, the company formerly known as Hound until a rename two or three weeks earlier, Nicole Forsgren, who is at Chef and a co-founder of DevOps Research and Assessment, Andrew Clay Shafer, and James Watters of Pivotal, who is responsible for Pivotal's products. Bridget reports to Andrew at Pivotal. Bridget admits forgetting to tell most of them that a podcast was the plan, and that they are in fact being live-streamed. Andrew reminds Bridget that last year's taping, which was billed as eating sushi with Andrew, had no sushi. Nicole opens with a line that returns later: "Teams deliver software, individuals don't. Teams perform, individuals don't."

    Everyone Is a Software Company

    Bridget asks what kinds of companies are realizing software matters. James mentions Merrill, a sponsor, whose executives were betting on a new software product as a global SaaS brand. Charity says platforms mean you never know who will show up: Disney signed up and created an account without talking to them, next to 13-year-olds building software on the same platforms as corporate America. Charity calls it the democratization of tools that used to be a competitive edge for big vendors with giant R&D budgets. Andrew describes a reinforcing spiral that started with open source, where the primitives for building Facebook, Google and Amazon became available, and has gone up the stack to things like TensorFlow, so you can start thinking about your domain and have neural networks. "The democracy is going up the stack," Andrew says, and James adds "abstraction levels going up democratize technologies," like a toddler using a touchscreen.

    Nicole says the companies doing it right reach customers earlier, get to market and feedback faster, and reduce complexity with an MVP, and the ones that spend a year on an RFP fall behind. Charity says that's why hashtag NoOps draws a wince: operations isn't vanishing, good operations is a competitive advantage, and what is shifting is the definition.

    Operations Isn't Going Away, and Neither Is Its Value

    Charity describes "the shadow self of DevOps": the industry has spent almost a decade telling ops people to write better code and tests, but hasn't told developers what they need to learn, the operational skills that let them build, ship and maintain products. Andrew dislikes labeling people as ops or dev, and prefers thinking in capabilities, since not everyone can do everything as organizations scale. Andrew says NoOps is a reaction to a world where sysadmins were responsible for the mail, and that "the systems are actually a reflection of the organization." Charity says anyone giving advice without context is selling nonsense. James asks enterprises what problem they're solving before talking about product differentiation, and asks how long deploys take. One bank told James eight weeks and 10% of their staff, a year into building their own platform. Nicole says that is solidly mid-to-low performance, and not even the worst of it.

    Charity says an inherent trait of infrastructure done well is that you don't notice it, like roads, and Bridget recalls the Minneapolis freeway that fell into the river in 2007. Nicole adds "when the work is done correctly, the work disappears," which contributes to devaluing it, and points to systematic salary differences between development and ops, and Charity says Google couldn't retain SREs until it paid them more than software engineers. Andrew says leading-edge cloud-native companies don't have as much of a disparity, and that treating IT as a cost center forces bad behavior. James says offshoring tried to lower the unit cost of developers as paying less for ops did. James describes operators running thousands of containers and hundreds of apps and says raising abstraction lets an operator have leverage, so James tells the operators' bosses how valuable the operators are.

    James's advice for IT professionals is that "application architecture and operations architecture are not dissimilar things," and to think about how a database is operated, not just its API. Andrew says lots of people who think they have operations problems have architecture problems, and adds, "Day 2 matters."

    Meeting People Where They Are

    After James leaves, Charity says context is everything, and Andrew says continuous delivery and microservices can sound like fairy tales to someone far from them. Nicole says you have to meet people where they are and help them envision what's possible, remembering the comfort of doing it manually back at IBM. Andrew uses a marathon analogy: if you're not ready and you try it, you'll hurt yourself. Charity's version is a patient in the emergency room with a broken leg and blood spurting from their head, who shouldn't be worried about skin cancer yet. First stabilize the patient, and the top skill in startups is "ruthless prioritization." Andrew says overfunded startups fail because cash protects them from their context.

    Asked how large organizations get startup nimbleness, Nicole says it happens in small teams that try something and scale, not in an organization-wide nimble process with posters. Charity says Facebook was a revelation, with a horizon 18 months out, and that what works at scale is "Outcomes-oriented and trust," define an outcome, develop trust and then go hands-off, empowering people to make mistakes as long as they won't destroy the company. Andrew says smart people solve problems, and also, "Smart people also cause problems." Charity says every workplace of Charity's had an outage caused by nearly dropping all the data.

    Careers, Teams, and Performance Reviews

    An audience member asks about HR and career development in DevOps teams. Charity says what an org values differs, like Heroku's five nines counting toward promotions, and signaling what you value is how people are incentivized. Charity likes asking reviewers who they would most like to be paired with on call, or would call at 3 a.m., and who they least want to be paired with, since it differs from who the best engineer is. Andrew says work can be done so that you're better at it afterwards, and if not, reevaluate the work, and adds that not confronting incompetence demoralizes the rest. Nicole says university doesn't prepare you for distributed software or continuous delivery, for developers or ops.

    Nicole's rant is that individual performance reviews are nonsense, because "Teams deliver software, individuals don't," and invisible work like the person who glues the team together may show the fewest commits. Andrew says "As soon as you make a measure a target, you made the measure useless," and takes a contrarian position that humans are non-fungible. Nicole says Google's study of 36,000 engineers found team dynamics, with psychological safety first, matter most, and Charity says Google still hires "as though they're hiring for Lego bricks." Andrew describes the 80 percenter persona who can prototype anything overnight and will never build anything that belongs in production. Bridget recalls Alice Goldfuss's talk on rock stars, builders and janitors. Charity says startups have the advantage of hiring for what the team needs, and that constrained resources drive creativity, and you can carve out a small budget for a team inside a big company, like a startup.

    What the Data Says About Enterprises

    Nicole responds to the assumption that the data doesn't apply to enterprises: "there are no statistical differences among the different enterprise sizes," or by industry, including highly regulated ones. Nicole classifies teams as high, medium and low performers by throughput, meaning deploy frequency and lead time, and stability, meaning mean time to restore and change fail rate. High performers score significantly higher on the Westrum culture measure, with high trust, good information flow and messengers not shot. Practices like version control of infrastructure, application and configuration differ, and the firms' characteristics don't. Nicole also sees a 50% difference in stock price performance between high and low performers over three years. Charity summarizes: you have no excuse. Bridget notes a recent conversation with a large company excited to be getting Git this year.

    An audience member asks whether high performers do stability or throughput first. Nicole doesn't have data on sequence and doesn't see trade-offs, and says gains now come in speed because "slow is the new down" and stability is near its ceiling. Andrew adds "Each nine costs 10 times more than the last one." Another audience member asks Andrew about synthesizing ideas, and Andrew says the best thing a technical person can do for their career is learn to speak and to write, helped by Andrew's time on a debate scholarship.

    Takeaways

    Charity has said no to 26 conferences over the next six months, and wants more acknowledgement at DevOpsDays that this is for software engineers too. Nicole shares Andrew's ideas from the conference: "all code is technical debt," so people should be rewarded for removing it, and "software is never the endgame," so do things for the business, the customer, not because of DevOps. Andrew adds that tests are code and thinks DevOps, microservices and continuous delivery are a single phenomenon, a cloud-native paradigm that can't be treated as separate initiatives in separate silos, and cites Deming: "change is not mandatory. Survival is not mandatory either." Bridget closes by praising Jeff Smith's talk from Grubhub about what happened when they did DevOps, with the spoiler that not everything is unicorns and rainbows.

    How do large enterprises transform the way they do IT? What does it mean for every company to become a software company? Our panel of experts at devopsdays Minneapolis 2016 has worked in some of the largest orgs out there and has seen a lot of transformation first-hand.

    • devopsdays Minneapolis

    • Alice Goldfuss - Rockstars, Builders, Janitors: You're doing it wrong

    • 2016 State of DevOps Report


    Previous 1 12 13 14 15 16 21 Next

    Related Podcasts

    Know How… (Video)

    1

    Know How… (Video) Education
    JavaScript Jabber

    2

    JavaScript Jabber Education
    Programming Throwdown

    3

    Programming Throwdown Software How-To
    Software Engineering Radio – the podcast for professional software developers

    4

    Software Engineering Radio – the podcast for professional software developers Software How-To
    The Changelog: Software Development, Open Source

    5

    The Changelog: Software Development, Open Source How To
    Coding Blocks

    6

    Coding Blocks Software How-To
    footer-logo

    Contact Us

    Toll Free: 844-670-7747

    Links

    • Home
    • Top Charts
    • Networks
    • Apps
    • Independents Podcasts
    • Podcast Advertising
    • Podcast News
    • Contact Us
    • About Us
    • Analytics & Insights

    Stay Connected

      Privacy, Terms of Use & Our Code of Ethics Protecting Content Creators Copyrights