Insightful conversations. Less snark.

Do you have some spare time? Can you figure out an easier way to do something? Then, why not build some software?! Today, we’re talking to Ian Mckay of Kablamo, an Amazon Web Services (AWS) consultancy. He is the author of Console Recorder, which is a browser extension that records your actions in the Management Console to convert them into SDK code and infrastructure as code templates. Some of the highlights of the show include: Timeline to build Console Recorder Infrastructure as Code: How to code repeatedly without starting over and take ownership of what you built by hand AWS vs. Individual Achievements: People asked AWS for years to create something to record console click-throughs that Ian did in his spare time Console Recorder support for any browser that exports Web extensions Sharp edges of what’s expected of Console Recorder to speed up development Management Console’s unreadable responses require reverse engineering Console Recorder: Recommended use cases and areas How to alleviate security concerns with Console Recorder Changes to Management Console that may break things Ian’s past, present, and future projects and products Words of Wisdom: If you don’t like something, just fix it yourself Links: Ian Mckay on Twitter AWS Console Recorder Kablamo AWS CloudFormation Terraform MediaLive Jeff Barr re:Invent CDK Google Cloud Platform AWS Management Console AWS RDS AWS Lambda DigitalOcean

A Manager README is a document designed to establish clarity between a manager and those who report to them. These documents are especially useful for onboarding content. For example, if you have someone new starting on your team, there's so many things you need to share with them - pieces of advice and guidance that help them to make the best decision about what to do in specific situations. A Manager README sets some expectations in advance to make things easier and reduce friction and anxiety for team members. Today, we’re talking to Matt Newkirk, who manages Etsy’s localization and translation group. He explains that even if your company has an intensive onboarding program and review process, some things are still left out. A Manager README is a helpful and proactive piece of content that prompts conversations about how people perceive things. Some of the highlights of the show include: Avoid writing READMEs that are extremely self-centered/arrogant READMEs clarify what to do until a relationship is established between the manager and their employee Get feedback early on to make sure that what you include in the document is helpful; it should reflect reality and be discussed Share README with your manager to make sure you’re both on the same page about team philosophies and expectations README is a living document that needs to be updated occasionally because things change README adds context; it’s not designed to make employee feel like they’re back in school and panicking because they’re not prepared Manager README - Not Matt’s best selection of terminology Who’s the best boss you ever had? Why? They can be a force that shapes your life and career from the right perspective Philosophy of Management: Don’t do what terrible managers have done; be transparent about strategic reasons for priorities changing Links: Matt Newkirk Matt Newkirk on LinkedIn Matt Newkirk on Twitter Share your Manager README Etsy Etsy’s Job Openings Shane Garoutte on LinkedIn Kubernetes Everbridge Digital Ocean

Would you like access to unlimited retention of your data within your Amazon S3, which costs far less than online storage on disc? Well, the next time you’re at re:Invent, visit CHAOSSEARCH’s booth. Today, we’re talking to Pete Cheslock, vice president of products at CHAOSSEARCH and former vice president of operations at Threat Stack. CHAOSSEARCH helps people get access to their login event data using Amazon S3. Some of the highlights of the show include: re:Invent - Year of the Pin: People go nuts for conference swag and were collecting pins as if they were gold Scan Your Badge and Drip Emails: Annoying and passive-aggressive marketing trends meant to be spontaneous and interesting Need a job? Corey’s looking to hire a “Quinntern” to use a tag email address to gather conference swag at the next re:invent; if interested, contact him    Corey and Pete’s Swag Rules: Something you want or can use, continues to be valuable, no sizes, no socks Densify Drama: Conference flyer to generate leads failed, created complaints Track and analyze data, but don’t use it to invade privacy or become creepy Las Vegas: Right place for conferences, such as re:Invent? Rather than focusing on going to conference sessions, make meeting and talking to people doing interesting things your priority Midnight Madness Event: Only place Corey could do stand-up Cloud comedy re:Invent 2019: Plan appropriately, identify what you want to get out of it, register ASAP to get a nearby hotel, and schedule meetings with AWS staff Links: Pete Cheslock on Twitter Pete Cheslock on LinkedIn CHAOSSEARCH Threat Stack AWS Amazon S3 Amazon Elasticsearch re:Invent Corey Quinn’s Newsletter Corey Quinn on Twitter Corey Quinn’s Email Sonian Acloud.guru Densify Oracle Apache Cassandra DigitalOcean AWS re:Invent 2018 - Keynote with Andy Jassy AWS re:Invent 2018 - Keynote with Werner Vogels AWS re:Inforce VMware Dreamforce Kubernetes Datadog

