Insightful conversations. Less snark.

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

Are you interested in computer science? How would you like to go to school for free and learn what you need to in just a few months? Then, check out Lambda School! Today, we’re talking to Ben Nelson, co-founder and CTO of Lambda School, which is a 30-week online immersive computer science academy. Lambda School has more than 500 students and takes a share of future earnings instead of traditional debt. So, it's free until students get a job. Some of the highlights of the show include: Bootcamps were created to address engineering shortages and quickly move people into technical careers Lambda is not explicitly a bootcamp; its 30-week program gives students more instructions and more time spent on developing a portfolio Lambda also makes time to cover computer science fundamentals; teaches C, Python, Django, and relational database - not just JavaScript Employers appreciate the school’s in-depth and advanced approach, which results in repeat hires Lambda avoids the typical reputation of traditional for-profit educational institutions by being mission-driven and knowing its investors want ROI Lambda aligns its incentives with those of students; an income share agreement means the school doesn’t make money, unless students are successful Lambda’s 7-month program is less of a risk for someone later in their career; some don't have capital to support their family while going to school for 4 years Lambda incentivizes healthy financial habits; after two years of repayment, students can put that money into retirement, savings, and investments 5 Tracks Now Offered by Lambda: iOS development, UX, Full Stack Web development, data science, and Android development Mastery Based Progression System: When you're learning something sequentially, where knowledge builds, you don't move on until you’ve mastered it Lambda’s acceptance rate is around 5% and based on people who can keep up Lambda works with different partner companies to help them find qualified graduates - people they want to hire Links: Lambda School Ben Nelson on Twitter Y Combinator Wealthfront Datadog

Have you ever been on-call duty as an IT person or otherwise? Woken up at 3 a.m. to solve a problem? Did you have to go through log files or look at a dashboard to figure out what was going on? Did you think there has got to be a better way to troubleshoot and solve problems? Today, we’re talking to Sam Bashton, who previously ran a premiere consulting partner with Amazon Web Services (AWS). Recently, he started runbook.cloud, which is a tool built on top of serverless technology that helps people find and troubleshoot problems within their AWS environment. Some of the highlights of the show include: Runbook.cloud looks at metrics to generate machine learning (ML) intelligence to pinpoint issues and present users with a pre-written set of solutions Runbook.cloud looks at all potential problems that can be detected in context with how the infrastructure is being used without being annoying and useless ML is used to do trend analysis and understand how a specific customer is using a service for a specific auto scaling group or Lambda functions Runbook.cloud takes all aggregate data to influence alerts; if there’s a problem in a specific region with a specific service, the tool is careful to caveat it Various monitoring solutions are on the market; runbook.cloud is designed for a mass market environment; it takes metrics that AWS provides for free and makes it so you don’t need to worry about them Will runbook.cloud compete with or sell out to AWS? Amazon wants to build underlying infrastructure, other people to use its APIs to build interfaces for users Runbook.cloud is sold through AWS Marketplace; it’s a subscription service where you pay by the hour and the charges are added to your AWS bill Amazon vs. Other Cloud Providers: Work is involved to detect problems that address multiple Clouds; it doesn’t make sense to branch out to other Clouds Runbook.cloud was built on top of serverless technology for business financial reasons; way to align outlay and costs because you pay for exactly what you use Analysis paralysis is real; it comes down to getting the emotional toil of making decisions down to as few decision points as possible Save money on Lambda; instead of using several Lambda functions concurrently, put everything into a single function using Go AWS responds to customers to discover how they use its services; it comes down to what customers need Links: Sam Bashton on Twitter runbook.cloud How We Massively Reduced Our AWS Lambda Bill with Go AWS AWS Lambda Microsoft Clippy Honeycomb AWS X-Ray Kubernetes Simon Wardley Go Secrets Manager DynamoDB EFS Digital Ocean

Trying to figure out if Amazon Web Services (AWS) is right for you? Use the “quadrant of doom” to determine your answer. When designing a Cloud architecture, there are factors to consider. Any system you design exists for one reason - support a business. Think about services and their features to make sure they’re right for your implementation. Today, we’re talking to Ernesto Marquez, owner and project director at Concurrency Labs. He helps startups launch and grow their applications on AWS. Ernesto especially enjoys building serverless architectures, automating everything, and helping customers cut their AWS costs. Some of the highlights of the show include: Amazon’s level of discipline, process, and willingness to recognize issues and fix them changed the way Ernesto sees how a system should be operated Specialize on a specific service within AWS, such as S3 and EC2, because there are principles that need to be applied when designing an architecture Sales and Delivery Cycle: Ernesto has a conversation with a client to discuss their different needs Vendor Lock-in: Customers concerned about moving application to Cloud provider and how difficult it will be to move code and design variables elsewhere For every service you include in your architecture, evaluate the service within the context of a particular business case Identify failure scenarios, what can go wrong, and if something goes wrong, how it’s going to be remediated CloudWatching detects events that are going to happen, and you can trigger responses for those events Partnering with Amazon: Companies are pushing a multi-Cloud narrative; you gain visibility and credibility, but it’s not essential to be successful Can you compete against Amazon? Depends on which area you choose Expand product selection to grow, focus on user experience, and improve performance to compete against Amazon MiserBot: Don’t freak out about your bill because Ernesto created a Slack chatbot to monitor your AWS costs Links: Concurrency Labs Ernesto Marquez on Twitter How to Know if an AWS is Right for You MiserBot AWS RDS Lambda Digital Ocean