Sort By
Search
Episode 46: Don’t Be Afraid of the Bold Ask
If you’re looking for older services at AWS, there really aren’t any. For example, Simple Storage Service (S3) has been with us since the beginning. It was the first publicly launched service that was quickly followed by Simple Queue Service (SQS). Still today, when it comes to these services, simplicity is key!
Today, we’re talking to Mai-Lan Tomsen Bukovec, vice president of S3 at AWS. Many people use S3 the same way that they have for years, such as for backups in the Cloud. However, others have taken S3 and ran with it to find a myriad of different use cases.
Some of the highlights of the show include:
Data: Where do I put it? What do I do with it?
S3 Select and Cross-Region Replication (CRR) make it easier and cheaper to use and manage data
Customer feedback drives AWS S3 price options and tiers
Using Glacier and S3 together for archive data storage; decisions and constraints that affect people’s use and storage of data
Feature requests should meet customers where they are, rather than having to invest in time and training
Different design patterns and best practices to use when building applications
Batch operations make it easier for customers to manage objects stored in S3
AWS considers compliance and retention when building features
Mentorship: Don’t be afraid of the bold ask
Links:
re:Invent
AWS S3
Amazon SQS
AWS Glacier
Lambda
CHAOSSEARCH
Episode 45: Everybody Needs Backup and Recovery
Do you have to deal with data protection? Do you usually mess it up? Some people think data protection architecture is broken and requires too many dependencies. By the time a business needs to backup a lot of data, it’s a complex problem to go back in time to retrofit a backup solution for an existing infrastructure.
Fortunately, Rubrik found a way to streamline data protection components. Today, we’re talking to Chris Wahl and Ken Hui of Rubrik.
Some of the highlights of the show include:
Transform backup and recovery to send data to a public Cloud and convert it to native format
Add value and expand what can be done with data - rather than let it sit idle
Easy way for customers to start putting data into the Cloud is to replace their tape environment; people hate tape infrastructure more than their backups
Necessity to backup virtual machines (VMs) probably won’t go away because of challenges; Clouds and computers break
Customers leaving the data center and exploring the Cloud to improve operations, utilize automation
Business requirements for data to have a level of durability and availability
People vs. Technology: Which is the bottleneck when it comes to backups?
Words of Wisdom: Establish an end goal and workflow/pathway to get there
Links:
Rubrik
Chris Wahl on Twitter
Chris Wahl on LinkedIn
Ken Hui on Twitter
Ken Hui on Medium
Amazon S3
IBM AS/400
Amazon EC2 Instances
Azure Virtual Machine Instances
re:Invent
DigitalOcean
Episode 44: Disagree In Commits Console Recorder for AWS
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
Episode 43: Here’s a Document on How to Best Deal with My Foibles
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
Episode 42: SCREAMING WITH CHAOSSEARCH: A reInvent reTrospective
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
Episode 41: Open Source is Not a Business Model
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
Episode 40: Wave of Innovation Breaking Ahead of the Bow of the Ship that is Amazon
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
Episode 39: Give 10 Bad Talks All in a Row and Then Get Fired
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
Episode 38: Must be Willing to Defeat the JSON Heretics
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
Episode 37: Hiring in the Cloud “I assume CrowdStrike makes drones”
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
Episode 36: I’m Not Here to Correct Your English, Just Cloud Bills
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
Episode 35: Metered Pricing: Everyone Hates That! Charge Based on Value
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