Have you ever had high expectations about a new software product? Did you think it was going to be spectacular? Instead, did it become less about solving a problem for you and more about reaching a bunch of billable consultants? The dynamics of open source communities and the Cloud platform can make or break software products. Today, we’re talking to Andrew Clay Shafer, who was a notable voice during the days of OpenStack. He had high hopes for OpenStack, which was an effort to bring a democratized solution of Cloud computing to anyone’s data center. He describes the importance of understanding the challenges associated with open source projects in order for them to be successful. Some of the highlights of the show include: Open source is not a business model; capture value for customers, or they’ll go with a different solution Openness/Closure: Every open source project has its own community dynamics Losing sight of level of expertise for profitability and easy path to useage Whether to become a product or service company - difficult to be both effectively or go from being one to the other; build partner relationship, focus, and say “no” Lack of awareness about AWS Outposts admitting public Cloud is no longer a viable business model Amazon relentlessly focuses on what its customers want and tries to keep promises about what it can and can’t do Cloud Native: Not where you run, but how you run; confining variables Self-fulfilling prophecy to under deliver when you make the bad decision to under source IT across the board Cloud Native, DevOps, SRE: Buzzwords that equal one thing and work together Dilemma of not building everything and buying some things, but you can’t buy everything; humans like to shop and go with the easiest option Links: Andrew Clay Shafer on Twitter Andrew Clay Shafer on LinkedIn Puppet Re:invent OpenStack Eucalyptus Docker Redis MongoDB Confluent Kubernetes AWS Outposts AWS Ground Station AmazonBasics Simon Wardley Maslach Burnout Inventory Datadog

You can't make money selling to developers! The bottleneck of getting business requirements and creating business value used to mean waiting for the next waterfall release. That’s not the case anymore in the venture community. There’s programmatic access to infrastructure and DevOps/agile developments that offer super-fast cycle times. Now, the bottleneck is about how fast your developers can move and how much they can get done. Today, we’re talking to Joseph Ruscio, general partner at Heavybit Industries, which is an accelerator for seed-stage companies and focuses on developer-first products. Tools and products that get you more leverage out of your developers are incredibly valuable. Some of the highlights of the show include: Measuring maturity of startups’ engineering teams by looking at SaaS list - what products they have in place and how many are using out-of-house vendors Customers don’t care how curated or artisan a piece of your stack is, they only care that it works Not all claims (scales infinitely or never fails) are true when it comes to products on the market, so people are skeptical Heavybit focuses on helping businesses build a bottoms-up, grassroots community around its products and a disciplined inside/direct sales motion Build vs. Buy: Whatever people try to do themselves is a costly, pale imitation of something they can buy Advice for New Entrepreneurs: Never compete with AWS on hosting compute because it will obliterate and Amazon is great at plumbing, terrible at painting AWS’s version of your product won't be as sophisticated; continually work on it to deliver a more seamless product and customer success experience Measure downtime/outages in terms of dollars by using monitoring tools that deliver more holistic, integrated, comprehensive experience than CloudWatch Starting a company is easier; even if you're the 800-pound gorilla in the category you created, keep innovating and building or Amazon’s coming after you Azure, unlike GCP, has ability to meet customers where they are, rather than telling them where they should be Understand the problem your customer is trying to solve and understand how far out of their current comfort zone they're willing to go to solve that problem Software exists to create business value; it doesn't matter what it's written in or how it's hosted, so some systems will be around for a long time Links: Joseph Ruscio on Twitter High Leverage Podcast Heavybit Industries Heavybit Library Serverless Framework Pagerduty Stripe Circle Lightstep LaunchDarkly Treasure Data Replicated AWS Twilio Librato re:Invent MongoDB Kubernetes Rackspace New Relic SolarWinds CloudWatch GCP Azure SimpleBB Datadog Digital Ocean

