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:
    Fireside Chat with Grandpa Paul Dec 04, 2017
    Show notes
    • https://en.wikipedia.org/wiki/Cynefin_framework
    • http://theshipshow.com/
    • Does Humor Belong In Technology
    • Bryan Berry’s blog post
    • Live DevOps Call In Show with Dr. Nicole Forsgren
    • @theitskeptic on Twitter
    • Wardley mapping introduction and Simon Wardley's free Wardley Mapping book
    • New York Times article on life at Etsy today
    • This American Life episode about NUMMI
    • DOES17 San Francisco - How Your Systems Keep Running Day After Day - John Allspaw
    • The Ship Show - Extinguishing Burnout
    • Twitter thread about adding release management features to git
    • Sysadvent Day 3 - 14 Tips for Git Giddiness in 2014

    Matt refers to an episode of “Coupling” on the BBC - the episode was Series 1, Episode 2, “Size Matters” - here’s the quote:

    Patrick: Oh, don’t be so piecey.
    Howard: Typical lefty puritan..
    Sally: Typical what? Come the revolution-.
    Patrick: What revolution!? You guys are in power! We’re the revolution now!.
    Sally: No. No, it can’t be right...
    Patrick: You’re the evil empire..
    Sally: No!.
    Howard: Yes! Like Star Wars, and Patrick and me are the Rebel Alliance..
    Sally: No! You’re not the goodies, we’re the goodies! We’re lefties!! We’re always goodies!.
    Patrick: puts glass on his mouth and makes a Darth Vader voice No, Sally. You’re the establishment.

    Open CFPs

    • https://www.devopsdays.org/speaking/
    • https://conferences.oreilly.com/velocity
    • https://chefconf.chef.io/cfp/

    Image credit
    By inkknife_2000 [CC BY-SA 2.0 (https://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons


    Fireside Chat with Alice Goldfuss Nov 28, 2017
    Show notes

    Bridget sits down for a remote chat with Alice Goldfuss, a site reliability engineer at GitHub who loves systems, lower-level problems and kernel panics, and also tea, cats, chocolate and box forts. Alice joins from the rainy Northwest with a desk lamp aimed at the face. The cold open is Alice's line, "Ladies is gender-neutral now," which turns out to be the name of a t-shirt. At the end, Alice says that if it had been announced as a fireside chat, Alice would have set something on fire in the background.

    Curating LISA

    Alice was talks co-chair for LISA, the Large Installation System Administration Conference, which USENIX runs and which has been around for over 30 years, back when a large installation meant 10 workstations. USENIX handles logistics and brings in people from the community each year to select talks, workshops, tutorials and keynotes. Alice likes that it is non-vendor-specific and for practitioners, and describes three days of training and workshops followed by three days of a more traditional conference. The 2017 event was in San Francisco, the next in Tennessee and the following one in Portland.

    In choosing talks, Alice wants the how: "there's a difference between how to use Docker and how we used Docker to change up our infrastructure." Alice also says "I also really love a good outage story," and wanted Niantic to talk about the Pokémon GO launch. Bridget asks how to get stories with failure in them past a company's lawyers. Alice says it's hard, since companies fear customers questioning an SLA, but an engineer hearing honest failure stories is more likely to buy, and talks from Google have gotten through when the incidents were old or vague enough. LISA, Alice says, sits at the end of the year when people are tired of flashy conferences and more willing to talk.

    Reaching Out for Talks

    Alice ran devopsdays Portland's vendors and MC duties, and did not choose talks that year, but encouraged people to submit who otherwise wouldn't have. A more diverse selection committee used its networks, telling people it would be a safe space. Bridget says that when you post a CFP and do nothing else, you get the people whose job it is to submit, so a broader range means reaching out. Alice's first conference talk, at LISA in 2015, happened because someone who was a chair that year reached out, and "someone reached out to me and said, I think you have something to add here." Alice adds that looking at past talks by people with PhDs would have scared Alice off.

    Alice says it matters who is reaching out and why. An invitation to a Python conference said it was looking for more women, for a framework Alice hadn't worked with in years, and Alice's reaction was "you just want a woman, that's all this is." Bridget says no one wants to be a decorative prop. Reaching out works when it names something specific, which Bridget calls "conference invitation Mad Libs," and when it says why the conference is good for the speaker, since Alice has to justify conference travel to an employer.

    Learning to the Bottom of the Stack

    At GitHub, Alice started on the Edge team, which handled the network tier and a custom load balancer, and now works on the Kubernetes platform that all of GitHub.com runs on, with plans for kernel-level work. Alice grew up in a very small upstate New York town with a Windows 95 computer and no internet until 16, so learning happened alone, with Compton's Encyclopedia for AP Calc. Alice has a film degree, started in tech support, tried Ruby and disliked it, then liked Python, and took an early Coursera programming class that built games in eight weeks. Alice says "I've had a career of doing one job during the day and learning to do another job at night," and prefers "self-guided" to self-taught, since other people wrote the materials. The method is the Socratic why, which keeps leading lower in the stack.

    Alice's laptop was resting on Understanding the Linux Kernel, the Practical Linux Security Cookbook and Docker Up and Running, and since the kernel book's examples are in C, Alice learned C for fun. Alice brought the kernel book to jury duty. For concepts like Kubernetes, YouTube videos with diagrams help, and Stack Overflow answers supply jargon to search the man pages. Alice carries a chip on the shoulder about lacking a CS degree, but says "I've made it this far without having to know really any computer science," and that knowing arrays and hashes gets you far. Bridget notes that even with a CS degree you still Google constantly.

    Interrupt Designs

    Alice made a t-shirt with a Panic! at the Colonel design after wanting shirts that weren't unisex tech swag, and when it sold, began donating the money. The first went to Women in Linux. Then came the "ladies is gender-neutral" shirt, made to answer "guys is gender neutral," offered only in fitted sizes and sold with every line conference organizers use on unisex shirts. It raised over $5,000 for Outreachy. A Manic Pixie Dream Girl shirt with PXE as the pixie benefits Free Geek, a Portland organization that refurbishes donated equipment. Alice moved from Teespring to Threadless for more cuts and colors, and includes sizes up to 4X. Fitted shirts, Alice says, should be table stakes for vendors, though they don't fit all women. Alice adds that scarves made things much easier for devopsdays Portland's swag, since no one needs a size.

    Humor, Loudness and the Internet Persona

    Bridget asks what Alice wants people to take from posting things that poke the bear. Alice says humor works: "comedy allows you to point out things that otherwise would be considered offensive or people would instantly shut down to," like the fool in a Shakespearean play, and people remember it better than a blog post with citations. Jokes about sexism may also embolden people to talk about it at work. Alice says the loudness comes from being vocal about things that get in the way, like sexism and racism: "I talk about them a lot because I want them to go away." Alice also talks about technical things and baking.

    Chairs, Meetups and Practice Talks

    Alice had been at GitHub over seven months before ordering an office chair, a Steelcase Gesture with narrow armrests that suit a smaller frame, describing the research habit as being "like the missing stair enabler of office equipment." Alice runs the PDX DevOps Meetup on the last Wednesday of the month, and encourages speakers to come, since the bar is lower than at a conference, with no recording, and a repeated talk is welcome. Bridget's tip is to give a conference talk at a local meetup the month before, pointing to a local speaker who changed about half the slides after the first run. Alice gives at least two practice talks, and plans to use the PDX meetup for the next new one. Alice likes devopsdays for the local angle, since it's harder to claim something can't be done locally when an organization three blocks away has done it.

    Planning 2018 and Containers in Production

    Alice plans the year during the holidays, because of a need to manage emotional highs and introvertness, and wants to keep 2018 domestic with not too many new talks. A planned January keynote was postponed indefinitely. Alice would like to give a technical keynote on three or four years of running containers in production: at New Relic, Docker went into prod at version 0.6, and Alice has run Dockerized databases and now runs Kubernetes at GitHub. Alice calls it "the mechanic's view of containers," leaning on the podium with a rusty wrench saying it's going to break, and jokes "Your problem is all of the whales that you put all your apps in." Bridget counts 29 public talks in 2016 and calls that too many.

    Career Advice

    Asked how people grow up to be Alice, the answer mixes self-guided learning with a network outside your employer. Alice says soft skills are a real deficit in tech, and that giving talks and keeping a social media presence is "kind of like a bridge between all of your jobs" and a safety net if a job ends, since you don't want your only network inside one company. Befriending women in tech has made life easier, Alice says, and the network doesn't have to be women. "Don't let your job be your whole life," because failing at work shouldn't take everything else down with it. Bridget adds that networking means connecting over common interests, and that following someone on Twitter doesn't make them your BFF. Alice adds that you can't control a promotion, but you can control learning a new language.

    For listeners trying to DevOps at their own companies, Alice says things are easier with buy-in from the top, since a grassroots effort without a VP's backing is hard, and convincing a manager's manager helps. If you keep hitting obstacles and aren't enjoying work, Alice says it may be time to look elsewhere, since "your job shouldn't be your whole life."

    Bridget sat down for a fireside chat with Alice Goldfuss (GitHub). No actual fires were harmed in the making of this episode.

    • LISA17
    • devopsdays Portland
    • Charity T-Shirts - Interrupt Designs - awesome nerdy shirts with proceeds going to charity

    Checkouts

    Alice

    • Chair
    • Baking Scale - round metal, good for scones
    • Increment Magazine
    • SysAdvent
    • Airplane food critique website
    • Sailor Mercury zines

    Bridget

    • Go Pirates - Veronica Mars podcast
    • Bombsheller leggings - again! because they’re just that great
    • Jewelbots - because I got Joe’s 10-year-old niece in the gift exchange
    • Nerdy Baby - great STEM gifts

    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

    Use code "ADO2017" for a discount on many devopsdays.

    Open CFPs

    • lots of DevOpsDays
    • SREcon - March 27-29 2018 - CFP closes Wednesday, November 29, 2017, 11:59 pm PST
    • ScaleConf Colombia - April 27 - 28th 2018 - CFP closes Jan 15
    • Velocity San Jose - June 12-14 2018 - CFP closes Jan 17

    devopsdays Madison 2017 with Emily Freeman, Joshua Zimmerman, & Christian Herro Oct 31, 2017
    Show notes

    Devopsdays Madison 2017 was the second year for this event. With great speakers, workshops, open spaces, and sponsors, this event brought the community together to learn and share.

    Bridget and Matt sat down with a speaker (Emily Freeman) and a couple of organizers (Joshua Zimmerman & Christian Herro) to talk about the wider themes of organizational change when you may not call all the shots in your org.

    • Emily Freeman's talk: Scaling Sparta: Military Lessons For Growing A DevOps Team

    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

    Use code "ADO2017" for a discount on many devopsdays.

    Open CFPs

    • lots of DevOpsDays

    Velocity with Inés Sombra & James Turnbull Sep 25, 2017
    Show notes

    Ines Sombra (Fastly) and James Turnbull (Empatico) are chairs of the Velocity conference series, which is celebrating its 10th year in 2017. They joined Bridget to talk about the events next month in New York and London, and share tips for making the most of your conference as well as submitting talks to future conferences.

    • The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier

    Check outs

    James

    • Launching new classroom collaboration project Empatico
    • Product-launch survival food Indomie Mi Goreng instant noodles
    • Bundle of Terraform and Packer books

    Inés

    • Fastly Teams growing the EdgeApps services - ImageOpto, Video, Load Balancing
    • Recently got into Almond lattes (like a true Californian)

    Bridget

    • Bombsheller leggings - I just bought circuitboard ones, and I see also that they have Settlers of Catan ones. WANT.
    • Cloud Developer Advocates at Microsoft - I just joined this awesome team!

    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

    Use code "ADO2017" for 20% off at Velocity New York Oct 1-4.

    Use code "ADO2017" for a discount on many devopsdays.

    Open CFPs

    • lots of DevOpsDays

    Live DevOps Call in Show with Nicole Forsgren Aug 30, 2017
    Show notes

    Food Fight Show and Arrested DevOps joined forces to host our first live devops call in show! We featured Dr. Nicole Forsgren to answer your DevOps questions about measuring effectiveness, ROI of DevOps initiatives, and more!

    Recorded May 8, 2017.

    The unofficial title of this episode: "Ya sure, Nicole?"

    • DORA - DevOps Research and Assessment
    • This ep on Food Fight Show
    • Kelsey Hightower's devopsdays Austin 2017 keynote
    • Release! The Game

    Check outs

    Nicole

    • Velocity San Jose 2017
    • DOES London
    • Metrics Workshops
    • 2017 State of DevOps Report

    Nell

    • devopsdays Seattle 2017
    • The Expanse

    Matt

    • Robot Unicorn Attack 3
    • Robocall protection with Nomorobo
    • School of Rock

    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

    Use code "ADO2017" for 20% off at Velocity New York Oct 1-4.

    Use code "ADO2017" for a discount on many devopsdays.

    Open CFPs

    • lots of DevOpsDays

    CI, CD, Oh My! with Jez Humble Aug 23, 2017
    Show notes

    Bridget talks with Jez Humble, who was last on the show in episode 15, about three years earlier, on continuous delivery. Since then Jez spent a year at 18F, a team inside the US federal government, working on infrastructure and on cloud.gov, a platform as a service built with Amazon and open source Pivotal Cloud Foundry to show agencies that continuous practices work in government. Now Jez works at DORA, DevOps Research and Assessment, with Nicole Forsgren, Sue Choi and Gene Kim, the team that produced the State of DevOps report with Puppet Labs. The cold open is a story about a Zen temple that returns at the end of the episode.

    What DORA Measures

    DORA's assessment surveys an organization's people against 20 capabilities the research has linked to IT performance, from culture to practices like automated deployment and managing work in process. It compares the organization to the industry, and with a group of 50 or more people it can say which investments give the most return. Bridget raises the customer who wants a RACI chart for who should do each thing. Jez's answer is that an organization should have a few strategic priorities and each team should work out how to collaborate, agreeing on a measurable goal for the next month. There's no way of knowing in advance who will have to change, "but, you know, my money is on everyone." Jez says DORA is "all about data," including measurable culture, and that picking a fight with Nicole over stats is a losing one.

    What the Continuous Things Are

    Jez defines continuous integration as building and testing every change, working off a shared trunk and not long-lived feature branches, with a quick, comprehensive automated test suite, so that the default state of the system is a working one. Jez tests people with three questions: does everyone check into a shared trunk at least once a day, do tests run on every check-in, and when the build breaks, is it typically fixed within 10 minutes? Most people can't answer yes to all three. Running Jenkins against feature branches and ignoring it when it turns red isn't continuous integration: "It's a practice and mindset, not a tool." Bridget notes the CI/CD theater, and Jez says DORA uses yes/no and agree/disagree questions, and that "asking the questions is, in many ways, the hard part," and "People love redefining terms so they can say they're already doing it."

    Continuous deployment means a passing build goes to production automatically, with high performers deploying hundreds or thousands of times a day. Continuous delivery is behaving as if you'd do that without deploying every build, which suits firmware or mobile apps, and still improves quality, cost, time to market and feedback loops. Bridget plays devil's advocate with Schrödinger's deployment, where a build could go out but a schema migration wasn't accounted for. Jez says to "do continuous deployment wherever you can," and that Jez wouldn't build non-web software unless forced to, noting people at Facebook who deploy mobile apps every couple of weeks aren't happy about it. Jez points to a recent Charity Majors blog post about testing in production, and agrees that production needs good monitoring, logging and tracing, and cheap, low-risk deploys through blue-green deployments, canaries, feature flags and circuit breakers. Jez says to accept that "failure is inevitable," and recalls that John Allspaw's focus on mean time to restore over mean time between failures was an aha moment. Bridget adds Andrew Clay Shafer's state of continuous partial failure.

    Organizations That Keep Improving

    Asked about the common thread among organizations on the path, Jez's answer is that "The best organizations are always trying to get better," and are never satisfied. Even Amazon and Facebook invested huge effort, and Jez notes Amazon was a monolith that spent four years re-architecting after making it a priority at all levels, consistently and with money. Jez adds that Amazon has miserable, dysfunctional pockets too, and Bridget asks whether that means software is made of humans.

    The Agile 2017 Keynote

    Bridget asks for the Cliff Notes of the end of Jez's Agile 2017 keynote. Jez explains that an ex-Google employee, James Damore, had written a 10-page document about Google and the causes of low representation of women and people of color in the industry, and that Jez was angry we're still having the discussion in 2017, like being angry about talking about continuous integration after 15 years. Jez holds up Douglas McGregor's The Human Side of Enterprise, from 1960, on motivating teams. Jez says there are biological differences, but real outcomes come from a complex interaction of genetics, epigenetics and environment, and "you can't go from those biological differences straight to differences in ability." Jez recalls telling the audience that math and science can't explain the lack of diversity, but sharing a work environment with people like Damore can, and some people walked out. Jez argues that unequal access to highly paid, high-status tech jobs is inequitable, produces worse products and affects the economy, and that people who care about the minutiae of tech but not how teams are composed will do worse, since these are systemic problems and the system is what dominates.

    Bureaucracy, InfoSec and Lunch

    Bridget asks about siloes. Jez says it's highly variable and depends on who leads each team. A high point of Jez's career was the federal government, where Jez met mission-driven, brilliant, hardworking people, including in InfoSec, and learned from Mark Schwartz's talk that bureaucracy can be helpful because it encodes what people think is the right way to do things. Jez's "number one DevOps hack" is to find the person everyone slags off, often InfoSec in the dev world, take them to lunch, and spend an hour actively listening to what's in their way. Bridget asks for a British-to-American translation of "slag off," and Jez says it means trash-talking someone.

    Bridget asks what individual contributors can do. Jez says it's making friends and understanding different perspectives, as in learning why a rule exists from the person who had the problem. Jez argues that "Most of the problems we face are due to a lack of empathy," pushing back on the idea that the obstacle is a failure to systemize. DORA measures collaboration between Dev and Ops, asking whether the outcome is win-win, and measures culture with the Westrum model, a construct from sociologist Ron Westrum, which John Allspaw also pointed Jez to, studying safety outcomes in healthcare and aviation along six axes. Jez says information flow is critical for resilient organizations, and "You can build the best systems in the world and use the best tools in the world, but if your cultural organizational structure is wrong, it just won't work."

    Cargo Culting and the Andon Cord

    Jez says large agile frameworks get adopted without changing procurement, contracting, leadership or organizational structure, and then "you're just shuffling around the chairs on the Titanic." The point of practices is to change the organization's behavior, and Jez objects to cargo culting. Jez says knowing where you are and where you're going in measurable terms comes first, and when people copied Toyota, "You're copying the practices, you're not copying the mindset and the culture of continuous improvement." Bridget gives the example of an andon cord in a place where pulling it gets you fired. Jez points to the NUMMI story on This American Life, where other GM factories copied the cord, but managers were rewarded by how many cars came off the line whether or not they worked, so pulling it got you fired.

    Where Change Needs Buy-In

    Jez cites John Kotter's Leading Change, whose first step is that most employees, about 75% of management and virtually all top executives need to believe that considerable change is essential. That shows up as ruthless prioritization, and it's "much easier to change an organization where there's a burning platform than it is to change an organization where everyone thinks that everything's just fine." Some leaders won't state priorities in measurable terms because it takes away the ability to change their minds. Jez says individuals can still effect change, though the impact will be limited and making it stick is the hard part, and organizations have backslid after people left. The original Continuous Delivery book came from a team of eight and colleagues working on miserable projects with Bash and CVS, transforming how an application was deployed, which shows "you can achieve great things with small teams." Jez adds "There is no linear path from A to B."

    Jez closes with the Zen temple story from the opening, told by the teacher at an introduction to meditation: sometimes you come to the temple feeling down, sometimes feeling great, "But don't worry, because that feeling will pass too." Jez thinks that sums up DevOps and the human condition. Jez also encourages listeners to speak at conferences, since you're probably doing things other people would be excited to hear about.

    Bridget chats with Jez Humble (DORA) about continuous... everything!

    • Continuous Delivery - ADO Ep 15 - Jez's previous ADO episode
    • DORA - DevOps Research and Assessment
    • Westrum model of organizational culture
    • The course website for Info 290M Lean/Agile Product Management, a three unit graduate class taught by Jez Humble at the UC Berkeley School of Information
    • Jobs at 18F - director job opening soon!

    Check outs

    Jez

    • Manjula's Kitchen
    • Plutopia - Nuclear families, Atomic Cities and the Great Soviet and American Plutonium Disasters

    Bridget

    • Favorite food blog: Smitten Kitchen
    • New-to-me food blog: Mountain Mama Cooks
    • Great Electric American Roadtrip

    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

    Use code "ADO2017" for 20% off at Velocity New York Oct 1-4.

    Bridget will be at Uptime in Pittsburgh this week.

    Open CFPs

    • lots of DevOpsDays

    Use code "ADO2017" for a discount on many devopsdays.


    devopsdays Minneapolis 2017 with Bryan Liles, Jessie Frazelle, and Andrew Clay Shafer Jul 29, 2017
    Show notes

    Bridget and Matty record live at devopsdays Minneapolis 2017, putting two keynote speakers in one conversation. Bryan Liles of Capital One, who opened the conference, took what Bryan calls a total non-tech approach: people matter more than anything, plus experiences of DevOps in the enterprise and how it could be better. Jessie Frazelle of Google, who closed, talked about security in a containerized world, making security on by default so that 99% of users benefit. Bridget calls the pairing "fanfic of the conference talks." Midway through, Andrew Clay Shafer wanders in from a game of werewolf in another room and describes Andrew as "A villager, not a werewolf." The cold open is Bryan explaining the vein of a banana.

    Incentives With Nothing but a Smile

    Bridget asks how to incentivize people in tech. Bryan says "the only incentive that I have is a smile," and describes spheres of influence: tensions occur where bubbles touch, so Bryan tries to make a bubble more permeable and bigger. Jessie says incentives are hard in open source because you can't pay people, so you use their interests, and don't push them into work they don't want to do, since it's free labor. Matty notes that Jessie's slides paired each deep technical point with a person problem, and that making security hard is itself an incentive, since people turn it off. Bryan adds that incentives are harder at big companies because "you can really blend in" and do the bare minimum for years.

    Let Users Fail Well

    Bryan took a note from Jessie's talk: "We should always allow our users to fail well." People will do the worst thing possible, so the default should leave no room for it: "You can't add privileges to Docker. You get what you get and you can only take away." Bridget says defaults apply to organizations too, and asks what a team does if no one takes any action. Bryan says people do the easiest thing, like turning off SELinux or booting cloud instances without thinking about security groups, and wants all that to be on by default, like a banana you have to peel.

    Matty tells of a sysadmin who wanted a release manager reporting to the CTO with hiring and firing power over developers so they'd follow a new release process. Matty's answer was to "make the right way the easy way," as in the book Switch, whose factory machine was redesigned to need both hands on switches away from the blade. The happy path should be a glide path, where "the default should be the happy path," and doing it wrong means fighting the current.

    Saying No as a Maintainer

    Bridget points to a GitHub thread in Jessie's slides where users wanted a use case that would harm the general one. Jessie says the maintainer takes the heat for saying no, and the aim is to leave the mass of users unaffected, while "someone's always going to be pissed off at the end of the day." Bryan recalls one key moment in that thread, when someone came 100 posts down and admitted reading none of it. Jessie remembers the reply, "maybe if you find the time to read the rest of the issue, you will know what is happening right now," and says friends in Slack absorb the heat not sent back on GitHub. Matty calls it a troll flame radiator.

    Bridget asks Bryan how to handle people fighting for their local optimizations. Bryan says a job isn't a place where you get your way all the time, and "at the end of the day, it's org first," but the approach is to set expectations early and offer tradeoffs, inside what Bryan calls a "circle of respect." Jessie says in open source there is mutual respect, and multiple maintainers will take the wheel when someone gets frustrated.

    Vendors, Customers and the Scale of Jerkiness

    Matty, who works for a vendor, explains that Matty and Bridget are advocates inside their companies, and a vendor doesn't have infinite resources. When a large customer demands a feature, a company may redo everything, run a 90-hour week, and compromise 10 to 20 other customers, without anyone asking five whys. Bryan's rule is "It's don't be a jerk," and every decision asks whether it's being a jerk, since there's a scale of jerkiness. Bryan wouldn't demand a feature now, but would point out that a vendor hinted at three months, and that was four months ago. Matty says roadmaps are not promises of dates.

    Bridget wonders whether unpaid users are more demanding. Jessie says "Everybody wants their thing, their Turing-complete thing that will make their life so easy," and that some users eventually say thanks after a maintainer adds the feature out of spite. Jessie notices when an issue comes from someone at a company using the tool, and those people are mostly willing to contribute the fix. Bridget notes Allstate contributed authentication and authorization work to open source Cloud Foundry, which Pivotal sells in a commercial distribution.

    Intersourcing and Pressure From Above

    Bryan describes intersourcing, open source to a company and no one else, and says it exists for good reasons in a specialized vertical like a bank. Inside Capital One, Bryan uses GitHub and gets pull requests all the time, and some are closed because they ignore the roadmap. Bryan says when people push hard internally it's because someone else is prodding them with a fork, and "we're all archaeologists." Matty calls it closed-door open source, and says open source has already solved collaborative coding, so vendors should stop trying to invent it. Matty adds that asking why uncovers the driver three levels up, and Bryan would call the person and say both of you are trying to get things done.

    Matty asks about incentives for smaller maintainers. Jessie says "giving people responsibility actually goes a long way," meaning commit rights or code review, and it becomes gamification of reaching maintainer, though some people just want a thank you.

    Open Source in the Enterprise

    Andrew says open source isn't always shiny, happy people. You can create a lot of value and capture little, and people assume they're entitled to enterprise-level support for weekend efforts. Bridget asks Bryan the right way for an enterprise to consume and contribute. Bryan says it's complicated: licenses and patents, for example, and without patent indemnity, using someone's open source could lead to being sued for IP, so "there's levels to this." Jessie says Jessie stays far from Google's secret sauce to avoid messing up.

    Andrew says some people want to give money to projects and there's no good way to, and that adoption sometimes stalls for lack of governance or indemnification. Others go YOLO, and Andrew says "I would be shocked if most enterprises realize what code's actually in production." Matty knows a CTO who requires code review of every open source project, and someone submits 10,000 lines of code that goes straight to prod. Bryan has been at Capital One since the previous October, after doing open source full time, including contributing to Terraform and writing Go for DigitalOcean. Bryan says the bank tries to know everything that goes into production, given the stakes. Bridget adds that during a startup acquisition Bridget had to find every license and rip out one library whose terms would have given the acquirer's IP away.

    Closing: Tech and People Together

    Asked how to get people to do the tech work and the people work, Bryan says to be the example, with empathy. Jessie says being kind makes people kind back. Matty, who coaches customers and isn't a line manager, says to be genuine, because fake coaches get smelled out. Andrew reinforces that, and says the two can't be solved separately: "there's not really a tech and a people thing. That it's one system."

    Bridget and Matt chat about enterprise transformation and open source with guests Bryan Liles, Jessie Frazelle, and Andrew Clay Shafer, in front of a live studio audience at devopsdays Minneapolis 2017.

    • devopsdays Minneapolis 2017

    • Sys Admins, DevOps, SRE. Oh My! - Bryan Liles' opening keynote

    • Security In A Containerized World - Jessie Frazelle's closing keynote

    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

    Open CFPs

    • lots of DevOpsDays

    Use code "ADO2017" for a discount on many devopsdays.


    Go Small or Go Home with Daphne Chong and Kenny Bastani Jul 02, 2017
    Show notes

    Bridget and Matty record the last of six live episodes at GOTO Chicago, a panel on microservices with Kenny Bastani and Daphne Chong. Kenny is a Spring developer advocate at Pivotal, on Bridget's team. Daphne is a software engineer at Amazon who has lived in the UK, the US and Australia, and gave a talk on video transcoding at the ABC, which Daphne clarifies is the Australian Broadcasting Corporation. The episode opens with Bridget asking what advice Daphne would give someone who thinks they need some microservices, and the answer is "Don't."

    Why Split It Up

    Daphne's reason for microservices at the ABC was scale. One part of the system, transcoding, has to scale far more than everything else, and the microservices part "tended by accident really," once that piece was separated. Transcoding means converting a video or audio file from one format to another, and the ABC needed to do it over its whole catalog, with requirements that commercial transcoders and Elastic Transcoder didn't meet. The transcoding service takes a JSON packet saying which file to transcode and where to save the output. It can run on a larger AWS instance type suited to the job, and Daphne says the cost of that instance goes 100% to transcoding. Matty calls that an interesting angle on showback and chargeback.

    Bridget points out that spreading work across services adds complexity, and Daphne answers "I think you just move the complexity. Because there's always complexity everywhere." Bridget says that is Tim Gross's "conservation of complexity." Daphne says independently deployed services tend to be stable, and adding a captioning extraction service would sit apart from the others, leaving the main complexity in coordinating which service is called when.

    What Is a Microservice?

    Matty asks how this differs from service-oriented architecture, which Matty worked with at a dot-com years earlier, with a mail service and a lead conversion service behind versioned APIs. Kenny says recent research into continuous delivery changed the definition Kenny started with. A shared delivery pipeline means you're "technically taking public transportation to production," batching up changes from, say, 500 engineers on one monolith. Splitting the pipelines lets people commit and deploy independently. Kenny admits "We're really bad at naming things," then lists small teams organized around business capabilities, independent deployability and a decomposition strategy, and calls it "a better SOA." A rule of thumb: if a new engineer takes longer than a day to ramp up on a service, it should probably be two services. Bridget, speaking as someone on the receiving end of the pager, adds that if a health check can only say some of it is working, too much is crammed into the service.

    Kenny's talk covered event-driven microservices, using events to maintain the integrity of foreign key relationships when a large shared database is torn apart. Somebody had found the Cloud Foundry management endpoint on a Spring Boot app in one of Kenny's demos, and crashed the application of ten microservices from an iPhone. Matty guesses that someone thought they were at DEF CON.

    Don't Just Rub Microservices on It

    Kenny passes along Matt Stein's line that microservices aren't the solution: you already have a problem, and want to go faster or scale. Matty says every VP wants a fill-in-the-blank this quarter, and Bridget recalls an open space at an Agile conference where someone said their VP wanted microservices that quarter. Kenny's advice is to get data first, for instance "How much unchanged code are you deploying per deployment?" Kenny notes that even a monolith on continuous delivery could be deploying every 11.6 seconds. Matty adds that the question is whether you need to go faster at all. Daphne says unchanged code is risk, since every deployment might go wrong, and Matty says small changes minimize the blast radius, which is a reason even if speed isn't.

    Kenny says shared resources are a good reason to consider microservices or serverless, and expects a healthy microservice architecture to reduce unchanged code per deploy. Kenny would like to test that by mining GitHub, though no enterprise is going to put its code there. Kenny and Josh Long spent two years writing a book, Cloud Native Java, on cloud-native applications with Spring Boot, Spring Cloud and Cloud Foundry, which had gone to press, with a copy expected in early June.

    Daphne's own route to microservices wasn't a formal journey. A team averaging about three people, each knowing a different part, built small pieces, and the scale question drove it. The project "kind of secretly started a bit off-piste" as a proof of concept that would save money.

    Conway's Law and Weaponized Microservices

    Bridget says teams sometimes want independently deployable services to avoid interacting with other teams, and asks about weaponizing microservices. Kenny: "Oh, they're already weapons." Kenny says teams need empathy for the services they consume and produce, and describes consumer-driven contract testing, where you publish a contract and other services test against a mock, so you can't reach production without passing consumer tests. That pushes you to go to other teams instead of them coming to you, "a good way to prevent evil." Matty adds that Conway's Law also works in reverse: at places with little trust, a change from hunter green to forest green on the front end meant testing the whole website down to the data warehouse, because nobody trusted the contracts. "No matter what, people are terrible," Matty says, and Kenny says to make the less terrible thing easy.

    Serverless, Replatforming and Product Lifecycles

    Bridget asks how serverless fits. Daphne says you still need to deploy and debug the serverless pieces, and the smaller the piece the easier it is: "it's a tool that you should wield in particular circumstances, and otherwise you're just gonna be shooting yourself in the foot." Kenny is researching how Lambda binds you to event sources that lock you into AWS, and suggests a Spring Boot microservice as an event source with Lambda functions as event handlers, though Kenny doesn't know of anyone doing it in production.

    Matty says enterprises move slowly, and most enterprise customers on AWS or Azure use only compute, not things like RDS, because they want to hold on to configuration, and a DBA wants to look at a slow query log. Matty's private serverless GIF is an empty data center. The appeal of tools like Habitat is getting some of the value without rewriting an app into a 12-factor app, and Matty can't make a legacy .NET app on Windows 2008 serverless. Kenny defines replatforming as modifying applications to suit a platform that runs them differently, such as a cloud-native one, and says it makes sense where competition is rough. The IRS, Kenny guesses, wants to move faster but faces higher risk and little competition.

    Matty brings in Marty Cagan's kill, maintain and innovate for products. A product on the kill list shouldn't be rewritten, one in maintenance doesn't need faster delivery, and only the innovate ones do. Matty says that's where bimodal IT goes wrong, though the Gartner idea properly read is that "different teams move at different speeds," like "one transmission for all of our teams, they're just in different gears." Bridget calls bimodal IT horseshit, and Matty's point is that declaring "microservice all the shit" skips thinking about each product's lifecycle.

    The Ridiculously Stupid Thing

    Asked for the most ridiculously stupid thing to do, Kenny says creating microservices for things the business doesn't drive, or special snowflake services like image filtering for one consumer. Daphne's answer is languages: the ABC system used different ones for different services, which is fine as long as you don't end up with 20, so "Don't write them all in 10 different things." Matty adds "Don't write one in Ada." Kenny adds shared libraries, since upgrading one across 500 microservices is trouble. Bridget warns about the hidden distributed monolith, where everything still talks to the same database, and Kenny's test is that if one change means deploying all ten microservices, "you've got a distributed monolith."

    Bridget and Matt chat with Daphne Chong (Amazon) and Kenny Bastani (Pivotal).

    • Daphne's GOTO Chicago talk: Video Transcoding at the ABC with Microservices

    • Kenny's GOTO Chicago talk: In the Eventual Consistency of Succeeding at Microservices

    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

    Open CFPs

    • lots of DevOpsDays

    Tupperware Party with Jérôme Petazzoni, Mark Heckler, and Jennifer Heckler Jun 28, 2017
    Show notes

    Bridget and Matty record at GOTO Chicago with three guests to talk about containers, with Matty playing the listener who knows very little about them. Mark Heckler is a developer advocate on Bridget's team at Pivotal, a Java and Spring developer who also works with Cloud Foundry. Mark and Jennifer Heckler, Mark's daughter and a programmer analyst at Edward Jones, gave a talk that morning on clouds and containers aimed at developers. Jérôme Petazzoni has been at Docker since before it was Docker and once managed a small team of SREs, before giving up the pager to explain Docker and containers to people. Jérôme says that adds up to six years of Docker experience "even though Docker is only 4 years old." Jennifer is the only person on stage who doesn't work at a vendor.

    From Lightweight VM to Just Processes

    Matty asks what the paradigm shift is, since customers often just want to spin up a container instead of a VM. Jérôme says the lightweight VM idea helps people grasp what a container is, but it should be dropped quickly: "it's just processes," or for the technically inclined, cgroups and namespaces. Containers will be many things to many people, the way virtualization went from stacking machines on a host, to cloud APIs, to disposable environments for CI. Matty asks whether calling a container a lightweight VM is itself a wrong statement as a global claim, and Bridget says it depends on the use case. Jérôme sticks to the point, calling the metaphor "just the tip of the iceberg," and noting there are use cases where it doesn't make sense.

    Mark adds the developer view, which is packaging. A VM is "just like driving a nail with a sledgehammer," while a declaratively configured image is repeatable, lightweight and easy to deploy. Bridget adds that a golden image stamps out your application and also a Heartbleed baked in, and Mark says rebuilding and retesting an entire golden image each time a backing service moves is heavy compared with a new Docker build.

    Runtimes and Choosing One

    Bridget asks for the most incendiary line in the talk, and Mark says nothing was flame-worthy, except that some people will not run on a Docker runtime while others will only run on one. Every new Docker release brings cries of anguish when something breaks, and some people are frustrated by the move-fast approach. Bridget asks Mark to explain what a runtime is. Mark sketches runc for initiating containers from images and containerd as the Docker runtime, with other vendors using other execution engines: Joyent Triton, which Mark describes as running Docker containers on Solaris zones, Cloud Foundry, which builds a container per the Docker image format and still uses runc, and CoreOS Rocket.

    Jérôme says Docker's strategy is to give people options, such as swapping runc for Rocket, or SwarmKit for Kubernetes, and compares the choice to picking a hypervisor. For a first cloud VM, you shouldn't spend an hour deciding between EC2 and DigitalOcean, and after hacking at the "cloud jungle" with a machete you'll know enough to choose. Matty agrees that you can't judge engines by letters you don't understand yet, and that "you'll know you need a scheduler when you need a scheduler."

    Diving In

    Bridget asks Jennifer about the actual adoption at Edward Jones. Jennifer says some teams are using containers, and some even run in production, which Jennifer only learned a few weeks earlier. Jennifer describes the financial advisors as the main moneymaker, and the concerns as security and reliability across six time zones. Containers connect to reliability because a sick container is replaced by a new one. Jennifer describes approaching the topic like standing on a beach and looking at the ocean, trying to find where to enter the water, then downloading VirtualBox, Docker, Kubernetes and PCF Dev, following Docker's docs, and running commands like ps to see the output. Jennifer says "You're not gonna horribly break something." Mark adds that Mac users should use the stable builds of Docker.

    Matty, who uses Docker to test cookbooks because a container is faster than a VM, warns that at some point you have to test on something that looks like production, unless production is a container. Mark agrees that less deviation between dev, test and prod is better. On databases, Jérôme asks "should you be running your database in the first place?" If you have one Postgres server and a manual failover in the middle of the night, it probably shouldn't be in a container. If you spin up thousands of databases, say one per CI test, containers pay off. The one deviation Jérôme encourages between prod and dev is running the database in a container in dev when production uses a third-party service.

    Ops Visibility and Buildpacks

    Matty says ops people see a container and ask what the hell it is. Bridget asks whether it holds an unpatched operating system. Jérôme calls the fear unfounded technically, but says techniques that work with VMs don't map to containers, and uses SSH as the example: you can attach a shell to a running container, so there's no need to cram an SSH server and keys into it. Communities, vendors and bloggers exist to share those tricks.

    Mark raises the difference between a Docker image and a Cloud Foundry buildpack, where the container is built around your application. When something like Heartbleed hits, the ops team can patch the underlying platform and reach into those lower layers, so developers don't need to rebuild, and Mark says "That's good and bad, right?" Matty says Habitat is a similar idea of abstracting a layer away.

    Domain Experts and Guardrails

    Bridget asks what to tell a developer who wants to create their thing and not care about buildpacks. Matty says to get off "this full-stack nonsense," since domain experts need to be domain experts, and that whatever is built, be it a Docker image, a Converge node or a binary, is an artifact that should be tested for compliance on its way through deployability. Jennifer says there are two sides: wanting to customize everything, and not having all the time in the world. Matty adds the example of a developer who reads on Stack Overflow that disabling SELinux helps a Node app and changes the cookbook, and says guardrails and fast feedback catch that before security wags fingers. Jennifer says you have to know what's valuable to your company. For a financial firm, that means regulation and privacy, plus user experience teams that once rejected a product for not being user-friendly to financial advisors. Mark says it's a matter of prioritization, developing your expertise and relying on others, and that containers "don't fix your broken culture."

    Aha Moments

    Matty asks for the surprising moment. Jérôme says there was no single one, but a series of crazy experiments, such as running a container on Linux that held a VM showing a screen of Moby running containers inside containers. Matty compares it to Sean O'Meara's configuration management parlor trick of CFEngine installing Puppet that configures Chef. Mark's moment was a gradual realization, from asking why we need this when we have VMs to spinning up Redis or Mongo in containers and seeing the potential. Jennifer says reading Docker docs wasn't enough until building and deploying a simple application, with the realization that you deploy one application in one container, not onto a massive piece of machinery.

    Bridget asks Jérôme for a two-sentence explanation of Moby, and the answer is one: "Docker Inc. is a company that makes Docker, a product that uses Moby, an open source project." Jérôme credits Laura Frank with the explanation.

    Bridget and Matt chat with Jérôme Petazzoni (Docker), Mark Heckler (Pivotal), and Jennifer Heckler (Edward Jones).

    • Mark & Jennifer's GOTO Chicago talk: Clouds & Containers: Hit the High Points and Give it to Me Straight, What's the Difference & Why Should I Care?

    • Jérôme's GOTO Chicago workshop: Container deployment, scaling, and orchestration with Docker Swarm

    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

    Open CFPs

    • lots of DevOpsDays

    Risky Business with Nicole Johnson, Matt Curry, and Anthony Lee Jun 19, 2017
    Show notes

    Bridget and Matty record at GOTO Chicago about risk, security and compliance in a DevOps pipeline. Nicole Johnson, who gave a talk on incorporating compliance and security testing into the release process, works with Matty at Chef, and Matty realizes Matty's own "shifting left securely" talk says nearly the same things. The other guests are Matt Curry, a director of cloud engineering at Allstate who leads the organization taking Allstate into the cloud and building its platform as a service, and Anthony Lee, who says Anthony is patient zero for the digital transformation initiative known as Compose, now 2.5 years in. The cold open is Matty's line: "people lie. Computers don't lie."

    Bringing Audit Along

    Bridget asks how an insurance company's customers and regulators shape this. Matt says the compliance and security teams were the tough part of the continuous integration journey, because "explain your job in an algorithm" puts people on the defensive, as if they're being replaced by a robot or a shell script. Anthony adds that insurance means state-by-state regulation plus PCI and SOX. The team reached out to its internal audit organization early and asked them to look at the work, and the greatest outcome was that the lead auditor eventually worked for Matt as a product manager. Anthony relays that auditors saw every production deploy trace back to a GitHub commit, and the reaction was, "I've never walked out of an audit with a smile on my face."

    Matty says every company has compliance with a lowercase c, meaning the standards important to the organization, and everybody thinks they're special. The "dirty little secret" is that one of the biggest ways Chef gets into companies is through audit and compliance, "because people lie. Computers don't lie." Nicole says compliance teams get scared when you go fast without them and hand over a spreadsheet or PDF, but once they're part of the process, they see the value and can collect data programmatically. Matty adds that nobody is automated out of a job, since the risk officer's big brain still decides what's important and the task is describing it consistently. Matt says engaging audit early made communication bidirectional, educated them on what new tools could do, and let the team understand their incentives, which turn out not to be checking the box. That was a chance to "build a bridge rather than kind of pile another brick on the wall," and Bridget notes that bricks into a bridge instead of a wall sounds suspiciously like DevOps.

    Audit Theater and the Compliance Sine Wave

    Matty draws a sine wave of compliance: a company does its regular business and drifts down, then scrambles before the quarterly audit, the auditors show up and leave, and it drifts down again. Bridget asks whether it's really more of a cliff. Matty says that when compliance is part of the process, you're continuously compliant, and a compliance officer knows an auditor could walk in at any time. Anthony describes the typical response as adding process on top of process: one audit finds a missing document, so a process is added to check for the document, and the next audit finds that the checking process failed. "That's what the system solves for you."

    Shifting Left, Hardening Sprints, and Democratized Compliance

    Matty describes a project that ends with a hardening sprint for security testing, which fails because nobody has looked all along, leaving a choice between delaying or getting an exception. Matty's point is that "the bad guys on the internet don't care that you have a note from your mom that says it's okay you didn't patch Heartbleed." Nobody would accept saving QA for the last sprint, and the closer to a defect's introduction you find it, the cheaper it is to fix. Bridget adds what happens if you find out six weeks later, after eight dependencies rely on the hole. Matty says you have to "democratize your compliance."

    Bridget recalls a line from Nicole's talk that Bridget tweeted: a raise of hands for whose job security and compliance are, with the point that all hands should be up. Nicole says it's not a joke. Anyone who touches a system is responsible for compliance, and before you even get to testing, the systems should be hardened, or you reach production with a gold-standard image and find the hardened images break the app. Nicole says you can't make everything compliant right away, so start with the lowest barrier to entry.

    Make the Right Thing the Easy Thing

    Anthony tells of a security team's preferred scanning tool, which Anthony won't name beyond a company that starts with an I and ends with an M, that the devs tried to get into their pipelines and could not. Once security acknowledged it wouldn't work for agile and went with another tool, about 60 dev teams switched in around two weeks, and every commit now goes through the scan. Bridget cites Andrew Clay Shafer's "make the right thing the easy thing," and Matty recalls the example from the book Switch of a machine redesigned so both hands had to be away from the blade.

    Bridget asks what leadership does when it needs to impose a choice. Matt says "if you have a problem that every developer needs to solve, that should become a platform concern," and imagines a world where you don't opt out of certain parts of the CI pipeline. Artisanship is fine inside constraints, and Matt explains the thinking in systems terms: "committees are not scalable," since teams that haven't moved this way can't get a meeting for months. Matty adds that the list of things needing human intervention is shorter than people think. Writing the standard needs a human brain, while checking a system against it does not, and Matty quotes the Continuous Delivery book saying that asking a highly skilled person to do a boring, monotonous task "introduces more errors than inebriation or sleep deprivation." Nicole adds that the standards still need the right humans, those who interact with the systems, to supply context to committees, since you'll never slap a CIS benchmark document on and be 100% done.

    One Pipeline Shape

    Matty says Allstate's decision that there's one way of doing CI and CD means not 60 different teams, and a feature team's core competency isn't building a pipeline. Bridget calls that resume-driven development, and Matty offers "excitement-driven development." Matt says consistency matters for compliance because it makes deployments auditable, predictable and boring. Matty explains the shape stays the same even when Maven differs from another build, so you can look in one Jenkins log no matter the project. Bridget asks Anthony how to motivate people away from what's on the front page of Hacker News, and Anthony says it's a never-ending fight between good and evil, kept grounded by user focus. A team shipped from start to production without talking to the platform team once, which makes it worth it, and constraining the outcome leaves flexibility over tooling.

    Culture, Tools, and Vendors

    Nicole asks how hard it was to change the culture. Matt credits open-minded partners in security and compliance, and says the process is often based on tools already bought, so it becomes a financial conversation, with a sales rep having promised the tool would solve world hunger. Matty adds that organizations tend to throw good money after bad because a decision was made. Bridget notes vendors outnumber customers on the panel. Anthony says that when choosing between Cloud Foundry and OpenShift, the team minimized vendor interaction to judge how well they could run the software on their own, though some vendors won't give access to a download site until a big check is signed. Anthony doesn't advocate cutting vendors off, and credits a great partnership with one.

    Matty says a good vendor partner wants to understand what you're trying to do, not force it a particular way, and Nicole, who is on the presales side, says it means asking the hard questions, such as why do it like that, and serving as a go-between for teams. Matty tells of Bridget referring a contact, who was having compliance problems, to Nicole about Inspect, which surprised the contact because Bridget works at Pivotal and Inspect is seen as a competitor's product. Bridget says the best thing for that customer is often Cloud Foundry, and Cloud Foundry is not Inspect. Matt adds a test for vendors: ask whether they say "yes, totally, I've done this before," or go find the one person in a 10,000-person company who may have kludged it once.

    Closing Advice

    Anthony says to apply the DevOps habit of small, frequent changes to organizations and people: "Small things, small incremental things." Matt says partnership, trust and credibility are the foundation, and that you may have to invest upfront in establishing them. Nicole says everyone is working toward the same goal, even with different paths to getting compliant or secure. Matty says if competitors can hug at a DevOps conference and "give each other hug ops," teams inside one company can too.

    Bridget and Matt chat with Nicole Johnson (Chef), Matt Curry (Allstate), and Anthony Lee (Allstate).

    • Nicole's GOTO Chicago talk: Automating Security & Compliance (for Fun & Profit)

    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

    • Velocity San Jose - discount code "ADO2017" gives 20% off for Gold, Silver, and Bronze passes.

    Open CFPs

    • lots of DevOpsDays

    Previous 1 10 11 12 13 14 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