Do you like to hear yourself talk? Especially while on a stage and in front of a lot of people? How do you come up with ideas to talk about? What process do you use to build a conference talk or presentation? Today, we’re talking to Matty Stratton of PagerDuty. His job involves building conference talks and finding ways to continuously improve them. Public speaking can be intimidating, so he shares some tips and tricks that have worked for him. Some of the highlights of the show include: Avoid creating something brand new for every event Don’t tell flattering stories about things that happened to you; may be uplifting, but doesn't resemble reality Failure stories are fantastic because people relate to making terrible decisions Everyone who gives a talk panics, gets nervous, and thinks they’re about a sentence away from stammering and falling off the stage; almost never happens Audience wants you to succeed because they're there to learn; no one is hoping a presenter messes up Preparation is key; could build a talk at the last minute, but it would be much better, if you prepared for it Don’t intentionally try to think of something; have conversations with people and listen to other talks to develop anecdotes, stories, and cold opens Humor can be tricky; what you think is funny, other people might not Make things memorable; show good ideas by showing bad ideas - it’s the ‘don't do this, do this instead’ model Submit early and often, but submit appropriately; if you are always submitting stuff that’s inappropriate for an event, your stuff starts to be ignored Sometimes, you may want to avoid slides that auto advance; if you trip over yourself: Stop, repeat, back up,  take questions, etc. Try not to read from notes or slides; takes the life and engagement out of the talk People can only do one thing at a time - listen or read Practice: Record yourself every time you practice and watch it; focus on blocking and tackling You have about 45 seconds to grab people's interest before they look at their phone; get them engaged via a story, picture, or anecdote Links: Matty Stratton’s Presentations Matty Stratton on Twitter PagerDuty Arrested DevOps Hot Takes, Myths, And Fake News—Why Everyone Is Wrong About DevOps, Except For Me DevOps Dispatch LastWeekinAWS Jez Humble Robert Rodriguez Rebel Without A Crew Adam Jacob from Chef Terrible Ideas in Git Azure DevOps Emily Freeman Decker Communications Don't You Know Who I Am?! Datadog

Do you understand how tabs work? How spaces work? Are you willing to defeat the JSON heretics? Most people understand the power of the serverless paradigm, but  need help to put it into a useful form. That’s where Stackery comes in to treat YAML as an assembly language. After all, no one programs processors like they did in the '80s with raw assembly routines and no one programs with C. Everyone is using a higher-level scripted or other programming language. Today, we’re talking to Chase Douglas, co-founder and CTO of Stackery, which is serverless acceleration software where levels of abstraction empower you to move quickly. Stackery has an intricate binding model that gives you a visual representation - at a human logical level - of the infrastructure you defined in your application. Some of the highlights of the show include: Stackery builds infrastructures by using best practices with security applications What's a VPC? Way to put resources into a Cloud account that aren’t accessible outside of that network; anything in that network can talk to each other Lambda layers let developers create one Git layer that includes multiple functionality and put it in all functions for consistency and management Git is an open-source amalgam of different programming languages that has grown and changed over time, but it has its own build system Stackery created a PHP runtime functionality for Lambda; you don't want to run your own runtime - leave that up to a Cloud service provider for security reasons Should you refactor existing Lambda functions to leverage layers? No, rebuild everything already built before re-architecting everything to use serverless Many companies find serverless to be useful for their types of workloads; about 95% of workloads can effectively be engineered on a serverless foundation Trough of Disillusionment or Gartner Hype Cycle: Stackery wants to re-engage and help people who have had challenges with serverless Is DynamoDB considered serverless? Yes, because it’s got global replication Puritanical (being able to scale down to zero) and practical approaches to the definition of serverless Links: Stackery JSON AWS Lambda Aurora Serverless Data API Hype Cycle Secrets Manager YAML S3 GitHub GitLab AWS Codecommit Node.js WordPress re:Invent Ruby on Rails Kinesis Streams DynamoDB Docker Simon Wardley Datadog

What’s hiring in the world of Cloud like? What are companies looking for in possible employees? What kind of career trajectory should applicants display? Today, we’re talking to Don O’Neill, who has had an interesting career path and the archetype of who most companies want to hire. He’s been an independent contributor, platform leader, and Cloud consultant. Currently, Don is platform engineer manager at Articulate, an eLearning software solution for course authoring and eLearning development. He works with platform engineers to automate Blue Ocean pipelines with Docker, Terraform, and various Amazon Web Services (AWS) technologies, such as Elastic Beanstalk. Some of the highlights of the show include: Don reached out to his network to ask people that he had a professional relationship with about who was hiring and what challenges they faced Don’s “Therapy”: Go to meet-ups to talk about DevOps topics; serves as a “I’ve-got-to-get-my-hiney-out-of-the-house-and-get-some-social-time” Don’s journey from being a “wee lad in the industry” to a senior member/leader and giving back as a way to recognize those who helped him along the way Hiring Horror Stories: People going through borderline ridiculous levels of hiring games and terrible interview paradigms Companies sometimes look for something too specific - exact match instead of fuzzy match; they never have time to train, but time to look for a perfect unicorn Articulate’s Hiring Process: Day 1 - Slack interview; Day 2 - Technical pieces; and Day 3 - Pairing with others Articulate looks for people enthusiastic about technology, able to learn, and with emotional intelligence; company values independence, autonomy, and respect Companies that spend several hours to make a hiring decision tend to have less success with those they hire Cloud Certificates/Certifications: Can be valuable for applicants with no real-world experience; they don’t indicate how they’re going to work or learn Applicants need to demonstrate a base level of knowledge; if they don’t have a skill set, they should start a project to learn about something - learning is fun If you’re established in your career, reach out to someone just starting out to guide them If you’re starting out in your career, reach out to people to talk about the next steps to take in your career (contact Corey or Don) Links: Don O’Neill on Twitter Articulate Hangops.slack.com CoffeeOps AWS Azure Docker Terraform Elastic Beanstalk Autoscan Marchex Apex Learning Dice Monster Indeed Switch App (Tinder for Jobs) Kubernetes Spotify in Stockholm CrowdStrike re:Invent AWS Summits Digital Ocean

Do you enjoy watching sports? Wear your favorite team or player’s jersey? Are you a fan who has shopped at Fanatics on the Cloud? Today, we’re talking to Johnny Sheeley, director of Cloud engineering at Fanatics, which is a sports eCommerce business that manufactures and sells sports apparel. Fanatics runs Cloud engineering to provide a robust and reliable set of services by building and deploying applications on top of the Azure Data Lake Store (ADLS) platform. Some of the highlights of the show include: If you compete with Amazon, be ready for it to come after you; some companies avoid its Cloud perspective or go multi-Cloud (paranoia-based movement) Focus on your ability to make your business function smoothly Transition, migration, and abstraction may be painful, but should not stop work; paying for Cloud-agnostic technology may not be worth it Challenges of governing use of Cloud resources to prevent mistakes/problems related to Fanatics’ security and budget Data collected focuses on what’s trending up or down to select an instance type that calculates costs; remain flexible and be aware of what you pay Natural instinct is to blame people; mistakes are made, especially when a human factor is introduced to an automated system Creating a mindset that focuses on feature and detail-oriented is challenging Cottage industry of code bases running in Big Data and other expensive realms As a product continues to evolve and grow, governance comes along for the ride and AWS bills are streamlined Will serverless, Lambda, and RDS change how Amazon charges in the future? State of scale of AWS and developing a more palatable method for releases because people can’t keep up with them and stop paying attention Two-Pizza Team: Amazon’s management philosophy that any team that works on a service should be able to be fed with two pizzas Such small teams work quickly and have the freedom to fail, but Amazon has a reliability for the longevity of its different services Links: Johnny Sheeley's Email Johnny Sheeley on Twitter Rands Leadership Slack Hangops.slack.com Fanatics Kubernetes Azure Lambda RDS Getafix: How Facebook Tools Learn to Fix Bugs Automatically Accidentally Quadratic Blog re:Invent Jeff Barr’s AWS News Blog Amazon SimpleDB Lots of Amazon's projects have failed...and that's ok, says Amazon's Andy Jassy Digital Ocean

Did you know that you can now run Lambda functions for 15 minutes, instead of dealing with 5-minute timeouts? Although customers will probably never need that much time, it helps dispel the belief that serverless isn’t useful for some use cases because of such short time limits. Today, we’re talking to Adam Johnson, co-founder and CEO of IOpipe. He understands that some people may misuse the increased timeframe to implement things terribly. But he believes the responsibility of a framework, platform, or technology should not be to hinder certain use cases to make sure developers are working within narrow constraints. Substantial guardrails can make developers shy away. With Lambda, they can do what they want, which is good and bad. Some of the highlights of the show include: Companies are using serverless as a foundation and for critical functions Serverless can be painful in some areas, but gaps are going away Investing in the Future: Companies doing lift-and-shift to AWS are looking at technology they should choose today that’s going to be prominent in 3 years Serverless empowers new billing models and traces the flow of capital; companies can choose to make pricing more complicated or simplified What value are you providing? Serverless can offer flexible pricing foundation When something breaks, you need to be made aware of such problems; Amazon bill doesn’t change based on what IOpipe does, which is not true with others Developers are the ones woken up and on call, so IOpipe focuses on providing them value and help; they are not left alone to figure out and fix problems Serverless and event-driven applications offer a new type of instrumentation and observability to collect telemetry on every event   For serverless to go mainstream, AWS needs to up its observability level to gather data to answer questions AWS, in the serverless space, needs to make significant progress on cold starts in other languages, and offer more visibility and easier deployment out of the box Links: IOpipe Episode 16: There are Still Servers, but We Don't Care About Them Lambda Google App Engine Python Node.js Kubernetes Simon Wardley DynamoDB re:Invent Perl PowerShell Digital Ocean

In the early days, angry nerd corners on the Internet viewed Slack and some of its predecessors as, “Oh, it’s just IRC. Now, you pay someone for it.” Many fell into that trap of wondering about what value such systems offered.The big differentiator? Slack is built as a collaborative business tool. Today, we’re talking to Holly Allen, who helped make government software better while  serving as the director of engineering at 18F. Now, she’s a senior engineering manager at Slack, a collaborative chat program where you can do most of your work through a rich platform of integrations. Holly enjoys taking a weird set of skills that make a computer do things and convincing people who know how to make computers do things do things. Some of the highlights of the show include: Safety engineering brings chaos and resilience engineering, incident management, and post-mortem processes together for resiliency and reliability Slack strives to move really fast while being in complete control Slack is primarily on AWS, but is working on a multi-Cloud strategy because if AWS is down, Slack still needs to work Slack has a close relationship with AWS and is a collaborative company; it has immediate access to AWS staff anytime there’s a problem Slack uses Terraform and Chef and working to determine if its production workflows in Kubernetes would be worthwhile Disasterpiece Theater: Real scenario that might happen and surmise what will happen; don’t cause production issues, but teach Slack employees Slack hires collaborative, empathetic people to create a collaborative environment where everyone works together toward a goal Slack was firmly in a centralized operations model, but is transforming toward development teams to increase responsibility and service ownership Slack doesn’t encourage remote work because it’s not in a position to put in that investment; day-to-day work happens in hallways and between desks Slack sees itself as an enterprise software company; an enterprise software company must have enterprise software reliability, stability, and processes Slack has thousands of servers, so events and disruptions happen more often; system needs to respond, react, and repair itself without human intervention Links: Holly Allen on Twitter 18F Slack Freenode IRC HipChat AWS Kubernetes Terraform Chef QCon Datadog

If you’ve been doing DevOps for the past 10-20 years, things have really changed in the industry. There’s no longer large pools of help desk support. People aren’t climbing around the data center and learning how to punch down cables and rack servers to gradually work their way up. Now, entry level DevOps jobs require about five years of experience. So, that’s where internships play a major role. But how can an internship program be set up for success? Where is the next generation of SREs or DevOps professionals coming from? Where do we find them? Today, we’re talking to Fatema Boxwala, who has been an intern at Rackspace, Yelp, and Facebook. She’s a computer science student at the University of Waterloo in Canada, where she’s involved with the Women in Computer Science Committee and Computer Science Club. Occasionally, she teaches people about Python, Git, and systems administration.   Some of the highlights of the show include: Mentors made Fatema’s intern experience positive for her; made site reliability and operations something she wanted to do Academic paths don’t tend to focus on such fields as SRE, and interns tend to come exclusively from specific schools Fatema’s school requires five internships to graduate and receive a degree; upper-year students are already very qualified professional software engineers Companies don’t have time to train and want to find someone with an exact skill set; instead of hiring someone, they spend months with an unfilled position Continuity Problem: You can’t train someone to be a systems administrator, if you aren’t willing to give them certain privileges due to inexperience Use a low-stakes environment to train, where mistakes can be made; most systems aren’t on a critical path - don’t keep people away from contributing If you have never broke production, that means either you’re lying or you’ve been in an environment that didn’t trust you to touch things that mattered Internship should mimic the kind of work that everyone else is doing; give them responsibilities where their work has an impact Bad mentors lead to bad internships; person in charge of your success doesn’t have the necessary skills; needs to be a good communicator, set expectations As the intern, ask about possible outcomes of internship early on; mentors should be clear about expectations, feedback, and offers Links: Fatema Boxwala Fatema Boxwala on Twitter Jackie Luo on Twitter Julia Evans Zines on Twitter SREcon MEA Digital Ocean