POPULARITY
9 episodes with jeff barr
6 episodes with jeff barr
6 episodes with jeff barr
6 episodes with jeff barr
2 episodes with jeff barr
2 episodes with jeff barr
9 episodes with jeff barr
2 episodes with jeff barr
Proximo talks to Jeff Barr, a senior vice president at Plenary Americas, about the I-10 Calcasieu River Bridge project financing and the broader US P3 landscape.
In this special episode from AWS re:Invent 2024, Jon Myer sits down with AWS Chief Evangelist Jeff Barr to discuss his incredible 20-year journey writing the AWS Blog. Jeff shares insights about starting the technical blog in 2004, his commitment to accuracy and authenticity, and his exciting plans for the future. Learn about Jeff's impact on the AWS community, his experience at re:Invent, and the promise of purple hair that might signal his eventual retirement. Key Takeaways:
In this special episode from AWS re:Invent 2024, Jon Myer sits down with AWS Chief Evangelist Jeff Barr to discuss his incredible 20-year journey writing the AWS Blog. Jeff shares insights about starting the technical blog in 2004, his commitment to accuracy and authenticity, and his exciting plans for the future. Learn about Jeff's impact on the AWS community, his experience at re:Invent, and the promise of purple hair that might signal his eventual retirement. Key Takeaways:
Dans cet épisode, Seb récapitule les principales annonces faites après la conférence AWS re:Invent 2024. Il met en avant la keynote de Werner Vogel sur la gestion de la complexité dans l'architecture des systèmes. Il aborde également les nouvelles instances EC2 et les réductions de prix sur certains services. Enfin, il rend hommage à Jeff Barr, une figure emblématique d'AWS, qui a annoncé qu'il ne publierait plus de blogs pour AWS.
Welcome to episode 285 of the Explain it to me Like I'm 5 Podcast, formerly known as The Cloud Pod – where the forecast is always cloudy! We've got a lot of news this week, including the last of our coverage from re:Invent, ChatGTP Pro, FPGA, and even some major staffing turnovers. Titles we almost went with this week: Throw $200 dollars in a fire with ChatGPT Pro Jeff Barr is wrapped up by Agentic AI The Tribble with Trilliums The Wind in the Quantum Willows Rise of the dead instances FPGA and PowerPC Jeff Barr is replaced by Nova The Cloud Pod: Return of the dead instances types After 6 year Jeff Barr hands over the reigns to the CloudPod For our 6th birthday Jeff barr Retires For our 6th birthday jeff barr delegates announcements to the cloud pod 6 years of meaningless PR drivel 6 years of cloud news and we still don't know what Quantum computing is A big thanks to this week's sponsor: We're sponsorless! Want to get your brand, company, or service in front of a very enthusiastic group of cloud news seekers? You've come to the right place! Send us an email or hit us up on our slack channel for more info. General News HAPPY 6th BIRTHDAY! 2:00 HashiCorp at re:Invent 2024: Security Lifecycle Management with AWS Hashi is a big sponsor of re:Invent, so of course they had some news of their own to release. HCP Vault Secrets auto-rotation is now generally available. Dynamic secrets are generally available via HCP Vault Secrets. Secrets sync will help keep your secrets synced with AWS Secrets Manager. It still appears to be one direction, but you can now also view secrets in AWS Secrets Manager that are managed by vault. HCP Vault Radar, now in beta, automates the detection and identification of unmanaged secrets in your code, including AWS infrastructure configurations 03:10 Matthew – “This qualifies under the category of things that I feel like we talked about so long ago, I just already assumed was GA. I’m surprised that it wasn’t.” 03:34 HashiCorp at re:Invent 2024: Infrastructure Lifecycle Management with AWS Terraform AWS provider is now at 3 billion downloads. The
This week, we discuss Jeff Barr's departure from AWS, OpenAI's latest announcements, and Broadcom's AI ambitions. Plus, Matt debates the finer points of Australian vs. American Apple Intelligence. Watch the YouTube Live Recording of Episode (https://www.youtube.com/live/PY1z81cRZiU?si=w1F7i-d7frDG27DN) 498 (https://www.youtube.com/live/PY1z81cRZiU?si=w1F7i-d7frDG27DN) Runner-up Titles That's a streak That's not a thing I miss the cold-calling lifestyle I miss being a JSON engineer I have trust issues with AI The metaphor was good Welcome to the treadmill Rundown Jeff Barr leaves AWS: And that's a wrap! (https://aws.amazon.com/blogs/aws/and-thats-a-wrap/) 12 Days of OpenAI (https://openai.com/12-days/) (6-9) Day 6: Advanced voice with video & Santa mode (https://youtu.be/NIQDnWlwYyQ) Day 7: Projects in ChatGPT (https://youtu.be/FcB97h3vrzk) Day 8: Search (https://youtu.be/OzgNJJ2ErEE) Day 9: OpenAI o1 and new tools for developers (https://openai.com/index/o1-and-new-tools-for-developers/) API, ChatGPT & Sora Facing Issues (https://status.openai.com/incidents/ctrsv3lwd797) Broadcom Broadcom shares rise 13% on profit beat, 'massive' opportunity in AI (https://www.cnbc.com/2024/12/12/broadcom-avgo-earnings-report-q4-2024-.html) Nvidia falls into correction territory, down more than 10% from its record close (https://www.cnbc.com/2024/12/16/nvidia-falls-into-correction-territory-down-more-than-10percent-from-its-record-close.html) VMware And Custom AI Chips: Broadcom's Recipe For Explosive Growth (https://seekingalpha.com/article/4744807-vmware-and-custom-ai-chips-broadcoms-recipe-for-explosive-growth) Relevant to your Interests Republican lawmakers ask Trump to kill IRS Direct File (https://www.nextgov.com/digital-government/2024/12/republican-lawmakers-ask-trump-kill-irs-direct-file/401595/) Adobe delivers strong Q4, record Firefly generations, but light outlook (https://www.constellationr.com/blog-news/insights/adobe-delivers-strong-q4-record-firefly-generations-light-outlook) Data Exports for FOCUS 1.0 is now in general availability (https://aws.amazon.com/blogs/aws-cloud-financial-management/data-exports-for-focus-1-0-is-now-generally-available/) Duolingo has bucked the post-pandemic blues in edtech (https://www.threads.net/@techmeme/post/DDj5oW5q8-N?xmt=AQGzIRoyTuZ2pO3q5kMBDSUXzruFwt7tqsJmvg732iQ_KQ) Satya Nadella | BG2 w/ Bill Gurley & Brad Gerstner (https://podcasts.apple.com/us/podcast/bg2pod-with-brad-gerstner-and-bill-gurley/id1727278168?i=1000680168104) API, ChatGPT & Sora Facing Issues Incident Report for OpenAI (https://status.openai.com/incidents/ctrsv3lwd797) AWS re:Invent 2024 - Best practices and new tools for cost reporting and estimation (https://www.youtube.com/watch?v=L6di_mQ2sKE) BlackBerry sells Cylance for $160M, a fraction of the $1.4B it paid in 2018 (https://techcrunch.com/2024/12/16/blackberry-sells-cylance-for-160m-a-fraction-of-the-1-4b-it-paid-in-2018/) EU signs $11B deal for sovereign satellite constellation to rival Musk's Starlink (https://techcrunch.com/2024/12/16/eu-signs-11b-deal-for-sovereign-satellite-constellation-to-rival-musks-starlink/) Nuon Seed + Series-A Funding (https://nuon.co/blog/byoc-for-everyone/) Databricks to Hit $62 Billion Valuation in Massive Funding Round (https://www.bloomberg.com/news/articles/2024-12-17/databricks-to-hit-62-billion-valuation-in-massive-funding-round) Android XR: The Gemini era comes to headsets and glasses (https://blog.google/products/android/android-xr/) A vision for Android XR (https://www.youtube.com/watch?v=Pn5uG1ys-pE) Gemini 2.0: Our latest, most capable AI model yet (https://blog.google/products/gemini/google-gemini-ai-collection-2024/) China orbits first Guowang Internet satellites, with thousands more to come (https://arstechnica.com/space/2024/12/china-orbits-first-guowang-internet-satellites-with-thousands-more-to-come/) Microsoft just released a tool that lets you convert Office files to Markdown (https://github.com/microsoft/markitdown) Nonsense Trump says GOP will push to eliminate daylight saving time (https://thehill.com/homenews/campaign/5039673-trump-gop-daylight-saving-time/) Gen Z says no to slim fit pants (https://bsky.app/profile/dieworkwear.bsky.social/post/3ldakaoeuhs24) The 1000-Foot High Rollercoaster Dream (https://interthemepark.com/1000rollercoaster.html) Timey Wimey (https://timeywimey.co/?ref=labnotes.org) (https://bsky.app/profile/dieworkwear.bsky.social/post/3ldakaoeuhs24)## Listener Feedback Great site collating AWS reInvent sessions along with their slides (https://reinvent-planner.cloud/sessions?catalog.view=cards&catalog.cardSize=large) Conferences CfgMgmtCamp (https://cfgmgmtcamp.org/ghent2025/), February 2-5, 2025. Civo Navigate North America (https://www.civo.com/navigate/north-america), San Francisco, Feb 10-11, 2025 DevOpsDayLA (https://www.socallinuxexpo.org/scale/22x/events/devopsday-la) at SCALE22x (https://www.socallinuxexpo.org/scale/22x), March 6-9, 2025, discount code DEVOP SDT News & Community Join our Slack community (https://softwaredefinedtalk.slack.com/join/shared_invite/zt-1hn55iv5d-UTfN7mVX1D9D5ExRt3ZJYQ#/shared-invite/email) Email the show: questions@softwaredefinedtalk.com (mailto:questions@softwaredefinedtalk.com) Free stickers: Email your address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) Follow us on social media: Twitter (https://twitter.com/softwaredeftalk), Threads (https://www.threads.net/@softwaredefinedtalk), Mastodon (https://hachyderm.io/@softwaredefinedtalk), LinkedIn (https://www.linkedin.com/company/software-defined-talk/), BlueSky (https://bsky.app/profile/softwaredefinedtalk.com) Watch us on: Twitch (https://www.twitch.tv/sdtpodcast), YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured), Instagram (https://www.instagram.com/softwaredefinedtalk/), TikTok (https://www.tiktok.com/@softwaredefinedtalk) Book offer: Use code SDT for $20 off "Digital WTF" by Coté (https://leanpub.com/digitalwtf/c/sdt) Sponsor the show (https://www.softwaredefinedtalk.com/ads): ads@softwaredefinedtalk.com (mailto:ads@softwaredefinedtalk.com) Recommendations Brandon: ChatGPT Mac App (https://openai.com/chatgpt/desktop/) Photo Credits Header (https://unsplash.com/photos/sydney-opera-house-australia-jK9dT34TfuI) Artwork (https://unsplash.com/photos/a-black-background-with-a-red-and-purple-light-5-lnaaMenBI)
Welcome to episode 271 of the Cloud Pod Podcast – where the forecast is always cloudy! Justin, Jonathan and Matthew are your hosts today as we discuss the latest news in cloud and AI, including earnings reports, Google's legal trouble, and SQL updates. We even take a minute to give some side eye to AWS's deprioritization techniques. Spoiler alert: 0 out of 5 stars for keeping customers informed. Titles we almost went with this week: No Google, you can't own Park Place, Boardwalk, the railroads and the utilities Amazons Titan Image Generator is no titan of photography BigTable graduates to SQL support TikTok/Instagram, Azure Reliability and Temu bring down the big three clouds’ earnings Span your Mind to Graphs & Vectors DOJ rules The Cloud Pod should be your default news source The CloudPod – now with SQL support AWS Deprioritizes 7 Services, Cloud Pod Hosts Prioritize Therapy A big thanks to this week's sponsor: We're sponsorless! Want to get your brand, company, or service in front of a very enthusiastic group of cloud news seekers? You've come to the right place! Send us an email or hit us up on our slack channel for more info. Follow Up 00:45 Amazon decision to deprioritize 7 cloud services caught customers and even some salespeople by surprise Jeff Barr confirmed on Twitter (Yes will always call it Twitter) after recording last week’s episode that they had made the tough decision to deprioritize 7 cloud services. There is still no official blog post announcing this, beyond the confirmation from Jeff Barr. Amazon is discontinuing new access to a small number of services in the tweet – but would continue to run them in a secure environment. Jeff Bar confirmed the list of services to be S3 Select, CloudSearch, Cloud9, SimpleDB, Forecast, Data Pipeline and CodeCommit. An AWS Spokesperson claimed to Business Insider that the changes were communicated through multiple channels within and outside the company. But were they REALLY though? 01:33 Justin – “Yeah, they kind of took a leap out of the Hitchhiker’s Guide to the Galaxy book and put the planning commission in the filing cabinet downstairs with the broken light.” General News It's Earnings Time! 07:35 Alphabet meets earnings expectations but misses on YouTube ad revenue Alphabet revenue was up 14% YOY, driven by search and cloud, GCP surpassed $10B in quarterly revenues and
Why AWS changed its policy on charging for HTTP errors on S3 buckets, how Bluesky dealt with an explosion in popularity by moving to on-prem, IBM buys Hashicorp, and our thoughts on cloud governance. News/discussion How an empty S3 bucket can make your AWS bill explode Jeff Barr responds on Twitter Update: S3 engineers... Read More
Why AWS changed its policy on charging for HTTP errors on S3 buckets, how Bluesky dealt with an explosion in popularity by moving to on-prem, IBM buys Hashicorp, and our thoughts on cloud governance. News/discussion How an empty S3 bucket can make your AWS bill explode Jeff Barr responds on Twitter Update: S3 engineers … Continue reading "Hybrid Cloud Show – Episode 04"
In this week's edition, we dive into the exciting release of ElixirLS 0.21.0, enhancing the developer experience with new code actions and more efficient dialyzing on the latest OTP. We also discuss José Valim's insightful commentary on Elixir's upcoming type system, addressing bug-prone comparison operations, and additional advancements in exception handling. Don't miss the unveiling of "Bloom," an opinionated extension to Phoenix core components, alongside Chris McCord's demo of lightning-fast hot code deploys across a global Fly.io cluster. We round off with the legal tussle over the FTC's ruling on non-compete clauses and AWS's S3 billing adjustments that provide relief from unauthorized access charges, and more! Show Notes online - http://podcast.thinkingelixir.com/202 (http://podcast.thinkingelixir.com/202) Elixir Community News - https://elixirforum.com/t/elixirls-the-elixir-language-server/5857/213 (https://elixirforum.com/t/elixirls-the-elixir-language-server/5857/213?utm_source=thinkingelixir&utm_medium=shownotes) – Announcing the release of ElixirLS 0.21.0 with improvements and features like incremental dialyzer and experimental support for code actions. - https://github.com/elixir-lsp/elixir-ls/pull/1057 (https://github.com/elixir-lsp/elixir-ls/pull/1057?utm_source=thinkingelixir&utm_medium=shownotes) – A pull request related to the experimental support for code actions in ElixirLS 0.21.0. - https://pragtob.wordpress.com/2024/05/01/10-elixir-gotchas/ (https://pragtob.wordpress.com/2024/05/01/10-elixir-gotchas/?utm_source=thinkingelixir&utm_medium=shownotes) – A blog post by Tobias Pfeiffer discussing "10 Elixir gotchas" to help new Elixir developers. - https://twitter.com/PragTob/status/1785681200322924666 (https://twitter.com/PragTob/status/1785681200322924666?utm_source=thinkingelixir&utm_medium=shownotes) – Tobias Pfeiffer's tweet about his blog post on "10 Elixir gotchas." - https://twitter.com/PragTob/status/1785681200322924666 (https://twitter.com/PragTob/status/1785681200322924666?utm_source=thinkingelixir&utm_medium=shownotes) – José Valim's response to Tobias Pfeiffer's post, providing insights on Elixir's upcoming type system. - https://twitter.com/josevalim/status/1785989792141890015 (https://twitter.com/josevalim/status/1785989792141890015?utm_source=thinkingelixir&utm_medium=shownotes) – José Valim details how the Elixir v1.17 will perform type-checking with the comparison operators to catch potential bugs. - https://github.com/elixir-lang/elixir/pull/13527 (https://github.com/elixir-lang/elixir/pull/13527?utm_source=thinkingelixir&utm_medium=shownotes) – A merged Elixir PR for "Perform type checking across comparison operators." - https://twitter.com/josevalim/status/1785990361418006768?t=ZvCKMAXrZFtDX8pfjW14Lw (https://twitter.com/josevalim/status/1785990361418006768?t=ZvCKMAXrZFtDX8pfjW14Lw?utm_source=thinkingelixir&utm_medium=shownotes) – A tweet by José Valim discussing the power of set-theoretic types in Elixir. - https://twitter.com/josevalim/status/1787543767341486181 (https://twitter.com/josevalim/status/1787543767341486181?utm_source=thinkingelixir&utm_medium=shownotes) – José Valim sharing updates about Elixir's type system checking exceptions fields and warning on undefined exceptions. - https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.html (https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.html?utm_source=thinkingelixir&utm_medium=shownotes) – The Elixir documentation for the gradual set-theoretic types. - https://hexdocs.pm/elixir/main/changelog.html#warnings-from-gradual-set-theoretic-types (https://hexdocs.pm/elixir/main/changelog.html#warnings-from-gradual-set-theoretic-types?utm_source=thinkingelixir&utm_medium=shownotes) – The Elixir 1.17.0 changelog on "Warnings from gradual set-theoretic types." - https://github.com/elixir-lang/elixir/pull/13534 (https://github.com/elixir-lang/elixir/pull/13534?utm_source=thinkingelixir&utm_medium=shownotes) – A Github pull request for a new is_non_struct_map guard in Elixir 1.17. - https://twitter.com/codestirring/status/1785769316304228590 (https://twitter.com/codestirring/status/1785769316304228590?utm_source=thinkingelixir&utm_medium=shownotes) – Chris Gregori announces "Bloom," a new LiveView component library project. - https://bloom-ui.fly.dev/ (https://bloom-ui.fly.dev/?utm_source=thinkingelixir&utm_medium=shownotes) – The "Bloom" UI component library site showcasing its features and usage. - https://github.com/chrisgreg/bloom (https://github.com/chrisgreg/bloom?utm_source=thinkingelixir&utm_medium=shownotes) – The Github repository for the "Bloom" LiveView component library. - https://twitter.com/chris_mccord/status/1785678249424461897 (https://twitter.com/chris_mccord/status/1785678249424461897?utm_source=thinkingelixir&utm_medium=shownotes) – A teaser from Chris McCord about hot deploys on Fly.io to a planet-wide cluster in seconds. - https://hexdocs.pm/mix/1.16.2/Mix.Tasks.Release.html#module-hot-code-upgrades (https://hexdocs.pm/mix/1.16.2/Mix.Tasks.Release.html#module-hot-code-upgrades?utm_source=thinkingelixir&utm_medium=shownotes) – Mix documentation discussing how to perform hot code upgrades. - https://twitter.com/bcardarella/status/1785419505134456895 (https://twitter.com/bcardarella/status/1785419505134456895?utm_source=thinkingelixir&utm_medium=shownotes) – A tweet from Brian Cardarella showing a LiveView Native tvOS simulator demo. - https://www.youtube.com/@CodeSync/videos (https://www.youtube.com/@CodeSync/videos?utm_source=thinkingelixir&utm_medium=shownotes) – Videos uploaded by CodeSync from ElixirConf EU 2024, including keynotes. - https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1 (https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1?utm_source=thinkingelixir&utm_medium=shownotes) – An article highlighting how unauthorized requests to S3 buckets can inflate AWS bills and AWS's billing policy update to address this. - https://twitter.com/jeffbarr/status/1787844682216792163 (https://twitter.com/jeffbarr/status/1787844682216792163?utm_source=thinkingelixir&utm_medium=shownotes) – AWS's Jeff Barr's tweet about the adjustment of billing policy for S3. - https://www.employmentlawworldview.com/ftc-bans-non-competes-throughout-the-united-states-us/ (https://www.employmentlawworldview.com/ftc-bans-non-competes-throughout-the-united-states-us/?utm_source=thinkingelixir&utm_medium=shownotes) – A follow-up on the FTC's recent ruling on non-compete clauses and the resulting legal challenges. Do you have some Elixir news to share? Tell us at @ThinkingElixir (https://twitter.com/ThinkingElixir) or email at show@thinkingelixir.com (mailto:show@thinkingelixir.com) Find us online - Message the show - @ThinkingElixir (https://twitter.com/ThinkingElixir) - Message the show on Fediverse - @ThinkingElixir@genserver.social (https://genserver.social/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen - @brainlid (https://twitter.com/brainlid) - Mark Ericksen on Fediverse - @brainlid@genserver.social (https://genserver.social/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - David Bernheisel on Fediverse - @dbern@genserver.social (https://genserver.social/dbern)
Jeff Barr & Simon Elisha discuss various aspects of the Amazon Web Services (AWS) offering. Each podcast include AWS news, tech tips, and interviews with startups, AWS partners, and AWS employees.
Chatting With Jeff Barr- Vice President & Chief Evangelist at Amazon Web Services from Seattle, Washington, United States- Jeff Barr said about his work and answered some of my questions. more info at https://www.smartcherrysthoughts.com
Explore AWS re:Invent 2023 with Jeff Barr on the Jon Myer Podcast. Jeff, AWS's VP and Chief Evangelist, delves into the latest AWS innovations and the importance of community.
Explore AWS re:Invent 2023 with Jeff Barr on the Jon Myer Podcast. Jeff, AWS's VP and Chief Evangelist, delves into the latest AWS innovations and the importance of community.
We are live from AWS re:Invent 2023 in Las Vegas, direct from the Expo floor, with a limited series of episodes talking to AWS leaders on themes of the conference, as well as filling in on all of the news and gossip.Dave, Sjoukje and Rob talk to Jeff Barr, VP & Chief Evangelist, AWS, about his early days at AWS, the evolution of re:Invent itself, the three major compute paradigms over the last 60 years, how Cloud and AI fit into that and how to equip the next generation. We also hear about Jeff's family all being at re:Invent for the first time together this year. GuestJeff Barr: https://www.linkedin.com/in/jeffbarr/HostsDave Chapman: https://www.linkedin.com/in/chapmandr/Sjoukje Zaal: https://www.linkedin.com/in/sjoukjezaal/Rob Kernahan: https://www.linkedin.com/in/rob-kernahan/ProductionMarcel Van Der Burg: https://www.linkedin.com/in/marcel-van-der-burg-99a655/Dave Chapman: https://www.linkedin.com/in/chapmandr/SoundBen Corbett: https://www.linkedin.com/in/ben-corbett-3b6a11135/Louis Corbett: https://www.linkedin.com/in/louis-corbett-087250264/
Jacob Winograd is the creator of the Biblical Anarchy podcast under the auspices of the Libertarian Christian Institute. He joins Bob to discuss the famous passages from the New Testament where Christians are ostensibly told to pay their taxes and obey the government.Mentioned in the Episode and Other Links of Interest:The YouTube version of this interview.Jacob's Biblical Anarchy Podcast.Jeff Barr's article on rendering unto Caesar.Help support the Bob Murphy Show.
Lars Kamp is the Co-Founder and CEO of Some Engineering, the makers of Resoto. In this episode, Lars describes what he's learned from founding and working at multiple start-ups, as well as the main differentiators he's experienced founding his first open-source startup. Lars describes his though process when it comes to selecting co-founders, and illustrates why it's even more important to be discerning when selecting investors. Lars and I also discuss the advantages that open-source gives to founders who are focused on the distribution strategy for their product, and Lars reveals why he is a big proponent of having docs be a part of your product-led growth strategy. Throughout our conversation, Lars' insights create a detailed picture of what second-time founders think about and how SaaS startup experience relates to open-source business strategy. Highlights: I introduce Lars, who is the CEO and Founder of Some Engineering (00:23) Lars describes what he does at Resoto and the user groups they work with (00:47) How a tweet by Jeff Barr inspired Lars and his co-founders to start working on Resoto (01:37) What it was like for Lars to start a company with co-founders he didn't know very well (05:03) Why Lars went from working with closed-source SaaS companies to founding an open-source company (07:26) The main differences Lars has found between founding a SaaS startup and an open-source company (09:24) Lars describes the value he sees in investing in really good docs (10:44) Why Lars focuses more on distribution than product as a second-time founder (13:19) What third time founders think about and what they don't (16:18) Lars' advice to founders (18:40) Why Lars sees a big advantage in open-source business models, especially when it comes to distribution (20:09) The advice Lars would give himself if he could go back in time to the early days of Resoto(28:31) How to get in touch with Lars (32:23) Links:Lars LinkedIn: https://www.linkedin.com/in/larskamp/ Twitter: https://twitter.com/l1rs Company: https://some.engineering/
Kinsella on Liberty Podcast: Episode 418. This is a followup to KOL414 | Corporations, Limited Liability, and the Title Transfer Theory of Contract, with Jeff Barr: Part I. See that episode for more information and notes. In Part III, we need to talk about corporations. For more on that, see Corporate Personhood, Limited Liability, and Double Taxation. https://youtu.be/5-Zvt59UlSk For more discussion of the comments below, see Libertarian Answer Man: Future and Conditional Title Transfers Under the Title-Transfer Theory of Contract.
Kinsella on Liberty Podcast: Episode 418. This is a followup to KOL414 | Corporations, Limited Liability, and the Title Transfer Theory of Contract, with Jeff Barr: Part I. See that episode for more information and notes. In Part III, we need to talk about corporations. For more on that, see Corporate Personhood, Limited Liability, and Double Taxation. https://youtu.be/5-Zvt59UlSk
Kinsella on Liberty Podcast: Episode 414. Regarding this post, Libertarian Answer Man: Breach of Contract, Binding Obligations, and Impossibility, my old and longtime buddy Jeff Barr, a brilliant attorney and legal scholar and fellow Hoppean-Rothbardian (Jeff studied at UNLV under Rothbard and Hoppe), (( See Murray Rothbard as a Teacher: The UNLV Years—A Panel with Rothbard's Former Students (AERC 2023). )) discussed these issues in further depth today. (Part 2: KOL418 | Corporations, Limited Liability, and the Title Transfer Theory of Contract, with Jeff Barr: Part II.) https://youtu.be/1jtDoShqnmI Jeff and I, it turns out, to my surprise (given past discussions), agree mostly on corporate limited liability, (( See my post Corporate Personhood, Limited Liability, and Double Taxation. )) and Jeff claims to also agree with the Rothbard-Evers take on contracts—the title-transfer theory. We also agree on terminology, legal issues, possession vs. ownership, and so on. (( Libertarian Answer Man: Self-ownership for slaves and Crusoe; and Yiannopoulos on Accurate Analysis and the term “Property”; Mises distinguishing between juristic and economic categories of “ownership”. )) Yet Jeff still thinks that failure/inability to pay a future debt is "theft," much like Rothbard (and Block) view this as "implicit theft," thus justifying in principle debtor's prison, although Barr thinks the theft is not even implicit; he thinks it's explicit theft. This is the crux of our disagreement. We talked about some preliminary matters first to make sure we are on the same page, and ended with this disagreement. Now that we've laid the groundwork, and identified some terminology and common ground, we may pick this up in a future discussion. More to come.
Kinsella on Liberty Podcast: Episode 414. Regarding this post, Libertarian Answer Man: Breach of Contract, Binding Obligations, and Impossibility, my old and longtime buddy Jeff Barr, a brilliant attorney and legal scholar and fellow Hoppean-Rothbardian (Jeff studied at UNLV under Rothbard and Hoppe), (( See Murray Rothbard as a Teacher: The UNLV Years—A Panel with Rothbard's Former Students (AERC 2023). )) discussed these issues in further depth today. https://youtu.be/1jtDoShqnmI Jeff and I, it turns out, to my surprise (given past discussions), agree mostly on corporate limited liability, (( See my post Corporate Personhood, Limited Liability, and Double Taxation. )) and Jeff claims to also agree with the Rothbard-Evers take on contracts—the title-transfer theory. We also agree on terminology, legal issues, possession vs. ownership, and so on. (( Libertarian Answer Man: Self-ownership for slaves and Crusoe; and Yiannopoulos on Accurate Analysis and the term “Property”; Mises distinguishing between juristic and economic categories of “ownership”. )) Yet Jeff still thinks that failure/inability to pay a future debt is "theft," much like Rothbard (and Block) view this as "implicit theft," thus justifying in principle debtor's prison, although Barr thinks the theft is not even implicit; he thinks it's explicit theft. This is the crux of our disagreement. We talked about some preliminary matters first to make sure we are on the same page, and ended with this disagreement. Now that we've laid the groundwork, and identified some terminology and common ground, we may pick this up in a future discussion. More to come.
Lawrence Ludlow has an MA in medieval studies and gives Bob numerous lines of evidence to suggest that Paul in Romans 13 is referring to spiritual authorities rather than political ones. In this interpretation, there is no tension between the New Testament and standard libertarianism.Mentioned in the Episode and Other Links of Interest:The YouTube version of this interview.Norman Horn on the BMS to talk Romans 13.Jeff Barr's analysis of "Render unto Caesar."A History of the Bible. A book on the transmission of the New Testament.Help support the Bob Murphy Show.The audio production for this episode was provided by Podsworth Media.
In this episode, I chat with Jeff Barr and we discuss Amazon's culture of writing. This conversation talks about PRFAQs, and the AWS News Blog and how it came to be.
Get ready for another exciting episode with Jeff Barr, Corey Quinn, and Stephen Barr. In this episode, we explore the Paul Alan Computer Museum and the Air Field Museum, reminiscing about the old days and discussing topics like wiring networking cables and the possibility of owning a yacht. Stay tuned as we dive into a fascinating conversation and uncover more intriguing stories. Oh, and did we mention that Amazon Luna pays us a visit during the podcast? Don't miss it!
In this episode, we explore the behind-the-scenes world of AWS services and webinars with Jeff Barr, Corey Quinn, and our special guest. Discover the story of how Jeff and our host became friends and the journey that led to their first webinar. Dive into the exciting world of AWS re:Invent and the intricacies of full video production. We also discuss the longevity of S3 objects, AWS billing, and the bold ask that set it all in motion. Prepare for an engaging and informative episode.
Join us for an insightful episode where Jeff Barr, Corey Quinn, and Stephen Barr dives into topics like AWS cost allocation tagging with emojis and the interesting story of Jeff's driver's licenses. We also explore converting chicken scratch to text and encounter Jeff on the streets of San Francisco. Delve into the world of IT as we discuss foundational skill sets and explain data centers to the uninitiated. Plus, discover what happened to the early EC2 instances. This episode is a goldmine of knowledge and engaging conversation.
In this episode, join us as we explore the journey of Jeff Barr, Chief Evangelist @ aws. We discuss Jeff's writing process, the review process for his posts, and whether Corey Quinn plans to join Amazon when Jeff retires. Discover the behind-the-scenes of Jeff's post-editing and gain insights into his unique perspective. We also touch on topics like typewriters and delve into the foundational skill sets in IT and data centers. Tune in to uncover the stories and wisdom shared in this thought-provoking conversation.
Get ready for another exciting episode with Jeff Barr, Corey Quinn, and Stephen Barr. In this episode, we explore the Paul Alan Computer Museum and the Air Field Museum, reminiscing about the old days and discussing topics like wiring networking cables and the possibility of owning a yacht. Stay tuned as we dive into a fascinating conversation and uncover more intriguing stories. Oh, and did we mention that Amazon Luna pays us a visit during the podcast? Don't miss it!
Join us for an intriguing episode featuring Jeff Barr, Corey Quinn, and Stephen Barr, dive into their discussion about podcast setups, AWS DeepRacer, and Jeff's role as Trackboss. Delve into the logistics of AWS re:Invent and uncover the secrets behind Jeff's writing process and office color choice. We also explore Corey's knowledge of AWS services and naming conventions. Find out how Jeff arranges his posts and discover the fascinating world of patents. This episode is packed with insights and behind-the-scenes stories.
In this episode, we explore the behind-the-scenes world of AWS services and webinars with Jeff Barr, Corey Quinn, and our special guest. Discover the story of how Jeff and our host became friends and the journey that led to their first webinar. Dive into the exciting world of AWS re:Invent and the intricacies of full video production. We also discuss the longevity of S3 objects, AWS billing, and the bold ask that set it all in motion. Prepare for an engaging and informative episode.
Join us for an insightful episode where Jeff Barr, Corey Quinn, and Stephen Barr dives into topics like AWS cost allocation tagging with emojis and the interesting story of Jeff's driver's licenses. We also explore converting chicken scratch to text and encounter Jeff on the streets of San Francisco. Delve into the world of IT as we discuss foundational skill sets and explain data centers to the uninitiated. Plus, discover what happened to the early EC2 instances. This episode is a goldmine of knowledge and engaging conversation.
In this episode, join us as we explore the journey of Jeff Barr, Chief Evangelist @ aws. We discuss Jeff's writing process, the review process for his posts, and whether Corey Quinn plans to join Amazon when Jeff retires. Discover the behind-the-scenes of Jeff's post-editing and gain insights into his unique perspective. We also touch on topics like typewriters and delve into the foundational skill sets in IT and data centers. Tune in to uncover the stories and wisdom shared in this thought-provoking conversation.
Join us for an intriguing episode featuring Jeff Barr, Corey Quinn, and Stephen Barr, dive into their discussion about podcast setups, AWS DeepRacer, and Jeff's role as Trackboss. Delve into the logistics of AWS re:Invent and uncover the secrets behind Jeff's writing process and office color choice. We also explore Corey's knowledge of AWS services and naming conventions. Find out how Jeff arranges his posts and discover the fascinating world of patents. This episode is packed with insights and behind-the-scenes stories.
Hi Everyone, I've got an unusual podcast series coming up with Jeff Barr, Chief Evangelist @ AWS, Corey Quinn, cloud economist at the Duckbill group, and principal architect @ CloudFix. In this episode, we take you into Jeff's home for a totally unscripted conversation. Join us as we delve into topics ranging from Jeff's network and power shades to the challenges of parenting and the unexpected things that come out of Corey's mouth. Plus, find out why we had to check the cameras while recording. Get ready for a unique and authentic experience!
Hi Everyone, I've got an unusual podcast series coming up with Jeff Barr, Chief Evangelist @ AWS, Corey Quinn, cloud economist at the Duckbill group, and principal architect @ CloudFix. In this episode, we take you into Jeff's home for a totally unscripted conversation. Join us as we delve into topics ranging from Jeff's network and power shades to the challenges of parenting and the unexpected things that come out of Corey's mouth. Plus, find out why we had to check the cameras while recording. Get ready for a unique and authentic experience!
Jeff Barr said about his work and how AWS is helping Human on the planet in different ways and answered some of my questions. More info- https://www.SmartCherrysThoughts.com --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app
On this episode, Rural Community Insurance Service's George Underwood and Jeff Barr discuss disaster claims and risk management for crops. Also, National Farm Medicine Center's Melissa Ploeckelman talks about new initiatives aimed at keeping farmers safe, and in this week's Meat Monitor segment, we learn that new opportunities might be on the way for U.S. red meat in China. In our Market Talk segment, Jesse Allen and Global Commodity Analytics' Mike Zuzulo discuss the soybean trade heading into 2023 and in “Bushels and Cents,” Ray Bohacz is talking about heat risers. The episode also features a new Christmas song from country music singer/songwriter Whey Jennings. Timestamps Soil Test Pro advertisement: 0:00 Intro and news: 0:30 Goatlifeclothing.com advertisement: 6:17 George Underwood and Jeff Barr, RCIS: 6:36 Melissa Ploeckelman, National Farm Medicine Center: 14:58 Joel Haggard, U.S. Meat Export Federation: 19:36 Jesse Allen, Market Talk: 22:00 Ray Bohacz, “Bushels and Cents”: 29:08 Whey Jennings: 30:48
On episode eight of The City of Ohio State Podcast, we talk with Robert Armstrong, Ohio State's Emergency Management Director and Jeff Barr, the university's Director of Landscape Services. Hear how Ohio State handles winter weather, from when to cancel classes, to how to keep campus roads and sidewalks safe.
About AllenAllen is a cloud architect at Tyler Technologies. He helps modernize government software by creating secure, highly scalable, and fault-tolerant serverless applications.Allen publishes content regularly about serverless concepts and design on his blog - Ready, Set Cloud!Links Referenced: Ready, Set, Cloud blog: https://readysetcloud.io Tyler Technologies: https://www.tylertech.com/ Twitter: https://twitter.com/allenheltondev Linked: https://www.linkedin.com/in/allenheltondev/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at AWS AppConfig. Engineers love to solve, and occasionally create, problems. But not when it's an on-call fire-drill at 4 in the morning. Software problems should drive innovation and collaboration, NOT stress, and sleeplessness, and threats of violence. That's why so many developers are realizing the value of AWS AppConfig Feature Flags. Feature Flags let developers push code to production, but hide that that feature from customers so that the developers can release their feature when it's ready. This practice allows for safe, fast, and convenient software development. You can seamlessly incorporate AppConfig Feature Flags into your AWS or cloud environment and ship your Features with excitement, not trepidation and fear. To get started, go to snark.cloud/appconfig. That's snark.cloud/appconfig.Corey: I come bearing ill tidings. Developers are responsible for more than ever these days. Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on. Because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud. And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are - Finding and fixing vulnerabilities right from the CLI, IDEs, Repos, and Pipelines. Snyk integrates seamlessly with AWS offerings like code pipeline, EKS, ECR, and more! As well as things you're actually likely to be using. Deploy on AWS, secure with Snyk. Learn more at Snyk.co/scream That's S-N-Y-K.co/screamCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Every once in a while I wind up stumbling into corners of the internet that I previously had not traveled. Somewhat recently, I wound up having that delightful experience again by discovering readysetcloud.io, which has a whole series of, I guess some people might call it thought leadership, I'm going to call it instead how I view it, which is just amazing opinion pieces on the context of serverless, mixed with APIs, mixed with some prognostications about the future.Allen Helton by day is a cloud architect at Tyler Technologies, but that's not how I encountered you. First off, Allen, thank you for joining me.Allen: Thank you, Corey. Happy to be here.Corey: I was originally pointed towards your work by folks in the AWS Community Builder program, of which we both participate from time to time, and it's one of those, “Oh, wow, this is amazing. I really wish I'd discovered some of this sooner.” And every time I look through your back catalog, and I click on a new post, I see things that are either I've really agree with this or I can't stand this opinion, I want to fight about it, but more often than not, it's one of those recurring moments that I love: “Damn, I wish I had written something like this.” So first, you're absolutely killing it on the content front.Allen: Thank you, Corey, I appreciate that. The content that I make is really about the stuff that I'm doing at work. It's stuff that I'm passionate about, stuff that I'd spend a decent amount of time on, and really the most important thing about it for me, is it's stuff that I'm learning and forming opinions on and wants to share with others.Corey: I have to say, when I saw that you were—oh, your Tyler Technologies, which sounds for all the world like, oh, it's a relatively small consultancy run by some guy presumably named Tyler, and you know, it's a petite team of maybe 20, 30 people on the outside. Yeah, then I realized, wait a minute, that's not entirely true. For example, for starters, you're publicly traded. And okay, that does change things a little bit. First off, who are you people? Secondly, what do you do? And third, why have I never heard of you folks, until now?Allen: Tyler is the largest company that focuses completely on the public sector. We have divisions and products for pretty much everything that you can imagine that's in the public sector. We have software for schools, software for tax and appraisal, we have software for police officers, for courts, everything you can think of that runs the government can and a lot of times is run on Tyler software. We've been around for decades building our expertise in the domain, and the reason you probably haven't heard about us is because you might not have ever been in trouble with the law before. If you [laugh] if you have been—Corey: No, no, I learned very early on in the course of my life—which will come as a surprise to absolutely no one who spent more than 30 seconds with me—that I have remarkably little filter and if ten kids were the ones doing something wrong, I'm the one that gets caught. So, I spent a lot of time in the principal's office, so this taught me to keep my nose clean. I'm one of those squeaky-clean types, just because I was always terrified of getting punished because I knew I would get caught. I'm not saying this is the right way to go through life necessarily, but it did have the side benefit of, no, I don't really engage with law enforcement going throughout the course of my life.Allen: That's good. That's good. But one exposure that a lot of people get to Tyler is if you look at the bottom of your next traffic ticket, it'll probably say Tyler Technologies on the bottom there.Corey: Oh, so you're really popular in certain circles, I'd imagine?Allen: Super popular. Yes, yes. And of course, you get all the benefits of writing that code that says ‘if defendant equals Allen Helton then return.'Corey: I like that. You get to have the exception cases built in that no one's ever going to wind up looking into.Allen: That's right. Yes.Corey: The idea of what you're doing makes an awful lot of sense. There's a tremendous need for a wide variety of technical assistance in the public sector. What surprises me, although I guess it probably shouldn't, is how much of your content is aimed at serverless technologies and API design, which to my way of thinking, isn't really something that public sector has done a lot with. Clearly I'm wrong.Allen: Historically, you're not wrong. There's an old saying that government tends to run about ten years behind on technology. Not just technology, but all over the board and runs about ten years behind. And until recently, that's really been true. There was a case last year, a situation last year where one of the state governments—I don't remember which one it was—but they were having a crisis because they couldn't find any COBOL developers to come in and maintain their software that runs the state.And it's COBOL; you're not going to find a whole lot of people that have that skill. A lot of those people are retiring out. And what's happening is that we're getting new people sitting in positions of power and government that want innovation. They know about the cloud and they want to be able to integrate with systems quickly and easily, have little to no onboarding time. You know, there are people in power that have grown up with technology and understand that, well, with everything else, I can be up and running in five or ten minutes. I cannot do this with the software I'm consuming now.Corey: My opinion on it is admittedly conflicted because on the one hand, yeah, I don't think that governments should be running on COBOL software that runs on mainframes that haven't been supported in 25 years. Conversely, I also don't necessarily want them being run like a seed series startup, where, “Well, I wrote this code last night, and it's awesome, so off I go to production with it.” Because I can decide not to do business anymore with Twitter for Pets, and I could go on to something else, like PetFlicks, or whatever it is I choose to use. I can't easily opt out of my government. The decisions that they make stick and that is going to have a meaningful impact on my life and everyone else's life who is subject to their jurisdiction. So, I guess I don't really know where I believe the proper, I guess, pace of technological adoption should be for governments. Curious to get your thoughts on this.Allen: Well, you certainly don't want anything that's bleeding edge. That's one of the things that we kind of draw fine lines around. Because when we're dealing with government software, we're dealing with, usually, critically sensitive information. It's not medical records, but it's your criminal record, and it's things like your social security number, it's things that you can't have leaking out under any circumstances. So, the things that we're building on are things that have proven out to be secure and have best practices around security, uptime, reliability, and in a lot of cases as well, and maintainability. You know, if there are issues, then let's try to get those turned around as quickly as we can because we don't want to have any sort of downtime from the software side versus the software vendor side.Corey: I want to pivot a little bit to some of the content you've put out because an awful lot of it seems to be, I think I'll call it variations on a theme. For example, I just read some recent titles, and to illustrate my point, “Going API First: Your First 30 Days,” “Solutions Architect Tips how to Design Applications for Growth,” “3 Things to Know Before Building A Multi-Tenant Serverless App.” And the common thread that I see running through all of these things are these are things that you tend to have extraordinarily strong and vocal opinions about only after dismissing all of them the first time and slapping something together, and then sort of being forced to live with the consequences of the choices that you've made, in some cases you didn't realize you were making at the time. Are you one of those folks that has the wisdom to see what's coming down the road, or did you do what the rest of us do and basically learn all this stuff by getting it hilariously wrong and having to careen into rebound situations as a result?Allen: [laugh]. I love that question. I would like to say now, I feel like I have the vision to see something like that coming. Historically, no, not at all. Let me talk a little bit about how I got to where I am because that will shed a lot of context on that question.A few years ago, I was put into a position at Tyler that said, “Hey, go figure out this cloud thing.” Let's figure out what we need to do to move into the cloud safely, securely, quickly, all that rigmarole. And so, I did. I got to hand-select team of engineers from people that I worked with at Tyler over the past few years, and we were basically given free rein to learn. We were an R&D team, a hundred percent R&D, for about a year's worth of time, where we were learning about cloud concepts and theory and building little proof of concepts.CI/CD, serverless, APIs, multi-tenancy, a whole bunch of different stuff. NoSQL was another one of the things that we had to learn. And after that year of R&D, we were told, “Okay, now go do something with that. Go build this application.” And we did, building on our theory our cursory theory knowledge. And we get pretty close to go live, and then the business says, “What do you do in this scenario? What do you do in that scenario? What do you do here?”Corey: “I update my resume and go work somewhere else. Where's the hard part here?”Allen: [laugh].Corey: Turns out, that's not a convincing answer.Allen: Right. So, we moved quickly. And then I wouldn't say we backpedaled, but we hardened for a long time before the—prior to the go-live, with the lessons that we've learned with the eyes of Tyler, the mature enterprise company, saying, “These are the things that you have to make sure that you take into consideration in an actual production application.” One of the things that I always pushed—I was a manager for a few years of all these cloud teams—I always push do it; do it right; do it better. Right?It's kind of like crawl, walk, run. And if you follow my writing from the beginning, just looking at the titles and reading them, kind of like what you were doing, Corey, you'll see that very much. You'll see how I talk about CI/CD, you'll see me how I talk about authorization, you'll see me how I talk about multi-tenancy. And I kind of go in waves where maybe a year passes and you see my content revisit some of the topics that I've done in the past. And they're like, “No, no, no, don't do what I said before. It's not right.”Corey: The problem when I'm writing all of these things that I do, for example, my entire newsletter publication pipeline is built on a giant morass of Lambda functions and API Gateways. It's microservices-driven—kind of—and each microservice is built, almost always, with a different framework. Lately, all the new stuff is CDK. I started off with the serverless framework. There are a few other things here and there.And it's like going architecting, back in time as I have to make updates to these things from time to time. And it's the problem with having done all that myself is that I already know the answer to, “What fool designed this?” It's, well, you're basically watching me learn what I was, doing bit by bit. I'm starting to believe that the right answer on some level, is to build an inherent shelf-life into some of these things. Great, in five years, you're going to come back and re-architect it now that you know how this stuff actually works rather than patching together 15 blog posts by different authors, not all of whom are talking about the same thing and hoping for the best.Allen: Yep. That's one of the things that I really like about serverless, I view that as a giant pro of doing Serverless is that when we revisit with the lessons learned, we don't have to refactor everything at once like if it was just a big, you know, MVC controller out there in the sky. We can refactor one Lambda function at a time if now we're using a new version of the AWS SDK, or we've learned about a new best practice that needs to go in place. It's a, “While you're in there, tidy up, please,” kind of deal.Corey: I know that the DynamoDB fanatics will absolutely murder me over this one, but one of the reasons that I have multiple Dynamo tables that contain, effectively, variations on the exact same data, is because I want to have the dependency between the two different microservices be the API, not, “Oh, and under the hood, it's expecting this exact same data structure all the time.” But it just felt like that was the wrong direction to go in. That is the justification I use for myself why I run multiple DynamoDB tables that [laugh] have the same content. Where do you fall on the idea of data store separation?Allen: I'm a big single table design person myself, I really like the idea of being able to store everything in the same table and being able to create queries that can return me multiple different types of entity with one lookup. Now, that being said, one of the issues that we ran into, or one of the ambiguous areas when we were getting started with serverless was, what does single table design mean when you're talking about microservices? We were wondering does single table mean one DynamoDB table for an entire application that's composed of 15 microservices? Or is it one table per microservice? And that was ultimately what we ended up going with is a table per microservice. Even if multiple microservices are pushed into the same AWS account, we're still building that logical construct of a microservice and one table that houses similar entities in the same domain.Corey: So, something I wish that every service team at AWS would do as a part of their design is draw the architecture of an application that you're planning to build. Great, now assume that every single resource on that architecture diagram lives in its own distinct AWS account because somewhere in some customer, there's going to be an account boundary at every interconnection point along the way. And so, many services don't do that where it's, “Oh, that thing and the other thing has to be in the same account.” So, people have to write their own integration shims, and it makes doing the right thing of putting different services into distinct bounded AWS accounts for security or compliance reasons way harder than I feel like it needs to be.Allen: [laugh]. Totally agree with you on that one. That's one of the things that I feel like I'm still learning about is the account-level isolation. I'm still kind of early on, personally, with my opinions in how we're structuring things right now, but I'm very much of a like opinion that deploying multiple things into the same account is going to make it too easy to do something that you shouldn't. And I just try not to inherently trust people, in the sense that, “Oh, this is easy. I'm just going to cross that boundary real quick.”Corey: For me, it's also come down to security risk exposure. Like my lasttweetinaws.com Twitter shitposting thread client lives in a distinct AWS account that is separate from the AWS account that has all of our client billing data that lives within it. The idea being that if you find a way to compromise my public-facing Twitter client, great, the blast radius should be constrained to, “Yay, now you can, I don't know, spin up some cryptocurrency mining in my AWS account and I get to look like a fool when I beg AWS for forgiveness.”But that should be the end of it. It shouldn't be a security incident because I should not have the credit card numbers living right next to the funny internet web thing. That sort of flies in the face of the original guidance that AWS gave at launch. And right around 2008-era, best practices were one customer, one AWS account. And then by 2012, they had changed their perspective, but once you've made a decision to build multiple services in a single account, unwinding and unpacking that becomes an incredibly burdensome thing. It's about the equivalent of doing a cloud migration, in some ways.Allen: We went through that. We started off building one application with the intent that it was going to be a siloed application, a one-off, essentially. And about a year into it, it's one of those moments of, “Oh, no. What we're building is not actually a one-off. It's a piece to a much larger puzzle.”And we had a whole bunch of—unfortunately—tightly coupled things that were in there that we're assuming that resources were going to be in the same AWS account. So, we ended up—how long—I think we took probably two months, which in the grand scheme of things isn't that long, but two months, kind of unwinding the pieces and decoupling what was possible at the time into multiple AWS accounts, kind of, segmented by domain, essentially. But that's hard. AWS puts it, you know, it's those one-way door decisions. I think this one was a two-way door, but it locked and you could kind of jimmy the lock on the way back out.Corey: And you could buzz someone from the lobby to let you back in. Yeah, the biggest problem is not necessarily the one-way door decisions. It's the one-way door decisions that you don't realize you're passing through at the time that you do them. Which, of course, brings us to a topic near and dear to your heart—and I only recently started have opinions on this myself—and that is the proper design of APIs, which I'm sure will incense absolutely no one who's listening to this. Like, my opinions on APIs start with well, probably REST is the right answer in this day and age. I had people, like, “Well, I don't know, GraphQL is pretty awesome.” Like, “Oh, I'm thinking SOAP,” and people look at me like I'm a monster from the Black Lagoon of centuries past in XML-land. So, my particular brand of strangeness side, what do you see that people are doing in the world of API design that is the, I guess, most common or easy to make mistakes that you really wish they would stop doing?Allen: If I could boil it down to one word, fundamentalism. Let me unpack that for you.Corey: Oh, please, absolutely want to get a definition on that one.Allen: [laugh]. I approach API design from a developer experience point of view: how easy is it for both internal and external integrators to consume and satisfy the business processes that they want to accomplish? And a lot of times, REST guidelines, you know, it's all about entity basis, you know, drill into the appropriate entities and name your endpoints with nouns, not verbs. I'm actually very much onto that one.But something that you could easily do, let's say you have a business process that given a fundamentally correct RESTful API design takes ten API calls to satisfy. You could, in theory, boil that down to maybe three well-designed endpoints that aren't, quote-unquote, “RESTful,” that make that developer experience significantly easier. And if you were a fundamentalist, that option is not even on the table, but thinking about it pragmatically from a developer experience point of view, that might be the better call. So, that's one of the things that, I know feels like a hot take. Every time I say it, I get a little bit of flack for it, but don't be a fundamentalist when it comes to your API designs. Do something that makes it easier while staying in the guidelines to do what you want.Corey: For me the problem that I've kept smacking into with API design, and it honestly—let me be very clear on this—my first real exposure to API design rather than API consumer—which of course, I complain about constantly, especially in the context of the AWS inconsistent APIs between services—was when I'm building something out, and I'm reading the documentation for API Gateway, and oh, this is how you wind up having this stage linked to this thing, and here's the endpoint. And okay, great, so I would just populate—build out a structure or a schema that has the positional parameters I want to use as variables in my function. And that's awesome. And then I realized, “Oh, I might want to call this a different way. Aw, crap.” And sometimes it's easy; you just add a different endpoint. Other times, I have to significantly rethink things. And I can't shake the feeling that this is an entire discipline that exists that I just haven't had a whole lot of exposure to previously.Allen: Yeah, I believe that. One of the things that you could tie a metaphor to for what I'm saying and kind of what you're saying, is AWS SAM, the Serverless Application Model, all it does is basically macros CloudFormation resources. It's just a transform from a template into CloudFormation. CDK does same thing. But what the developers of SAM have done is they've recognized these business processes that people do regularly, and they've made these incredibly easy ways to satisfy those business processes and tie them all together, right?If I want to have a Lambda function that is backed behind a endpoint, an API endpoint, I just have to add four or five lines of YAML or JSON that says, “This is the event trigger, here's the route, here's the API.” And then it goes and does four, five, six different things. Now, there's some engineers that don't like that because sometimes that feels like magic. Sometimes a little bit magic is okay.Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig secures your cloud from source to run. They believe, as do I, that DevOps and security are inextricably linked. If you wanna learn more about how they view this, check out their blog, it's definitely worth the read. To learn more about how they are absolutely getting it right from where I sit, visit Sysdig.com and tell them that I sent you. That's S Y S D I G.com. And my thanks to them for their continued support of this ridiculous nonsense.Corey: I feel like one of the benefits I've had with the vast majority of APIs that I've built is that because this is all relatively small-scale stuff for what amounts to basically shitposting for the sake of entertainment, I'm really the only consumer of an awful lot of these things. So, I get frustrated when I have to backtrack and make changes and teach other microservices to talk to this thing that has now changed. And it's frustrating, but I have the capacity to do that. It's just work for a period of time. I feel like that equation completely shifts when you have published this and it is now out in the world, and it's not just users, but in many cases paying customers where you can't really make those changes without significant notice, and every time you do you're creating work for those customers, so you have to be a lot more judicious about it.Allen: Oh, yeah. There is a whole lot of governance and practice that goes into production-level APIs that people integrate with. You know, they say once you push something out the door into production that you're going to support it forever. I don't disagree with that. That seems like something that a lot of people don't understand.And that's one of the reasons why I push API-first development so hard in all the content that I write is because you need to be intentional about what you're letting out the door. You need to go in and work, not just with the developers, but your product people and your analysts to say, what does this absolutely need to do, and what does it need to do in the future? And you take those things, and you work with analysts who want specifics, you work with the engineers to actually build it out. And you're very intentional about what goes out the door that first time because once it goes out with a mistake, you're either going to version it immediately or you're going to make some people very unhappy when you make a breaking change to something that they immediately started consuming.Corey: It absolutely feels like that's one of those things that AWS gets astonishingly right. I mean, I had the privilege of interviewing, at the time, Jeff Barr and then Ariel Kelman, who was their head of marketing, to basically debunk a bunch of old myths. And one thing that they started talking about extensively was the idea that an API is fundamentally a promise to your customers. And when you make a promise, you'd better damn well intend on keeping it. It's why API deprecations from AWS are effectively unique whenever something happens.It's the, this is a singular moment in time when they turn off a service or degrade old functionality in favor of new. They can add to it, they can launch a V2 of something and then start to wean people off by calling the old one classic or whatnot, but if I built something on AWS in 2008 and I wound up sleeping until today, and go and try and do the exact same thing and deploy it now, it will almost certainly work exactly as it did back then. Sure, reliability is going to be a lot better and there's a crap ton of features and whatnot that I'm not taking advantage of, but that fundamental ability to do that is awesome. Conversely, it feels like Google Cloud likes to change around a lot of their API stories almost constantly. And it's unplanned work that frustrates the heck out of me when I'm trying to build something stable and lasting on top of it.Allen: I think it goes to show the maturity of these companies as API companies versus just vendors. It's one of the things that I think AWS does [laugh]—Corey: You see the similar dichotomy with Microsoft and Apple. Microsoft's new versions of Windows generally still have functionalities in them to support stuff that was written in the '90s for a few use cases, whereas Apple's like, “Oh, your computer's more than 18-months old? Have you tried throwing it away and buying a new one? And oh, it's a new version of Mac OS, so yeah, maybe the last one would get security updates for a year and then get with the times.” And I can't shake the feeling that the correct answer is in some way, both of those, depending upon who your customer is and what it is you're trying to achieve.If Microsoft adopted the Apple approach, their customers would mutiny, and rightfully so; the expectation has been set for decades that isn't what happens. Conversely, if Apple decided now we're going to support this version of Mac OS in perpetuity, I don't think a lot of their application developers wouldn't quite know what to make of that.Allen: Yeah. I think it also comes from a standpoint of you better make it worth their while if you're going to move their cheese. I'm not a Mac user myself, but from what I hear for Mac users—and this could be rose-colored glasses—but is that their stuff works phenomenally well. You know, when a new thing comes out—Corey: Until it doesn't, absolutely. It's—whenever I say things like that on this show, I get letters. And it's, “Oh, yeah, really? They'll come up with something that is a colossal pain in the ass on Mac.” Like, yeah, “Try building a system-wide mute key.”It's yeah, that's just a hotkey away on windows and here in Mac land. It's, “But it makes such beautiful sounds. Why would you want them to be quiet?” And it's, yeah, it becomes this back-and-forth dichotomy there. And you can even explain it to iPhones as well and the Android ecosystem where it's, oh, you're going to support the last couple of versions of iOS.Well, as a developer, I don't want to do that. And Apple's position is, “Okay, great.” Almost half of the mobile users on the planet will be upgrading because they're in the ecosystem. Do you want us to be able to sell things those people are not? And they're at a point of scale where they get to dictate those terms.On some level, there are benefits to it and others, it is intensely frustrating. I don't know what the right answer is on the level of permanence on that level of platform. I only have slightly better ideas around the position of APIs. I will say that when AWS deprecates something, they reach out individually to affected customers, on some level, and invariably, when they say, “This is going to be deprecated as of August 31,” or whenever it is, yeah, it is going to slip at least twice in almost every case, just because they're not going to turn off a service that is revenue-bearing or critical-load-bearing for customers without massive amounts of notice and outreach, and in some cases according to rumor, having engineers reach out to help restructure things so it's not as big of a burden on customers. That's a level of customer focus that I don't think most other companies are capable of matching.Allen: I think that comes with the size and the history of Amazon. And one of the things that they're doing right now, we've used Amazon Cloud Cams for years, in my house. We use them as baby monitors. And they—Corey: Yea, I saw this I did something very similar with Nest. They didn't have the Cloud Cam at the right time that I was looking at it. And they just announced that they're going to be deprecating. They're withdrawing them for sale. They're not going to support them anymore. Which, oh at Amazon—we're not offering this anymore. But you tell the story; what are they offering existing customers?Allen: Yeah, so slightly upset about it because I like my Cloud Cams and I don't want to have to take them off the wall or wherever they are to replace them with something else. But what they're doing is, you know, they gave me—or they gave all the customers about eight months head start. I think they're going to be taking them offline around Thanksgiving this year, just mid-November. And what they said is as compensation for you, we're going to send you a Blink Cam—a Blink Mini—for every Cloud Cam that you have in use, and then we are going to gift you a year subscription to the Pro for Blink.Corey: That's very reasonable for things that were bought years ago. Meanwhile, I feel like not to be unkind or uncharitable here, but I use Nest Cams. And that's a Google product. I half expected if they ever get deprecated, I'll find out because Google just turns it off in the middle of the night—Allen: [laugh].Corey: —and I wake up and have to read a blog post somewhere that they put an update on Nest Cams, the same way they killed Google Reader once upon a time. That's slightly unfair, but the fact that joke even lands does say a lot about Google's reputation in this space.Allen: For sure.Corey: One last topic I want to talk with you about before we call it a show is that at the time of this recording, you recently had a blog post titled, “What does the Future Hold for Serverless?” Summarize that for me. Where do you see this serverless movement—if you'll forgive the term—going?Allen: So, I'm going to start at the end. I'm going to work back a little bit on what needs to happen for us to get there. I have a feeling that in the future—I'm going to be vague about how far in the future this is—that we'll finally have a satisfied promise of all you're going to write in the future is business logic. And what does that mean? I think what can end up happening, given the right focus, the right companies, the right feedback, at the right time, is we can write code as developers and have that get pushed up into the cloud.And a phrase that I know Jeremy Daly likes to say ‘infrastructure from code,' where it provisions resources in the cloud for you based on your use case. I've developed an application and it gets pushed up in the cloud at the time of deploying it, optimized resource allocation. Over time, what will happen—with my future vision—is when you get production traffic going through, maybe it's spiky, maybe it's consistently at a scale that outperforms the resources that it originally provisioned. We can have monitoring tools that analyze that and pick that out, find the anomalies, find the standard patterns, and adjust that infrastructure that it deployed for you automatically, where it's based on your production traffic for what it created, optimizes it for you. Which is something that you can't do on an initial deployment right now. You can put what looks best on paper, but once you actually get traffic through your application, you realize that, you know, what was on paper might not be correct.Corey: You ever noticed that whiteboard diagrams never show the reality, and they're always aspirational, and they miss certain parts? And I used to think that this was the symptom I had from working at small, scrappy companies because you know what, those big tech companies, everything they build is amazing and awesome. I know it because I've seen their conference talks. But I've been a consultant long enough now, and for a number of those companies, to realize that nope, everyone's infrastructure is basically a trash fire at any given point in time. And it works almost in spite of itself, rather than because of it.There is no golden path where everything is shiny, new and beautiful. And that, honestly, I got to say, it was really [laugh] depressing when I first discovered it. Like, oh, God, even these really smart people who are so intelligent they have to have extra brain packs bolted to their chests don't have the magic answer to all of this. The rest of us are just screwed, then. But we find ways to make it work.Allen: Yep. There's a quote, I wish I remembered who said it, but it was a military quote where, “No battle plan survives impact with the enemy—first contact with the enemy.” It's kind of that way with infrastructure diagrams. We can draw it out however we want and then you turn it on in production. It's like, “Oh, no. That's not right.”Corey: I want to mix the metaphors there and say, yeah, no architecture survives your first fight with a customer. Like, “Great, I don't think that's quite what they're trying to say.” It's like, “What, you don't attack your customers? Pfft, what's your customer service line look like?” Yeah, it's… I think you're onto something.I think that inherently everything beyond the V1 design of almost anything is an emergent property where this is what we learned about it by running it and putting traffic through it and finding these problems, and here's how it wound up evolving to account for that.Allen: I agree. I don't have anything to add on that.Corey: [laugh]. Fair enough. I really want to thank you for taking so much time out of your day to talk about how you view these things. If people want to learn more, where is the best place to find you?Allen: Twitter is probably the best place to find me: @AllenHeltonDev. I have that username on all the major social platforms, so if you want to find me on LinkedIn, same thing: AllenHeltonDev. My blog is always open as well, if you have any feedback you'd like to give there: readysetcloud.io.Corey: And we will, of course, put links to that in the show notes. Thanks again for spending so much time talking to me. I really appreciate it.Allen: Yeah, this was fun. This was a lot of fun. I love talking shop.Corey: It shows. And it's nice to talk about things I don't spend enough time thinking about. Allen Helton, cloud architect at Tyler Technologies. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment that I will reject because it was not written in valid XML.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
About DanDan Moore is head of developer relations for FusionAuth, where he helps share information about authentication, authorization and security with developers building all kinds of applications.A former CTO, AWS certification instructor, engineering manager and a longtime developer, he's been writing software for (checks watch) over 20 years.Links Referenced: FusionAuth: https://fusionauth.io Twitter: https://twitter.com/mooreds TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at AWS AppConfig. Engineers love to solve, and occasionally create, problems. But not when it's an on-call fire-drill at 4 in the morning. Software problems should drive innovation and collaboration, NOT stress, and sleeplessness, and threats of violence. That's why so many developers are realizing the value of AWS AppConfig Feature Flags. Feature Flags let developers push code to production, but hide that that feature from customers so that the developers can release their feature when it's ready. This practice allows for safe, fast, and convenient software development. You can seamlessly incorporate AppConfig Feature Flags into your AWS or cloud environment and ship your Features with excitement, not trepidation and fear. To get started, go to snark.cloud/appconfig. That's snark.cloud/appconfig.Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig secures your cloud from source to run. They believe, as do I, that DevOps and security are inextricably linked. If you wanna learn more about how they view this, check out their blog, it's definitely worth the read. To learn more about how they are absolutely getting it right from where I sit, visit Sysdig.com and tell them that I sent you. That's S Y S D I G.com. And my thanks to them for their continued support of this ridiculous nonsense.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I am joined today on this promoted episode, which is brought to us by our friends at FusionAuth by Dan Moore, who is their head of DevRel at same. Dan, thank you for joining me.Dan: Corey, thank you so much for having me.Corey: So, you and I have been talking for a while. I believe it predates not just you working over at FusionAuth but me even writing the newsletter and the rest. We met on a leadership Slack many years ago. We've kept in touch ever since, and I think, I haven't run the actual numbers on this, but I believe that you are at the top of the leaderboard right now for the number of responses I have gotten to various newsletter issues that I've sent out over the years.And it's always something great. It's “Here's a link I found that I thought that you might appreciate.” And we finally sat down and met each other in person, had a cup of coffee somewhat recently, and the first thing you asked was, “Is it okay that I keep doing this?” And at the bottom of the newsletter is “Hey, if you've seen something interesting, hit reply and let me know.” And you'd be surprised how few people actually take me up on it. So, let me start by thanking you for being as enthusiastic a contributor of the content as you have been.Dan: Well, I appreciate that. And I remember the first time I ran across your newsletter and was super impressed by kind of the breadth of it. And I guess my way of thanking you is to just send you interesting tidbits that I run across. And it's always fun when I see one of the links that I sent go into the newsletter because what you provide is just such a service to the community. So, thank you.Corey: The fun part, too, is that about half the time that you send a link in, I already have it in my queue, or I've seen it before, but not always. I talked to Jeff Barr about this a while back, and apparently, a big Amazonian theme that he lives by is two is better than zero. He'd rather two people tell him about a thing than no one tells him about the thing. And I've tried to embody that. It's the right answer, but it's also super tricky to figure out what people have heard or haven't heard. It leads to interesting places. But enough about my nonsense. Let's talk about your nonsense instead. So, FusionAuth; what do you folks do over there?Dan: So, FusionAuth is an auth provider, and we offer a Community Edition, which is downloadable for free; we also offer premium editions, but the space we play in is really CIAM, which is Customer Identity Access Management. Very similar to Auth0 or Cognito that some of your listeners might have heard of.Corey: If people have heard about Cognito, it's usually bracketed by profanity, in one direction or another, but I'm sure we'll get there in a minute. I will say that I never considered authentication to be a differentiator between services that I use. And then one day I was looking for a tool—I'm not going to name what it was just because I don't really want to deal with the angry letters and whatnot—but I signed up for this thing to test it out, and “Oh, great. So, what's my password?” “Oh, we don't use passwords. We just every time you want to log in, we're going to email you a link and then you go ahead and click the link.”And I hadn't seen something like that before. And my immediate response to that was, “Okay, this feels like an area they've decided to innovate in.” Their core business is basically information retention and returning it to you—basically any CRUD app. Yay. I don't think this is where I want them to be innovating.I want them to use the tried and true solutions, not build their own or be creative on this stuff, so it was a contributor to me wanting to go in a different direction. When you start doing things like that, there's no multi-factor authentication available and you start to wonder, how have they implemented this? What corners have they cut? Who's reviewed this? It just gave me a weird feeling.And that was sort of the day I realized that authentication for me is kind of like crypto, by which I mean cryptography, not cryptocurrency, I want to be very clear on, here. You should not roll your own cryptography, you should not roll your own encryption, you should buy off-the-shelf unless you're one of maybe five companies on the planet. Spoiler, if you're listening to this, you are almost certainly not one of them.Dan: [laugh]. Yeah. So, first of all, I've been at FusionAuth for a couple of years. Before I came to FusionAuth, I had rolled my own authentication a couple of times. And what I've realized working there is that it really is—there a couple of things worth unpacking here.One is you can now buy or leverage open-source libraries or other providers a lot more than you could 15 or 20 years ago. So, it's become this thing that can be snapped into your architecture. The second is, auth is the front door to application. And while it isn't really that differentiated—I don't think most applications, as you kind of alluded to, should innovate there—it is kind of critical that it runs all the time that it's safe and secure, that it's accessible, that it looks like your application.So, at the same time, it's undifferentiated, right? Like, at the end of the day, people just want to get through authentication and authorization schemes into your application. That is really the critical thing. So, it's undifferentiated, it's critical, it needs to be highly available. Those are all things that make it a good candidate for outsourcing.Corey: There are a few things to unpack there. First is that everything becomes commoditized in the fullness of time. And this is a good thing. Back in the original dotcom bubble, there were entire teams of engineers at all kinds of different e-commerce companies that were basically destroying themselves trying to build an online shopping cart. And today you wind up implementing Shopify or something like it—which is usually Shopify—and that solves the problem for you. This is no longer a point of differentiation.If I want to start selling physical goods on the internet, it feels like it'll take me half an hour or so to wind up with a bare-bones shopping cart thing ready to go, and then I just have to add inventory. Authentication feels like it was kind of the same thing. I mean, back in that song from early on in internet history “Code Monkey” talks about building a login page as part of it, and yeah, that was a colossal pain. These days, there are a bunch of different ways to do that with folks who spend their entire careers working on this exact problem so you can go and work on something that is a lot more core and central to the value that your business ostensibly provides. And that seems like the right path to go down.But this does lead to the obvious counter-question of how is it that you differentiate other than, you know, via marketing, which again, not the worst answer in the world, but it also turns into skeezy marketing. “Yes, you should use this other company's option, or you could use ours and we don't have any intentional backdoors in our version.” “Hmm. That sounds more suspicious and more than a little bit frightening. Tell me more.” “No, legal won't let me.” And it's “Okay.” Aside from the terrible things, how do you differentiate?Dan: I liked that. That was an oddly specific disclaimer, right? Like, whenever a company says, “Oh, yeah, no.” [laugh].Corey: “My breakfast cereal has less arsenic than leading brands.”Dan: Perfect. So yeah, so FusionAuth realizes that, kind of, there are a lot of options out there, and so we've chosen to niche down. And one of the things that we really focus on is the CIAM market. And that stands for Customer Identity Access Management. And we can dive into that a little bit later if you want to know more about that.We have a variety of deployment options, which I think differentiates us from a lot of the SaaS providers out there. You can run us as a self-hosted option with, by the way, professional-grade support, you can use us as a SaaS provider if you don't want to run it yourself. We are experts in operating this piece of software. And then thirdly, you can move between them, right? It's your data, so if you start out and you're bare bones and you want to save money, you can start with self-hosted, when you grow, move to the SaaS version.Or we actually have some bigger companies that kickstart on the SaaS version because they want to get going with this integration problem and then later, as they build out their capabilities, they want the option to move it in-house. So, that is a really key differentiator for us. The last one I'd say is we're really dev-focused. Who isn't, right? Everyone says they're dev-focused, but we live that in terms of our APIs, in terms of our documentation, in terms of our open development process. Like, there's actually a GitHub issues list you can go look on the FusionAuth GitHub profile and it shows exactly what we have planned for the next couple of releases.Corey: If you go to one of my test reference applications, lasttweetinaws.com, as of the time of this recording at least, it asks you to authenticate with your Twitter account. And you can do that, and it's free; I don't charge for any of these things. And once you're authenticated, you can use it to author Twitter threads because I needed it to exist, first off, and secondly, it makes a super handy test app to try out a whole bunch of different things.And one of the reasons you can just go and use it without registering an account for this thing or anything else was because I tried to set that up in an early version with Cognito and immediately gave the hell up and figured, all right, if you can find the URL, you can use this thing because the experience was that terrible. If instead, I had gone down the path of using FusionAuth, what would have made that experience different, other than the fact that Cognito was pretty clearly a tech demo at best rather than something that had any care, finish, spit and polish went into it.Dan: So, I've used Cognito. I'm not going to bag on Cognito, I'm going to leave that to—[laugh].Corey: Oh, I will, don't worry. I'll do all the bagging on Cognito you'd like because the problem is, and I want to be clear on this point, is that I didn't understand what it was doing because the interface was arcane, and the failure mode of everything in this entire sector, when the interface is bad, the immediate takeaway is not “This thing's a piece of crap.” It's, “Oh, I'm bad at this. I'm just not smart enough.” And it's insulting, and it sets me off every time I see it. So, if I feel like I'm coming across as relatively annoyed by the product, it's because it made me feel dumb. That is one of those cardinal sins, from my perspective. So, if you work on that team, please reach out. I would love to give you a laundry list of feedback. I'm not here to make you feel bad about your product; I'm here to make you feel bad about making your customers feel bad. Now please, Dan, continue.Dan: Sure. So, I would just say that one of the things that we've strived to do for years and years is translate some of the arcane IAM Identity Access Management jargon into what normal developers expect. And so, we don't have clients in our OAuth implementation—although they really are clients if you're an RFC junkie—we have applications, right? We have users, we have groups, we have all these things that are what users would expect, even though underlying them they're based on the same standards that, frankly, Cognito and Auth0 and a lot of other people use as well.But to get back to your question, I would say that, if you had chosen to use FusionAuth, you would have had a couple of advantages. The first is, as I mentioned, kind of the developer friendliness and the extensive documentation, example applications. The second would be a themeability. And this is something that we hear from our clients over and over again, is Cognito is okay if you stay within the lines in terms of your user interface, right? If you just want to login form, if you want to stay between lines and you don't want to customize your application's login page at all.We actually provide you with HTML templates. It's actually using a language called FreeMarker, but they let you do whatever the heck you want. Now, of course, with great power comes great responsibility. Now, you own that piece, right, and we do have some more simple customization you can do if all you want to do is change the color. But most of our clients are the kind of folks who really want their application login screen to look exactly like their application, and so they're willing to take on that slightly heavier burden. Unfortunately, Cognito doesn't give you that option at all, as far as I can tell when I've kicked the tires on it. The theming is—how I put this politely—some of our clients have found the theming to be lacking.Corey: That's part of the issue where when I was looking at all the reference implementations, I could find for Cognito, it went from “Oh, you have your own app, and its branding, and the rest,” and bam, suddenly, you're looking right, like, you're logging into an AWS console sub-console property because of course they have those. And it felt like “Oh, great. If I'm going to rip off some company's design aesthetic wholesale, I'm sorry, Amazon is nowhere near anywhere except the bottom 10% of that list, I've got to say. I'm sorry, but it is not an aesthetically pleasing site, full stop. So, why impose that on customers?”It feels like it's one of those things where—like, so many Amazon service teams say, “We're going to start by building a minimum lovable product.” And it's yeah, it's a product that only a parent could love. And the problem is, so many of them don't seem to iterate beyond that do a full-featured story. And this is again, this is not every AWS service. A lot of them are phenomenal and grow into themselves over time.One of the best rags-to-riches stories that I can recall is EFS, their Elastic File System, for an example. But others, like Cognito just sort of seem to sit and languish for so long that I've basically given up hope. Even if they wind up eventually fixing all of these problems, the reputation has been cemented at this point. They've got to give it a different terrible name.Dan: I mean, here's the thing. Like, EFS, if it looks horrible, right, or if it has, like, a toughest user experience, guess what? Your users are devs. And if they're forced to use it, they will. They can sometimes see the glimmers of the beauty that is kind of embedded, right, the diamond in the rough. If your users come to a login page and see something ugly, you immediately have this really negative association. And so again, the login and authentication process is really the front door of your application, and you just need to make sure that it shines.Corey: For me at least, so much of what's what a user experience or user takeaway is going to be about a company's product starts with their process of logging into it, which is one of the reasons that I have challenges with the way that multi-factor auth can be presented, like, “Step one, login to the thing.” Oh, great. Now, you have to fish out your YubiKey, or you have to go check your email for a link or find a code somewhere and punch it in. It adds friction to a process. So, when you have these services or tools that oh, your session will expire every 15 minutes and you have to do that whole thing again to log back in, it's ugh, I'm already annoyed by the time I even look at anything beyond just the login stuff.And heaven forbid, like, there are worse things, let's be very clear here. For example, if I log in to a site, and I'm suddenly looking at someone else's account, yeah, that's known as a disaster and I don't care how beautiful the design aesthetic is or how easy to use it is, we're done here. But that is job zero: the security aspect of these things. Then there's all the polish that makes it go from something that people tolerate because they have to into something that, in the context of a login page I guess, just sort of fades into the background.Dan: That's exactly what you want, right? It's just like the old story about the sysadmin. People only notice when things are going wrong. People only care about authentication when it stops them from getting into what they actually want to do, right? No one ever says, “Oh, my gosh, that login experience was so amazing for that application. I'm going to come back to that application,” right? They notice when it's friction, they noticed when it's sand in the gears.And our goal at FusionAuth, obviously, security is job zero because as you said, last thing you want is for a user to have access to some other user's data or to be able to escalate their privileges, but after that, you want to fade in the background, right? No one comes to FusionAuth and builds a whole application on top of it, right? We are one component that plugs into your application and lets you get on to the fundamentals of building the features that your users really care about, and then wraps your whole application in a blanket of security, essentially.Corey: I'll take even one more example before we just drive this point home in a way that I hope resonates with folks. Everyone has an opinion on logging into AWS properties because “Oh, what about your Amazon account?” At which point it's “Oh, sit down. We're going for a ride here. Are you talking about amazon.com account? Are you talking about the root account for my AWS account? Are you talking about an IAM user? Are you talking about the service formerly known as AWS SSO that's now IAM Identity Center users? Are you talking about their Chime user account? Are you talking about your repost forum account?” And so, on and so on and so on. I'm sure I'm missing half a dozen right now off the top of my head.Yeah, that's awful. I've been also developing lately on top of Google Cloud, and it is so far to the opposite end of that spectrum that it's suspicious and more than a little bit frightening. When I go to console.cloud.google.com, I am boom, there. There is no login approach, which on the one hand, I definitely appreciate, just from a pure perspective of you're Google, you track everything I do on the internet. Thank you for not insulting my intelligence by pretending you don't know who I am when I log into your Cloud Console.Counterpoint, when I log into the admin portal for my Google Workspaces account, admin.google.com, it always re-prompts for a password, which is reasonable. You'd think that stuff running production might want to do something like that, in some cases. I would not be annoyed if it asked me to just type in a password again when I get to the expensive things that have lasting repercussions.Although, given my personality, logging into Gmail can have massive career repercussions as soon as I hit send on anything. I digress. It is such a difference from user experience and ease-of-use that it's one of those areas where I feel like you're fighting something of a losing battle, just because when it works well, it's glorious to the point where you don't notice it. When authentication doesn't work well, it's annoying. And there's really no in between.Dan: I don't have anything to say to that. I mean, I a hundred percent agree that it's something that you could have to get right and no one cares, except for when you get it wrong. And if your listeners can take one thing away from this call, right, I know it's we're sponsored by FusionAuth, I want to rep Fusion, I want people to be aware of FusionAuth, but don't roll your own, right? There are a lot of solutions out there. I hope you evaluate FusionAuth, I hope you evaluate some other solutions, but this is such a critical thing and Corey has laid out [laugh] in multiple different ways, the ways it can ruin your user experience and your reputation. So, look at something that you can build or a library that you can build on top of. Don't roll your own. Please, please don't.Corey: This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate. Is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other; which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at honeycomb.io/screaminginthecloud. Observability: it's more than just hipster monitoring.Corey: So, tell me a little bit more about how it is that you folks think about yourselves in just in terms of the market space, for example. The idea of CIAM, customer IAM, it does feel viscerally different than traditional IAM in the context of, you know, AWS, which I use all the time, but I don't think I have the vocabulary to describe it without sounding like a buffoon. What is the definition between the two, please? Or the divergence, at least?Dan: Yeah, so I mean, not to go back to AWS services, but I'm sure a lot of your listeners are familiar with them. AWS SSO or the artist formerly known as AWS SSO is IAM, right? So, it's Workforce, right, and Workforce—Corey: And it was glorious, to the point where I felt like it was basically NDA'ed from other service teams because they couldn't talk about it. But this was so much nicer than having to juggle IAM keys and sessions that timeout after an hour in the console. “What do you doing in the console?” “I'm doing ClickOps, Jeremy. Leave me alone.”It's just I want to make sure that I'm talking about this the right way. It feels like AWS SSO—creature formerly known as—and traditional IAM feels like they're directionally the same thing as far as what they target, as far as customer bases, and what they empower you to do.Dan: Absolutely, absolutely. There are other players in that same market, right? And that's the market that grew up originally: it's for employees. So, employees have this very fixed lifecycle. They have complicated relationships with other employees and departments in organizations, you can tell them what to do, right, you can say you have to enroll your MFA key or you are no longer employed with us.Customers have a different set of requirements, and yet they're crucial to businesses because customers are, [laugh] who pay you money, right? And so, things that customers do that employees don't: they choose to register; they pick you, you don't pick them; they have a wide variety of devices and expectations; they also have a higher expectation of UX polish. Again, with an IAM solution, you can kind of dictate to your employees because you're paying them money. With a customer identity access management solution, it is part of your product, in the same way, you can't really dictate features unless you have something that the customer absolutely has to have and there are no substitutes for it, you have to adjust to the customer demands. CIAM is more responsive to those demands and is a smoother experience.The other thing I would say is CIAM, also, frankly, has a simpler model. Most customers have access to applications, maybe they have a couple of roles that you know, an admin role, an editor role, a viewer role if you're kind of a media conglomerate, for an example, but they don't have necessarily the thicket of complexity that you might have to have an eye on, so it's just simpler to model.Corey: Here's an area that feels like it's on the boundary between them. I distinctly remember being actively annoyed a while back that I had to roll my marketing person her own entire AWS IAM account solely so that she could upload assets into an S3 bucket that was driving some other stuff. It feels very much like that is a better use case for something that is a customer IAM solution. Because if I screw up those permissions even slightly, well, congratulations, now I've inadvertently given someone access to wind up, you know, taking production down. It feels like it is way too close to things that are going to leave a mark, whereas the idea of a customer authentication story for something like that is awesome.And no please if you're listening to this, don't email me with this thing you built and put on the Marketplace that “Oh, it uses signed URLs and whatnot to wind up automatically federating an identity just for this one per—” Yes. I don't want to build something ridiculous and overwrought so a single person can update assets within S3. I promise I don't want to do that. It just ends badly.Dan: Well, that was the promise of Cognito, right? And that is actually one of the reasons you should stick with Cognito if you have super-detailed requirements that are all about AWS and permissions to things inside AWS. Cognito has that tight integration. And I assume—I haven't looked at some of the other big cloud providers, but I assume that some of the other ones have that similar level of integration. So yeah, so that my answer there would be Cognito is the CIAM solution that AWS has, so that is what I would expect it to be able to handle, relatively smoothly.Corey: A question I have for you about the product itself is based on a frustration I originally had with Cognito, which is that once you're in there and you are using that for authentication and you have users, there's no way for me to get access to the credentials of my users. I can't really do an export in any traditional sense. Is that possible with FusionAuth?Dan: Absolutely. So, your data is your data. And because we're a self-hosted or SaaS solution, if you're running it self-hosted, obviously you have access to the password hashes in your database. If you are—Corey: The hashes, not the plaintext passwords to be explicitly clear on this. [laugh].Dan: Absolutely the hashes. And we have a number of guides that help you get hashes from other providers into ours. We have a written export guide ourselves, but it's in the database and the schema is public. You can go download our schema right now. And if—Corey: And I assume you've used an industry standard hashing algorithm for this?Dan: Yeah, we have a number of different options. You can bring your own actually, if you want, and we've had people bring their own options because they have either special needs or they have an older thing that's not as secure. And so, they still want their users to be able to log in, so they write a plugin and then they import the users' hashes, and then we transparently re-encrypt with a more modern one. The default for us is PDK.Corey: I assume you do the re-encryption at login time because there's no other way for you to get that.Dan: Exactly. Yeah yeah yeah—Corey: Yeah.Dan: —because that's the only time we see the password, right? Like we don't see it any other time. But we support Bcrypt and other modern algorithms. And it's entirely configurable; if you want to set a factor, which basically is how—Corey: I want to use MD5 because I'm still living in 2003.Dan: [laugh]. Please don't use MD5. Second takeaway: don't roll your own and don't use MD5. Yeah, so it's very tweakable, but we shipped with a secured default, basically.Corey: I just want to clarify as well why this is actively important. I don't think people quite understand that in many cases, picking an authentication provider is one of those lasting decisions where migrations take an awful lot of work. And they probably should. There should be no mechanism by which I can export the clear text passwords. If any authentication provider advertises or offers such a thing, don't use that one. I'm going to be very direct on that point.The downside to this is that if you are going to migrate from any other provider to any other provider, it has to happen either slowly as in, every time people log in, it'll check with the old system and then migrate that user to the new one, or you have to force password resets for your entire customer base. And the problem with that is I don't care what story you tell me. If I get an email from one of my vendors saying “You now have to reset your password because we're migrating to their auth thing,” or whatnot, there's no way around it, there's no messaging that solves this, people will think that you suffered a data breach that you are not disclosing. And that is a heavy, heavy lift. Another pattern I've seen is it for a period of three months or whatnot, depending on user base, you will wind up having the plug in there, and anyone who logs in after that point will, “Ohh you need to reset your password. And your password is expired. Click here to reset.” That tends to be a little bit better when it's not the proactive outreach announcement, but it's still a difficult lift and it adds—again—friction to the customer experience.Dan: Yep. And the third one—which you imply it—is you have access to your password hashes. They're hashed in a secure manner. And trust me, even though they're hashed securely, like, if you contact FusionAuth and say, “Hey, I want to move off FusionAuth,” we will arrange a way to get you your database in a secure manner, right? It's going to be encrypted, we're going to have a separate password that we communicate with you out-of-band because this is—even if it is hashed and salted and handled correctly, it's still very, very sensitive data because credentials are the keys to the kingdom.So, but those are the three options, right? The slow migration, which is operationally expensive, the requiring the user to reset their password, which is horribly expensive from a user interface perspective, right, and the customer service perspective, or export your password hashes. And we think that the third option is the least of the evils because guess what? It's your data, right? It's your user data. We will help you be careful with it, but you own it.Corey: I think that there's a lot of seriously important nuance to the whole world of authentication. And the fact that this is such a difficult area to even talk about with folks who are not deeply steeped in that ecosystem should be an indication alone that this is the sort of thing that you definitely want to outsource to a company that knows what the hell they're doing. And it's not like other areas of tech where you can basically stumble your way through something. It's like “Well, I'm going to write a Lambda to go ahead and post some nonsense on Twitter.” “Okay, are you good at programming?” “Not even slightly, but I am persistent and brute force is a viable strategy, so we're going to go with that one.” “Great. Okay, that's awesome.”But authentication is one of those areas where mistakes will show. The reputational impact of losing data goes from merely embarrassing to potentially life-ruining for folks. The most stressful job I've ever had from a data security position wasn't when I was dealing with money—because that's only money, which sounds like a weird thing to say—it was when I did a brief stint at Grindr where people weren't out. In some countries, users could have wound up in jail or have been killed if their sexuality became known. And that was the stuff that kept me up at night.Compared to that, “Okay, you got some credit card numbers with that. What the hell do I care about that, relatively speaking?” It's like, “Yeah, it's well, my credit card number was stolen.” “Yeah, but did you die, though?” “Oh, you had to make a phone call and reset some stuff.” And I'm not trivializing the importance of data security. Especially, like, if you're a bank, and you're listening to this, and you're terrified, yeah, that's not what I'm saying at all. I'm just saying there are worse things.Dan: Sure. Yeah. I mean, I think that, unfortunately, the pandemic showed us that we're living more and more of our lives online. And the identity online and making sure that safe and secure is just critical. And again, not just for your employees, although that's really important, too, but more of your customer interactions are going to be taking place online because it's scalable, because it makes people money, because it allows for capabilities that weren't previously there, and you have to take that seriously. So, take care of your users' data. Please, please do that.Corey: And one of the best ways you can do that is by not touching the things that are commoditized in your effort to apply differentiation. That's why I will never again write my own auth system, with a couple of asterisks next to it because some of what I do is objectively horrifying, intentionally so. But if I care about the authentication piece, I have the good sense to pay someone else to do it for me.Dan: From personal experience, you mentioned at the beginning that we go back aways. I remember when I first discovered RDS, and I thought, “Oh, my God. I can outsource all this scut work, all of the database backups, all of the upgrades, all of the availability checking, right? Like, I can outsource this to somebody else who will take this off my plate.” And I was so thankful.And I don't—outside of, again, with some asterisks, right, there are places where I could consider running a database, but they're very few and far between—I feel like auth has entered that category. There are great providers like FusionAuth out there that are happy to take this off your plate and let you move forward. And in some ways, I'm not really sure which is more dangerous; like, not running a database properly or not running an auth system properly. They both give me shivers and I would hate to [laugh] hate to be forced to choose. But they're comparable levels of risk, so I a hundred percent agree, Corey.Corey: Dan, I really want to thank you for taking so much time to talk to me about your view of the world. If people want to learn more because you're not in their inboxes responding to newsletters every week, where's the best place to find you?Dan: Sure, you can find more about me at Twitter. I'm @mooreds, M-O-O-R-E-D-S. And you can learn more about FusionAuth and download it for free at fusionauth.io.Corey: And we will put links to all of that in the show notes. I really want to thank you again for just being so generous with your time. It's deeply appreciated.Dan: Corey, thank you so much for having me.Corey: Dan Moore, Head of DevRel at FusionAuth. I'm Cloud Economist Corey Quinn. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment that will be attributed to someone else because they screwed up by rolling their own authentication.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
On The Cloud Pod this week, the team gets skeptical on Prime Day numbers. Plus: AWS re:Inforce brings GuardDuty, Detective and Identity Center updates and announcements; Google Cloud says hola to Mexico with a new Latin American region; and Azure introduces its new cost API for EC and MCA customers. A big thanks to this week's sponsor, Foghorn Consulting, which provides full-stack cloud solutions with a focus on strategy, planning and execution for enterprises seeking to take advantage of the transformative capabilities of AWS, Google Cloud and Azure. This week's highlights
Uncommon Conversations: Deep Talks with Community & DevRel Leaders
In this 25-minute convo, Jeff Barr, VP & Chief Evangelist at AWS for over 20 years, talks about the importance of making developer education accessible and approachable, showing up for your community both in-person and online, and truly welcoming new members into community spaces. Community and DevRel leaders perform incredible feats to grow, engage, and support their communities, empower their businesses, and build products and experiences people love. Each day, they bring their companies and communities closer together. These are the stories of their work. The Uncommon community is powered by Common Room, the intelligent community growth platform that enables you to unlock community insights so you can grow happier customers, measure outcomes, and drive business impact. Learn more about how you can help your community thrive with Common Room at commonroom.io , and join the Uncommon community at commonroom.io/uncommon.
Hey Everyone… Joining us today is AWS Chief Evangelist Jeff Barr for a behind the scenes look into his recording studio and office. Including his “Jeff Barr” style of building it out to scale in a lego model. Speaking of models, you need to stick around and see Jeff's 3D printing station. The first AWS re:invent in two years happened back in December and Jeff is going to give us his take on the whole event. Also, stick around because it seems like Jeff has taken up a new hobby that has nothing to do with Tech or AWS but he's making a lot of “dough” doing it.
Hey Everyone… Joining us today is AWS Chief Evangelist Jeff Barr for a behind the scenes look into his recording studio and office. Including his “Jeff Barr” style of building it out to scale in a lego model. Speaking of models, you need to stick around and see Jeff's 3D printing station. The first AWS re:invent in two years happened back in December and Jeff is going to give us his take on the whole event. Also, stick around because it seems like Jeff has taken up a new hobby that has nothing to do with Tech or AWS but he's making a lot of “dough” doing it.
On The Cloud Pod this week, the team discusses Peter's concept of fun. Plus digital adventures with AWS Cloud Quest game, much-wanted Google price increases, and a labyrinthine run-through of the details of Azure Health Data Services. A big thanks to this week's sponsor, Foghorn Consulting, which provides full-stack cloud solutions with a focus on strategy, planning and execution for enterprises seeking to take advantage of the transformative capabilities of AWS, Google Cloud and Azure. This week's highlights
About AnilAnil Dash is the CEO of Glitch, the friendly developer community where coders collaborate to create and share millions of web apps. He is a recognized advocate for more ethical tech through his work as an entrepreneur and writer. He serves as a board member for organizations like the Electronic Frontier Foundation, the leading nonprofit defending digital privacy and expression, Data & Society Research Institute, which researches the cutting edge of tech's impact on society, and The Markup, the nonprofit investigative newsroom that pushes for tech accountability. Dash was an advisor to the Obama White House's Office of Digital Strategy, served for a decade on the board of Stack Overflow, the world's largest community for coders, and today advises key startups and non-profits including the Lower East Side Girls Club, Medium, The Human Utility, DonorsChoose and Project Include.As a writer and artist, Dash has been a contributing editor and monthly columnist for Wired, written for publications like The Atlantic and Businessweek, co-created one of the first implementations of the blockchain technology now known as NFTs, had his works exhibited in the New Museum of Contemporary Art, and collaborated with Hamilton creator Lin-Manuel Miranda on one of the most popular Spotify playlists of 2018. Dash has also been a keynote speaker and guest in a broad range of media ranging from the Obama Foundation Summit to SXSW to Desus and Mero's late-night show.Links: Glitch: https://glitch.com Web.dev: https://web.dev Glitch Twitter: https://twitter.com/glitch Anil Dash Twitter: https://twitter.com/anildash TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: It seems like there is a new security breach every day. Are you confident that an old SSH key, or a shared admin account, isn't going to come back and bite you? If not, check out Teleport. Teleport is the easiest, most secure way to access all of your infrastructure. The open source Teleport Access Plane consolidates everything you need for secure access to your Linux and Windows servers—and I assure you there is no third option there. Kubernetes clusters, databases, and internal applications like AWS Management Console, Yankins, GitLab, Grafana, Jupyter Notebooks, and more. Teleport's unique approach is not only more secure, it also improves developer productivity. To learn more visit: goteleport.com. And not, that is not me telling you to go away, it is: goteleport.com.Corey: It seems like there is a new security breach every day. Are you confident that an old SSH key, or a shared admin account, isn't going to come back and bite you? If not, check out Teleport. Teleport is the easiest, most secure way to access all of your infrastructure. The open source Teleport Access Plane consolidates everything you need for secure access to your Linux and Windows servers—and I assure you there is no third option there. Kubernetes clusters, databases, and internal applications like AWS Management Console, Yankins, GitLab, Grafana, Jupyter Notebooks, and more. Teleport's unique approach is not only more secure, it also improves developer productivity. To learn more visit: goteleport.com. And not, that is not me telling you to go away, it is: goteleport.com.Corey: This episode is sponsored in part by our friends at Redis, the company behind the incredibly popular open source database that is not the bind DNS server. If you're tired of managing open source Redis on your own, or you're using one of the vanilla cloud caching services, these folks have you covered with the go to manage Redis service for global caching and primary database capabilities; Redis Enterprise. To learn more and deploy not only a cache but a single operational data platform for one Redis experience, visit redis.com/hero. Thats r-e-d-i-s.com/hero. And my thanks to my friends at Redis for sponsoring my ridiculous non-sense. Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's guest is a little bit off the beaten path from the cloud infrastructure types I generally drag, kicking and screaming, onto the show. If we take a look at the ecosystem and where it's going, it's clear that in the future, not everyone who wants to build a business, or a tool, or even an application is going to necessarily spring fully-formed into the world from the forehead of some God, knowing how to code. And oh, “I'm going to go to a boot camp for four months to learn how to do it first,” is increasingly untenable. I don't know if you would call it low-code or not. But that's how it feels. My guest today is Anil Dash, CEO of Glitch. Anil, thank you for joining me.Anil: Thanks so much for having me.Corey: So, let's get the important stuff out of the way first, since I have a long-standing history of mispronouncing the company Twitch as ‘Twetch,' I should probably do the same thing here. So, what is Gletch? And what does it do?Anil: Glitch is, at its simplest, a tool that lets you build a full-stack app in your web browser in about 30 seconds. And, you know, for your community, your audience, it's also this ability to create and deploy code instantly on a full-stack server with no concern for deploy, or DevOps, or provisioning a container, or any of those sort of concerns. And what it is for the users is, honestly, a community. They're like, “I looked at this app that was on Glitch; I thought it was cool; I could do what we call [remixing 00:02:03].” Which is to kind of fork that app, a running app, make a couple edits, and all of a sudden live at a real URL on the web, my app is running with exactly what I built. And that's something that has been—I think, just captured a lot of people's imagination to now where they've built over 12 or 15 million apps on the platform.Corey: You describe it somewhat differently than I would, and given that I tend to assume that people who create and run successful businesses don't generally tend to do it without thought, I'm not quite, I guess, insufferable enough to figure out, “Oh, well, I thought about this for ten seconds, therefore I've solved a business problem that you have been needling at for years.” But when I look at Glitch, I would describe it as something different than the way that you describe it. I would call it a web-based IDE for low-code applications and whatnot, and you never talk about it that way. Everything I can see there describes it talks about friendly creators, and community tied to it. Why is that?Anil: You're not wrong from the conventional technologist's point of view. I—sufficient vintage; I was coding in Visual Basic back in the '90s and if you squint, you can see that influence on Glitch today. And so I don't reject that description, but part of it is about the audience we're speaking to, which is sort of a next generation of creators. And I think importantly, that's not just age, right, but that could be demographic, that can be just sort of culturally, wherever you're at. And what we look at is who's making the most interesting stuff on the internet and in the industry, and they tend to be grounded in broader culture, whether they're on, you know, Instagram, or TikTok, or, you know, whatever kind of influencer, you want to point at—YouTube.And those folks, they think of themselves as creators first and they think of themselves as participating in the community first and then the tool sort of follow. And I think one of the things that's really striking is, if you look at—we'll take YouTube as an example because everyone's pretty familiar with it—they have a YouTube Creator Studio. And it is a very rich and deep tool. It does more than, you know, you would have had iMovie, or Final Cut Pro doing, you know, 10 or 15 years ago, incredibly advanced stuff. And those [unintelligible 00:04:07] use it every day, but nobody goes to YouTube and says, “This is a cloud-based nonlinear editor for video production, and we target cinematographers.” And if they did, they would actually narrow their audience and they would limit what their impact is on the world.And so similarly, I think we look at that for Glitch where the social object, the central thing that people organize around a Glitch is an app, not code. And that's this really kind of deep and profound idea, which is that everybody can understand an app. Everybody has an idea for an app. You know, even the person who's, “Ah, I'm not technical,” or, “I'm not really into technology,” they're like, “But you know what? If I could make an app, I would make this.”And so we think a lot about that creative impulse. And the funny thing is, that is a common thread between somebody that literally just got on the internet for the first time and somebody who has been doing cloud deploys for as long as there's been a cloud to deploy to, or somebody has been coding for decades. No matter who you are, you have that place that is starting from what's the experience I want to build, the app I want to build? And so I think that's where there's that framing. But it's also been really useful, in that if you're trying to make a better IDE in the cloud and a better text editor, and there are multiple trillion-dollar companies that [laugh] are creating products in that category, I don't think you're going to win. On the other hand, if you say, “This is more fun, and cooler, and has a better design, and feels better,” I think we could absolutely win in a walk away compared to trillion-dollar companies trying to be cool.Corey: I think that this is an area that has a few players in it could definitely stand to benefit by having more there. My big fear is not that AWS is going to launch stuff in your space and drive you out of business; I think that is a somewhat naive approach. I'm more concerned that they're going to try to launch something in your space, give it a dumb name, fail that market and appropriately, not understand who it's for and set the entire idea back five years. That is, in some cases, it seems like their modus operandi for an awful lot of new markets.Anil: Yeah, I mean, that's not an uncommon problem in any category that's sort of community driven. So, you know, back in the day, I worked on building blogging tools at the beginning of this, sort of, social media era, and we worried about that a lot. We had built some of the first early tools, Movable Type, and TypePad, and these were what were used to launch, like, Gawker and Huffington Post and all the, sort of, big early sites. And we had been doing it a couple years—and then at that time, major player—AOL came in, and they launched their own AOL blog service, and we were, you know, quaking in our boots. I remember just being kind of like, pit in your stomach, “Oh, my gosh. This is going to devastate the category.”And as it turns out, people were smart, and they have taste, and they can tell. And the domain that we're in is not one that is about raw computing power or raw resources that you can bring to bear so much as it is about can you get people to connect together, collaborate together, and feel like they're in a place where they want to make something and they want to share it with other people? And I mean, we've never done a single bit of advertising for Glitch. There's never been any paid acquisition. There's never done any of those things. And we go up against, broadly in the space, people that have billboards and they buy out all the ads of the airport and, you know, all the other kind of things we see—Corey: And they do the typical enterprise thing where they spend untold millions in acquiring the real estate to advertise on, and then about 50 cents on the message, from the looks of it. It's, wow, you go to all this trouble and expense to get something in front of me, and after all of that to get my attention, you don't have anything interesting to say?Anil: Right.Corey: [crosstalk 00:07:40] inverse of that.Anil: [crosstalk 00:07:41] it doesn't work.Corey: Yeah. Oh, yeah. It's brand awareness. I love that game. Ugh.Anil: I was a CIO, and not once in my life did I ever make a purchasing decision based on who was sponsoring a golf tournament. It never happened, right? Like, I never made a call on a database platform because of a poster that was up at, you know, San Jose Airport. And so I think that's this thing that developers in particular, have really good BS filters, and you can sort of see through.Corey: What I have heard about the airport advertising space—and I but a humble cloud economist; I don't know if this is necessarily accurate or not—but if you have a company like Accenture, for example, that advertises on airport billboards, they don't even bother to list their website. If you go to their website, it turns out that there's no shopping cart function. I cannot add ‘one consulting' to my cart and make a purchase.Anil: “Ten pounds of consult, please.”Corey: Right? I feel like the primary purpose there might very well be that when someone presents to your board and says, “All right, we've had this conversation with Accenture.” The response is not, “Who?” It's a brand awareness play, on some level. That said, you say you don't do a bunch traditional advertising, but honestly, I feel like you advertise—more successfully—than I do at The Duckbill Group, just by virtue of having a personality running the company, in your case.Now, your platform is for the moment, slightly larger than mine, but that's okay,k I have ambition and a tenuous grasp of reality and I'm absolutely going to get there one of these days. But there is something to be said for someone who has a track record of doing interesting things and saying interesting things, pulling a, “This is what I do and this is how I do it.” It almost becomes a personality-led marketing effort to some degree, doesn't it?Anil: I'm a little mindful of that, right, where I think—so a little bit of context and history: Glitch as a company is actually 20 years old. The product is only a few years old, but we were formerly called Fog Creek Software, co-founded by Joel Spolsky who a lot of folks will know from back in the day as Joel on Software blog, was extremely influential. And that company, under leadership of Joel and his co-founder Michael Pryor spun out Stack Overflow, they spun out Trello. He had created, you know, countless products over the years so, like, their technical and business acumen is off the charts.And you know, I was on the board of Stack Overflow from, really, those first days and until just recently when they sold, and you know, you get this insight into not just how do you build a developer community that is incredibly valuable, but also has a place in the ecosystem that is unique and persists over time. And I think that's something that was very, very instructive. And so when it came in to lead Glitch I, we had already been a company with a, sort of, visible founder. Joel was as well known as a programmer as it got in the world?Corey: Oh, yes.Anil: And my public visibility is different, right? I, you know, I was a working coder for many years, but I don't think that's what people see me on social media has. And so I think, I've been very mindful where, like, I'm thrilled to use the platform I have to amplify what was created on a Glitch. But what I note is it's always, “This person made this thing. This person made this app and it had this impact, and it got these results, or made this difference for them.”And that's such a different thing than—I don't ever talk about, “We added syntax highlighting in the IDE and the editor in the browser.” It's just never it right. And I think there are people that—I love that work. I mean, I love having that conversation with our team, but I think that's sort of the difference is my enthusiasm is, like, people are making stuff and it's cool. And that sort of is my lens on the whole world.You know, somebody makes whatever a great song, a great film, like, these are all things that are exciting. And the Glitch community's creations sort of feel that way. And also, we have other visible people on the team. I think of our sort of Head of Community, Jenn Schiffer, who's a very well known developer and her right. And you know, tons of people have read her writing and seen her talks over the years.And she and I talk about this stuff; I think she sort of feels the same way, which is, she's like, “If I were, you know, being hired by some cloud platform to show the latest primitives that they've deployed behind an API,” she's like, “I'd be miserable. Like, I don't want to do that in the world.” And I sort of feel the same way. But if you say, “This person who never imagined they would make an app that would have this kind of impact.” And they're going to, I think of just, like, the last couple of weeks, some of the apps we've seen where people are—it could be [unintelligible 00:11:53]. It could be like, “We made a Slack bot that finally gets this reporting into the right channel [laugh] inside our company, but it was easy enough that I could do it myself without asking somebody to create it even though I'm not technically an engineer.” Like, that's incredible.The other extreme, we have people that are PhDs working on machine learning that are like, “At the end of the day, I don't want to be responsible for managing and deploying. [laugh]. I go home, and so the fact that I can do this in create is really great.” I think that energy, I mean, I feel the same way. I still build stuff all the time, and I think that's something where, like, you can't fake that and also, it's bigger than any one person or one public persona or social media profile, or whatever. I think there's this bigger idea. And I mean, to that point, there are millions of developers on Glitch and they've created well over ten million apps. I am not a humble person, but very clearly, that's not me, you know? [laugh].Corey: I have the same challenge to it's, effectively, I have now a 12 employee company and about that again contractors for various specialized functions, and the common perception, I think, is that mostly I do all the stuff that we talk about in public, and the other 11 folks sort of sit around and clap as I do it. Yeah, that is only four of those people's jobs as it turns out. There are more people doing work here. It's challenging, on some level, to get away from the myth of the founder who is the person who has the grand vision and does all the work and sees all these things.Anil: This industry loves the myth of the great man, or the solo legend, or the person in their bedroom is a genius, the lone genius, and it's a lie. It's a lie every time. And I think one of the things that we can do, especially in the work at Glitch, but I think just in my work overall with my whole career is to dismantle that myth. I think that would be incredibly valuable. It just would do a service for everybody.But I mean, that's why Glitch is the way it is. It's a collaboration platform. Our reference points are, you know, we look at Visual Studio and what have you, but we also look at Google Docs. Why is it that people love to just send a link to somebody and say, “Let's edit this thing together and knock out a, you know, a memo together or whatever.” I think that idea we're going to collaborate together, you know, we saw that—like, I think of Figma, which is a tool that I love. You know, I knew Dylan when he was a teenager and watching him build that company has been so inspiring, not least because design was always supposed to be collaborative.And then you think about we're all collaborating together in design every day. We're all collaborating together and writing in Google Docs—or whatever we use—every day. And then coding is still this kind of single-player game. Maybe at best, you throw something over the wall with a pull request, but for the most part, it doesn't feel like you're in there with somebody. Certainly doesn't feel like you're creating together in the same way that when you're jamming on these other creative tools does. And so I think that's what's been liberating for a lot of people is to feel like it's nice to have company when you're making something.Corey: Periodically, I'll talk to people in the AWS ecosystem who for some reason appear to believe that Jeff Barr builds a lot of these services himself then writes blog posts about them. And it's, Amazon does not break out how many of its 1.2 million or so employees work at AWS, but I'm guessing it's more than five people. So yeah, Jeff probably only wrote a dozen of those services himself; the rest are—Anil: That's right. Yeah.Corey: —done by service teams and the rest. It's easy to condense this stuff and I'm as guilty of it as anyone. To my mind, a big company is one that has 200 people in it. That is not apparently something the world agrees with.Anil: Yeah, it's impossible to fathom an organization of hundreds of thousands or a million-plus people, right? Like, our brains just aren't wired to do it. And I think so we reduce things to any given Jeff, whether that's Barr or Bezos, whoever you want to point to.Corey: At one point, I think they had something like more men named Jeff on their board than they did women, which—Anil: Yeah. Mm-hm.Corey: —all right, cool. They've fixed that and now they have a Dave problem.Anil: Yeah [unintelligible 00:15:37] say that my entire career has been trying to weave out of that dynamic, whether it was a Dave, a Mike, or a Jeff. But I think that broader sort of challenge is this—that is related to the idea of there being this lone genius. And I think if we can sort of say, well, creation always happens in community. It always happens influenced by other things. It is always—I mean, this is why we talk about it in Glitch.When you make an app, you don't start from a blank slate, you start from a working app that's already on the platform and you're remix it. And there was a little bit of a ego resistance by some devs years ago when they first encountered that because [unintelligible 00:16:14] like, “No, no, no, I need a blank page, you know, because I have this brilliant idea that nobody's ever thought of before.” And I'm like, “You know, the odds are you'll probably start from something pretty close to something that's built before.” And that enabler of, “There's nothing new under the sun, and you're probably remixing somebody else's thoughts,” I think that sort of changed the tenor of the community. And I think that's something where like, I just see that across the industry.When people are open, collaborative, like even today, a great example is web browsers. The folks making web browsers at Google, Apple, Mozilla are pretty collaborative. They actually do share ideas together. I mean, I get a window into that because they actually all use Glitch to do test cases on different bugs and stuff for them, but you see, one Glitch project will add in folks from Mozilla and folks from Apple and folks from the Chrome team and Google, and they're like working together and you're, like—you kind of let down the pretense of there being this secret genius that's only in this one organization, this one group of people, and you're able to make something great, and the web is greater than all of them. And the proof, you know, for us is that Glitch is not a new idea. Heroku wanted to do what we're doing, you know, a dozen years ago.Corey: Yeah, everyone wants to build Heroku except the company that acquired Heroku, and here we are. And now it's—I was waiting for the next step and it just seemed like it never happened.Anil: But you know when I talked to those folks, they were like, “Well, we didn't have Docker, and we didn't have containerization, and on the client side, we didn't have modern browsers that could do this kind of editing experience, all this kind of thing.” So, they let their editor go by the wayside and became mostly deploy platform. And—but people forget, for the first year or two Heroku had an in-browser editor, and an IDE and, you know, was constrained by the tech at the time. And I think that's something where I'm like, we look at that history, we look at, also, like I said, these browser manufacturers working together were able to get us to a point where we can make something better.Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance accelerator for the Oracle MySQL Database Service. Although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLTP and OLAP, don't ask me to ever say those acronyms again, workloads directly from your MySQL database and eliminate the time consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora, and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.Corey: I do have a question for you about the nuts and bolts behind the scenes of Glitch and how it works. If I want to remix something on Glitch, I click the button, a couple seconds later it's there and ready for me to start kicking the tires on, which tells me a few things. One, it is certainly not using CloudFormation to provision it because I didn't have time to go and grab a quick snack and take a six hour nap. So, it apparently is running on computers somewhere. I have it on good authority that this is not just run by people who are very fast at assembling packets by hand. What does the infrastructure look like?Anil: It's on AWS. Our first year-plus of prototyping while we were sort of in beta and early stages of Glitch was getting that time to remix to be acceptable. We still wish it were faster; I mean, that's always the way but, you know, when we started, it was like, yeah, you did sit there for a minute and watch your cursor spin. I mean, what's happening behind the scenes, we're provisioning a new container, standing up a full stack, bringing over the code from the Git repo on the previous project, like, we're doing a lot of work, lift behind the scenes, and we went through every possible permutation of what could make that experience be good enough. So, when we start talking about prototyping, we're at five-plus, almost six years ago when we started building the early versions of what became Glitch, and at that time, we were fairly far along in maturity with Docker, but there was not a clear answer about the use case that we're building for.So, we experimented with Docker Swarm. We went pretty far down that road; we spent a good bit of time there, it failed in ways that were both painful and slow to fix. So, that was great. I don't recommend that. In fairness, we have a very unusual use case, right? So, Glitch now, if you talk about ten million containers on Glitch, no two of those apps are the same and nobody builds an orchestration infrastructure assuming that every single machine is a unique snowflake.Corey: Yeah, massively multi-tenant is not really a thing that people know.Anil: No. And also from a security posture Glitch—if you look at it as a security expert—it is a platform allowing anonymous users to execute arbitrary code at scale. That's what we do. That's our job. And so [laugh], you know, so your threat model is very different. It's very different.I mean, literally, like, you can go to Glitch and build an app, running a full-stack app, without even logging in. And the reason we enable that is because we see kids in classrooms, they're learning to code for the first time, they want to be able to remix a project and they don't even have an email address. And so that was about enabling something different, right? And then, similarly, you know, we explored Kubernetes—because of course you do; it's the default choice here—and some of the optimizations, again, if you go back several years ago, being able to suspend a project and then quickly sort of rehydrate it off disk into a running app was not a common use case, and so it was not optimized. And so we couldn't offer that experience because what we do with Glitch is, if you haven't used an app in five minutes, and you're not a paid member, who put that app to sleep. And that's just a reasonable—Corey: Uh, “Put the app to sleep,” as in toddler, or, “Put the app to sleep,” as an ill puppy.Anil: [laugh]. Hopefully, the former, but when we were at our worst and scaling the ladder. But that is that thing; it's like we had that moment that everybody does, which is that, “Oh, no. This worked.” That was a really scary moment where we started seeing app creation ramping up, and number of edits that people were making in those apps, you know, ramping up, which meant deploys for us ramping up because we automatically deploy as you edit on Glitch. And so, you know, we had that moment where just—well, as a startup, you always hope things go up into the right, and then they do and then you're not sleeping for a long time. And we've been able to get it back under control.Corey: Like, “Oh, no, I'm not succeeding.” Followed immediately by, “Oh, no, I'm succeeding.” And it's a good problem to have.Anil: Exactly. Right, right, right. The only thing worse than failing is succeeding sometimes, in terms of stress levels. And organizationally, you go through so much; technically, you go through so much. You know, we were very fortunate to have such thoughtful technical staff to navigate these things.But it was not obvious, and it was not a sort of this is what you do off the shelf. And our architecture was very different because people had looked at—like, I look at one of our inspirations was CodePen, which is a great platform and the community love them. And their front end developers are, you know, always showing off, “Here's this cool CSS thing I figured out, and it's there.” But for the most part, they're publishing static content, so architecturally, they look almost more like a content management system than an app-running platform. And so we couldn't learn anything from them about our scaling our architecture.We could learn from them on community, and they've been an inspiration there, but I think that's been very, very different. And then, conversely, if we looked at the Herokus of the world, or all those sort of easy deploy, I think Amazon has half a dozen different, like, “This will be easier,” kind of deploy tools. And we looked at those, and they were code-centric not app-centric. And that led to fundamentally different assumptions in user experience and optimization.And so, you know, we had to chart our own path and I think it was really only the last year or so that we were able to sort of turn the corner and have high degree of confidence about, we know what people build on Glitch and we know how to support and scale it. And that unlocked this, sort of, wave of creativity where there are things that people want to create on the internet but it had become too hard to do so. And the canonical example I think I was—those of us are old enough to remember FTPing up a website—Corey: Oh, yes.Anil: —right—to Geocities, or whatever your shared web host was, we remember how easy that was and how much creativity was enabled by that.Corey: Yes, “How easy it was,” quote-unquote, for those of us who spent years trying to figure out passive versus active versus ‘what is going on?' As far as FTP transfers. And it turns out that we found ways to solve for that, mostly, but it became something a bit different and a bit weird. But here we are.Anil: Yeah, there was definitely an adjustment period, but at some point, if you'd made an HTML page in notepad on your computer, and you could, you know, hurl it at a server somewhere, it would kind of run. And when you realize, you look at the coding boot camps, or even just to, like, teach kids to code efforts, and they're like, “Day three. Now, you've gotten VS Code and GitHub configured. We can start to make something.” And you're like, “The whole magic of this thing getting it to light up. You put it in your web browser, you're like, ‘That's me. I made this.'” you know, north star for us was almost, like, you go from zero to hello world in a minute. That's huge.Corey: I started participating one of those boot camps a while back to help. Like, the first thing I changed about the curriculum was, “Yeah, we're not spending time teaching people how to use VI in, at that point, the 2010s.” It was, that was a fun bit of hazing for those of us who were becoming Unix admins and knew that wherever we'd go, we'd find VI on a server, but here in the real world, there are better options for that.Anil: This is rank cruelty.Corey: Yeah, I mean, I still use it because 20 years of muscle memory doesn't go away overnight, but I don't inflict that on others.Anil: Yeah. Well, we saw the contrast. Like, we worked with, there's a group called Mouse here in New York City that creates the computer science curriculum for the public schools in the City of New York. And there's a million kids in public school in New York City, right, and they all go through at least some of this CS education. [unintelligible 00:24:49] saw a lot of work, a lot of folks in the tech community here did. It was fantastic.And yet they were still doing this sort of very conceptual, theoretical. Here's how a professional developer would set up their environment. Quote-unquote, “Professional.” And I'm like, you know what really sparks kids' interests? If you tell them, “You can make a page and it'll be live and you can send it to your friend. And you can do it right now.”And once you've sparked that creative impulse, you can't stop them from doing the rest. And I think what was wild was kids followed down that path. Some of the more advanced kids got to high school and realized they want to experiment with, like, AI and ML, right? And they started playing with TensorFlow. And, you know, there's collaboration features in Glitch where you can do real-time editing and a code with this. And they went in the forum and they were asking questions, that kind of stuff. And the people answering their questions were the TensorFlow team at Google. [laugh]. Right?Corey: I remember those days back when everything seemed smaller and more compact, [unintelligible 00:25:42] but almost felt like a balkanization of community—Anil: Yeah.Corey: —where now it's oh, have you joined that Slack team, and I'm looking at this and my machine is screaming for more RAM. It's, like, well, it has 128 gigs in it. Shouldn't that be enough? Not for Slack.Anil: Not for chat. No, no, no. Chat is demanding.Corey: Oh, yeah, that and Chrome are basically trying to out-ram each other. But if you remember the days of volunteering as network staff on Freenode when you could basically gather everyone for a given project in the entire stack on the same IRC network. And that doesn't happen anymore.Anil: And there's something magic about that, right? It's like now the conversations are closed off in a Slack or Discord or what have you, but to have a sort of open forum where people can talk about this stuff, what's wild about that is, for a beginner, a teenage creator who's learning this stuff, the idea that the people who made the AI, I can talk to, they're alive still, you know what I mean? Like, yeah, they're not even that old. But [laugh]. They think of this is something that's been carved in stone for 100 years.And so it's so inspiring to them. And then conversely, talking to the TensorFlow team, they made these JavaScript examples, like, tensorflow.js was so accessible, you know? And they're like, “This is the most heartwarming thing. Like, we think about all these enterprise use cases or whatever. But like, kids wanting to make stuff, like recognize their friends' photo, and all the vision stuff they're doing around [unintelligible 00:26:54] out there,” like, “We didn't know this is why we do it until we saw this is why we do it.”And that part about connecting the creative impulse from both, like, the most experienced, advanced coders at the most august tech companies that exist, as well as the most rank beginners in public schools, who might not even have a computer at home, saying that's there—if you put those two things together, and both of those are saying, “I'm a coder; I'm able to create; I can make something on the internet, and I can share it with somebody and be inspired by it,” like, that is… that's as good as it gets.Corey: There's something magic in being able to reach out to people who built this stuff. And honestly—you shouldn't feel this way, but you do—when I was talking to the folks who wrote the things I was working on, it really inspires you to ask better questions. Like when I'm talking to Dr. Venema, the author of Postfix and I'm trying to figure out how this thing works, well, I know for a fact that I will not be smarter than he is at basically anything in that entire universe, and maybe most beyond that, as well, however, I still want to ask a question in such a way that doesn't make me sound like a colossal dumbass. So, it really inspires you—Anil: It motivates you.Corey: Oh, yeah. It inspires you to raise your question bar up a bit, of, “I am trying to do x. I expect y to happen. Instead, z is happening as opposed to what I find the documentation that”—oh, as I read the documentation, discover exactly what I messed up, and then I delete the whole email. It's amazing how many of those things you never send because when constructing a question the right way, you can help yourself.Anil: Rubber ducking against your heroes.Corey: Exactly.Anil: I mean, early in my career, I'd gone through sort of licensing mishap on a project that later became open-source, and sort of stepped it in and as you do, and unprompted, I got an advice email from Dan Bricklin, who invented the spreadsheet, he invented VisiCalc, and he had advice and he was right. And it was… it was unreal. I was like, this guy's one of my heroes. I grew up reading about his work, and not only is he, like, a living, breathing person, he's somebody that can have the kindness to reach out and say, “Yeah, you know, have you tried this? This might work.”And it's, this isn't, like, a guy who made an app. This is the guy who made the app for which the phrase killer app was invented, right? And, you know, we've since become friends and I think a lot of his inspiration and his work. And I think it's one of the things it's like, again, if you tell somebody starting out, the people who invented the fundamental tools of the digital era, are still active, still building stuff, still have advice to share, and you can connect with them, it feels like a cheat code. It feels like a superpower, right? It feels like this impossible thing.And I think about like, even for me, the early days of the web, view source, which is still buried in our browser somewhere. And you can see the code that makes the page, it felt like getting away with something. “You mean, I can just look under the hood and see how they made this page and then I can do it too?” I think we forget how radical that is—[unintelligible 00:29:48] radical open-source in general is—and you see it when, like, you talk to young creators. I think—you know, I mean, Glitch obviously is used every day by, like, people at Microsoft and Google and the New York Timesor whatever, like, you know, the most down-the-road, enterprise developers, but I think a lot about the new creators and the people who are learning, and what they tell me a lot is the, like, “Oh, so I made this app, but what do I have to do to put it on the internet?”I'm like, “It already is.” Like, as soon as you create it, that URL was live, it all works. And their, like, “But isn't there, like, an app store I have to ask? Isn't there somebody I have to get permission to publish this from? Doesn't somebody have to approve it?”And you realize they've grown up with whether it was the app stores on their phones, or the cartridges in their Nintendo or, you know, whatever it was, they had always had this constraint on technology. It wasn't something you make; it's something that is given to you, you know, handed down from on high. And I think that's the part that animates me and the whole team, the community, is this idea of, like, I geek out about our infrastructure. I love that we're doing deploys constantly, so fast, all the time, and I love that we've taken the complexity away, but the end of the day, the reason why we do it, is you can have somebody just sort of saying, I didn't realize there was a place I could just make something put it in front of, maybe, millions of people all over the world and I don't have to ask anybody permission and my idea can matter as much as the thing that's made by the trillion-dollar company.Corey: It's really neat to see, I guess, the sense of spirit and soul that arises from a smaller, more, shall we say, soulful company. No disparagement meant toward my friends at AWS and other places. It's just, there's something that you lose when you get to a certain point of scale. Like, I don't ever have to have a meeting internally and discuss things, like, “Well, does this thing that we're toying with doing violate antitrust law?” That is never been on my roadmap of things I have to even give the slightest crap about.Anil: Right, right? You know, “What does the investor relations person at a retirement fund think about the feature that we shipped?” Is not a question that we have to answer. There's this joy in also having community that sort of has come along with us, right? So, we talk a lot internally about, like, how do we make sure Glitch stays weird? And, you know, the community sort of supports that.Like, there's no reason logically that our logo should be the emoji of two fish. But that kind of stuff of just, like, it just is. We don't question it anymore. I think that we're very lucky. But also that we are part of an ecosystem. I also am very grateful where, like… yeah, that folks at Google use Glitch as part of their daily work when they're explaining a new feature in Chrome.Like, if you go to web.dev and their dev portal teaches devs how to code, all the embedded examples go to these Glitch apps that are running, showing running code is incredible. When we see the Stripe team building examples of, like, “Do you want to use this new payment API that we made? Well, we have a Glitch for you.” And literally every day, they ship one that sort of goes and says, “Well, if you just want to use this new Stripe feature, you just remix this thing and it's instantly running on Glitch.”I mean, those things are incredible. So like, I'm very grateful that the biggest companies and most influential companies in the industry have embraced it. So, I don't—yeah, I don't disparage them at all, but I think that ability to connect to the person who'd be like, “I just want to do payments. I've never heard of Stripe.”Corey: Oh yeah.Anil: And we have this every day. They come into Glitch, and they're just like, I just wanted to take credit cards. I didn't know there's a tool to do that.Corey: “I was going to build it myself,” and everyone shrieks, “No, no. Don't do that. My God.” Yeah. Use one of their competitors, fine,k but building it yourself is something a lunatic would do.Anil: Exactly. Right, right. And I think we forget that there's only so much attention people can pay, there's only so much knowledge they have.Corey: Everything we say is new to someone. That's why I always go back to assuming no one's ever heard of me, and explain the basics of what I do and how I do it, periodically. It's, no one has done all the mandatory reading. Who knew?Anil: And it's such a healthy exercise to, right, because I think we always have that kind of beginner's mindset about what Glitch is. And in fairness, I understand why. Like, there have been very experienced developers that have said, “Well, Glitch looks too colorful. It looks like a toy.” And that we made a very intentional choice at masking—like, we're doing the work under the hood.And you can drop down into a terminal and you can do—you can run whatever build script you want. You can do all that stuff on Glitch, but that's not what we put up front and I think that's this philosophy about the role of the technology versus the people in the ecosystem.Corey: I want to thank you for taking so much time out of your day to, I guess, explain what Glitch is and how you view it. If people want to learn more about it, about your opinions, et cetera. Where can they find you?Anil: Sure. glitch.com is easiest place, and hopefully that's a something you can go and a minute later, you'll have a new app that you built that you want to share. And, you know, we're pretty active on all social media, you know, Twitter especially with Glitch: @glitch. I'm on as @anildash.And one of the things I love is I get to talk to folks like you and learn from the community, and as often as not, that's where most of the inspiration comes from is just sort of being out in all the various channels, talking to people. It's wild to be 20-plus years into this and still never get tired of that.Corey: It's why I love this podcast. Every time I talk to someone, I learn something new. It's hard to remain too ignorant after you have enough people who've shared wisdom with you as long as you can retain it.Anil: That's right.Corey: Thank you so much for taking the time to speak with me.Anil: So, glad to be here.Corey: Anil Dash, CEO of Gletch—or Glitch as he insists on calling it. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment telling me how your small team at AWS is going to crush Glitch into the dirt just as soon as they find a name that's dumb enough for the service.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
About DanAfter earning his CPA in New York, Dan dedicated his early career to education, helping to build eight schools across two continents. Three of those schools make up the charter school network Coney Island Prep, a 160-person, $20mm+ organization where Dan served as both CFO and COO. He has served as CFO of many fast-growth start-ups, is a recurring guest lecturer at Harvard Graduate School of Education, and is an avid adventurer and musician. But most importantly, he's a dedicated husband and an enamored father who, at this point, knows the lyrics to each and every Raffi song ever created.Links:Duckbillgroup.com: https://duckbillgroup.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at Redis, the company behind the incredibly popular open source database that is not the bind DNS server. If you're tired of managing open source Redis on your own, or you're using one of the vanilla cloud caching services, these folks have you covered with the go to manage Redis service for global caching and primary database capabilities; Redis Enterprise. Set up a meeting with a Redis expert during re:Invent, and you'll not only learn how you can become a Redis hero, but also have a chance to win some fun and exciting prizes. To learn more and deploy not only a cache but a single operational data platform for one Redis experience, visit redis.com/hero. Thats r-e-d-i-s.com/hero. And my thanks to my friends at Redis for sponsoring my ridiculous non-sense. Corey: This episode is sponsored in part by Honeycomb. When production is running slow, it's hard to know where problems originate: is it your application code, users, or the underlying systems? I've got five bucks on DNS, personally. Why scroll through endless dashboards, while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter? Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other, which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at Honeycomb.io/screaminginthecloud. Observability, it's more than just hipster monitoring.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. A common myth that has sort of permeated the entire ecosystem is, when you associate a single person with a company, they're the only person is really there. It turns out that with AWS, Jeff Barr is writing an awful lot of blog posts, but I have it on good authority that there are at least three services he didn't personally create himself. Similarly here at The Duckbill Group, there are a lot of folks who aren't necessarily in the public eye as much as I am because they don't have the overriding personality flaws that I do. One of those people is my guest today. Dan Shapiro is our CFO, and I guess the closest thing you could consider to us having adult supervision. Dan, thanks for joining me.Dan: Thanks for having me, and I appreciate you considering me an adult, even though I don't always feel that way.Corey: I always assume there's someone else out there who knows what's going on and how life works, and one day they're going to bother to explain it to me because the alternative is that none of us know and we're making it up as we go along, and I'm not sure I can wrap my head around that fear.Dan: Yeah, my job is to allow you guys to have the vision, some wild ideas, try to put data to ideas, tell you if I think it's a good idea. I think, you know, I'm the balloon string to your guys' balloon is the way I think about it.Corey: It's funny, given that we fix the AWS bill and deal with customers, who are in many cases themselves working in finance, that for the first year or so that we were doing this as The Duckbill Group, and never back when I was independent did we really have anyone in a CFO position. What we were doing made sense to me from a very simplistic naive point of view. Okay, well, how is the company doing? Well, I have an app that tells me that. No, it's not QuickBooks, it's I'm going to pull up the banking app and see how much money is currently sitting in the company accounts.And that would inform things like can we hire new people, can we afford this piece of equipment, or embark on this project? And it was sort of Fisher-Price finance, from our perspective. And when you came in, you were very good at this in that you did not make us feel like the naive hayseeds we very clearly were. You were excellent at hiding your contempt, which is great. But before we dive into the specifics, let's ask the big question that I didn't know the answer to back when we first started working with you, which is, what does a CFO do?Dan: CFO does a lot of tactical things, but ultimately, I think that they have two main 30,000-foot view functions. One is to safeguard the assets of the company, and two is to ensure that those assets are employed in the best way possible for the best outcomes that the company is after. And that doesn't always necessarily have to be financial; it could be operational successes. But whatever the goals of the company are, the CFO's role is to utilize the assets to help approximate those goals as best as you can, get the most out of your resources. So, I think that, you know, you play a little bit of defense in trying to make sure that you're protected and you play a little bit of offense in trying to make sure that when you put your chips on the table, that they're in the right place.Corey: So, please take this in the spirit of which it's intended, but if I'm starting out my career today, I can attend a boot camp, learn how the ins-and-outs of software programming work, get a job somewhere, and if I manage my career right, in two or three years I'll get a job somewhere as a senior engineer. So, from that perspective, are you more or less an accountant with title inflation? What's going on? What is the difference between finance and accounting?Dan: Yeah, so to define those two words, I think of the delineator being time, right? So, today backwards is accounting. It's a historical record of everything that has happened, well categorized. And I think of finance as today forward. It is the strategy and planning and potentially analysis of what you think is going to happen in the future.So, those two buckets are delineated by time in my mind. Am I an accountant? Yes. Do I think that the best financial people have an accounting background? I do. I think accounting is the alphabet of finance and I think it's hard to really fully understand or be effective without, you know, at least some baseline accounting information. So yeah, I think accounting is super important. It's a codebase to an engineer, except there's really only one code.Corey: I will say that once you started working with us, it enabled me to understand things in a way that I hadn't before. And on some level, I feel… a little embarrassed, I'm in my mid 30s, here—which annoys the hell out of my wife because I'm 39—but I've gotten this far in my career without understanding a lot of the basic literacy of corporate finance. Now, let's be clear, I'm very good at handling personal finance aspects to my life. I can quote chapter and verse in some cases, from ERISA requirements around 401(k)s and how much I'm allowed to put in in a given year. And that's great, but business finance looks very different than personal finance in a few key ways. And I'm curious as to what your impression is of those key differences because I have thoughts, but I don't generally invite experts in areas onto this show and then explain their field to them.Dan: [laugh]. I will go into that but I am curious what you think. You know, or what you perceive in your experience in working with me, what you've seen—maybe one or two differences that you've seen between personal finance and corporate finance. I certainly feel like there's differences, but I actually don't feel like there's a tremendous differences, I just think it's much greater scale with a lot more people involved. But I'm curious what your experience has been, and then I can kind of jump off of that.Corey: Sure. From my perspective, it is—and this is probably heresy, but I tend to view finance in many ways as being more psychological than it is mathematical. And if I were to pick a random person off the street, and give them a choice of you need to come up with a thousand bucks: you can either make another $1,000 or you can save another $1,000—and let's be clear, I'm talking about someone who is in a technical-style career track; I understand the margins, this becomes a very different thing in either direction and I want to be sensitive to that—but if I ask most people, their answer is almost universally going to be to save the money because if you look at folks who are in a salary job, if they want to make more money, they need to either come up with a side project and start moonlighting, they need to petition their boss for a raise, they need to do a few other things here and there and okay, it becomes a pain. And well, I haven't updated my resume in years, I'm not great at interviewing for jobs, I don't really want to leave and upset the applecart. Whereas saving a thousand bucks when you're making six figures a year is not necessarily that hard. Eat out less, cancel Netflix, et cetera, et cetera, and you can get there by saving.Companies philosophically are the exact opposite. Because there's a theoretical upper bound of one hundred percent of a company's AWS bill that I can cut, either by moving them to another provider—which is cheating—or flying to Seattle and taking hostages—which is not particularly something we'd like to do, and it doesn't generally work more than once. And that's fine, but they can earn a multiple of that by launching the right feature or product to the right market at the right time, faster. That's always going to be more compelling for a company because they're after growth, not protecting the baseline that they have, in most cases. When that shifts, they tend to be companies in decline.Dan: Yeah, that's a great point. And I think to add onto that, when you're running a company, almost every company is going to have something like 60 to 70% of their expenses tied up in their people. So, cutting discretionary spending at a corporate level is not always going to yield the impact that you might need it to. And if you actually need to cut expenses, you're talking about very serious decisions about reducing your workforce, which happens in big steps, right? You can't just find, you know, 5k here, 10k there; you're talking about, you know, reducing your org chart, which is a very serious decision that a lot of companies take very seriously, which is great.Versus there's a lot of avenues to increasing revenue, you know, new product streams, growing your team, investing in your team, raising prices, follow-on sales with these existing customers. You know, there's just a lot more opportunity to generate revenue because companies, by definition, have a lot more opportunities to create revenue than just, you know, like you said, somebody who has a salary job.Corey: One of the things that really woke me up to what our customers are going through is I take a look at the finances of The Duckbill Group—as pointed out and categorized and [aligned 00:09:09] by you, which first, thank you, it's extremely helpful, and two, it helps me contextualize things. You raised a flag on things being out of bounds, where they had been historically. At one point, our AWS bill was a little over $2,000 a month, and your question was, “What's up with this?” It is not the sort of thing that was going to make or break the company; our payroll is six figures a month and compared to that the AWS bill is irrelevant.But given what we do, and given that it's always a good idea to be good financial stewards of the money that has been entrusted to us, “Great, let's take a look at that.” And it was dropped down to 700, 800 bucks. I think it [crested 00:09:47] at $950 last month, as of the time of this recording because I was doing some fun experiments. And sure it's annoying in that I want to keep it as low as possible just given the nature of what we do, but from a business perspective, it does not fundamentally matter. Now, that is not the case for most of our clients, it matters; it's a large expense, but payroll is still bigger.In many cases, depending on the company, real estate is bigger. And Netflix, one of the larger AWS customers, has publicly stated that their biggest expense is content. Yeah, they've built a bunch of studios, they have to get rights to all the content that they stream, they pay people through the nose, and their AWS bill is reportedly massive—it would have to be given what they do—but it's never the number one driving focus. And, on some level, it feels like a company deals with two classes of problem. There's the side that we're on of cost control, risk mitigation, et cetera—insurance hangs out here, too—and the other is speeding up time to market or growth and expansion. Our class of problem is a good diligence thing, but it isn't usually ‘summon the board in the middle of the night because of an opportunity' territory. If I look at those as the two great problems, it is more lucrative as a business to be targeting the former.Dan: Yeah. I mean, so just to go back to that AWS example for a second, right, it's contradictory, right, because on the one hand, are you really going to win the day by shaving, you know, $500 off your AWS bill a month if you're a $3 million company? You know, is that going to move the needle? Not necessarily.But I believe in hygiene and habits, and I believe as you're a growing company, that it's a lot harder to put in good financial process and good financial hygiene, the bigger you get. And so if you start doing these things early, you know, if you have a quarterly review of your subscriptions, your SaaS products, you have some kind of budget versus actual process in place where you have—even if it's wrong, right? I mean, you just take a stab at what you think, you track your actuals, and at least now you have some data to rally around from a financial perspective, as opposed to saying, “Oh, look, we spent X on Y. That's interesting.” Or, “Does that feel right? Or”—And so you have a baseline and you have a measuring stick, and then you have a process in place for figuring out what happened, and then how to better guess in the future. And so yeah, I think that hygiene is important and I think the hard part—and I think it was exhibited by you guys early on—is when you're starting a company, this is the last thing that you want to focus on, or even think you need to focus on because it's not on fire, right? Finance is never on fire until it's absolutely on fire, and it's going to kill you. And I think a lot of founders sweep finance and accounting to the back of the closet because a client is upset, or an employee quit, or their code broke, and those things are on fire today, and if they don't get fixed, the company can't move forward.And so finance, it doesn't matter, doesn't matter, doesn't matter, doesn't matter; it kills your company. So, I think it's not that the founders don't know about it, aren't smart enough for it, don't care about it. It's just that it's not on fire, and when you're starting a company, all you can do is pay attention to the things that are.Corey: It's easy to look back and beat myself up for my lack of understanding or lack of focus on things. The similarly I talked to technical people all the time where the first DevOps hire into an environment. It's been application engineers or developers building the environment so far, and it's easy to look at it in a condescending way of, “Oh, our entire field knows not to build things this way. What's wrong with you fools?” Well, it worked well enough to get to a point where they could afford to hire you, so perhaps show some respect when you're in an environment like that.This is something that most business folk, like I don't know, a CFO intrinsically understands, but many engineers still don't seem to have fully wrap their heads around just because it's easy to over-index on the area that you're focusing in. You almost certainly view companies, start to finish, through a lens of finance. A lot of engineering folks I spend time with—and used to be one of, myself—view it through a lens of well, what's their stack look like? What's their technical debt? How are they actually architected?Which is interesting, but usually not the indicator of whether a company will succeed or fail. There are other broader focuses that are important to look at, and being able to view our own company through a lens of something other than dealing with just the technology or just the sales aspect of it, or, “All right, time for me to go shitposting again because that's our substitute for marketing.” Instead, we're focusing on what the larger picture is through a finance lens. It introduces a level of rigor that I hadn't expected, though, clearly, we do still put our own stamp on it. I suspect we are probably the only company you have ever worked with that has an explicit line item in the budget labeled ‘Spite' for example, from which we make our ridiculous parody videos and other assorted nonsense, for those who are unfamiliar with the Spite Budget.Dan: That was a new one for me. I've seen, I think, every other chart of account line item before and Duckbill Group was the first one that I had to type in ‘Spite Budget' for. I didn't even really understand what it meant, and then as I, you know, got to know you a little bit better, I knew exactly what it meant. And it is—Corey: Yeah, this is what passes humor with his set.Dan: [laugh].Corey: Got it. Okay, I'll smile, nod, and continue to keep the finances in order.Dan: Yeah. So, when you leave, I just cross it out and I write marketing. But [laugh] it is what makes you you and what makes this company successful. But in all seriousness, it's an outstanding financial investment because our business is—like every business—is driven by eyeballs. And whether you're a media company or you're any other company, you need people to know about you.You need people to want to believe that your services are valuable, and want to engage in your services. And the Spite Budget brings eyeballs. And the other thing is, I think it's always wrapped up in farce, but there's always an underlying truth to it which is why people find it compelling. I think if you were out there actually, slinging shit to us, you know, [laugh] you're parlance, I think you wouldn't get 100 Twitter followers. But I think because the undercurrent is truth, you don't give yourself credit for this but there's an immense amount of knowledge behind the truth that people find it compelling. So yeah, from a serious financial perspective, I think it's one of the best investments that we make. [laugh].Corey: It's definitely a lot of fun. And it always bothered me when I would walk around re:Invent or travel for client trips and whatnot to see billboard ads in airports because I've priced out what those things cost, and for those who are wondering, it's not a small number. And okay, so you're going to go to all of the expense of buying out ads in multiple airports doing a country wide brand saturation campaign, and with all of that space, and all of those millions of dollars you're spending on this to get your message in front of folks, you fill it with something that is so anodyne, something that is so… I guess, droll, that no one notices or cares. You wind up getting all of these eyeballs and then have nothing interesting to say. And to me, that's the cardinal sin.I can build an audience, and the way I built it is by having something interesting to say. But take a look at any brand awareness billboard for a large consultancy. I mean, Accenture had one years ago in airports that I still haven't stopped making fun of them for, even more so since they blocked me on Twitter. And it said, “The new isn't on its way. It's here now. New, applied now.” So yeah, I guess they're bringing the new and it's… okay, they spent how many millions of dollars on that campaign and then wound up effectively building the tagline and the phrasing just by, I don't know, having some analyst in some junior role bang their head off a keyboard a few times? I don't get it. I just don't get it.Dan: Yeah, without being a marketing expert, I think that's the product of risk tolerance being a directly inverse relationship to the height of an org chart. I think the higher you grow in your decision-making capability and potency, the more responsibility you have on your shoulders, the less willing you are to do anything that's interesting, fun, risky, and that's why we have a lot of the marketing that we have today. We're lucky to be a small company, we're lucky to be a small company that has creative founders. I think a lot of founders for their marketing go, they use a lot of external folks, and you know, they—sometimes it works, but a lot of times they lose the actual, like, heart and soul of the company because they just aren't in it, they don't understand it. And I think it's fun, a lot of the stuff that, you know, we get to do.But I think we're fortunate that we are in a unique spot in the sense that—you know, we talk about this a lot—we're a company that has a services arm and we're a company that has a media arm. And where many companies in services have to think about marketing and sales in a very straight up and down way, we get to play in our media space, which is a revenue-generating arm of our business, in a lot of experimental ways that other companies are spending thousands, millions of dollars on marketing expenses, we get to do it and make money doing it, via media. And it's really this incredible, bifurcated business where one serves the other and vice versa. And, you know, it's fascinating.Corey: I still don't pretend to understand how we got to the place that we did. When you look back, it's easy to see a sense of plodding inevitability, where, “Oh, yeah. You did this, that led to that, and it led to this, and here you are now.” But at the time you're making the decisions, you are throwing darts blindfolded. Professional advice for those in bars, don't do that. They do not find it nearly as amusing as it sounds.Dan: I think that's how it feels, but I don't actually believe that story that you like to tell. You and Mike are—[laugh] you enjoy the self-deprecation but you're very bright guys and I think you are always fiscally responsible. You just didn't have the language that I have to show how you're fiscally responsible. And I think you really were conservative founders in the fact that you made very short-term decisions and always made conservative short-term decisions, and that puts you in a good place. I think what I have brought to the table is an ability to look a little bit further out and think about, you know, okay, it's not just next month, right? It's not just two months from now. What are we building here? What are the long-term goals, and what are the intermediary goals that will be true if we're on the right path?And that's some planning, that's using historicals, that's using some good analysis tools to try and get there, but it's also a matter of time. When you're a founder of a company, you can't spend all of your time on finance and accounting. It's just the reality. You have 8 million things to do, and so you do exactly what you guys did, which is you look at your bank account, you try and make a decision in a vacuum. But you don't have time to really grind over the details, or the strategy of the next 6, 12, 18 months because you've got people to hire, and you've got clients to appease, and you've got work to do that will generate the revenue.And so there's a whole world of fractional CFOs, some who are good, some are not good. There's a world of bookkeepers out there that are competent. And I think, even though it's not a great use of cash, or revenue-generating use of cash, which I think a lot of startups, you know, are reticent to go down that path, I think having good hygiene and good strategy on your financial front early on is necessary for the future planning of a lot of these startups. And also probably peace of mind, right? I mean, I'm not sure—Corey: Oh, I sleep way better now than I did before.Dan: [laugh]. Yeah, I hope so. I mean, I think just the not knowing creates such an undertone of stress that, you know, may or may not be recognized by founders. And I think being able to look at a document and say, “Okay, this makes sense to me, I know what the future probably holds.” And I hope it allows you to think about other things than money.Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of "Hello, World" demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And—let me be clear here—it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking load, balancing and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free, no asterisk. Start now. Visit snark.cloud/oci-free that's snark.cloud/oci-free.Corey: One challenge we had was that a lot of the advice for first-time founders—since there's a lot of those in our space—is not applicable to us. The way that Mike and I built this place, we provided the initial investment personally; we're the only investors in this place, we don't have outside funding, we don't have investors, and we've given no equity away, so it is all us. And the way that most companies in tech tend to work is I would go and debase myself in front of a bunch of investors, and some VC would absolutely bite on my Twitter for Pets idea and give me $50 million to go and build the prototype.And at that point, I'm not making money. I have $50 million in the bank that I am burning through every month as I hire, as I build the MVP, et cetera, et cetera, and there's a ticking clock–it's called a runway in our space—and if we don't wind up hitting a certain milestone of being able to raise more money by the time that we've crossed a certain point, it's time to begin an orderly shutdown of the company. And that's a ticking clock hanging over the head of many founders. In our case, I was looking at it like that originally, but we are profitable, we are actively closing deals, and one of the things you taught me, for example, was when we have accounts receivable, money that is owed to us that has not yet been paid, we can count that and use that as in many ways an asset because it is. It also helps the fact that we are in a market where businesses do not generally decline to pay us money that they owe us.This is very much an understood thing in business, but my question was always, “Well, yeah, but what if they don't pay? What does that mean for us?” And that's really been a non-issue, which at first I was really grateful for and thought, “Wow, we have great customers.” It turns out that this is expected. This is like running a store and being super ecstatic because most of the people in your store aren't shoplifting.It's, yes, that is the baseline expectation for people doing business in the modern era. That was an eye opener. But it also kept me up at night because it was, “Oh, if suddenly this money in the bank is all that we're going to get in, then we only have enough runway to go two, three, four months and then we have to shut the company down.” Yeah, but we're profitable every month, so what's the concern here? It doesn't work that way.Dan: Right. We look at two key metrics as a company every single week, right? We look at a metric called months of cash.Corey: Which is pretty self-descriptive. It's in the title.Dan: Yeah, [laugh] just, you take your bank balance and you divide it by your, you know, average monthly burn, you know, total expenses out each month. And that will give you some number. You know, we really like that number to be at least two, closer to three, but I think something like having, like, six months of cash—now this is for a company that has not raised a bunch of money, right? So, if you've raised $5 million, your months of cash is going to be well more than that because you're investing in your—Corey: And the goal should be to lower that months of cash because it's designed to be used to hire and grow, not sit there, and you should not be turning a profit on that interest; you should be spending through it at a reasonable clip.Dan: Right. And for companies who have not raised money, right, even if you have a month's of cash, you know, five, six, that's probably not right either, right? I mean, there's probably opportunities for investment where you want to get your chips on the table for growth, right? Because you don't always have to be after hypergrowth. But typically, if a company's not growing, it's declining, and that's not a great thing, right? So, some amount of growth is always important for a healthy company.So, months of cash is one metric that we look at every week. And the other is what I call an adjusted quick ratio. But essentially, it's taking current assets over your current liabilities. Now, many startups are going to be debt free, short-term debt free, and so what we do is we try and talk about cash plus accounts receivable—so invoices that are out that have not been paid—and that gives you your numerator, over any outflows that you should experience over the next 30 or so days, right, we think about that as, like, our current liabilities. Because there's no real debt.In larger corporate finance, you have big, big balance sheets, quick ratios are more formulaic corporate formula, but in this case, we look at cash plus accounts receivable, over 30 days of liabilities. And that gives us a number that we're tracking constantly. And we have our own benchmarks for internally for what that number is, but that's a really great tracking of liquidity; that's more than just what's the cash in the bank, right? You're looking at your cash, you're looking at your receivables, and you're looking at your upcoming payments, you know, whether that's payroll or big vendor payments or any other, you know, non-recurring expenses that you know are coming down the pike.Corey: Yeah, a lot of things can impact that number. And that means, oh, that number is out of kilter. It's time to dig a little bit into why, but it's not itself a diagnostic, it's just an indicator that gives a snapshot of overall financial health.Dan: That's right. There are also ratios that you can track on a weekly basis and not just wait month-over-month because you can actually start to see trend lines up and down and start to ask questions about, “Hey, what happened this week?” “Oh, we sent out a big invoice, you know, we just haven't been paid on it. That's why we saw our AQR go up.” Or, “Hey, we just took in a big invoice for redoing the website. We owe $50,000 to x vendor and that's why the denominator of that equation went up. And so our AQR went down a little bit this week, but we expect it to climb back up in the coming weeks.”And so it's a really good way to track liquidity. On a longer-term, we're talking about things like margin analysis, right? Gross margins is an important thing we talk about. You know, revenue, minus the cost of goods to deliver that revenue, want to make sure that we're delivering products with efficiency. And, you know, we talk about net margin or EBITDA, or, you know, however, you want to describe the bottom line, and that's obviously your profitability.So, those are sort of the things we rally around internally. We try and look at them at least weekly, or monthly, depending on the metric. And this just goes back to hygiene and habits. You don't have to do a tremendous amount of work here. And you also—I think, people can get wrapped up in esoteric formulas that they've read in books, right, but I think if you're looking at cash, you're looking at cash and receivables over expenses, you're looking at your margins, and you're looking at your bottom line, those four metrics tracked well, you know, weekly or monthly over time, should really protect you, and should also give you great insights about your business.Corey: This is another example of viewing personal and company finances through a different lens. If I were to come home and tell my spouse that I had just dropped $50,000 on a website for example, the conversation would not be pleasant immediately afterwards. But it's not personal money. Conversely, an awful lot of business owners that I've heard stories about get into trouble by treating the company as their personal piggy bank, which Mike and I are very clear never to do. If you're listening to this from tax authority, I want to emphasize, we keep our noses remarkably clean.And again, it comes down to one of those, I don't want to lose sleep at night over things. That's why you're here, Dan. I don't want to lose sleep over the idea that we're going to run out of money, or that I'm going to get audited and my great fraud will be discovered. It's no, I don't want to get audited because it's a pain in the neck, and I have to wind up providing a whole bunch of receipts and whatnot, but everything's legitimate. That's the type of fear and paperwork thing that I just want to be able to avoid, by and large.Dan: Yeah, we do keep clean books, and there's probably things that we could be expensing that we're not, right? More than the tax gray area that exists there is the difficulty with partners and equity—and I don't mean equity on the balance sheet; I mean, like, fairness amongst partners, right? So, if one partner is going out more often than the other for dinners, is that really fair for that person to get their meals paid for more than the partner? Vice versa, if one person lives in a city and the other person doesn't and their car runs through the business. You know, how do you deal with those differences with multiple owners of a business? And I think those complexities are sometimes more difficult to deal with in the tax gray area of what is deductible and what is not?Corey: Oh, yeah. That's why I've always been such a big fan of making sure that when you have a business partner that your values are aligned. Mike and I are incredibly dissimilar in a bunch of different ways. He loves spreadsheets, I love shitposting on Twitter. But when it comes to values in how we approach these things that was laid out at the very beginning in our partnership agreement.And it's never been something that we've had cause to even visit, like, “Well, let's see what the partnership agreement says.” Just because it makes sense. It's, yeah, Mike doesn't spend tens of thousands of dollars a year on travel—in non-pandemic years—just because he's not constantly out there doing the things that I have been doing, historically. Now, post-pandemic that might change it, if he winds up traveling a lot and I'm sitting at home, I'm not sitting there upset because he gets to expense dinners out. It doesn't work that way. Whenever you start seeing that type of breakdown that feels like it's a proxy for something that's deeper.Dan: Yeah, I would agree with that. I think also just not like a marriage, you know, it comes down to communication and expectations. I mean, like any management in company, right? I mean, you have to be clear about what is expected of your partner. Ideally, you're measuring those things, and you're making sure that everybody's in line with those expectations, but yeah, I would say you and Mike have always been aligned in that sense, and I think you're right, the instance—or examples where it goes south, it's not because someone spent $600 more than the other, it's because there's a lot more going on there.Corey: Yeah, it's the proxy for things. So, at some point it's, “Okay, why do you have a $4 million yacht that just parked in your driveway? And yeah, what's the deal here?” One last area I want to cover because this is probably relevant to folks who I imagine most of our listeners are, who are employees elsewhere. I always was extremely bothered by the fact that I had remarkably little financial wiggle room when it came to expensing things.Like, “Let me get this straight. I have root in production, but you're going to question me over a $15 expense?” That always sat very strangely. And I carry that with me to the point where even now at the time of this recording, we're going through one of our periodic exercises that you put us through of, yeah, here's a list of all the recurring expenses on your credit card. Is this something that we still need? And how do I categorize it if so? If not, let's cancel it.And it's weird because instinctively, I hear that, even now, as you saying, what's up with this $9.99 a month thing? And I'm sitting here going, “Wait a minute.” Like, I'm trying to justify, like, “Is that really worth $10 a month to me? Should I—wait a minute, I don't work for you.”Dan: Right. [laugh].Corey: It was a bit of a different moment here. Like, I felt like I'm being called to the carpet by my boss, but that is absolutely not what's going on. So, my question for you, as someone who has a storied career in finance, is that what's being asked in most companies by management when they question expenses? Is that about, “Help me understand what this is,” or is it in fact what I'm hearing, a, “Justify why you think a $10 monthly expense is worthwhile?”Dan: I think it really depends. I mean, in my case, in our case, I am genuinely trying to understand how to categorize most things so that when I do my reporting, I can tell you where we spent our money. So, you know, if I see a charge that I don't know what it is and I ask you for clarity on it, it is a hundred percent so that I understand is this COGS? Was this part of delivering our revenue? Is this, you know, a sales and marketing expense that at the end of the year, I could say, “Hey, we spent x percent on sales and marketing for y revenue,” and I want that to be an accurate number.If you're talking about big corporate bureaucracy and they have expense policies and a lot of rigorous rules that were derived from the head of HR who doesn't know the 500 people that this rule is going to impact, I think there's probably a different motivation for those questions. And I think it's tough; it's not to say that you shouldn't have policies, you need to have policies, but you know, the bigger you get, the harder it is to have the right policies for the right people and you end up making blanket decisions to try and get to an average lau that nobody's probably happy with, instead of empowering your people and trusting your people, that they're going to spend their money on things that are good for the company. At Duckbill, I know, it's not even a question. Everybody here has a corporate card, and I don't think I've once seen you question somebody about an expense that they had. The only questions they get are from me in terms of how to use it for accounting purpose, but the underlying current there is we hired these people; we trust these people; they're our employees and we're all swimming in the same direction, so if they spent money on something, I would assume it's because it's good for the company.And I think that goes a long way. I would always prefer to have better tracking and reporting metrics to spot the bad apples than to have a policy that turns the good apples, the 95% of good apples into sour apples. Not to have a terrible analogy on this recording. But I [laugh] would much rather convey to my employees that I trust them and then do a little bit of extra work on the back end to ask questions about, you know, the expenses I think are a little funny, versus writing a policy that says, “Here's x. Here's what you can spend on y.” And now everyone is dissatisfied. Someone was telling me just because someone wore shorts to the office, don't write a policy, “No shorts in the office.” Just talk to that person and say, “Hey, pants might be a better choice.”Corey: Right. You should not need a list of policies that are organically built every time someone does something they shouldn't. And at some level, it's one of those ideas where collective punishment never works. I wound up getting an email from my boss once to the entire team of, “We have to start at nine or there's going to be problems.” And I'm sweating bullets because I came in at 9:03, a couple of days this week.Meanwhile, the person next to me has slowly started drifting from coming in at 10:45 to 11:30. And it's one of those I think I'm going to get fired. No, no, no, it's really you have one particular person and you're just being chickenshit as far as approaching them and telling them that there's an issue.Dan: That's right. Yep. Totally agree.Corey: Dan, thank you so much for taking the time to speak with me today. If people want to learn more, where can they find you?Dan: I don't have a huge footprint on the interwebs, but I'm always here at Duckbill, you know, serving the company, and if anybody has specific Duckbill questions, they can always reach out and I'm happy to converse. But I really appreciate you having me, and happy to talk Duckbill anytime.Corey: No, it's appreciated. Dan Shapiro, CFO at The Duckbill Group. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment talking about how as an accountant, you are annoyed by this episode because you will never be depreciated in your own lifetime.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
Ep#28 Daily Tech Show: Unofficial Mask Challenge & re:invent 2021 with AWS Jeff Barr What if I told you that there is an Unofficial Challenge about to happen for AWS re:invent this year? Or wouldn't you like to know “What's New with AWS What's New” and how come it isn't ON-AIR? Are you looking for some inside information on how to interview with AWS? Well stick around because we're unleashing an action packed show with AWS Chief Evangelist Jeff Barr and we aren't stopping there…. Welcome Folks to the Daily Tech show. I'm your host Jon Myer and boy do we have an exciting interview coming up. We are talking AWS re:invent, an unofficial mask challenge that you can only find the details here. J oin me as we sit down with AWS Chief Evangelist Jeff Barr who's going to give us some not so secretive information around re:invent, live streaming, and this unofficial mask challenge by Jeff. Also, Jeff's going to give us some tips on how to interview at AWS that helped numerous people through the process.
Ep#28 Daily Tech Show: Unofficial Mask Challenge & re:invent 2021 with AWS Jeff Barr What if I told you that there is an Unofficial Challenge about to happen for AWS re:invent this year? Or wouldn't you like to know “What's New with AWS What's New” and how come it isn't ON-AIR? Are you looking for some inside information on how to interview with AWS? Well stick around because we're unleashing an action packed show with AWS Chief Evangelist Jeff Barr and we aren't stopping there…. Welcome Folks to the Daily Tech show. I'm your host Jon Myer and boy do we have an exciting interview coming up. We are talking AWS re:invent, an unofficial mask challenge that you can only find the details here. J oin me as we sit down with AWS Chief Evangelist Jeff Barr who's going to give us some not so secretive information around re:invent, live streaming, and this unofficial mask challenge by Jeff. Also, Jeff's going to give us some tips on how to interview at AWS that helped numerous people through the process.
In this episode Dave and Emily chat with Jeff Barr, VP of Evangelism at AWS. Jeff has been with Amazon since 2002 and was the first person in a full-time developer advocate role. In this follow-up conversation from last week's episode, Jeff covers the culture of innovation behind AWS, tips for managing time, and how to have productive interactions with other developer teams. Jeff on Twitter: https://twitter.com/jeffbarr Jeff on LinkedIn: https://www.linkedin.com/in/jeffbarr/ Jeff Barr FAQ: http://jeff-barr.com/jeff-barr-faq/ AWS Blog: https://aws.amazon.com/blogs AWS Community on Reddit: https://www.reddit.com/r/aws/ ----------- Connect with Us on Twitter: Emily on Twitter: https://twitter.com/editingemily Dave on Twitter: https://twitter.com/thedavedev Subscribe: Amazon Music: https://music.amazon.com/podcasts/f8bf7630-2521-4b40-be90-c46a9222c159/aws-developers-podcast Apple Podcasts: https://podcasts.apple.com/us/podcast/aws-developers-podcast/id1574162669 Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zb3VuZGNsb3VkLmNvbS91c2Vycy9zb3VuZGNsb3VkOnVzZXJzOjk5NDM2MzU0OS9zb3VuZHMucnNz Spotify: https://open.spotify.com/show/7rQjgnBvuyr18K03tnEHBI TuneIn: https://tunein.com/podcasts/Technology-Podcasts/AWS-Developers-Podcast-p1461814/ RSS Feed: https://feeds.soundcloud.com/users/soundcloud:users:994363549/sounds.rss
In this episode Dave and Emily chat with Jeff Barr, VP of Evangelism at Amazon Web Services. Jeff has been with Amazon since 2002, and was the first person in a full-time developer advocate role. Jeff covers what the early AWS developer community looked like, early developer relations at AWS, the importance of community, and how developers have shaped the roadmap for many AWS services over time. If you enjoy tech industry history this episode is for you! Jeff on Twitter: https://twitter.com/jeffbarr Jeff on LinkedIn: https://www.linkedin.com/in/jeffbarr/ Jeff Barr FAQ: http://jeff-barr.com/jeff-barr-faq/ AWS Blog: https://aws.amazon.com/blogs AWS Community on Reddit: https://www.reddit.com/r/aws/ ----------- Connect with Us on Twitter: Emily on Twitter: https://twitter.com/editingemily Dave on Twitter: https://twitter.com/thedavedev Subscribe: Amazon Music: https://music.amazon.com/podcasts/f8bf7630-2521-4b40-be90-c46a9222c159/aws-developers-podcast Apple Podcasts: https://podcasts.apple.com/us/podcast/aws-developers-podcast/id1574162669 Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zb3VuZGNsb3VkLmNvbS91c2Vycy9zb3VuZGNsb3VkOnVzZXJzOjk5NDM2MzU0OS9zb3VuZHMucnNz Spotify: https://open.spotify.com/show/7rQjgnBvuyr18K03tnEHBI TuneIn: https://tunein.com/podcasts/Technology-Podcasts/AWS-Developers-Podcast-p1461814/ RSS Feed: https://feeds.soundcloud.com/users/soundcloud:users:994363549/sounds.rss
About NatalieNatalie is the Director of Marketing at the Duckbill Group. Her background includes marketing roles in the localization and SaaS industries. In her free time, she teaches yoga, creates beadwork, and tries to keep up with her toddler. All of which impacts how she approaches growth and storytelling. Natalie resides in Missoula, Montana with her husband, daughter, and two wild corgisLinks:Twitter: https://twitter.com/natveiswilliams TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part my Cribl Logstream. Cirbl Logstream is an observability pipeline that lets you collect, reduce, transform, and route machine data from anywhere, to anywhere. Simple right? As a nice bonus it not only helps you improve visibility into what the hell is going on, but also helps you save money almost by accident. Kind of like not putting a whole bunch of vowels and other letters that would be easier to spell in a company name. To learn more visit: cribl.ioCorey: And now for something completely different!Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Periodically, it seems that I've misunderstood the fundamental concept of marketing and interpret it through a lens of aggressively shitposting on Twitter and other places. I have since been informed that what I do is less about marketing and more about creative stunts in public, which are apparently close, but not exactly the same thing. This led to a natural evolution of the Duckbill Group's understanding of what marketing is, and effectively culminated in our hiring, earlier this year, of Natalie Williams, who joins me today to tell me what a Director of Snarketing might actually do that differs from my ridiculous nonsense. Natalie, thanks for joining me.Natalie: Thanks, Corey. It's great to be here.Corey: At a high level, something that is one of the most misunderstood concepts across the board is what marketing even is. So, before we proceed down the barrel of inevitable, ridiculous commentary I'm about to levy at you, what is marketing?Natalie: Marketing is a way to attract the audience that you're looking for and to frame your services, your content, whatever you're selling, to your audience in a way that makes sense to them. And I think that another piece of it that's important is, everybody has a pain point; you really have to be able to find the emotion behind what you're selling in order to attract your audiences.Corey: So, fundamentally an authenticity story more than anything else.Natalie: Yeah, it's finding that—yeah, the authenticity in what you're selling, and meeting your audience with their pain point.Corey: So, many times, it seems like the next follow-up question for most companies would be, “Great. So, what emotion is it exactly where people reflexively reach for their wallet and hand all the cash in it to our company?” It tries to be combined with aspects of sales; it tries to, on some level, wind up doing the entire job, in some cases of not even having a decent offering in the first place, but if the marketing story is strong enough, it'll sell. Is that overly cynical?Natalie: I don't think so. I think that marketing, it's challenging in this time, we have so many options, so many choices there, our attention spans are so short. And so I don't think it's cynical because there's a lot of noise to cut through, and I think what's important is to think of your audience as—or what you're selling to your audience in a way that, how can I make their lives easier? I think that's what's going to, like you said, get people to pull the money out of their pocket and give it to you. What can you do to make their life easier and how can you show them that what you're selling is going to make their life easier?Corey: There's a recurring trope that engineers, developers, whatever we're calling ourselves this week—anything except DevOps is fine—that we don't like marketing because no one likes being marketed to et cetera, et cetera. And I feel like that, in many cases, is because most marketing is terrible at its job. It comes across as smarmy: if I were to talk to people in person the way that marketing talks to people, I'd get punched in the mouth a lot. And I feel that is not an accurate view. It's almost like looking at salespeople through the lens of the worst experience you've ever had buying a used car. And I feel like by judging an entire field by some of its worst examples, people are prone to prematurely dismiss a very challenging field.Natalie: Absolutely, I think that it's very easy to pick out that dishonesty, like you said, the slimy marketing sales tactic that just feels, it feels like it's too much. I think people are very, very good at being able to see that. It's like the spam that you get in your email or your LinkedIn direct messages. It's just this constant barrage of tactics to try and tell you what you need without actually getting to know what you need, what you're looking for, and how it can help you. So, I think there are a lot of those tactics that really give marketing and sales I think, too, a bad name.An easy way to cut through that is just to be human about what you're doing. Think of your audience as human beings and not just a target or a persona that isn't a real person. And so I think, like you said earlier, the authenticity piece of it; it's not difficult to… well, I don't think it's difficult to be human. I think it's easier to take the emotion out of it and just try and put a sales pitch or a marketing pitch together that hits on all the points of the services you provide, and, you know, “I'm so great, and this is what we do,” without being able to talk to the people that you're marketing to as the humans that they are.Corey: It feels almost like I became a marketing person of sorts without ever intending to. When I started this company as an independent consultant, I was finding my initial source of clients to my personal network, as most small independent consultants do. And one thing that almost came by accidentally was that newsletter, Last Week in AWS, that took on an additional series of—it gets a different level of meaning to the ecosystem, and it turned out, sort of, growing like a weed. At which point, great, now it turns out that is marketing, although I didn't realize it at the time. And at least from my perspective, I didn't consider it marketing, which meant that I built it the way that I would want to receive things because, as it turned out, I was a relatively close match to the people that I was going to be emailing every week.And as a result, I didn't do a bunch of scammy nonsense that would alienate people; there's never any tracking put into it in the form of, “Oh, if you click on a link, that implies that you're going to be interested in what I'm selling. We're now going to fire off drip campaign number 17.” We stepped away from a lot of that because I've been on the receiving end of it, and it always rings hollow and strange. When we were interviewing to fill your role, we made it a point very early in the interview process to make clear that, yeah, this is not going to be one of those scenarios where you walk in and effectively get to instrument everything with all of the latest marketing technology and the rest. Okay, yeah, we have a list now of almost 27,000 subscribers.We don't mine that for leads. Now, should we? Maybe in an idealized sense, but it turns out that the reputational management of people trusting us not to do skeezy things far outweighs any temporary benefit we get from doing things like that. Now, that wound up driving an awful lot of people away, which is why we mentioned this in the early stages; it didn't drive you away. You decided to say yes; you actually showed up on Monday for your first day, and then continued to show up every day since. What was it about, I guess, that statement that would drive some folks that we spoke to away, but it wasn't a deal-breaker for you?Natalie: I remember clearly that part of the interview, and I remember it feeling like a bit of a breath of fresh air. I think that when you get into all the tech, all the marketing tools, there is that trade-off of losing a little bit of that human touch with your audience where all of a sudden they're not humans, they turn into data points, they turn into the demographics about themselves. And all of that stuff is important and has a role, but when you lose that personal connection of the storytelling piece of it and you're just driven on a lot of these metrics, which I think it's very easy to almost paralyze yourself by looking at too many metrics and getting all this set of data versus just what are the most important pieces? What does our audience need? And you know that by knowing your audience, and so I think that's why it was such a good point when you talked about, you know, you didn't really know you were doing marketing, but you were having success with it because you were doing it in a way that was genuine to your mission and to your audience, and you weren't doing it with the intent of how do I get X number of subscribers?You were doing it in a way of how do I provide something that I think is beneficial to people like me. You had that pain point and you filled that pain point, and it resonated with your audience. And so, yeah, in the interview, when we were talking about those things, I just—it excited me to be able to have that connection with my audience and not be so focused on the data and the intel. Which, I'm not the kind of person that wants everybody to know every single thing that I do online anyway. I think that some of those tactics are, quite frankly, a little bit terrifying. So, knowing that wasn't a push of knowing every single thing that you could possibly know about all of your audience was something that was very refreshing to me.Corey: One of the things I built fairly early on was my own custom click-tracker because sponsors demand this, on some level, but I also found it useful for my own purposes in the aggregate. Specifically what I built is something that shows me the number of people that click on a given link in a particular issue, but it doesn't tell me who any of those people were. It dedupes it, so it isn't one person clicking a link 500 times winds up inflating the count, but that was as far as I went. And I use that data to periodically put together a best-of issue when there's a slow week, when Amazon, I don't know, winds up in a super-contentious company-wide argument about what is the absolute worst name to give something, and then there's not a whole lot of releases that week.Great. I can go back and highlight things that people found interesting and useful in the past because no one reads everything, and even if I've talked about it before, it's new to someone. And that took a surprising amount of work because every time I would talk about what I was building with folks in the space it was, “But yeah, then don't you want to track the people who click it as they move through your website, and as they wind up moving across the internet so you can start putting them into cohorts and the rest?” And no. First, I don't have the patience to wind up doing that sort of tracking; I don't speak Excel that fluently.And also, it's somewhat marginal as far as the ability to improve any meaningful business outcome. We don't tend to manage by a whole bunch of iron metrics here around things like that. When I wind up doing ridiculous stunts, like a music video making fun of some Amazon exec or whatnot, I do it because I think it'd be funny and it will probably resonate, but there's no business case behind it. It's, “Ehh, why not? Worst case, we learn something.” And I get the sense, talking to folks, that is increasingly rare.Natalie: I think it is, too, but I like the approach. I think the click-through rate, what's important there is the success of your content. If people are clicking through it, your content is resonating. And I think that people really underestimate people's ability to decide if they want to move forward and reach out to become a customer or go further down in the funnel. I think people are pretty smart.Just because they clicked on a link, you don't need to berate them with 15 more touchpoints to say, “Hey, are you ready to make this purchase? Are you ready for this?” I mean, all of these things, people can get there, and if you frame your funnel in a way that makes it easy for them to get to point A and point B, really shouldn't have to have that much involvement in their journey. And some marketing people might not agree with me on that, but I think as long as you make it easy for them to get what they need, to find what they need, to learn as much as they can about your service before they purchase, you don't need to have all of those touchpoints, you don't need to know that they clicked on all of these things. And I think, too, as a user, if I know that if I click on a link, I'm going to get a barrage of emails selling a service if I'm not ready for it, it's going to make me hesitate to click a link.And so I think that that approach is just a more user-friendly approach, and it really just makes the experience of the user that much more smooth knowing that there's kind of a mutual trust there. I'll let you know when I'm ready and you can help me get there, but don't try and do it for me.Corey: The piece that I've always found surprising was that everyone talks in the ad tech space as if without this data, our businesses will wither and die on the vine. But the ability to track people as they move across the internet and go through their lives is a relatively recent horrible invention. Companies existed and sold goods and services phenomenally well for millennia before the advent of any of these things. And does it improve around margins? Of course, it does; I'm not saying the industry is built on fraud. I'm just saying that it winds up making a trade-off that I'm not comfortable making myself, and therefore I'm unwilling to ask my audience members to make similar trade-offs themselves.Natalie: Yeah. And it's like, at what point do you get to be too much, where you know too much about your audience? And like I said before, people are smart; we don't need constant advertisements across all of these platforms to remind us of something we thought about or we looked about. I mean, it's good; there's certainly a time and a place to have a reminder come through or be retargeted in a way that isn't creepy, but I mean, it's those things where I think about something and all of a sudden I see an ad, those still freak me out, so I think that people don't need this over-advertised approach to make a purchase. Like you said, people have been purchasing things for a very long time, and I think that people are capable, people are smart, people know where they're at in the journey better than, really, anybody else.And so there is a time and a place for it, but there is also—it seems to be moving in too much information, too much interruption in people's lives and it is certainly—yeah, if I don't want it, I'm certainly not going to—or if I don't want to be targeted that way, I'm not going to do it to anybody else either.Corey: Turns out there's an entire seedy underbelly to the web, and as soon as you have a website that has a little bit of traction, you wind up getting exposed to countless piles of spam about it. There's the standard SEO stuff of how to optimize your results in search engines. I have this ancient approach that seems to serve me pretty well, which is, I write fun, engaging original content and then put it on the website, and then it sort of takes over from there. I don't write with an eye towards, “Well, use the following phrase more than 20 times but less than 50 in the course of the next month.” It's, “no.”But then you wind up with folks guaranteeing, “Oh, use us for search engine optimization,” which I always think is the weirdest pitch because let's face it, if I want someone to do my search engine optimization work, wouldn't you think I would just type the word search engine optimization into Google and then click the number one result? Seems like they have the proof and no one else would. But there's also this sea of folks asking if they can pay me to put a guest blog post on the website. And the answer is no. When we have guest blog posts—usually on Fridays—that comes from people that we pay to write them.It's not some random thing that's only tangentially tied to what we do but includes a suspicious number of links to some other third-party website. It doesn't make sense for me to just start devaluing the experience of the reader like that. I try to be as respectful of people's time as I can be when it comes to content creation.Natalie: Right. And I think I'm becoming a broken record on this point, but I will say it again: people are smart; they can see through those tactics. And yes, there are certain things that will help your content rank better: where you put your keywords, having a title and a meta description, and all those things are important, but at the end of the day you need to write for your audience and not for the search engines. They're getting smarter, right, the search engines are getting smarter, but they are still not the humans and so if you overstuff your keywords, if you put in a bunch of links, it's going to look like you're doing it solely for the search engine and people will see that, they'll recognize that, and they won't value your content because they will feel like they're being sold to. And they won't get what they need out of it; they won't see it as a thought leader that's genuinely producing content in order to help inform them and it'll be devalued.Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance accelerator for the Oracle MySQL Database Service. Although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLTP and OLAP, don't ask me to ever say those acronyms again, workloads directly from your MySQL database and eliminate the time consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora, and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.Corey: It's disturbing in some ways to see the number of companies losing their collective minds [unintelligible 00:16:29] there's a Google algorithm change, and suddenly, as a web browser myself—as in the person, not the software—when suddenly I'm no longer seeing a bunch of eHow links or whatnot dominating search results, or the godawful Experts Exchange site for a while where they would pretend to have a paywall, but scroll down far enough and they have the full text of the thing to keep within Google's rules. And Google got better at these things with time. If a single change to a search engine algorithm can destroy your business, I wonder how sustainable business is in the long term.Natalie: Right. And I think that, like you said, it's—I mean, it's a game, right, and the game constantly changes, it constantly involves. The search engines are getting smarter, but if you just try and constantly keep up with the rules of the game in that way, you're going to lose because it's just going to be a constant change. I think the most important thing is to just show up consistently and write good content. I mean, when SEO became a thing, if you put in five million keywords, you're going to rank well, but it's not any value.And so if your intent is just to always produce good content, be aware of the rules of the game and apply them when it makes sense to, and figure out what the ones that are most important to you are, you will do well, but it's just that consistently showing up, producing good content, and having your readers in mind is what's going to help you go forward. If you're just focused on the algorithms and making it fit in that, it's going to look that way and you're never going to be able to catch up.Corey: For me, the big indicator that I'm doing something right is periodically, because it is a collection of links, I'll link to some site that has some sort of attack malware on it, usually from an ad network that was compromised somewhere—surprise; it's just a thing that happens—and as a result, some companies will start blocking it or will start putting it in the spam folder. And when you wind up with larger outside spam folks reaching out to you because of the number of complaints they're getting from their customers about it being blocked, that's my indication that we're probably doing something kind of right, as opposed to it being incumbent on us to track that down from our side.Natalie: Yeah. And like I said before, I mean, the users know what—they also know the rules of the game, too, right? Or they're at least aware of it, and so they can recognize that. But like I said, it's just having the goal of informing your audience and producing good content that you know is going to resonate with your audience. It's just a smart way to go. I mean, having the user in mind always, and not it as a way to see them as just a dollar sign or a number, but knowing how can I really help them learn about this topic or share what I know, is going to always benefit.Corey: The piece that I think resonates in some respects as well is what I'll periodically do even on this podcast, where it's, I will ask people about what they're good at and listen to the answer, and then ask follow-up questions. It's not exactly a pioneering technique; it's just storytelling. And for whatever reason, it seems that marketing—the way I view it—is always tied back to storytelling. It's about understanding who your audience is for anything that you're working on, understand what action you want them to take. Maybe it is to fix their S3 bucket permissions.Maybe it's to reach out and ask me about AWS bill consulting. Whatever it is, understand who the audience is and what the expected outcome is, and then just tell a story around that. It's not that compellingly difficult, but for some reason, it seems like it's the most novel thing in the world to some companies. I always equated marketing with storytelling. Is that rare? Am I wrong on something?Natalie: Not in my book. I mean, that's how I think about it as well, too. I think that some companies get so focused on talking about themselves, and this is what we do and this is why we're the best. But they miss that storytelling piece of it of why it matters to the audience. You can talk about your company until you're blue in the face, but if you don't connect it to your audience, they aren't going to know how it helps them.And maybe you have a service that they don't know that they need yet, but by producing content and telling them a story of how what you're doing is going to make their lives easier, you're going to resonate with them. I mean, that's why people look for services: because they have a problem. And maybe it's not identified, or they don't know how to fix it, but if you frame your content in a way that takes them through a journey of, this is where you're at, this is how we can help you and then—or this can ask, how can you make your life better, and this is where you'll be at the end of it, it's going to resonate with your audience. And so yeah, I think that if you're focused on shouting the benefits without connecting it to the emotion of why it matters, it's going to come across that way. And so I think, yeah, storytelling, having the audience, their perspective, who they are, what they need, and telling the story in a way that is a good experience for them, is always the way to go.Corey: For whatever reason, it seems like the folks that are the worst offenders of that tend to be the big cloud companies themselves, where, “Okay, here's a service we built.” “Great, how am I going to use that to solve an actual business problem that I have?” “Next up, we have a guest speaker from Netflix to tell us what they did with it.” “Cool. Maybe I have problems that don't look like Netflix-scale problems, maybe I'm just trying to contextualize this thing that you've released with the 200 other things that you have, and figure out what component that will replace, or extend, or what feature it will grant inside of my existing environment. Or even if it's something new, it'll give me ideas for different directions to move things in.”And they never do that. They talk about features, they talk about capabilities, they talk about how innovative they are, and they just completely abdicate the entire role of telling a compelling story around this. I mean, Jeff Barr's blog posts are a terrific counterexample to this. I think it's the only time that AWS actually tells a story of, “I'm going to set out to build this thing to do this. Here's how I do it, and here's how it works.”And it's incredibly engaging, it has a distinct voice—because Jeff has a personality and can express that personality—and I get the sense, at times, he's the only person at Amazon allowed to do that. Everyone else just winds up falling into these same somewhat tired tropes of, “Here's a bunch of feature announcements.” The release feed doesn't even let you include images, so wind up—people trying to describe the layout of a new console page to you. And it just doesn't resonate or make sense. I mean, half the value of building the audience that I have is, whenever something comes out, people's immediate question for me is—they'll tell me that it's out by, “Can you explain this to me because Amazon, once again, has failed to do so.” I didn't show up here, due to the express purpose of being the de facto head of AWS marketing; it just kind of happened because functionally, it feels like it's a pretty empty seat.Natalie: Yeah, and I think that those are all really important points because they put out all this information about their services and their features, but they don't complete the cycle to say how it affects the user, how they would use it, and so it's like you're not finishing the race there. And so you also have to acknowledge that you might target a similar set of companies, so maybe you're targeting a bunch of companies in one space, but everybody's pain points are going to be a little bit different, so if your audience can't relate to how you're implement—or how you're telling them to implement a service or a feature, they're not going to feel that. And so you have to tell your audience how what you're doing is going to improve their life, but also doing it in a way that is going to apply to them. And so that's part of understanding your audience and understanding the different pain points associated with each of your target audiences. And so that's why it's important to have some of those intel on your audience, but finding out a way to resonate it across all of the companies that you target and make it relatable is what's going to be success.Corey: It's always strange to me that when we talk to sponsors who are—they want to wind up telling people about, great, I try to have conversations with them; imagine that? And understand, okay, how does this differentiate from, for example, an AWS service that does something very similar? And the answer is often, “Wait, that's a real thing that exists?” If people in that market aren't aware that there's an AWS release that does the thing that they do, what hope do customers have? None.Natalie: Right.Corey: It feels like it's not just a matter of will AWS launch a service that competes with you it's, will they do an even passable job of telling a story around it so people know it exists? They tend to do everything very frugally, which means that they can release things that are competing with, in some cases, many billion-dollar companies out there. And great, okay, so you've got a 60-person team or whatnot, trying to compete with a company with a $30 billion valuation. Yeah, my money is on not Amazon for stuff like this, until they start trying to do things that reek of anti-competitive acts. I'm not super worried about Amazon as a competitor for a lot of these upstart services.Natalie: Yeah. And I think another thing, too, that you touched on was having conversations with your audience and really understanding how they are perceiving what you're selling. I think if you get caught up in, “This is what we're going to push; this is how we're going to say it; this is what we're going to do,” but you don't have that touchpoint of how are they perceiving it, are they aware of this? There's a big missed opportunity there. Because if something's not working, there's a disconnect; there's a miscommunication. So, being able to have some kind of engagement with your audience, where you're surveying them, or whatever, to see how their perception of what you're selling is vital in shaping your marketing story.Corey: You really would think that this wouldn't be anywhere near as challenging as it has clearly become.Natalie: Mm-hm.Corey: But here we are.Natalie: And I think people, they try and make things more complicated, I think, from time to time. I think that just going back to the reason why you're selling things: the reason why you're providing a service is to help your audience fill a need, hit a pain point. And so I think that it can certainly get over complicated quickly and you can forget, really, the mission behind a lot of what you're doing.Corey: I wish more people shared your viewpoint. I guess, so far, all we can do is set a good example and hope the rest of the industry follows us wherever we're going.Natalie: Right. And I mean, you know, like I said, there's always kind of moving in that direction of a lot of tech, a lot of these big things that are supposed to make your life easier in marketing, but I think it'll always come back to the audience, it'll always come back to the storytelling, it'll always come back to the user experience. And so, it's just riding the waves, and seeing what's going to happen, and how things evolve. Because marketing and everything, it's just a constant keeping track of the trends and the evolution of it.Corey: And it never seems to hold still. If people want to hear more about what you're up to and how you think about these things, where can they find you?Natalie: You can find me on Twitter at @natveiswilliams.Corey: I will, of course, put a link to that in the [show notes 00:27:31]. Thank you so much for taking the time to speak with me.Natalie: Yep, Thanks, Corey. This was wonderful. I really enjoyed it.Corey: Natalie Williams, Director of Snarketing here at the Duckbill Group. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an insulting comment telling me exactly which features on the checklist this episode should have had instead, phrased in the worst way possible.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
Welcome to season two of That Gives Me Anxiety! In this episode our anxiety is caused by going to the dentist. Patrick Jones (@Patrick_E_Jones) talks with comedian Matt Morrison about his anxiety related to getting his teeth looked at. Pat also interviews Jeff Barr, a dentist and former ice hockey teammate of Pat's about ways to improve your experience at the dentist if you're nervous about going.If you're liking the show and want to support it, feel free to buy me a coffee!https://www.buymeacoffee.com/givesmeanxietyCheck out the show on all of your favorite social platforms.https://twitter.com/GivesanxietyPodhttps://www.facebook.com/thatgivesmeanxietypodcasthttps://www.instagram.com/thatgivesmeanxietypodcast/https://www.youtube.com/channel/UCgCOITNlRi_K7JP9QxBK-vQSupport the show (https://www.buymeacoffee.com/givesmeanxiety)
On The Cloud Pod this week, Ryan was busy buying stuff on Amazon Prime Day and didn't want to talk about JEDI, so he arrived late to the recording. Also, long-time sponsor of The Cloud Pod, Foghorn Consulting, has been acquired by Evoque, so the team grilled Peter for the juicy details. A big thanks to this week's sponsors: Foghorn Consulting, which provides full-stack cloud solutions with a focus on strategy, planning and execution for enterprises seeking to take advantage of the transformative capabilities of AWS, Google Cloud and Azure. JumpCloud, which offers a complete platform for identity, access, and device management — no matter where your users and devices are located. This week's highlights The $10 billion JEDI cloud contract has been canceled by the Pentagon. In its place, the DOD announced a new multi-vendor contract known as the “Joint Warfighter Cloud Capability.” Evoque Data Center Solutions has acquired cloud engineering experts Foghorn Consulting. This is a key part of the company's Multi-Generational Infrastructure (MGI) strategy, which it announced the same day as the acquisition. AWS released some incredible numbers from Amazon Prime Day. Jeff Barr gives his annual take on how AWS performed and the record-setting event. Top Quotes “The Pentagon has called off the $10 billion cloud contract [JEDI]. It was being dragged through the courts by Amazon and Microsoft, and this is sort of an admission that the Pentagon didn’t want Donald Trump to get subpoenaed and testify on what his involvement was in the whole contract.” “This is a big problem that almost every business has: how do you stop a deployment, especially a large deployment? Typically, we throw people at it, and we have them watch millions of dashboards, and hopefully, they catch it. But usually, it’s a problem somewhere that’s exposed to the customer that triggers that. So if we can have more tools like Gandalf that detect problems earlier, it's great.” General News: Some People Can't Take a Joke Evoque Data Center Solutions acquires Foghorn Consulting. Congratulations to Peter on this exciting news! The AWS Infinidash story has taken on a life of its own. What started as a joke has led to backlash from the community complaining about it being a form of technology gatekeeping. JEDI: We're Not Talking About This Anymore The Pentagon has canceled the $10 billion JEDI cloud contract. It's not really dead, they’ve just turned it into a joint multi-cloud offering, which is what we said they should do six months ago. Amazon Web Services: A Little Gooey Andy Jassy thanks AWS employees as he takes over as Amazon CEO. We wonder if Bezos is bored yet. Between the Blue Origin launch and The Washington Post, he's probably not. Jeff Barr is back with his annual take on how AWS did with Amazon Prime Day. It would be great to know how they manage the surge in workloads: maybe they have their own secret regions. The Bottlerocket AMI for Amazon ECS is now generally available. They've added functions to help automate clusters and troubleshoot, which is super cool. Amazon announces smaller units and a price drop for Amazon Kendra. It's still expensive, but if you're building internal tools to search your internal corporate internet, this is much more usable. Introducing AWS solution implementation Tag Tamer. If you’re embroiled in the tagging nightmare, this might be a better route than building it all in house. Google Cloud Platform: Looking To The Stars Rubin Observatory offers the first astronomy research platform in the cloud. It's great to see a partnership in the science field, rather than with another big corporation. Google introduces predictive autoscaling for managed instance groups (MIGs). Autoscaling can be difficult to manage, so anything that helps automate it is great. Google has made several updates to Google Cloud VMWare Engine. Allowing users to leverage policy-driven automation to scale nodes needed to meet compute demands of the VMWare infrastructure is fantastic. Azure: Big Fans of Lord of the Rings Azure VPN NAT is now in public preview. One of the most impressive features will help avoid IP conflict, especially with the transit gateway, which is awesome. Azure announces the integration of New Relic One performance monitoring into Azure Spring Cloud. This is supported by VMware and Azure at the same time, which is not bad if you have a Spring Boot app: Getting access to VMware engineers to troubleshoot your Java code is always a plus. Azure builds a safe deployment service called ‘Gandalf'. When the data center is on fire because of new code, it stops the problem from spreading. TCP Lightning Round In a controversial move, Peter claims that jokes that write themselves should be a point for him so awards himself this week's point, leaving scores at Justin (11), Ryan (5), Jonathan (8), Peter (2). Other Headlines Mentioned: Soft delete for blobs capability for Azure Data Lake Storage is now in limited public preview Amazon EKS managed node groups now supports parallel node upgrades AWS Glue Studio now provides data previews during visual job authoring AWS Glue DataBrew adds support for backslash delimiter () in .csv datasets AWS Glue DataBrew adds support for 14 new advanced data types for data preparation AWS Amplify launches new full-stack CI/CD capabilities AWS Amplify CLI adds support for storing environment variables and secrets accessed by AWS Lambda functions AWS IQ now supports attachments Amazon Athena adds parameterized queries to improve reusability and security Things Coming Up Announcing Google Cloud 2021 Summits [frequently updated] Security Summit — July 20th Retail and Consumer Goods Summit — July 28th Amazon re:Inforce — August 24–25 — Houston, TX Google Cloud Next 2021 — October 12–14, 2021 AWS re:Invent — November 29–December 3 — Las Vegas Oracle Open World (no details yet)
About MichaelMichael Garski is the Director of Platform Engineering at Fender Musical Instruments, where he leads the teams responsible for service development & testing, devops, and data. He's been with Fender for over 5 years and prior to that worked as a software engineer & architect on back-end systems at Viant, MySpace, Countrywide Home Loans & Fandango. He is passionate about application reliability and observability and their impact on customer satisfaction.Links:LinkedIn: https://www.linkedin.com/in/mgarski/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Your company might be stuck in the middle of a DevOps revolution without even realizing it. Lucky you! Does your company culture discourage risk? Are you willing to admit it? Does your team have clear responsibilities? Depends on who you ask. Are you struggling to get buy in on DevOps practices? Well, download the 2021 State of DevOps report brought to you annually by Puppet since 2011 to explore the trends and blockers keeping evolution firms stuck in the middle of their DevOps evolution. Because they fail to evolve or die like dinosaurs. The significance of organizational buy in, and oh it is significant indeed, and why team identities and interaction models matter. Not to mention weither the use of automation and the cloud translate to DevOps success. All that and more awaits you. Visit: www.puppet.com to download your copy of the report now!Corey: If your familiar with Cloud Custodian, you'll love Stacklet. Which is made by the same people who made Cloud Custodian, but put something useful on top of it so you don't have to be a need to be a YAML expert to work with it. They're hosting a webinar called “Governance as Code: The Guardrails for Cloud at Scale” because its a new paradigm that enables organizations to use code to manage and automate various aspects of governance. If you're interested in exploring this you should absolutely make it a point to sign up, because they're going to have people who know what they're talking about—just kidding they're going to have me talking about this. Its doing to be on Thursday, July 22nd at 1pm Eastern. To sign up visit snark.cloud/stackletwebinar and I'll talk to you on Thursday, July 22nd.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. We talk to a lot of people here on this show who are deep in the weeds of SaaS companies, or cloud vendors, or cloud vendors cosplaying as SaaS companies. Today, we're taking a bit of a different direction. My guest is Michael Garski, Director of Platform Engineering at Fender Musical Instruments. They make guitars among many other things. Michael, thank you for joining me.Michael: Oh, thanks for having me on, Corey.Corey: So, one of the things that I really appreciate about what you do as a company is I can, at least presumably, explain it to someone who is not super deep in technical weeds without 45 minutes of explainer first. The easy answer is, “Oh, Fender. You folks make guitars.” These days, no one just does one thing, I have to imagine. How do you describe what the company does?Michael: Oh, well, to quote Leo Fender, his view was that artists are angels and it's our job to give them wings. So, in addition to actually making and developing guitars and amplifiers, we've branched off into consumer-facing products to actually teach people how to play those instruments.Corey: You folks have been relatively outspoken about the various things you're doing at different AWS events. I mean, my approach to that tends to be that if AWS is great at making bricks that you can use to build amazing things with, “Well, great, can you draw a picture of the house that you can build with this?” “No, we're going to have a customer come out and talk about that stuff instead.” You folks have been focusing on a lot of serverless work, and you've been very public about the fact that you are almost entirely serverless-driven in terms of architecture if I'm not mistaken.Michael: That is true.Corey: Tell me about that. How did you get there and what brought it about?Michael: So, I work in the digital division in Fender. We started, let's see, we're coming up on five years I've been there. So, what we did was, initially, we started building services that could run within a container, or on an EC2 instance, but we started looking at Lambda functions. We had need to ingest a product catalog, so the IT team was able to drop us off a product catalog into an S3 bucket, and the easiest thing to do then was just trigger a Lambda function to then process that file. And it just kind of snowballed in from there.Corey: I think the common problem when people hear ‘serverless' is they think, “Oh, great. More discussions about Lambda functions.” And Lambda is almost getting something of a tarred reputation in some circles because when we can build amazing things with it ourselves, we love it, but when we ask AWS how to wind up integrating two services, or about a feature gap, their response is, “Oh, use a Lambda function for it,” It starts to feel like they're using it as spackle and the spackle has become load-bearing. Do you view serverless as being purely function-driven or is it broader than that?Michael: It's much broader than that. Serverless is a mindset where you're looking beyond just Lambda functions to using a lot of third-party services so that you can actually focus on your core business. Like, we use Zuora as a subscription provider for web-based subscriptions; we use Algolia for full-text search; we use a variety of other services so that we can just focus on the core business.Corey: One thing that's been on everyone's mind, somewhat recently, has been the idea of dramatic changes as far as user behavior goes. And in the more traditional environments where you see things like EC2 instances or on-premises data centers, back when the pandemic first hit and companies that were very focused on a model of business that aligned directly with people behaving in certain ways that they suddenly didn't, would the 80% drop-offs or more in their user traffic, but their infrastructure spend just kept hanging out exactly where it was, in a straight line. So, at some level, it feels like yes, the whole point of cloud is that it can be elastic, except no one builds it that way for a variety of reasons. When COVID hit, what changed for your business?Michael: Change for our business is we launched a program called Playthrough, okay we did this about a year ago; we started it, we gave away three months of Fender Play for free. It was a single-use code that a user would redeem and no credit card required, and over a period of five days, we saw our traffic increase by more than ten times. And we had very little changes we needed to make. Everything scaled up, we had no issue with—we used a lot of Lambda functions, DynamoDB, everything just scaled up fine. The only point that became a bottleneck was our Elasticsearch cluster. However, beefing up the nodes and adding a few more nodes that resolved that issue immediately.Corey: So, I'm going to go out on a limb and postulate that you folks increased pickup when the lockdowns hit, if for no other reason then, “Well, I'm trapped at home and I'm tired of staring at the guitar on the wall. I may as well learn to play it.” I would guess. I could be way off base on that.Michael: No, no, that's very true. Even since then, even after that program has expired—of course, not everyone then converts and sticks around—but many, many did, many more than we thought would did stick around, and our usage and our goals were exceeded for this last year, and we're in a healthy place, and looking at continuing to grow and expand in the future.Corey: So, one of the applications that I think gets a fair bit of attention—rightfully so—lately, is something called Fender Play, and as best I can tell, that is a app that works in web, it works on mobile, and it's a video-based instruction tool for guitar at least, but some other instruments as well. How did that come to be? Did that exist before COVID hit? Has that been something that's been in the works for a while? Or was it, “Well, we're going to do a two-week sprint and build this thing from scratch?”Michael: No, we launched that—this June we're coming up on the fourth anniversary since it's been launched, so we launched this in summer of 2017.Corey: One of the problems I've always found is that it's challenging to learn to do something that is as, I guess, physical and intricate, et cetera, as playing an instrument without having someone in the room looking at you and smacking you with a stick whenever you do things that are wrong. “Nope, that's a bad habit. If you keep doing that it's going to hurt you.” How do you approach that as a company from a non-interactive perspective of someone who's going to watch a video and do things and maybe it'll work, maybe it won't? Particularly in light of things like, well, the competition is YouTube, which, you know, I'm going to roll the dice and sometimes I'll see a great tutorial, sometimes I'll see one that I don't realize teaching me terrible things, and then it's going to recommend some baseless conspiracy theory because YouTube. How do you differentiate that? What makes Fender Play different?Michael: So currently, you're right; it's just a video-based instruction app. There's not any way to, like, provide direct feedback to students within the web and mobile applications. However, we do have an online community, and our Fender Play instructors do an office hours feature, is where they'll actually answer questions live and talk to students. We are investigating and doing some earlier research in some, possibly, being able to provide that type of feedback to users, but it's very challenging problem, just due to the nature of you're playing an instrument that has multiple strings, so you're trying to pick out the chord that they're playing in, and the timing. But it's something we definitely need to add.Corey: There's something to be said as well for the kind of care and attention that you folks wind up putting into your media where, “This is how you finger a chord,” and someone on the YouTube video will do it for two-tenths of a second, and they're filming it with a potato that isn't focused properly and pointing at the wrong part of the guitar. You folks have a high bar for quality on this. Is that done in-house? Do you wind up just going through a bunch of random folks that you just wind up offering a bunch of gift cards to, or free guitars to do this? How does the program work on the back end?Michael: So, we have an in-house curriculum team that puts together the lesson plans to really help people learn in small bite-sized lessons so that it's not too overwhelming at once. And that curriculum then is shot and filmed by an in-house video team that put that together; they upload the data into S3 for the final cut, then that gets transcoded via MediaConvert, and we serve it up via CloudFront.Corey: It's rare to wind up talking to a company that is something of a household name about something that they're doing, and hear the AWS services that they're using not trend toward a baseline mean if I can be so bold. Normally, you'll see some of the case studies, like, “Oh, this is an online bank. What services are they using?” “Oh, they're using EC2, and S3, and load balancing because did you miss the part where it's a bank?” They're not going to use these far-future services due to regulatory risk, among other things, in many cases.You're using Elemental MediaConvert, which is one of those relatively high-up-the-stack offerings that isn't broadly known. It's one of those services that is focused on specific use cases and specific industry verticals in a way that a baseline primitive service isn't. What does MediaConvert do?Michael: What it does is it takes the final edit of the video, and we have several different presets so that it will put it into an HLS format with different bitrates so that the user is getting the best quality video depending on their bandwidth.Corey: When I looked into it in the early days when it was first launching, I found that it looked an awful lot like Elastic Transcoder, which is a service that they've had for a while, only they changed up some of the capabilities. It's obviously far more capable as a service, but they also added something that felt like 15 different billing dimensions to it, “So, what is this going to cost me?” “Well, we're going to run it for a month and find out if we're still in business.” And it seemed like it was one of those very difficult to get started with and run experiments with service. Now, obviously, services evolve over time. When you started looking into it was that experience roughly akin to what you felt, or am I completely and unfairly slandering in the product?Michael: We actually started out using Elastic Transcoder and then moved over to MediaConvert, I believe it was last year. We found it to be a little bit easier to use, and the pricing overall in transcoding the videos for us is really a drop in the bucket as compared to actually hosting them and serving them up via CloudFront. And when we switched over to MediaConvert, we adjusted our settings to lower the maximum bitrate for a given video, we found that after a certain point, the quality to the user just doesn't really improve, and yet we're paying to serve the larger video.Corey: One statistic that I found was that in March of 2020—you know which I believe we're still in at this point; just, it's the Endless September model, applied to March—you wound up seeing over an order of magnitude in traffic increase within five days, and looking at that through a lens of traditional architecture, that means that nobody sleeps a whole heck of a lot. Given that you're in on the serverless story, and you have been since before that hit, what was that scaling experience like for you?Michael: Scaling experience was completely seamless. We use a lot of Lambda, DynamoDB, Kinesis, SNS, to glue things together, and no problems whatsoever. Just had to bump up our Elasticsearch cluster a bit, that was really the only thing because we saw some latency starting to rise on some of our APIs.Corey: Let me ask the uncomfortable question then because whenever I tried to scale things up quickly in a cloud environment, what was your experience with smacking into various AWS service limits as the traffic grew?Michael: Initially, we actually requested some service limits increase to make sure we weren't hitting the concurrent Lambda invocation limit, and same thing with Cognito, making sure that we weren't going to hit any limits as far as sign-ins and things like that. So, we were able to just put in requests, and they served us around pretty quick turnaround time on that, as well.Corey: It really does seem like there's a strong benefit on the serverless space, but I had to double-check before we started recording that you do, in fact, work at Fender because you are a staunch advocate for observability. And usually, when someone is that passionate about observability, you can guess that they work at an observability-slash-monitoring company. It's akin to the idea of someone selling mattresses telling you that mattresses are great and you should have four of them. You're on the customer side of that and still very passionate about it. Where'd that come from?Michael: Came from my time years ago, when I worked at MySpace—if anyone can still remember that—working on the search systems there. And as the company started winding down, to laying people off, and being one of the only people left working on those systems, being able to know and understand them, you just have to, so you have to continue to monitor and find ways to monitor, and that really ingrained how important instrumentation is and being able to really understand the health of your application as it's running so that you can see, yes, everything is good, and then when something doesn't look right so that you can know where to start looking, and you can be alerted of a problem.Corey: So, I tend to view the world in olden terms where monitoring was what we did, and we use something like Nagios, which was the second-worst option out there because everything else felt like it was tied for first. I also take a somewhat regressive view that observability is to monitoring as DevOps is to being a systems administrator. It's the same thing, but by using the more modern terminology, you can charge more for it. I'm going to go out on a limb and guess that you take a somewhat contrarian [laugh] view to that.Michael: Yes, yes, I do. It's about really understanding how your applications is running. It's not just looking at, oh, how many HTTP 500s am I serving up per hour, if I hit a threshold for the last hour? It's a lot more than that. It's really being able to really dig in and see what the issue is or what's working really well.And to that end, we rely on two services for this. We use Honeycomb and Epsagon. Honeycomb, kind of, acts as our top layer because it gives us the really good high-cardinality metrics where I can punch in a user ID and I can see all the API traffic that this user has performed. As well as, even just like when we launched the Playthrough when our traffic rose, that the reason we discovered that our latency was dropping was due to a service-level objective being triggered in Honeycomb on latency. And we were able to respond to that using that before customers really noticed anything at all.Corey: As an Epsagon customer myself, I'm always conflicted when I find myself going into their service and using it to figure out what the heck's going on with my giant pile of Lambda functions, and API gateways, and whatnot, wired together because the experience is uniformly excellent, but I'm also frustrated in that it needs a third-party to even begin to allude to what's going on. It feels, on some level, like the vendor that is providing this service to me should be reasonably effective at telling me what it's doing, and when it's breaking. I understand that how I wish the world is and how it actually is are two radically different things but does that ever strike you as well?Michael: Whether or not AWS should be providing that type of level, that seems… that seems like more of a service that you can have competition and other vendors that really specialize and get in the weeds on it. I don't think AWS needs to provide every service you could possibly use for your application. That's not something I'm too concerned about. I don't really even think it's their place, frankly.Corey: No, no, I understand. The problem I keep running into, on some level, whenever I try and diagnose it natively is, I look at CloudWatch and it's difficult to understand that is this—in my case because again, I'm still early days with a lot of these things—is it the API gateway that's having the problem? Is it the CloudFront distribution that is tied to that? Is it the Lambda function? Where's the handoff?Trying to understand where in a complicated application the failure is occurring is a challenge. And let's be clear, most of that is a problem of my own making because I didn't have the good sense to instrument this thing in a reliable repeatable way when I built it. It feels like everything is tied together with duct tape, and baling wire, and spit, and a bit of luck. As a counterpoint, the more companies I talk to, the more I realize that no, no, this is actually how most people feel [laugh] when they look at things that are working. It's, yeah, it's terrible. It's a trash fire, but it makes money so we're going to roll with it.And there's always, on some level, a sense of what we've built is very far from the platonic ideal of what we should have built. Does that resonate with you, or do you take a step back and look at what you've achieved with a perspective of, “This is awesome. More people should do it exactly like this.” And honestly, if it's that one, I'd love to take a look at what you've built.Michael: I think there's always room for us to improve on what we're doing because we're constantly learning and evolving to improve both, even at such a low level of like, “Okay, how do we lay out the files in our service repository to make the best organization to make sense?” All the way up to, “Okay, how are we going to do tracing? And what kind of information do we need to get from that so that we can find problems when they occur?” We're always looking to learn what others are doing, and talking to others in this space. No one will ever be a hundred percent right. There's always room for improvement everywhere.Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I'm going to just guess that it's awful because it's always awful. No one loves their deployment process. What if launching new features didn't require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren't what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.Corey: One thing that you folks have done that I think was really interesting and didn't get as much play as I think it really deserved, was that, especially in the early days of the pandemic, you wound up seeing that massive increase due to giving out almost a million free three-month subscriptions to Playthrough. Additionally, you also worked closely with LAUSD, the Los Angeles Unified School District, to add Fender Play to their middle school music program's curriculum to help supplement their remote learning programs. First, was that all in the same timeframe? Or—and, two, what has it been like, I guess, working with a organization that is, I guess, on some level, not particularly cloud-first. I would imagine. When I lived in Los Angeles, I never got the sense that LAUSD was full-on serverless, full on-board with cloud, full on-board with remote learning. And then the pandemic of course exacerbates all of that.Michael: Yeah, so those were really two different projects. So, that the Playthrough project that started in March, and we started working with Los Angeles Unified School District last year during their summer school program; started out with 1500 students and we put it together very quickly. Essentially, we use the same three-month codes that we used for that Playthrough promotion so that we could set things up very quickly for students and gave out, through our nonprofit arm of Fender, the Fender Play Foundation, gave out 1500 instruments to these students to use during the summer school program. And that program became so successful, we continued on with them in the fall, and now in the current semester, and we will be again this summer. I believe there's 7000 students in the program now.And working with their IT team has actually been quite nice. And in dealing with partners, you wouldn't think much of, “Oh, it's a school district, what do they have?” But as far as just ease of working with them, we actually hooked into their SAML provider in Cognito so that LAUSD students could authenticate when they come in through the remote learning systems. And they were great to work with and very helpful and cooperative.Corey: One of the arguments that you'll see that comes up against serverless, from time to time, is that you are now indelibly linked to your provider, but you can't take what you've built with all of these services and just move it over to Azure or GCP on a moment's whim. Now, in practice, people who tend to build for that, just build everything on top of EC2 and very little else, and then run it entirely in AWS and never move it to any of those other places. But was there friction with making that, I guess, architectural commitment to a single vendor?Michael: Oh, you're bringing up the vendor lock-in Boogeyman.Corey: Oh, I absolutely am. Most people who bring that—when I bring it up as a straw man so you can attack it, most people who bring up the vendor lock-in Boogeyman, “Oh, you have to go multi-cloud,” are either trying to sell you something that is required if you want to go multi-cloud, or they're a cloud provider themselves who know that if you go all-in on one provider, it will certainly not be theirs.Michael: I think if you properly architect your applications with separations of concerns that you could move to, say—okay, say Lambda wasn't working out for us anymore, and we needed to take our applications and, where, we're going to put them into a container, but we're going to stay in AWS. Our applications are set up in such a way that Lambda is basically a deployment pattern. We could easily convert those individual function handlers into route handlers with a minimal effort because the business logic and then the underlying data storage are separated. So, it would be feasible for us if we wanted to, say, move to Azure and use Azure Functions and whatever comparable service they have to DynamoDB. I'm not too familiar with a lot of their offerings.But that would certainly be possible to do it with, obviously, some effort and really, at the end of the day, the resources you have working on the applications are end up going to costing you much more than any, sort of like, software licensing or specific savings you're going to get from a cloud vendor, so might as well go ahead and just use those service that they're providing. So that you can just focus on the business.Corey: My approach has almost universally been that looking at an awful lot of companies and their AWS bills, it is a challenge to find an environment where the resources in the environment cost more than the people who are operating them. In the context of business, AWS bills seemed giant and enormous, right up until you look at payroll and then it's, “Oh, okay.” That's counterintuitive for folks who are learning this, and I fall prey to it myself is, when I'm playing around as a hobbyist trying to build something I value, my time is free because I'm learning as this goes, and then in that context, especially when I was starting out as a student, it was, “Oh, great. So, this winds up costing me $7 a month. Oh, that's a lot of money. That's my ramen budget, so I'm instead going to wind up spending eight hours avoiding it charging me anything.” It's the exact opposite from the direction you want staff that you're paying to work on these things to go in. How do you approach the idea of increasing the cloud cost if it will save time for your team?Michael: It's a balance between, where do we need to build this ourselves? And then not only build it, you have to operate it and maintain it? Or what is the cost of getting this third-party service? And that's really what it comes down to in all of them. And do we actually want to spend time working on this piece of infrastructure that these other people are specializing in and do so well? I've got better things I can have people doing than that.Corey: Speaking of people, one thing that you talk about, as you self-describe, is that you wind up not writing a whole lot of code anymore, but you're something of a stickler for observability and enforcing consistency between services, so you'll periodically do things like submit a PR to tweak a log message to put your mind at ease, was one example that you gave. Given that you're a director, which is generally manager of managers style approaches, how do you avoid having those PRs come across to your team as either micromanagement or a condemnation of what they've built? Because I get it; when I see something that's easy and small to tweak, I want to go ahead and get it fixed immediately. I don't want to go back and forth and play those games; I just want it done. But I'm also always weighing that against, I don't want to have people think that I'm judging them somehow for something I'm very much not.Michael: That's a very good point. The larger technical decisions on how things are laid out, I generally just try to—I don't insert myself into. I let the team go ahead, and make those decisions, and leave that direction, and let them take the charge on that, and I take the approach of looking at it as more of a guiding, and mentoring and teaching to really hone and instill that discipline in really being able to understand what the applications are doing. And as our team is growing, I have less and less time to even do those things, but I can go through the systems and go, “Hey, how come we're not tracing this call to the reCAPTCHA servers? Let's add that in there.” And I'll just at this point now, I mainly just write Jira tickets to have someone else actually do the work.Corey: The more I do this, the more I realize that as complicated as the technology is, the people are in many ways, far more complicated. And let's be fair here, non-deterministic things that work super well on one person one month could work entirely differently a following month, or even with the same person, or between teams. It's a constant balancing act, on some level. And giving people a sense of psychological safety has always been the biggest challenge. The thing that surprised me about management, back when I was running ops teams was the more, I guess, responsibility you accrue as you rise from individual contributor into the management—or ‘rise' is sort of a wrong term; it's an orthogonal transition—is that you spend a lot more time on the people problems, and your ability to directly control or affect change diminishes because you have to do everything via influence. You get a lot more responsibility with a lot less direct power [laugh] over the outcome in some ways. Does that align with how you see it, or am I just—do I have very strange approaches on management? Which may be true, and why I got out of it as fast as I could.Michael: No, that is a good point because you are having to [unintelligible 00:27:05], like, influence, and guide, and more take a higher-level view, as opposed to really getting into the weeds of like, “Okay, what methods are we going to put on this interface? How are we going to, say, architect the internals of an application?” Those are details I just really don't have time for anymore. But larger things as to making sure that we're okay, it's like, “What's the performance of this?” And, “Overall, is something that can be adapted as the business needs change, and as we change? And as we learn, what can we do to modify it?” And more just things like guiding, and mentoring, and really taking a higher-level view of that.Corey: I'm going to selfishly ask about something that I struggle with myself. That goes a bit more into the technical area, but you talk about enforcing consistency across all of your different services. What does that mean? Similar coding style? Similar instrumentation?Because I look at the things I built and microservices that power my internal nonsense, and each one of those is very different than all the rest. So, whatever your version of consistency is, I know I'm not doing it. But how do you view it?Michael: So, there's really two types of consistency. The one I really refer to the most is in observability. So that, if you've got a thousand Lambda functions out there, and each one is logging things slightly differently, that's just a pain to deal with, and realistically, dealing with a thousand unicorns is a real pain. So, through that observability, at least in Lambda, we use an internally developed middleware to make sure that the logging is consistent, and it's easy enough to use. And then other consistency, like, just within projects of how we lay things out.That's something that's been consistently evolving. What's the folder structure in how we organize the code? And we've kind of been evolving that over the last three years. And within about the last six months, we've come up with a really good pattern and a template for the future. And it's not much different from what we started out with, but it's a little bit easier, really, to comprehend as a new engineer coming in. It makes more sense.Corey: I have to ask—and I understand if you don't want to give a particular endorsement in any direction—but do you go through Serverless Framework, SAM CLI, the CDK, using the console and then lying about it? What is the template that you wind up using for that uniformity? Because even internally, I use three or four of those different things and professional advice: don't do that.Michael: Let's see. So, in our development, QA, production environments, infrastructure is all managed with Terraform. Each engineer has their own personal AWS account so that they can work on things there—Corey: Oh, that makes billing granularity super easy.Michael: Oh, yes. You can tell who's got EC2 instances running up for too long. But for the most part, we'll use Serverless Framework in that regard to say—for the engineer can just deploy into your local environment. Although we are working on ways to reuse the Terraform infrastructure and deploy that. But we have our own build and deployment pipeline that we built using CircleCI, and all of our Lambda functions are in Go.And so having to compile, say, 20 binaries in a service, that gets kind of slow, one of our DevOps engineers actually came up with a way to use Lambda to build the Lambdas, so that we can build them all in a distributed parallel fashion during the build process.Corey: One thing that I do love about the whole serverless approach—and it is a neat part about Lambda—is no two people ever seem to do it quite the same way. You can tie things together in so many different and exciting ways, and it's fun. It's almost like a modern version of playing with Lego. And I know that if Jeff Barr is listening, he just perked up at that. But I love the concept that you can take so many different ways to achieve similar outcomes. And it almost gives a bigger sense of creativity in how you approach problems. Has that been your experience?Michael: Oh, definitely. It's not only the creativity; it's also the flexibility in how you solve it, and the ability to adapt and evolve as services evolve, or change, or there's new ones are added. And to the point of using AWS, kind of, saying, “Oh, using a Lambda function to do this.” Like, using Lambda functions for customizing behavior of Cognito with the Cognito triggers, is to me, I think, a perfect way to customize the service to do exactly what you need to do.Corey: I want to thank you so much for taking the time to speak with me today. It's always appreciated. If people want to hear more about what you have to say and how you view these things or even, possibly, decide to work with you, okay can they find you?Michael: I'm somewhat active on LinkedIn. LinkedIn is the best place to find me. Please go ahead and connect to me; tell me you heard me on the podcast here.And yes, we are hiring. We have, all within our technical organization, from client, to web, and mobile engineers, data engineers, DevOps, API, we're always hiring and if we don't have something right now that fits your experience, let me know that you're interested and I'll put you on the list so that when we do have an opening, we'll reach out right away.Corey: And we will, of course, include links to that in the [show notes 00:32:20]. Thank you so much for being so generous with your time. I appreciate it.Michael: Thanks for having me on, Corey. It was nice talking to you.Corey: Michael Garski, Director of Platform Engineering at Fender Musical Instruments. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment telling me that I'm almost certainly doing that chord incorrectly.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
00:00:35 How Jeff got started with Amazon Web Services in the place and how innovation has been moving along briskly with Amazon AWS.00:06:15 How did it feel to promise an Internet File System and promise not to loose any data? How does AWS deal internally with failure and downtime?00:11:24 How did Amazon add so much transparency to their IT department?00:15:46 How did EC2 get so good so quickly between 2006 – 2011?00:19:35 Why Amazon AWS works without any free support for customers. Why does support cost extra?00:22:25 Where is the biggest growth and excitement with AWS right now?00:24:06 Why is traffic and core CPU so much more expensive with AWS (up to 1,000 times more).00:29:59 How does AWS Activate work and how does AWS support start-ups with free credits (up to one million dollars!)?00:41:26 What is Jeff’s prediction how the cloud will develop in the next 10 years? You may watch this episode on Youtube – Jeff Barr (The amazing story of Amazon Web Services). Jeff Barr is the Chief Evangelist for Amazon Web Services (AWS) and has been its chief promoter since 2004. Big Thanks to our Sponsors! ExpressVPN – Claim back your Internet privacy for less than $10 a month! Mighty Travels Premium – incredible airfare and hotel deals – so everyone can afford to fly Business Class and book 5 Star Hotels! Sign up for free! Divvy – get business credit without a personal guarantee and 21st century spend management plus earn 7x rewards on restaurants & more. Get started for free! Brex – get a business account, a credit card, spend management & convertible rewards for every dollar you spend. Plus now earn $250 just for signing up (Terms & Conditions apply).
About BradAuthor and Senior Executive Editor, Bloomberg TechnologyBrad Stone is the author of four books, including Amazon Unbound: Jeff Bezos and the Invention of a Global Empire,published by Simon & Schuster in May 2021. It traces the transformation of Amazon into one of the largest and most feared companies of the world and the accompanying emergence of Jeff Bezos as the richest man alive. Brad is also the author of The Everything Store: Jeff Bezos and the Age of Amazon, which chronicled the foundational early years of the company and its founder. The book, a New York Times and Wall Street Journal bestseller, was translated into more than 35 languages and won the 2013 Financial Times/Goldman Sachs Business Book of the Year Award. In 2017, he also published The Upstarts: Uber, Airbnb, and the Battle for the New Silicon Valley.Brad is Senior Executive Editor for Global Technology at Bloomberg Newswhere he oversees a team of 65 reporters and editors that covers high-tech companies, startups, cyber security and internet trends around the world. Over the last ten years, as a writer for Bloomberg Businessweek, he’s authored over two dozen cover stories on companies such as Apple, Google, Amazon, Softbank, Twitter, Facebook and the Chinese internet juggernauts Didi, Tencent and Baidu. He’s a regular contributor to Bloomberg’s technology newsletter Fully Charged, and to the daily Bloomberg TV news program, Bloomberg Technology. He was previously a San Francisco-based correspondent for The New York Times and Newsweek. A graduate of Columbia University, he is originallyfrom Cleveland, Ohio and lives in the San Francisco Bay Area with his wifeand three daughtersLinks: The Everything Store: https://www.amazon.com/Everything-Store-Jeff-Bezos-Amazon/dp/0316219282/ Amazon Unbound: https://www.amazon.com/Amazon-Unbound-Invention-Global-Empire/dp/1982132612/ Andy Jassy book review: https://www.amazon.com/gp/customer-reviews/R1Q4CQQV1ALSN0/ref=cm_cr_getr_d_rvw_ttl?ie=UTF8&ASIN=B00FJFJOLC TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It’s an awesome approach. I’ve used something similar for years. Check them out. But wait, there’s more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It’s awesome. If you don’t do something like this, you’re likely to find out that you’ve gotten breached, the hard way. Take a look at this. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That’s canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I’m a big fan of this. More from them in the coming weeks.Corey: This episode is sponsored in part by VMware. Because let’s face it, the past year hasn’t been kind to our AWS bills, or honestly any cloud bills. The pandemic had a bunch of impacts: it forced us to move workloads to the cloud sooner than we would have otherwise, we saw strange patterns such as user traffic drops off but infrastructure spend doesn’t. What do you do about it? Well, the CloudLIVE 2021 virtual conference is your chance to connect with people wrestling with the same type of thing, be they practitioners, vendors in the space, leaders of thought—ahem, ahem—and get some behind the scenes look into various ways different companies are handling this. Hosted by CloudHealth by VMware on May 20, the CloudLIVE 2021 conference will be 100% virtual and 100% free to attend, so you really have no excuses for missing out on this opportunity to deal with people who care about cloud bills. Visit cloudlive.com/coreyto learn more and save your virtual seat today. That’s cloud L-I-V-E slash Corey. C-O-R-E-Y. Drop the E, we’re all in trouble. My thanks to VMware for sponsoring this ridiculous episode.Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. Sometimes people tell me that I should write a book about Amazon. And that sounds awful. But to be sure, today, my guest is Brad Stone, someone who has written not one, but two books about Amazon, one of which coming out on May 11th, or as most of you will know while listening to this, today. Brad, thanks for joining me.Brad: Corey, thanks for having me.Corey: So, what on earth would inspire you to not just write a book about one of what is in many ways an incredibly secretive company, but then to go back and do it again?Brad: Yeah. I’m a glutton for punishment. And Corey, my hair right now is completely white way before it should be, and I think that Amazon might be responsible for some of that. So, as you contemplate your own project, consider that this company—will you already know: it can age you. They are sometimes resistant to scrutiny.So, to answer your question, I set out to write The Everything Store back in 2011, and this was a much smaller company. It was a cute little tiny internet company of about $100 billion in market value. And poor, impoverished Jeff Bezos maybe had, I’d be guessing maybe $50 billion.So anyway, it was a much different time. And that was a great experience. The company was kind of flowering as the book came out. And to my surprise, it was embraced not by Bezos or the management team, who maybe we’ll talk about didn’t love it, but by Amazon employees, and customers, and competitors, and prospective employees. And I was really proud of it that this had become a kind of definitive account of the early years of the company.And then a funny thing happened. The little cute little internet company became a juggernaut, a $1.5 trillion market cap. Bezos is the wealthiest guy in the world now with a $200 billion fortune, and Alexa, and the rise of AWS, and the Go store, and incursions into India and Mexico and other countries, I mean, so much had changed, and my definitive history felt a little out of date. And so back in 2017—also a different world, Bezos is a happily married man; he’s the CEO of Amazon, Amazon’s headquarters are in Seattle only—I set out to research and write Amazon Unbound. And as I was writing the story, yeah, just, like, the ground kept shifting under my feet.Corey: Not a lot changes in the big sphere. I mean, one of the things that Bezos said is, “Oh, what’s going to be different in 10 years? I think the better question is, ‘what’s going to not be different in 10 years?’” but watching the company shift, watching it grow, just from the outside has been a real wild ride, I’ve got to say. And I restrict myself primarily to the AWS parts because well, there’s too much to cover if you go far beyond that, and two, it’s a very different place with very different challenges around it.I viewed The Everything Store when it came out and I read that, almost like it was a biography of Jeff Bezos himself. And in some respects, Amazon Unbound feels like it hews in that direction as well, but it also goes beyond that. How do you approach separating out the story of Amazon from the story of Jeff Bezos?Brad: Yeah, you’re putting your finger on almost the core challenge, and the adjoining challenge, which is how do you create a narrative, a linear story? Often readers want a chronological story out of a miasma of overlapping events, and initiatives, and challenges. Amazon’s really decentralized; everything is happening at once. Bezos is close to some things, he was very close to Alexa. He is really distant from other things.Andy Jassy for years had a lot of independence to run AWS. So, how do you tell that story, and then keep Bezos in the center? I mean, Andy Jassy and Jeff Wilke and everyone, I mean, those are great business people. Not necessarily dynamic personalities as, Corey, you know well, but people want to read about Jeff Bezos. He is a larger-than-life figure.He’s a pioneer. He’s an innovator. He’s controversial. And so the challenge all along is to, kind of, keep him in the center. And so that’s just, like, a writing challenge. It’s a narrative challenge.And the lucky thing is that Amazon does tend to orbit around Jeff Bezos’s brain. And so in all the storytelling, even the AWS bits of the book, which we can talk about, as an author, you can always bring Bezos back just by following the facts. You’ll eventually get, in the evolution of any story, to an S Team meeting, or to an acquisition discussion where Jeff had an impact, said something insightful, walked out of a meeting, raise the bar, had impossibly high standards. So, the last thing I’ll say is, because Amazon’s so decentralized, when you write these books you have to talk to a lot of people. And then you get all the pieces of the puzzle, and you start to assemble them, and the challenge as a writer is to, kind of, keep Bezos, your main character in the lens at all times, never let him drift too far out.Corey: One of the things that I learned from it was just the way that Bezos apparently talks to his senior executives, as far as, “I will invest in this project, more than you might think I would.” I guess I’ve never really heard of a budget meeting talking about, “I”—in the first person—“Will invest.” Like, that is what happens, but for some reason the business books never put it quite that starkly or frame it quite that way. But in hindsight, it made a lot of things of my own understanding of Amazon fall into place. That makes sense.Brad: He’s got a lot of levers, ways in which he’ll back a new initiative or express his support. And one of them is simply how he spends his time. So, with Alexa in the early years, he would meet once or twice a week with that team. But another lever is just the amount of investment. And oftentimes teams will come to him—the India team is a great example—they’ll come to the S Team with a budget, and they’ll list out their priorities and their goals for the coming year, and he’ll say, “You know, you’re thinking about this all wrong. Don’t constrain yourself. Tell us what the goals are, tell us what the opportunity is, then we’ll figure out how much it costs.”And his mindset is like you can kind of break up opportunity into two categories: one are the land grabs, the big immediate opportunities where he will go all out, and India was a great example of that, I think the failed fire phone was another example, Prime Video, he doesn’t cap the investment, he wants to win. And then there are the more greenfield opportunities that he thinks he can go slower on and groceries for a long time was in that category. And there the budgets might be more constrained. The other example is the much older businesses, just like the retail business. That’s 20 years old—I have a chapter about that—and the advertising business, and he recognized that the retail business wasn’t profitable and it was depending on advertising as a crutch, and he blew it up because he thinks that those older divisions shouldn’t require investment; they should be able to stand on their own.Corey: One quote you had as well, that just really resonated with me, as far as basically my entire ethos of how I make fun of Amazon is—and I’m going to read the excerpt here. My apologies. You have to listen to your own words being read back toward you—Brad: [laugh].Corey: These were typically Amazonian names: geeky, obscure, and endlessly debated inside AWS since—according to an early AWS exec—Bezos had once mused, “You know, the name is about 3% of what matters, but sometimes 3% is the difference between winning and losing.” And I just want to call that out because I don’t think I’ve ever seen an AWS exec ever admit that names might be even 3% worth of important. Looking at how terrible some of their service names are, I would say that 3% might be an aspirational target for their worldview.Brad: [laugh]. Let me throw this back at you, Corey. Have you ever figured out why certain AWS services are Amazon and why others are AWS?Corey: I did. I got to sit down—in the before times—with then the VP of Global Marketing, Ariel Kelman—who’s now Oracle’s Chief Marketing Officer—and Jeff Barr. And the direction that they took that in was that if you could use an AWS service without getting into the AWS weeds of a bunch of other services, then it was called Amazon whatever. Amazon S3, for example, as a primitive service doesn’t need a bunch of other AWS services hooked into it, so that gets the Amazon moniker. Whereas if you’re dealing with a service that requires the integration of a whole bunch of AWS in the weeds stuff—Brad: Mmm, right.Corey: —then it’s AWS. For example, AWS Systems Manager is useless without a whole bunch of other Amazon services. And they say they don’t get it perfectly right all the time, but that is the direction that it’s gone in. And for better or worse, I still have to look a lot of them up myself because I don’t care nearly as much as their branding people do.Brad: Right. Well, I’ll tell you in the chapter about AWS, that quote comes up when the team is contemplating the names of the databases. And they do go into long debates, and I remember talking to Charlie Bell about the search for Redshift, and they go back and forth on it, and the funny thing about that one was, of course, Oracle interpreted it as a competitive slight. Its corporate color, I guess, being red, which he intended it more as a physics term. But yeah, when they were launching Aurora and Redshift, they contemplated those names quite a bit. And I don’t know if it’s 3%. I don’t know if it does matter, but certainly, those services have become really important to a lot of businesses.Corey: Oh, yeah. And once you name something, it’s really hard to rename it. And AWS does view for—better or worse—APIs as a promise, so when you build something and presented a certain way, they’re never going to turn it off. Our grandkids are going to have to deal with some of these decisions once they get into computers. That’s a problem.And I understand the ethos behind it, but again, it’s easy to make fun of names; it’s an accessible thing because let’s be very real here, a lot of what AWS does is incredibly inaccessible to people who don’t live in this space. But naming is something that everyone can get behind making fun of.Brad: Absolutely. Yep. And [laugh] it’s perhaps why they spend a lot of time on it because they know that this is going to be the shingle that they hang out to the world. I don’t know that they’re anticipating your ridicule, but it’s obviously key to the marketing process for them.Corey: Some of the more aware ones do. But that’s a different topic for a different time. One question I have for you that I wrestle with myself is I’ve been spending the last four years or so basically studying AWS all the time. And there’s a lot of things they get right; there’s a lot of things that they get wrong. But for better or worse, it’s very difficult not to come away from an in-depth study with an appreciation for an awful lot of the things that they do. At least for me.I’m not saying that I fall in love with the company and will excuse them their wrongs; I absolutely do not do that. But it is hard, bordering on impossible for me, to not come away with a deep respect for a lot of the things that they do and clearly believe. How do you feel about that? Looking at Amazon, do you come away with this with, “Ooh. Remind me to never to become a Prime member and get rid of everything with an Amazon logo in my house,” versus the you’re about to wind up wondering if they can hire you for some esoteric role? Where do you fall on that spectrum?Brad: I think I’m probably with you. I come away with an admiration. And look, I mean, let me say upfront, I am a Prime member. I have a Alexas in my home, probably more than my wife and kids are comfortable with. We watch Prime Video, we have Prime Video.We order from Amazon all the time, we ordered from Whole Foods. I’m an Amazon customer, and so part of my appreciation comes from, like all other customers, the fact that Amazon uniquely restores time to our lives rather than extracts it. I wouldn’t say that about the social networks, right? You know, those can be time-wasters. Amazon’s a great efficiency machine.But in terms of my journalism, you know, now two books and this big in-depth study in Amazon Unbound, and you have to admire what they have built. I mean, a historic American institution that has not only changed our economic reality, in ways good and bad but over the last year and a half, in the pandemic was among the few institutions that functioned properly and served as a kind of lifeline. And there is a critique in Amazon Unbound and we can talk about it, but it’s hard to come away—I think you said it well—it’s hard to come away after studying this company and studying the top executives, and how Jeff Bezos, thinks and how he has conceived products without real admiration for what they have built over the last 25 years.Corey: Well, let’s get into your critique of Amazon. What do you think is, from what you’ve seen with all of the years of research you put into this company, what’s the worst thing about them?Brad: Well, that’s a good way to put it, Corey. [laugh]. Let me—Corey: [laugh]. It’s like, talk about a target-rich opportunity. Like, “Oh, wow. It’s like my children. I can’t stand any of them. How in the world could I pick just one?” But give it a shot.Brad: Right. Well, let me start this way, which is I often will listen to their critiques from Amazon critics—and I’m sure you might feel this way as well—and just think, like, “Do they get it?” They’ll argue that Amazon exercised its size and might to buy the companies that led to Alexa. As I write in the Alexa chapter, that’s not true at all. They bought a couple of small companies, and those executives were all horrified at what Amazon was trying to do, and then they made it work.Or the critics will say, “Fifty percent or more of internet users start their product searches on Amazon. Amazon has lock-in.” That’s not true either. Lock-in on the internet is only as strong as a browser window that remains open. And you could always go find a competitor or search on a search engine.So, I find at least some of the public criticism to be a little specious. And often, these are people that complained about Walmart for ten years. And now Amazon’s the big, bad boogeyman.Corey: Oh, I still know people who refuse to do business with Walmart but buy a bunch of stuff from Amazon, and I’m looking at these things going, any complaints you have about Walmart are very difficult to avoid mapping to Amazon.Brad: Here’s maybe the distillation of the critique that’s an Amazon Unbound. We make fun of Facebook for, “Move fast and break things.” And they broke things, including, potentially, our democracy. When you look at the creation of the Amazon Marketplace, Jeff wanted a leader who can answer the question, “How would you bring a million sellers into the Amazon Marketplace?” And what that tells you is he wanted to create a system, a self-service system, where you could funnel sellers the world over into the system and sell immediately.And that happened, and a lot of those sellers, there was no friction, and many of them came from the Wild West of Chinese eCommerce. And you had—inevitably because there were no guardrails—you had fraud and counterfeit, and all sorts of lawsuits and damage. Amazon moved fast and broke things. And then subsequently tried to clean it up. And if you look at the emergence of the Amazon supply chain and the logistics division, the vans that now crawl our streets, or the semi-trailers on our highways, or the planes.Amazon moved fast there, too. And the first innings of that game were all about hiring contractors, not employees, getting them on the road with a minimum of guidance. And people died. There were accidents. You know, there weren’t just drivers flinging packages into our front yards, or going to the bathroom on somebody’s porch.That happened, but there were also accidents and costs. And so I think some of the critique is that Amazon, despite its profession that it focuses only on customers, is also very competitor-aware and competitor-driven, and they move fast, often to kind of get ahead of competitors, and they build the systems and they’re often self-service systems, and they avoid employment where it’s possible, and the result have been costs to society, the cost of moving quickly. And then on the back-end when there are lawsuits, Amazon attempts to either evade responsibility or settle cases, and then hide those from the public. And I think that is at the heart of what I show in a couple of ways in Amazon Unbound. And it’s not just Amazon; it’s very typical right now of corporate America and particularly tech companies.And part of it is the state of the laws and regulations that allow the companies to get away with it, and really restrict the rights of plaintiffs, of people who are wronged from extracting significant penalties from these companies and really changing their behavior.Corey: Which makes perfect sense. I have the luxury of not having to think about that by having a mental division and hopefully one day a real division between AWS and Amazon’s retail arm. For me at least, the thing I always had an issue with was their treatment of staff in many respects. It is well known that in the FAANG constellation of tech companies, Facebook, Amazon, Apple, Netflix, and Google, apparently, it’s an acronym and it’s cutesy. People in tech think they’re funny.But the problem is that Amazon’s compensation is significantly below that. One thing I loved in your book was that you do a breakdown of how those base salaries work, how most of it is stock-based and with a back-loaded vesting and the rest, and looking through the somewhat lengthy excerpt—but I will not read your own words to you this time—it more or less completely confirms what I said in my exposé of this, which means if we’re wrong, we’re both wrong. And we’ve—and people have been very convincing and very unified across the board. We’re clearly not wrong. It’s nice to at least get external confirmation of some of the things that I stumble over.Brad: But I think this is all part of the same thing. What I described as the move fast and break things mentality, often in a race with competition, and your issues about the quality, the tenor of work, and the compensation schemes, I think maybe and this might have been a more elegant answer to your question, we can wrap it all up under the mantle of empathy. And I think it probably starts with the founder and soon-to-be-former CEO. And look, I mean, an epic business figure, a builder, an inventor, but when you lay out the hierarchy of qualities, and attributes, and strengths, maybe empathy with the plight of others wasn’t near the top. And when it comes to the treatment of the workforce, and the white-collar employees, and the compensation schemes, and how they’re very specifically designed to make people uncomfortable, to keep them running fast, to churn them out if they don’t cut it, and the same thing in the workforce, and then the big-scale systems and marketplace and logistics—look, maybe empathy is a drag, and not having it can be a business accelerant, and I think that’s what we’re talking about, right?That some of these systems seem a little inhumane, and maybe to their credit, when Amazon recognizes that—or when Jeff has recognized it00, he’s course-corrected a little bit. But I think it’s all part of that same bundle. And maybe perversely, it’s one of the reasons why Amazon has succeeded so much.Corey: I think that it’s hard to argue against the idea of culture flowing from the top. And every anecdote I’ve ever heard about Jeff Bezos, never having met the man myself, is always filtered through someone else; in many cases, you. But there are a lot of anecdotes from folks inside Amazon, folks outside Amazon, et cetera, and I think that no one could make a serious argument that he is not fearsomely intelligent, penetratingly insightful, and profoundly gifted in a whole bunch of different ways. People like to say, “Well, he started Amazon with several $100,000 and loan from his parents, so he’s not really in any ways a self-made anything.” Well, no one is self-made. Let’s be very clear on that.But getting a few $100,000 to invest in a business, especially these days, is not that high of a stumbling block for an awful lot of folks similarly situated. He has had outsized success based upon where he started and where he wound up ending now. But not a single story that I’ve ever heard about him makes me think, yeah, that’s the kind of guy I want to be friends with. That’s the kind of guy I want to invite to a backyard barbecue and hang out with, and trade stories about our respective kids, and just basically have a social conversation with. Even a business conversation doesn’t feel like it would be particularly warm or compelling.It would be educational, don’t get me wrong, but he doesn’t strike me as someone who really understands empathy in any meaningful sense. I’m sure he has those aspects to him. I’m sure he has a warm, wonderful relationship with his kids, presumably because they still speak to him, but none of that ever leaks through into his public or corporate persona.Brad: Mmm, partially agree, partially disagree. I mean, certainly maybe the warmth you’re right on, but this is someone who’s incredibly charismatic, who is incredibly smart, who thinks really deeply about the future, and has intense personal opinions about current events. And getting a beer with him—which I have not done—with sound fantastic. Kicking back at the fireplace at his ranch in Texas, [laugh] to me, I’m sure it’s tremendously entertaining to talk to him. But when it comes to folks like us, Corey, I have a feeling it’s not going to happen, whether you want to or not.He’s also incredibly guarded around the jackals of the media, so perhaps it doesn’t make a difference one way or another. But, yeah, you’re right. I mean, he’s all business at work. And it is interesting that the turnover in the executive ranks, even among the veterans right now, is pretty high. And I don’t know, I mean, I think Amazon goes through people in a way, maybe a little less on the AWS side. You would know that better than me. But—Corey: Yes and no. There’s been some turnover there that you can also pretty easily write down to internal political drama—for lack of a better term—palace intrigue. For lack of a better term. When, for example, Adam Selipsky is going to be the new CEO of AWS as Andy Jesse ascends to be the CEO of all Amazon—the everything CEO as it were. And that has absolutely got to have rubbed some people in unpleasant ways.Let’s be realistic here about what this shows: he quit AWS to go be the CEO of Tableau, and now he’s coming back to run AWS. Clearly, the way to get ahead there is to quit. And that might not be the message they’re intending to send, but that’s something that people can look at and take away, that leaving a company doesn’t mean you can’t boomerang and go back there at a higher level in the future.Brad: Right.Corey: And that might be what people are waking up to because it used to be a culture of once you’re out, you’re out. Clearly not the case anymore. They were passed over for a promotion they wanted, “Well, okay, I’m going to go talk to another company. Oh, my God, they’re paying people in yachts.” And it becomes, at some level, time for something new.I don’t begrudge people who decide to stay; I don’t begrudge people who decide to leave, but one of my big thrusts for a long time has been understand the trade-offs of either one of those decisions and what the other side looks like so you go into it with your eyes open. And I feel like, on some level, a lot of folks there didn’t necessarily feel that they could have their eyes open in the way that they can now.Brad: Mm-hm. Interesting. Yeah. Selipsky coming back, I never thought about that, sends a strong message. And Amazon wants builders, and operators, and entrepreneurial thinking at the top and in the S Team. And the fact that Andy had a experienced leadership team at AWS and then went outside it for the CEO could be interpreted as pretty demotivating for that team. Now, they’ve all worked with Adam before, and I’ve met him and he seems like a great guy so maybe there are no hard feelings, but—Corey: I never have. He left a few months before I started this place. So, it—I get the sense that he knew I was coming and said, “Well, better get out of here. This isn’t going to go well at all.”Brad: [laugh]. I actually went to interview him for this book, and I sat in his office at Tableau thinking, “Okay, here’s a former AWS guy,” and I got to tell you, he was really on script and didn’t say anything bad, and I thought, “Okay, well, that wasn’t the best use of my time.” He was great to meet, and it was an interesting conversation, but the goss he did not deliver. And so when I saw that he got this job, I thought, well, he’s smart. He smartly didn’t burn any bridges, at least with me.Corey: This episode is sponsored in part by our friends at ChaosSearch., you could run Elasticsearch or Elastic Cloud—or OpenSearch as they’re calling it now—or a self-hosted ELK stack. But why? ChaosSearch gives you the same API you’ve come to know and tolerate, along with unlimited data retention and no data movement. Just throw your data into S3 and proceed from there as you would expect. This is great for IT operations folks, for app performance monitoring, cybersecurity. If you’re using Elasticsearch, consider not running Elasticsearch. They’re also available now in the AWS marketplace if you’d prefer not to go direct and have half of whatever you pay them count towards your EDB commitment. Discover what companies like HubSpot, Klarna, Equifax, Armor Security, and Blackboard already have. To learn more, visit chaossearch.io and tell them I sent you just so you can see them facepalm, yet again.Corey: No. And it’s pretty clear that you don’t get to rise to those levels without being incredibly disciplined with respect to message. I don’t pity Andy Jesse’s new job wherein a key portion of the job description is going to be testifying before Congress. Without going into details, I’ve been in situations where I’ve gotten to ask him questions before in a real-time Q&A environment, and my real question hidden behind the question was, “How long can I knock him off of his prepared talking points?” Because I—Brad: Good luck. [laugh].Corey: Yeah. I got the answer: about two and a half seconds, which honestly was a little bit longer than I thought I would get. But yeah, incredibly disciplined and incredibly insightful, penetrating answers, but they always go right back to talking points. And that’s what you have to do at that level. I’ve heard stories—it may have been from your book—that Andy and Adam were both still friendly after Adam’s departure, they would still hang out socially and clearly, relationships are still being maintained, if oh, by the way, you’re going to be my successor. It’s kind of neat. I’m curious to see how this plays out once that transition goes into effect.Brad: Yeah, it’ll be interesting. And then also, Andy’s grand homecoming to the other parts of the business. He started in the retail organization. He was Jeff’s shadow. He ran the marketing department at very early Amazon.He’s been in all those meetings over the years, but he’s also been very focused on AWS. So, I would imagine there’s a learning curve as he gets back into the details of the other 75% of Amazon.Corey: It turns out that part of the business has likely changed in the last 15 years, just a smidgen when every person you knew over there is now 10,000 people. There was an anecdote in your book that early on in those days, Andy Jesse was almost let go as part of a layoff or a restructuring, and Jeff Bezos personally saved his job. How solid is that?Brad: Oh, that is solid. An S Team member told me that, who was Andy’s boss at the time. And the story was, in the late 90s—I hope I remember this right—there was a purge of the marketing department. Jeff always thought that marketing—in the early days marketing was purely satisfying customers, so why do we need all these people? And there was a purge of the marketing department back when Amazon was trying to right-size the ship and get profitable and survive the dotcom bust.And Jeff intervened in the layoffs and said, “Not Andy. He’s one of the most—yeah, highest ceiling folks we have.” And he made him his first full-time shadow. Oh, and that comes right from an S Team member. I won’t say the name because I can’t remember if that was on or off the record.But yeah, it was super interesting. You know what? I’ve always wondered how good of a identifier of talent and character is Bezos. And he has some weaknesses there. I mean, obviously, in his personal life, he certainly didn’t identify Lauren Sánchez’s brother as the threat that he became.You know, I tell the story in the book of the horrific story of the CEO of Amazon Mexico, who Jeff interviewed, and they hired and then later ended up what appears to be hiring an assassin to kill his wife. I tell the story in the book. It’s a horrible story. So, not to lay that at the feet of Jeff Bezos, of course, but he often I think, moves quickly. And I actually have a quote from a friend of his in the book saying, “It’s better to not be kind of paranoid, and the”—sort of—I can’t remember what the quote is.It’s to trust people rather than be paranoid about everyone. And if you trust someone wrongly, then you of course-correct. With Andy, though, he somehow had an intuitive sense that this guy was very high potential, and that’s pretty impressive.Corey: You’re never going to bet a thousand. There’s always going to be people that slip through the cracks. But learning who these people are and getting different angles on them is always interesting. Every once in a while—and maybe I’m completely wrong on this, but never having spent time one on one with Andy Jassy, I have to rely on other folks and different anecdotes, most of them, I can’t disclose the source of, but every time that I wind up hearing about these stories, and maybe I’m projecting here, but there are aspects of him where it seems like there is a genuinely nice person in there who is worried, on some level, that people are going to find out that he’s a nice person.Brad: [laugh]. I think he is. He’s extraordinarily nice. He seems like a regular guy, and what’s sort of impressive is that obviously he’s extraordinarily wealthy now, and unlike, let’s say Bezos, who’s obviously much more wealthy, but who, who really has leaned into that lifestyle, my sense is Andy does not. He’s still—I don’t know if he’s on the corporate jet yet, but at least until recently he wasn’t, and he presents humbly. I don’t know if he’s still getting as close from wherever, [unintelligible 00:32:50] or Nordstroms.Corey: He might be, but it is clear that he’s having them tailored because fit is something—I spent a lot of time in better years focusing on sartorial attention, and wherever he’s sourcing them from aside, they fit well.Brad: Okay, well, they didn’t always. Right?Corey: No. He’s, he’s… there’s been a lot of changes over the past decade. He is either discovered a hidden wellspring of being one of the best naturally talented speakers on the planet, or he’s gone through some coaching to improve in those areas. Not that he was bad at the start, but now he’s compelling.Brad: Okay. Well, now we’re talking about his clothes and his speaking style. But—Corey: Let’s be very honest here. If he were a woman, we would have been talking about that as the beginning topic of this. It’s on some level—Brad: Or we wouldn’t have because we’d know it’s improper these days.Corey: We would like to hope. But I am absolutely willing to turn it back around.Brad: [laugh]. Anyway.Corey: So, I’m curious, going back a little bit to criticisms here, Amazon has been criticized roundly by regulators and Congress and the rest—folks on both sides of the aisle—for a variety of things. What do you see is being the fair criticisms versus the unfair criticisms?Brad: Well, I mean, I think we covered some of the unfair ones. But there’s one criticism that Amazon uses AWS to subsidize other parts of the business. I don’t know how you feel about that, but until recently at least, my reading of the balance sheet was that the enormous profits of AWS were primarily going to buy more AWS. They were investing in capital assets and building more data centers.Corey: Via a series of capital leases because cash flow is king in how they drive those things there. Oh, yeah.Brad: Right. Yeah. You know, and I illustrate in the book how when it did become apparent that retail was leaning on advertising, Jeff didn’t accept that. He wanted retail to stand on its own, and it led to some layoffs and fiercer negotiations with brands, higher fees for sellers. Advertising is the free cash flow that goes in Prime movies, and TV shows, and Alexa, and stuff we probably don’t know about.So, this idea that Amazon is sort of improperly funneling money between the divisions to undercut competitors on price, I think we could put that in the unfair bucket. In the fair bucket, those are the things that we can all look at and just go, “Okay, that feels a little wrong.” So, for an example, the private brand strategy. Now, of course, every supermarket and drugstore is going to line their shelves with store brands. But when you go to an Amazon search results page these days, and they are pockmarked with Amazon brands, and Whole Foods brands, and then sponsored listings, the pay-to-play highest bidder wins.And then we now know that, at least for a couple of years, Amazon managers, private label managers were kind of peeking at the third-party data to figure out what was selling and what they should introduce is a private Amazon brand. It just feels a little creepy that Amazon as the everything store is so different than your normal Costco or your drugstore. The shelves are endless; Amazon has the data, access to the data, and the way that they’re parlaying their valuable real estate and the data at their disposal to figure out what to launch, it just feels a little wrong. And it’s a small part of their business, but I think it’s one where they’re vulnerable. The other thing is, in the book, I tried to figure out how can I take the gauge of third-party sellers?There’s so many disgruntled voices, but do they really speak for everyone? And so instead of going to the enemies, I went to every third-party seller that had been mentioned in Jeff Bezos’s shareholder letters over the past decade. And these were the allies. These were the success stories that Bezos was touting in his sacrosanct investor letter, and almost to a one, they had all become disgruntled. And so the way in which the rules of the marketplace change, the way that the fees go up, and the difficulty that sellers often have in getting a person or a guiding hand at Amazon to help them with those changes, that kind of feels wrong.And I think that maybe that’s not a source of regulation, but it could be a source of disruptive competition. If somebody can figure out how to create a marketplace that caters to sellers a little better with lower fees, then they could do to Amazon with Amazon years ago did to eBay. And considering that Marketplace is now a preponderance of sales more than even retail on amazon.com, that can end up hurting the company.Corey: Yeah, at some point, you need to continue growing things, and you’ve run out of genuinely helpful ways, and in turn in start to have to modify customer behavior in order to continue doing things, or expand into brand new markets. We saw the AWS bleeding over into Alexa as an example of that. And I think there’s a lot of interesting things still to come in spaces like that. It’s interesting watching how the Alexa ecosystem has evolved. There’s still some very basic usability bugs that drive me nuts, but at the same token, it’s not something that I think we’re going to see radically changing the world the next five years. It feels like a hobby, but also a lucrative one, and keeps people continuing to feed into the Amazon ecosystem. Do you see that playing out differently?Brad: Wait, with Alexa?Brad: Absolutely.Brad: Yeah. I agree with you. I mean, it feels like there was more promise in the early years, and that maybe they’ve hit a little bit of a wall in terms of the AI and the natural language understanding. It feels like the ecosystem that they tried to build, the app store-like ecosystem of third-party skills makers, that hasn’t crystallized in the way we hoped—in the way they hoped. And then some of these new devices like the glasses or the wristband that have Alexa feel, just, strange, right?Like, I’m not putting Alexa on my face. And those haven’t done as well. And so yeah, I think they pioneered a category: Alexa plays music and answers basic queries really well, and yet it hasn’t quite been conversational in the way that I think Jeff Bezos had hoped in the early days. I don’t know if it’s a profitable business now. I mean, they make a lot of money on the hardware, but the team is huge.I think it was, like, 10,000 people the last I checked. And the R&D costs are quite large. And they’re continuing to try to improve the AI, so I think Jeff Bezos talks about the seeds, and then the main businesses, and I don’t think Alexa has graduated yet. I think there’s still a little bit of a question mark.Corey: It’s one of those things that we remain to see. One last thing that I wanted to highlight and thank you for, was that when you wrote the original book, The Everything Store, Andy Jassy wrote a one-star review. It went into some depth about all the things that, from his perspective, you got wrong, were unfair about, et cetera.And that can be played off as a lot of different things, but you can almost set that aside for a minute and look at it as the really only time in recent memory that Andy Jassy has sat down and written something, clearly himself, and then posted it publicly. He writes a lot—Amazon has a writing culture—but they don’t sign their six-pagers. It’s very difficult to figure out where one person starts and one person stops. This shows that he is a gifted writer in many respects, and I don’t think we have another writing sample from him to compare it to.Brad: So, Corey, you’re saying I should be honored by his one-star review of The Everything Store?Corey: Oh, absolutely.Brad: [laugh].Corey: He, he just ignores me. You actually got a response.Brad: I got a response. Well.Corey: And we’ll put a link to that review in the [show notes 00:40:10] because of course we will.Brad: Yes, thank you. Do you—remember, other Amazon executives also left one-star reviews. And Jeff’s wife, and now ex-wife Mackenzie left a one-star review. And it was a part of a, I think a little bit of a reflexive reaction and campaign that Jeff himself orchestrated at my—this was understanding now, in retrospect. After the book came out, he didn’t like it.He didn’t like aspects of his family life that were represented in the book, and he asked members of the S Team to leave bad reviews. And not all of them did, and Andy did. So, you wonder why he’s CEO now. No, I’m kidding about that. But you know what?It ended up, kind of perversely, even though that was uncomfortable in the moment, ended up being good for the first book. And I’ve seen Andy subsequently, and no hard feelings. I don’t quite remember what his review said. Didn’t it, strangely, like, quote a movie or something like that?Corey: I recall that it did. It went in a bunch of different directions, and at the end—it ended with, “Well, maybe someday he’ll write the actual story. And I’m not trying to bait anyone into doing it, but this book isn’t it.” Well, in the absence of factual corrections, that’s what we go with. That is also a very Amazonian thing. They don’t tell their own story, but they’re super quick to correct the record—Brad: Yeah.Corey: —after someone says a thing.Brad: But I don’t recall him making many specific claims of anything I got wrong. But why don’t we hope that there’s a sequel review for Amazon Unbound? I will look forward to that from Andy.Corey: I absolutely hope so. It’s one of those things that we just really, I guess, hope goes in a positive direction. Now, I will say I don’t try to do any reviews that are all positive. And that’s true. There’s one thing that you wrote that I vehemently disagree with.Brad: Okay, let’s hear it.Corey: Former Distinguished Engineer and VP at AWS, Tim Bray, who resigned on conscientious objector grounds, more or less, has been a guest on the show, and I have to say, you did him dirty. You described him—Brad: How did I—what did I do? Mm-hm.Corey: Oh, I quote, “Bray, a fedora-wearing software developer”—which is true, but still is evocative in an unpleasant way—“And one of the creators of the influential web programming language, XML”—which is true, but talk about bringing up someone’s demons to haunt them. Oh, my starts.Brad: [laugh]. But wait. How is the fedora-wearing pejorative?Corey: Oh, it has a whole implication series of, and entire subculture of the gamer types, people who are misogynist, et cetera. It winds up being an unfair characterization—Brad: But he does wear a fedora.Corey: He does. And he can pull it off. He has also mentioned that he is well into retirement age, and it was a different era when he wore one. But that’s not something that people often will associate with him. It’s—Brad: I’m so naive. You’re referring to things that I do not understand what the implication was that I made. But—Corey: Oh, spend more time with the children of Reddit. You’ll catch on quickly.Brad: [laugh]. I try, I try not to do that. But thank you, Corey.Corey: Of course. So, thank you so much for taking the time to go through what you’ve written. I’m looking forward to seeing the reaction once the book is published widely. Where can people buy it? There’s an easy answer, of course, of Amazon itself, but is there somewhere you would prefer them to shop?Brad: Well, everyone can make their own decisions. I flattered if anyone decides to pick up the book. But of course, there is always their independent bookstore. On sale now.Corey: Excellent. And we will, of course, throw a link to the book in the [show notes 00:43:31]. Brad, thank you so much for taking the time to speak with me. I really appreciate it.Brad: Corey, it’s been a pleasure. Thank you.Corey: Brad Stone, author of Amazon Unbound: Jeff Bezos and the Invention of a Global Empire, on sale now wherever fine books are sold—and crappy ones, too. I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice and then a multi-paragraph, very long screed telling me exactly what I got wrong.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.
About Rebecca MarshburnRebecca's interested in the things that interest people—What's important to them? Why? And when did they first discover it to be so? She's also interested in sharing stories, elevating others' experiences, exploring the intersection of physical environments and human behavior, and crafting the perfect pun for every situation. Today, Rebecca is the Head of Content & Community at Common Room. Prior to Common Room, she led the AWS Serverless Heroes program, where she met the singular Jeremy Daly, and guided content and product experiences for fashion magazines, online blogs, AR/VR companies, education companies, and a little travel outfit called Airbnb.Twitter: @beccaodelayLinkedIn: Rebecca MarshburnCompany: www.commonroom.ioPersonal work (all proceeds go to the charity of the buyer's choice): www.letterstomyexlovers.comWatch this episode on YouTube: https://youtu.be/VVEtxgh6GKI This episode sponsored by CBT Nuggets and Lumigo.Transcript:Rebecca: What a day today is! It's not every day you turn 100 times old, and on this day we celebrate Serverless Chats 100th episode with the most special of guests. The gentleman whose voice you usually hear on this end of the microphone, doing the asking, but today he's going to be doing the telling, the one and only, Jeremy Daly, and me. I'm Rebecca Marshburn, and your guest host for Serverless Chats 100th episode, because it's quite difficult to interview yourself. Hey Jeremy!Jeremy: Hey Rebecca, thank you very much for doing this.Rebecca: Oh my gosh. I am super excited to be here, couldn't be more honored. I'll give your listeners, our listeners, today, the special day, a little bit of background about us. Jeremy and I met through the AWS Serverless Heroes program, where I used to be a coordinator for quite some time. We support each other in content, conferences, product requests, road mapping, community-building, and most importantly, I think we've supported each other in spirit, and now I'm the head of content and community at Common Room, and Jeremy's leading Serverless Cloud at Serverless, Inc., so it's even sweeter that we're back together to celebrate this Serverless Chats milestone with you all, the most important, important, important, important part of the podcast equation, the serverless community. So without further ado, let's begin.Jeremy: All right, hit me up with whatever questions you have. I'm here to answer anything.Rebecca: Jeremy, I'm going to ask you a few heavy hitters, so I hope you're ready.Jeremy: I'm ready to go.Rebecca: And the first one's going to ask you to step way, way, way, way, way back into your time machine, so if you've got the proper attire on, let's do it. If we're going to step into that time machine, let's peel the layers, before serverless, before containers, before cloud even, what is the origin story of Jeremy Daly, the man who usually asks the questions.Jeremy: That's tough. I don't think time machines go back that far, but it's funny, when I was in high school, I was involved with music, and plays, and all kinds of things like that. I was a very creative person. I loved creating things, that was one of the biggest sort of things, and whether it was music or whatever and I did a lot of work with video actually, back in the day. I was always volunteering at the local public access station. And when I graduated from high school, I had no idea what I wanted to do. I had used computers at the computer lab at the high school. I mean, this is going back a ways, so it wasn't everyone had their own computer in their house, but I went to college and then, my first, my freshman year in college, I ended up, there's a suite-mate that I had who showed me a website that he built on the university servers.And I saw that and I was immediately like, "Whoa, how do you do that"? Right, just this idea of creating something new and being able to build that out was super exciting to me, so I spent the next couple of weeks figuring out how to do HTML, and this was before, this was like when JavaScript was super, super early and we're talking like 1997, and everything was super early. I was using this, I eventually moved away from using FrontPage and started using this thing called HotDog. It was a software for HTML coding, but I started doing that, and I started building websites, and then after a while, I started figuring out what things like CGI-bins were, and how you could write Perl scripts, and how you could make interactions happen, and how you could capture FormData and serve up different things, and it was a lot of copying and pasting.My major at the time, I think was psychology, because it was like a default thing that I could do. But then I moved into computer science. I did computer science for about a year, and I felt that that was a little bit too narrow for what I was hoping to sort of do. I was starting to become more entrepreneurial. I had started selling websites to people. I had gone to a couple of local businesses and started building websites, so I actually expanded that and ended up doing sort of a major that straddled computer science and management, like business administration. So I ended up graduating with a degree in e-commerce and internet marketing, which is sort of very early, like before any of this stuff seemed to even exist. And then from there, I started a web development company, worked on that for 12 years, and then I ended up selling that off. Did a startup, failed the startup. Then from that startup, went to another startup, worked there for a couple of years, went to another startup, did a lot of consulting in between there, somewhere along the way I found serverless and AWS Cloud, and then now it's sort of led me to advocacy for building things with serverless and now I'm building sort of the, I think what I've been dreaming about building for the last several years in what I'm doing now at Serverless, Inc.Rebecca: Wow. All right. So this love story started in the 90s.Jeremy: The 90s, right.Rebecca: That's an incredible, era and welcome to 2021.Jeremy: Right. It's been a journey.Rebecca: Yeah, truly, that's literally a new millennium. So in a broad way of saying it, you've seen it all. You've started from the very HotDog of the world, to today, which is an incredible name, I'm going to have to look them up later. So then you said serverless came along somewhere in there, but let's go to the middle of your story here, so before Serverless Chats, before its predecessor, which is your weekly Off-by-none newsletter, and before, this is my favorite one, debates around, what the suffix "less" means when appended to server. When did you first hear about Serverless in that moment, or perhaps you don't remember the exact minute, but I do really want to know what struck you about it? What stood out about serverless rather than any of the other types of technologies that you could have been struck by and been having a podcast around?Jeremy: Right. And I think I gave you maybe too much of a surface level of what I've seen, because I talked mostly about software, but if we go back, I mean, hardware was one of those things where hardware, and installing software, and running servers, and doing networking, and all those sort of things, those were part of my early career as well. When I was running my web development company, we started by hosting on some hosting service somewhere, and then we ended up getting a dedicated server, and then we outgrew that, and then we ended up saying, "Well maybe we'll bring stuff in-house". So we did on-prem for quite some time, where we had our own servers in the T1 line, and then we moved to another building that had a T3 line, and if anybody doesn't know what that is, you probably don't need to anymore.But those are the things that we were doing, and then eventually we moved into a co-location facility where we rented space, and we rented electricity, and we rented all the utilities, the bandwidth, and so forth, but we had Blade servers and I was running VMware, and we were doing all this kind of stuff to manage the infrastructure, and then writing software on top of that, so it was a lot of work. I know I posted something on Twitter a few weeks ago, about how, when I was, when we were young, we used to have to carry a server on our back, uphill, both ways, to the data center, in the snow, with no shoes, and that's kind of how it felt, that you were doing a lot of these things.And then 2008, 2009, as I was kind of wrapping up my web development company, we were just in the process of actually saying it's too expensive at the colo. I think we were paying probably between like $5,000 and $7,000 a month between the ... we had leases on some of the servers, you're paying for electricity, you're paying for all these other things, and we were running a fair amount of services in there, so it seemed justifiable. We were making money on it, that wasn't the problem, but it just was a very expensive fixed cost for us, and when the cloud started coming along and I started actually building out the startup that I was working on, we were building all of that in the cloud, and as I was learning more about the cloud and how that works, I'm like, I should just move all this stuff that's in the co-location facility, move that over to the cloud and see what happens.And it took a couple of weeks to get that set up, and now, again, this is early, this is before ELB, this is before RDS, this is before, I mean, this was very, very early cloud. I mean, I think there was S3 and EC2. I think those were the two services that were available, with a few other things. I don't even think there were VPCs yet. But anyways, I moved everything over, took a couple of weeks to get that over, and essentially our bill to host all of our clients' sites and projects went from $5,000 to $7,000 a month, to $750 a month or something like that, and it's funny because had I done that earlier, I may not have sold off my web development company because it could have been much more profitable, so it was just an interesting move there.So we got into the cloud fairly early and started sort of leveraging that, and it was great to see all these things get added and all these specialty services, like RDS, and just taking the responsibility because I literally was installing Microsoft SQL server on an EC2 instance, which is not something that you want to do, you want to use RDS. It's just a much better way to do it, but anyways, so I was working for another startup, this was like startup number 17 or whatever it was I was working for, and we had this incident where we were using ... we had a pretty good setup. I mean, everything was on EC2 instances, but we were using DynamoDB to do some caching layers for certain things. We were using a sharded database, MySQL database, for product information, and so forth.So the system was pretty resilient, it was pretty, it handled all of the load testing we did and things like that, but then we actually got featured on Good Morning America, and they mentioned our app, it was the Power to Mobile app, and so we get mentioned on Good Morning America. I think it was Good Morning America. The Today Show? Good Morning America, I think it was. One of those morning shows, anyways, we got about 10,000 sign-ups in less than a minute, which was amazing, or it was just this huge spike in traffic, which was great. The problem was, is we had this really weak point in our system where we had to basically get a lock on the database in order to get an incremental-ID, and so essentially what happened is the database choked, and then as soon as the database choked, just to create user accounts, other users couldn't sign in and there was all kinds of problems, so we basically lost out on all of this capability.So I spent some time doing a lot of research and trying to figure out how do you scale that? How do you scale something that fast? How do you have that resilience in there? And there's all kinds of ways that we could have done it with traditional hardware, it's not like it wasn't possible to do with a slightly better strategy, but as I was digging around in AWS, I'm looking around at some different things, and we were, I was always in the console cause we were using Dynamo and some of those things, and I came across this thing that said "Lambda," with a little new thing next to it. I'm like, what the heck is this?So I click on that and I start reading about it, and I'm like, this is amazing. We don't have to spin up a server, we don't have to use Chef, or Puppet, or anything like that to spin up these machines. We can basically just say, when X happens, do Y, and it enlightened me, and this was early 2015, so this would have been right after Lambda went GA. Had never heard of Lambda as part of the preview, I mean, I wasn't sort of in that the re:Invent, I don't know, what would you call that? Vortex, maybe, is a good way to describe the event.Rebecca: Vortex sounds about right. That's about how it feels by the end.Jeremy: Right, exactly. So I wasn't really in that, I wasn't in that group yet, I wasn't part of that community, so I hadn't heard about it, and so as I started playing around with it, I immediately saw the value there, because, for me, as someone who again had managed servers, and it had built out really complex networking too. I think some of the things you don't think about when you move to an on-prem where you're managing your stuff, even what the cloud manages for you. I mean, we had firewalls, and we had to do all the firewall rules ourselves, right. I mean, I know you still have to do security groups and things like that in AWS, but just the level of complexity is a lot lower when you're in the cloud, and of course there's so many great services and systems that help you do that now.But just the idea of saying, "wait a minute, so if I have something happen, like a user signup, for example, and I don't have to worry about provisioning all the servers that I need in order to handle that," and again, it wasn't so much the server aspect of it as it was the database aspect of it, but one of the things that was sort of interesting about the idea of Serverless 2 was this asynchronous nature of it, this idea of being more event-driven, and that things don't have to happen immediately necessarily. So that just struck me as something where it seemed like it would reduce a lot, and again, this term has been overused, but the undifferentiated heavy-lifting, we use that term over and over again, but there is not a better term for that, right?Because there were just so many things that you have to do as a developer, as an ops person, somebody who is trying to straddle teams, or just a PM, or whatever you are, so many things that you have to do in order to get an application running, first of all, and then even more you have to do in order to keep it up and running, and then even more, if you start thinking about distributing it, or scaling it, or getting any of those things, disaster recovery. I mean, there's a million things you have to think about, and I saw serverless immediately as this opportunity to say, "Wait a minute, this could reduce a lot of that complexity and manage all of that for you," and then again, literally let you focus on the things that actually matter for your business.Rebecca: Okay. As someone who worked, how should I say this, in metatech, or the technology of technology in the serverless space, when you say that you were starting to build that without ELB even, or RDS, my level of anxiety is like, I really feel like I'm watching a slow horror film. I'm like, "No, no, no, no, no, you didn't, you didn't, you didn't have to do that, did you"?Jeremy: We did.Rebecca: So I applaud you for making it to the end of the film and still being with us.Jeremy: Well, the other thing ...Rebecca: Only one protagonist does that.Jeremy: Well, the other thing that's interesting too, about Serverless, and where it was in 2015, Lambda goes GA, this will give you some anxiety, there was no API gateway. So there was no way to actually trigger a Lambda function from a web request, right. There was no VPC access in Lambda functions, which meant you couldn't connect to a database. The only thing you do is connect via HDP, so you could connect to DynamoDB or things like that, but you could not connect directly to RDS, for example. So if you go back and you look at the timeline of when these things were released, I mean, if just from 2015, I mean, you literally feel like a caveman thinking about what you could do back then again, it's banging two sticks together versus where we are now, and the capabilities that are available to us.Rebecca: Yeah, you're sort of in Plato's cave, right, and you're looking up and you're like, "It's quite dark in here," and Lambda's up there, outside, sowing seeds, being like, "Come on out, it's dark in there". All right, so I imagine you discovering Lambda through the console is not a sentence you hear every day or general console discovery of a new product that will then sort of change the way that you build, and so I'm guessing maybe one of the reasons why you started your Off-by-none newsletter or Serverless Chats, right, is to be like, "How do I help tell others about this without them needing to discover it through the console"? But I'm curious what your why is. Why first the Off-by-none newsletter, which is one of my favorite things to receive every week, thank you for continuing to write such great content, and then why Serverless Chats? Why are we here today? Why are we at number 100? Which I'm so excited about every time I say it.Jeremy: And it's kind of crazy to think about all the people I've gotten a chance to talk to, but so, I think if you go back, I started writing blog posts maybe in 2015, so I haven't been doing it that long, and I certainly wasn't prolific. I wasn't consistent writing a blog post every week or every, two a week, like some people do now, which is kind of crazy. I don't know how that, I mean, it's hard enough writing the newsletter every week, never mind writing original content, but I started writing about Serverless. I think it wasn't until the beginning of 2018, maybe the end of 2017, and there was already a lot of great content out there. I mean, Ben Kehoe was very early into this and a lot of his stuff I read very early.I mean, there's just so many people that were very early in the space, I mean, Paul Johnson, I mean, just so many people, right, and I started reading what they were writing and I was like, "Oh, I've got some ideas too, I've been experimenting with some things, I feel like I've gotten to a point where what I could share could be potentially useful". So I started writing blog posts, and I think one of the earlier blog posts I wrote was, I want to say 2017, maybe it was 2018, early 2018, but was a post about serverless security, and what was great about that post was that actually got me connected with Ory Segal, who had started PureSec, and he and I became friends and that was the other great thing too, is just becoming part of this community was amazing.So many awesome people that I've met, but so I saw all this stuff people were writing and these things people were doing, and I got to maybe August of 2018, and I said to myself, I'm like, "Okay, I don't know if people are interested in what I'm writing". I wasn't writing a lot, but I was writing a little bit, but I wasn't sure people were overly interested in what I was writing, and again, that idea of the imposter syndrome, certainly everything was very early, so I felt a little bit more comfortable. I always felt like, well, maybe nobody knows what they're talking about here, so if I throw something into the fold it won't be too, too bad, but certainly, I was reading other things by other people that I was interested in, and I thought to myself, I'm like, "Okay, if I'm interested in this stuff, other people have to be interested in this stuff," but it wasn't easy to find, right.I mean, there was sort of a serverless Twitter, if you want to use that terminology, where a lot of people tweet about it and so forth, obviously it's gotten very noisy now because of people slapped that term on way too many things, but I don't want to have that discussion, but so I'm reading all this great stuff and I'm like, "I really want to share it," and I'm like, "Well, I guess the best way to do that would just be a newsletter."I had an email list for my own personal site that I had had a couple of hundred people on, and I'm like, "Well, let me just turn it into this thing, and I'll share these stories, and maybe people will find them interesting," and I know this is going to sound a little bit corny, but I have two teenage daughters, so I'm allowed to be sort of this dad-jokey type. I remember when I started writing the first version of this newsletter and I said to myself, I'm like, "I don't want this to be a newsletter." I was toying around with this idea of calling it an un-newsletter. I didn't want it to just be another list of links that you click on, and I know that's interesting to some people, but I felt like there was an opportunity to opine on it, to look at the individual links, and maybe even tell a story as part of all of the links that were shared that week, and I thought that that would be more interesting than just getting a list of links.And I'm sure you've seen over the last 140 issues, or however many we're at now, that there's been changes in the way that we formatted it, and we've tried new things, and things like that, but ultimately, and this goes back to the corny thing, I mean, one of the first things that I wanted to do was, I wanted to basically thank people for writing this stuff. I wanted to basically say, "Look, this is not just about you writing some content". This is big, this is important, and I appreciate it. I appreciate you for writing that content, and I wanted to make it more of a celebration really of the community and the people that were early contributors to that space, and that's one of the reasons why I did the Serverless Star thing.I thought, if somebody writes a really good article some week, and it's just, it really hits me, or somebody else says, "Hey, this person wrote a great article," or whatever. I wanted to sort of celebrate that person and call them out because that's one of the things too is writing blog posts or posting things on social media without a good following, or without the dopamine hit of people liking it, or re-tweeting it, and things like that, it can be a pretty lonely place. I mean, I know I feel that way sometimes when you put something out there, and you think it's important, or you think people might want to see it, and just not enough people see it.It's even worse, I mean, 240 characters, or whatever it is to write a tweet is one thing, or 280 characters, but if you're spending time putting together a tutorial or you put together a really good thought piece, or story, or use case, or something where you feel like this is worth sharing, because it could inspire somebody else, or it could help somebody else, could get them past a bump, it could make them think about something a different way, or get them over a hump, or whatever. I mean, that's just the kind of thing where I think people need that encouragement, and I think people deserve that encouragement for the work that they're doing, and that's what I wanted to do with Off-by-none, is make sure that I got that out there, and to just try to amplify those voices the best that I could. The other thing where it's sort of progressed, and I guess maybe I'm getting ahead of myself, but the other place where it's progressed and I thought was really interesting, was, finding people ...There's the heavy hitters in the serverless space, right? The ones we all know, and you can name them all, and they are great, and they produce amazing content, and they do amazing things, but they have pretty good engines to get their content out, right? I mean, some people who write for the AWS blog, they're on the AWS blog, right, so they're doing pretty well in terms of getting their things out there, right, and they've got pretty good engines.There's some good dev advocates too, that just have good Twitter followings and things like that. Then there's that guy who writes the story. I don't know, he's in India or he's in Poland or something like that. He writes this really good tutorial on how to do this odd edge-case for serverless. And you go and you look at their Medium and they've got two followers on Medium, five followers on Twitter or something like that. And that to me, just seems unfair, right? I mean, they've written a really good piece and it's worth sharing right? And it needs to get out there. I don't have a huge audience. I know that. I mean I've got a good following on Twitter. I feel like a lot of my Twitter followers, we can have good conversations, which is what you want on Twitter.The newsletter has continued to grow. We've got a good listener base for this show here. So, I don't have a huge audience, but if I can share that audience with other people and get other people to the forefront, then that's important to me. And I love finding those people and those ideas that other people might not see because they're not looking for them. So, if I can be part of that and help share that, that to me, it's not only a responsibility, it's just it's incredibly rewarding. So ...Rebecca: Yeah, I have to ... I mean, it is your 100th episode, so hopefully I can give you some kudos, but if celebrating others' work is one of your main tenets, you nail it every time. So ...Jeremy: I appreciate that.Rebecca: Just wanted you to know that. So, that's sort of the Genesis of course, of both of these, right?Jeremy: Right.Rebecca: That underpins the foundational how to share both works or how to share others' work through different channels. I'm wondering how it transformed, there's this newsletter and then of course it also has this other component, which is Serverless Chats. And that moment when you were like, "All right, this newsletter, this narrative that I'm telling behind serverless, highlighting all of these different authors from all these different global spaces, I'm going to start ... You know what else I want to do? I don't have enough to do, I'm going to start a podcast." How did we get here?Jeremy: Well, so the funny thing is now that I think about it, I think it just goes back to this tenet of fairness, this idea where I was fortunate, and I was able to go down to New York City and go to Serverless Days New York in late 2018. I was able to ... Tom McLaughlin actually got me connected with a bunch of great people in Boston. I live just outside of Boston. We got connected with a bunch of great people. And we started the Serverless Days Boston for 2019. And we were on that committee. I started traveling and I was going to conferences and I was meeting people. I went to re:Invent in 2018, which I know a lot of people just don't have the opportunity to do. And the interesting thing was, is that I was pulling aside brilliant people either in the hallway at a conference or more likely for a very long, deep discussion that we would have about something at a pub in Northern Ireland or something like that, right?I mean, these were opportunities that I was getting that I was privileged enough to get. And I'm like, these are amazing conversations. Just things that, for me, I know changed the way I think. And one of the biggest things that I try to do is evolve my thinking. What I thought a year ago is probably not what I think now. Maybe call it flip-flopping, whatever you want to call it. But I think that evolving your thinking is the most progressive thing that you can do and starting to understand as you gain new perspectives. And I was talking to people that I never would have talked to if I was just sitting here in my home office or at the time, I mean, I was at another office, but still, I wasn't getting that context. I wasn't getting that experience. And I wasn't getting those stories that literally changed my mind and made me think about things differently.And so, here I was in this privileged position, being able to talk to these amazing people and in some cases funny, because they're celebrities in their own right, right? I mean, these are the people where other people think of them and it's almost like they're a celebrity. And these people, I think they deserve fame. Don't get me wrong. But like as someone who has been on that side of it as well, it's ... I don't know, it's weird. It's weird to have fans in a sense. I love, again, you can be my friend, you don't have to be my fan. But that's how I felt about ...Rebecca: I'm a fan of my friends.Jeremy: So, a fan and my friend. So, having talked to these other people and having these really deep conversations on serverless and go beyond serverless to me. Actually I had quite a few conversations with some people that have nothing to do with serverless. Actually, Peter Sbarski and I, every time we get together, we only talk about the value of going to college for some reason. I don't know why. It has usually nothing to do with serverless. So, I'm having these great conversations with these people and I'm like, "Wow, I wish I could share these. I wish other people could have this experience," because I can tell you right now, there's people who can't travel, especially a lot of people outside of the United States. They ... it's hard to travel to the United States sometimes.So, these conversations are going on and I thought to myself, I'm like, "Wouldn't it be great if we could just have these conversations and let other people hear them, hopefully without bar glasses clinking in the background. And so I said, "You know what? Let's just try it. Let's see what happens. I'll do a couple of episodes. If it works, it works. If it doesn't, it doesn't. If people are interested, they're interested." But that was the genesis of that, I mean, it just goes back to this idea where I felt a little selfish having conversations and not being able to share them with other people.Rebecca: It's the very Jeremy Daly tenet slogan, right? You got to share it. You got to share it ...Jeremy: Got to share it, right?Rebecca: The more he shares it, it celebrates it. I love that. I think you do ... Yeah, you do a great job giving a megaphone so that more people can hear. So, in case you need a reminder, actually, I'll ask you, I know what the answer is to this, but do you know the answer? What was your very first episode of Serverless Chats? What was the name, and how long did it last?Jeremy: What was the name?Rebecca: Oh yeah. Oh yeah.Jeremy: Oh, well I know ... Oh, I remember now. Well, I know it was Alex DeBrie. I absolutely know that it was Alex DeBrie because ...Rebecca: Correct on that.Jeremy: If nobody, if you do not know Alex DeBrie, not only is he an AWS data hero, as well as the author of The DynamoDB Book, but he's also like the most likable person on the planet too. It is really hard if you've ever met Alex, that you wouldn't remember him. Alex and I started communicating, again, we met through the serverless space. I think actually he was working at Serverless Inc. at the time when we first met. And I think I met him in person, finally met him in person at re:Invent 2018. But he and I have collaborated on a number of things and so forth. So, let me think what the name of it was. "Serverless Purity Versus Practicality" or something like that. Is that close?Rebecca: That's exactly what it was.Jeremy: Oh, all right. I nailed it. Nailed it. Yes!Rebecca: Wow. Well, it's a great title. And I think ...Jeremy: Don't ask me what episode number 27 was though, because no way I could tell you that.Rebecca: And just for fun, it was 34 minutes long and you released it on June 17th, 2019. So, you've come a long way in a year and a half. That's some kind of wildness. So it makes sense, like, "THE," capital, all caps, bold, italic, author for databases, Alex DeBrie. Makes sense why you selected him as your guest. I'm wondering if you remember any of the ... What do you remember most about that episode? What was it like planning it? What was the reception of it? Anything funny happened recording it or releasing it?Jeremy: Yeah, well, I mean, so the funny thing is that I was incredibly nervous. I still am, actually a lot of guests that I have, I'm still incredibly nervous when I'm about to do the actual interview. And I think it's partially because I want to do justice to the content that they're presenting and to their expertise. And I feel like there's a responsibility to them, but I also feel like the guests that I've had on, some of them are just so smart, and the things they say, just I'm in awe of some of the things that come out of these people's mouths. And I'm like, "This is amazing and people need to hear this." And so, I feel like we've had really good episodes and we've had some okay episodes, but I feel like I want to try to keep that level up so that they owe that to my listener to make sure that there is high quality episode that, high quality information that they're going to get out of that.But going back to the planning of the initial episodes, so I actually had six episodes recorded before I even released the first one. And the reason why I did that was because I said, "All right, there's no way that I can record an episode and then wait a week and then record another episode and wait a week." And I thought batching them would be a good idea. And so, very early on, I had Alex and I had Nitzan Shapira and I had Ran Ribenzaft and I had Marcia Villalba and I had Erik Peterson from Cloud Zero. And so, I had a whole bunch of these episodes and I reached out to I think, eight or nine people. And I said, "I'm doing this thing, would you be interested in it?" Whatever, and we did planning sessions, still a thing that I do today, it's still part of the process.So, whenever I have a guest on, if you are listening to an episode and you're like, "Wow, how did they just like keep the thing going ..." It's not scripted. I don't want people to think it's scripted, but it is, we do review the outline and we go through some talking points to make sure that again, the high-quality episode and that the guest says all the things that the guest wants to say. A lot of it is spontaneous, right? I mean, the language is spontaneous, but we do, we do try to plan these episodes ahead of time so that we make sure that again, we get the content out and we talk about all the things we want to talk about. But with Alex, it was funny.He was actually the first of the six episodes that I recorded, though. And I wasn't sure who I was going to do first, but I hadn't quite picked it yet, but I recorded with Alex first. And it was an easy, easy conversation. And the reason why it was an easy conversation was because we had talked a number of times, right? It was that in a pub, talking or whatever, and having that friendly chat. So, that was a pretty easy conversation. And I remember the first several conversations I had, I knew Nitzan very well. I knew Ran very well. I knew Erik very well. Erik helped plan Serverless Days Boston with me. And I had known Marcia very well. Marcia actually had interviewed me when we were in Vegas for re:Invent 2018.So, those were very comfortable conversations. And so, it actually was a lot easier to do, which probably gave me a false sense of security. I was like, "Wow, this was ... These came out pretty well." The conversations worked pretty well. And also it was super easy because I was just doing audio. And once you add the video component into it, it gets a little bit more complex. But yeah, I mean, I don't know if there's anything funny that happened during it, other than the fact that I mean, I was incredibly nervous when we recorded those, because I just didn't know what to expect. If anybody wants to know, "Hey, how do you just jump right into podcasting?" I didn't. I actually was planning on how can I record my voice? How can I get comfortable behind a microphone? And so, one of the things that I did was I started creating audio versions of my blog posts and posting them on SoundCloud.So, I did that for a couple of ... I'm sorry, a couple of blog posts that I did. And that just helped make me feel a bit more comfortable about being able to record and getting a little bit more comfortable, even though I still can't stand the sound of my own voice, but hopefully that doesn't bother other people.Rebecca: That is an amazing ... I think we so often talk about ideas around you know where you want to go and you have this vision and that's your goal. And it's a constant reminder to be like, "How do I make incremental steps to actually get to that goal?" And I love that as a life hack, like, "Hey, start with something you already know that you wrote and feel comfortable in and say it out loud and say it out loud again and say it out loud again." And you may never love your voice, but you will at least feel comfortable saying things out loud on a podcast.Jeremy: Right, right, right. I'm still working on the, "Ums" and, "Ahs." I still do that. And I don't edit those out. That's another thing too, actually, that one of the things I do want people to know about this podcast is these are authentic conversations, right? I am probably like ... I feel like I'm, I mean, the most authentic person that I know. I just want authenticity. I want that out of the guests. The idea of putting together an outline is just so that we can put together a high quality episode, but everything is authentic. And that's what I want out of people. I just want that authenticity, and one of the things that I felt kept that, was leaving in, "Ums" and, "Ahs," you know what I mean? It's just, it's one of those things where I know a lot of podcasts will edit those out and it sounds really polished and finished.Again, I mean, I figured if we can get the clinking glasses out from the background of a bar and just at least have the conversation that that's what I'm trying to achieve. And we do very little editing. We do cut things out here and there, especially if somebody makes a mistake or they want to start something over again, we will cut that out because we want, again, high quality episodes. But yeah, but authenticity is deeply important to me.Rebecca: Yeah, I think it probably certainly helps that neither of us are robots because robots wouldn't say, "Um" so many times. As I say, "Uh." So, let's talk about, Alex DeBrie was your first guest, but there's been a hundred episodes, right? So, from, I might say the best guest, as a hundredth episode guests, which is our very own Jeremy Daly, but let's go back to ...Jeremy: I appreciate that.Rebecca: Your guests, one to 99. And I mean, you've chatted with some of the most thoughtful, talented, Serverless builders and architects in the industry, and across coincident spaces like ML and Voice Technology, Chaos Engineering, databases. So, you started with Alex DeBrie and databases, and then I'm going to list off some names here, but there's so many more, right? But there's the Gunnar Grosches, and the Alexandria Abbasses, and Ajay Nair, and Angela Timofte, James Beswick, Chris Munns, Forrest Brazeal, Aleksandar Simovic, and Slobodan Stojanovic. Like there are just so many more. And I'm wondering if across those hundred conversations, or 99 plus your own today, if you had to distill those into two or three lessons, what have you learned that sticks with you? If there are emerging patterns or themes across these very divergent and convergent thinkers in the serverless space?Jeremy: Oh, that's a tough question.Rebecca: You're welcome.Jeremy: So, yeah, put me on the spot here. So, yeah, I mean, I think one of the things that I've, I've seen, no matter what it's been, whether it's ML or it's Chaos Engineering, or it's any of those other observability and things like that. I think the common thing that threads all of it is trying to solve problems and make people's lives easier. That every one of those solutions is like, and we always talk about abstractions and, and higher-level abstractions, and we no longer have to write ones and zeros on punch cards or whatever. We can write languages that either compile or interpret it or whatever. And then the cloud comes along and there's things we don't have to do anymore, that just get taken care of for us.And you keep building these higher level of abstractions. And I think that's a lot of what ... You've got this underlying concept of letting somebody else handle things for you. And then you've got this whole group of people that are coming at it from a number of different angles and saying, "Well, how will that apply to my use case?" And I think a lot of those, a lot of those things are very, very specific. I think things like the voice technology where it's like the fact that serverless powers voice technology is only interesting in the fact as to say that, the voice technology is probably the more interesting part, the fact that serverless powers it is just the fact that it's a really simple vehicle to do that. And basically removes this whole idea of saying I'm building voice technology, or I'm building a voice app, why do I need to worry about setting up servers and all this kind of stuff?It just takes that away. It takes that out of the equation. And I think that's the perfect idea of saying, "How can you take your use case, fit serverless in there and apply it in a way that gets rid of all that extra overhead that you shouldn't have to worry about." And the same thing is true of machine learning. And I mean, and SageMaker, and things like that. Yeah, you're still running instances of it, or you still have to do some of these things, but now there's like SageMaker endpoints and some other things that are happening. So, it's moving in that direction as well. But then you have those really high level services like NLU API from IBM, which is the Watson Natural Language Processing.You've got AP recognition, you've got the vision API, you've got sentiment analysis through all these different things. So, you've got a lot of different services that are very specific to machine learning and solving a discrete problem there. But then basically relying on serverless or at least presenting it in a way that's serverless, where you don't have to worry about it, right? You don't have to run all of these Jupiter notebooks and things like that, to do machine learning for a lot of cases. This is one of the things I talk about with Alexandra Abbas, was that these higher level APIs are just taking a lot of that responsibility or a lot of that heavy lifting off of your plate and allowing you to really come down and focus on the things that you're doing.So, going back to that, I do think that serverless, that the common theme that I see is that this idea of worrying about servers and worrying about patching things and worrying about networking, all that stuff. For so many people now, that's just not even a concern. They didn't even think about it. And that's amazing to think of, compute ... Or data, or networking as a utility that is now just available to us, right? And I mean, again, going back to my roots, taking it for granted is something that I think a lot of people do, but I think that's also maybe a good thing, right? Just don't think about it. I mean, there are people who, they're still going to be engineers and people who are sitting in the data center somewhere and racking servers and doing it, that's going to be forever, right?But for the things that you're trying to build, that's unimportant to you. That is the furthest from your concern. You want to focus on the problem that you're trying to solve. And so I think that, that's a lot of what I've seen from talking to people is that they are literally trying to figure out, "Okay, how do I take what I'm doing, my use case, my problem, how do I take that to the next level, by being able to spend my cycles thinking about that as opposed to how I'm going to serve it up to people?"Rebecca: Yeah, I think it's the mantra, right, of simplify, simplify, simplify, or maybe even to credit Bruce Lee, be like water. You're like, "How do I be like water in this instance?" Well, it's not to be setting up servers, it's to be doing what I like to be doing. So, you've interviewed these incredible folks. Is there anyone left on your list? I'm sure there ... I mean, I know that you have a large list. Is there a few key folks where you're like, "If this is the moment I'm going to ask them, I'm going to say on the hundredth episode, 'Dear so-and-so, I would love to interview you for Serverless Chats.'" Who are you asking?Jeremy: So, this is something that, again, we have a stretch list of guests that we attempt to reach out to every once in a while just to say, "Hey, if we get them, we get them." But so, I have a long list of people that I would absolutely love to talk to. I think number one on my list is certainly Werner Vogels. I mean, I would love to talk to Dr. Vogels about a number of things, and maybe even beyond serverless, I'm just really interested. More so from a curiosity standpoint of like, "Just how do you keep that in your head?" That vision of where it's going. And I'd love to drill down more into the vision because I do feel like there's a marketing aspect of it, that's pushing on him of like, "Here's what we have to focus on because of market adoption and so forth. And even though the technology, you want to move into a certain way," I'd be really interesting to talk to him about that.And I'd love to talk to him more too about developer experience and so forth, because one of the things that I love about AWS is that it gives you so many primitives, but at the same time, the thing I hate about AWS is it gives you so many primitives. So, you have to think about 800 services, I know it's not that many, but like, what is it? 200 services, something like that, that all need to kind of connect together. And I love that there's that diversity in those capabilities, it's just from a developer standpoint, it's really hard to choose which ones you're supposed to use, especially when several services overlap. So, I'm just curious. I mean, I'd love to talk to him about that and see what the vision is in terms of, is that the idea, just to be a salad bar, to be the Golden Corral of cloud services, I guess, right?Where you can choose whatever you want and probably take too much and then not use a lot of it. But I don't know if that's part of the strategy, but I think there's some interesting questions, could dig in there. Another person from AWS that I actually want to talk to, and I haven't reached out to her yet just because, I don't know, I just haven't reached out to her yet, but is Brigid Johnson. She is like an IAM expert. And I saw her speak at re:Inforce 2019, it must have been 2019 in Boston. And it was like she was speaking a different language, but she knew IAM so well, and I am not a fan of IAM. I mean, I'm a fan of it in the sense that it's necessary and it's great, but I can't wrap my head around so many different things about it. It's such a ...It's an ongoing learning process and when it comes to things like being able to use tags to elevate permissions. Just crazy things like that. Anyways, I would love to have a conversation with her because I'd really like to dig down into sort of, what is the essence of IAM? What are the things that you really have to think about with least permission? Especially applying it to serverless services and so forth. And maybe have her help me figure out how to do some of the cross role IAM things that I'm trying to do. Certainly would love to speak to Jeff Barr. I did meet Jeff briefly. We talked for a minute, but I would love to chat with him.I think he sets a shining example of what a developer advocate is. Just the way that ... First of all, he's probably the only person alive who knows every service at AWS and has actually tried it because he writes all those blog posts about it. So that would just be great to pick his brain on that stuff. Also, Adrian Cockcroft would be another great person to talk to. Just this idea of what he's done with microservices and thinking about the role, his role with Netflix and some of those other things and how all that kind of came together, I think would be a really interesting conversation. I know I've seen this in so many of his presentations where he's talked about the objections, what were the objections of Lambda and how have you solved those objections? And here's the things that we've done.And again, the methodology of that would be really interesting to know. There's a couple of other people too. Oh, Sam Newman who wrote Building Microservices, that was my Bible for quite some time. I had it on my iPad and had a whole bunch of bookmarks and things like that. And if anybody wants to know, one of my most popular posts that I've ever written was the ... I think it was ... What is it? 16, 17 architectural patterns for serverless or serverless microservice patterns on AWS. Can't even remember the name of my own posts. But that post was very, very popular. And that even was ... I know Matt Coulter who did the CDK. He's done the whole CDK ... What the heck was that? The CDKpatterns.com. That was one of the things where he said that that was instrumental for him in seeing those patterns and being able to use those patterns and so forth.If anybody wants to know, a lot of those patterns and those ideas and those ... The sort of the confidence that I had with presenting those patterns, a lot of that came from Sam Newman's work in his Building Microservices book. So again, credit where credit is due. And I think that that would be a really fascinating conversation. And then Simon Wardley, I would love to talk to. I'd actually love to ... I actually talked to ... I met Lin Clark in Vegas as well. She was instrumental with the WebAssembly stuff, and I'd love to talk to her. Merritt Baer. There's just so many people. I'm probably just naming too many people now. But there are a lot of people that I would love to have a chat with and just pick their brain.And also, one of the things that I've been thinking about a lot on the show as well, is the term "serverless." Good or bad for some people. Some of the conversations we have go outside of serverless a little bit, right? There's sort of peripheral to it. I think that a lot of things are peripheral to serverless now. And there are a lot of conversations to be had. People who were building with serverless. Actually real-world examples.One of the things I love hearing was Yan Cui's "Real World Serverless" podcast where he actually talks to people who are building serverless things and building them in their organizations. That is super interesting to me. And I would actually love to have some of those conversations here as well. So if anyone's listening and you have a really interesting story to tell about serverless or something peripheral to serverless please reach out and send me a message and I'd be happy to talk to you.Rebecca: Well, good news is, it sounds like A, we have at least ... You've got at least another a hundred episodes planned out already.Jeremy: Most likely. Yeah.Rebecca: And B, what a testament to Sam Newman. That's pretty great when your work is referred to as the Bible by someone. As far as in terms of a tome, a treasure trove of perhaps learnings or parables or teachings. I ... And wow, what a list of other folks, especially AWS power ... Actually, not AWS powerhouses. Powerhouses who happened to work at AWS. And I think have paved the way for a ton of ways of thinking and even communicating. Right? So I think Jeff Barr, as far as setting the bar, raising the bar if you will. For how to teach others and not be so high-level, or high-level enough where you can follow along with him, right? Not so high-level where it feels like you can't achieve what he's showing other people how to do.Jeremy: Right. And I just want to comment on the Jeff Barr thing. Yeah.Rebecca: Of course.Jeremy: Because again, I actually ... That's my point. That's one of the reasons why I love what he does and he's so perfect for that position because he's relatable and he presents things in a way that isn't like, "Oh, well, yeah, of course, this is how you do this." I mean, it's not that way. It's always presented in a way to make it accessible. And even for services that I'm not interested in, that I know that I probably will never use, I generally will read Jeff's post because I feel it gives me a good overview, right?Rebecca: Right.Jeremy: It just gives me a good overview to understand whether or not that service is even worth looking at. And that's certainly something I don't get from reading the documentation.Rebecca: Right. He's inviting you to come with him and understanding this, which is so neat. So I think ... I bet we should ... I know that we can find all these twitter handles for these folks and put them in the show notes. And I'm especially ... I'm just going to say here that Werner Vogels's twitter handle is @Werner. So maybe for your hundredth, all the listeners, everyone listening to this, we can say, "Hey, @Werner, I heard that you're the number one guest that Jeremy Daly would like to interview." And I think if we get enough folks saying that to @Werner ... Did I say that @Werner, just @Werner?Jeremy: I think you did.Rebecca: Anyone if you can hear it.Jeremy: Now listen, he did retweet my serverless musical that I did. So ...Rebecca: That's right.Jeremy: I'm sort of on his radar maybe.Rebecca: Yeah. And honestly, he loves serverless, especially with the number of customers and the types of customers and ... that are doing incredible things with it. So I think we've got a chance, Jeremy. I really do. That's what I'm trying to say.Jeremy: That's good to know. You're welcome anytime. He's welcome anytime.Rebecca: Do we say that @Werner, you are welcome anytime. Right. So let's go back to the genesis, not necessarily the genesis of the concept, right? But the genesis of the technology that spurred all of these other technologies, which is AWS Lambda. And so what ... I don't think we'd be having these conversations, right, if AWS Lambda was not released in late 2014, and then when GA I believe in 2015.Jeremy: Right.Rebecca: And so subsequently the serverless paradigm was thrust into the spotlight. And that seems like eons ago, but also three minutes ago.Jeremy: Right.Rebecca: And so I'm wondering ... Let's talk about its evolution a bit and a bit of how if you've been following it for this long and building it for this long, you've covered topics from serverless CI/CD pipelines, observability. We already talked about how it's impacted voice technologies or how it's made it easy. You can build voice technology without having to care about what that technology is running on.Jeremy: Right.Rebecca: You've even talked about things like the future and climate change and how it relates to serverless. So some of those sort of related conversations that you were just talking about wanting to have or having had with previous guests. So as a host who thinks about these topics every day, I'm wondering if there's a topic that serverless hasn't touched yet or one that you hope it will soon. Those types of themes, those threads that you want to pull in the next 100 episodes.Jeremy: That's another tough question. Wow. You got good questions.Rebecca: That's what I said. Heavy hitters. I told you I'd be bringing it.Jeremy: All right. Well, I appreciate that. So that's actually a really good question. I think the evolution of serverless has seen its ups and downs. I think one of the nice things is you look at something like serverless that was so constrained when it first started. And it still has constraints, which are good. But it ... Those constraints get lifted. We just talked about Adrian's talks about how it's like, "Well, I can't do this, or I can't do that." And then like, "Okay, we'll add some feature that you can do that and you can do that." And I think that for the most part, and I won't call it anything specific, but I think for the most part that the evolution of serverless and the evolution of Lambda and what it can do has been thoughtful. And by that I mean that it was sort of like, how do we evolve this into a way that doesn't create too much complexity and still sort of holds true to the serverless ethos of sort of being fairly easy or just writing code.And then, but still evolve it to open up these other use cases and edge cases. And I think that for the most part, that it has held true to that, that it has been mostly, I guess, a smooth ride. There are several examples though, where it didn't. And I said I wasn't going to call anything out, but I'm going to call this out. I think RDS proxy wasn't great. I think it works really well, but I don't think that's the solution to the problem. And it's a band-aid. And it works really well, and congrats to the engineers who did it. I think there's a story about how two different teams were trying to build it at the same time actually. But either way, I look at that and I say, "That's a good solution to the problem, but it's not the solution to the problem."And so I think serverless has stumbled in a number of ways to do that. I also feel EFS integration is super helpful, but I'm not sure that's the ultimate goal to share ... The best way to share state. But regardless, there are a whole bunch of things that we still need to do with serverless. And a whole bunch of things that we still need to add and we need to build, and we need to figure out better ways to do maybe. But I think in terms of something that doesn't get talked about a lot, is the developer experience of serverless. And that is, again I'm not trying to pitch anything here. But that's literally what I'm trying to work on right now in my current role, is just that that developer experience of serverless, even though there was this thoughtful approach to adding things, to try to check those things off the list, to say that it can't do this, so we're going to make it be able to do that by adding X, Y, and Z.As amazing as that has been, that has added layers and layers of complexity. And I'll go back way, way back to 1997 in my dorm room. CGI-bins, if people are not familiar with those, essentially just running on a Linux server, it was a way that it would essentially run a Perl script or other types of scripts. And it was essentially like you're running PHP or you're running Node, or you're running Ruby or whatever it was. So it would run a programming language for you, run a script and then serve that information back. And of course, you had to actually know ins and outs, inputs and outputs. It was more complex than it is now.But anyways, the point is that back then though, once you had the script written. All you had to do is ... There's a thing called FTP, which I'm sure some people don't even know what that is anymore. File transfer protocol, where you would basically say, take this file from my local machine and put it on this server, which is a remote machine. And you would do that. And the second you did that, magically it was updated and you had this thing happening. And I remember there were a lot of jokes way back in the early, probably 2017, 2018, that serverless was like the new CGI-bin or something like that. But more as a criticism of it, right? Or it's just CGI-bins reborn, whatever. And I actually liked that comparison. I felt, you know what? I remember the days where I just wrote code and I just put it to some other server where somebody was dealing with it, and I didn't even have to think about that stuff.We're a long way from that now. But that's how serverless felt to me, one of the first times that I started interacting with it. And I felt there was something there, that was something special about it. And I also felt the constraints of serverless, especially the idea of not having state. People rely on things because they're there. But when you don't have something and you're forced to think differently and to make a change or find a way to work around it. Sometimes workarounds, turn into best practices. And that's one of the things that I saw with serverless. Where people were figuring out pretty quickly, how to build applications without state. And then I think the problem is that you had a lot of people who came along, who were maybe big customers of AWS. I don't know.I'm not going to say that you might be influenced by large customers. I know lots of places are. That said, "We need this." And maybe your ... The will gets bent, right. Because you just... you can only fight gravity for so long. And so those are the kinds of things where I feel some of the stuff has been patchwork and those patchwork things haven't ruined serverless. It's still amazing. It's still awesome what you can do within the course. We're still really just focusing on fast here, with everything else that's built. With all the APIs and so forth and everything else that's serverless in the full-service ecosystem. There's still a lot of amazing things there. But I do feel we've become so complex with building serverless applications, that you can't ... the Hello World is super easy, but if you're trying to build an actual application, it's a whole new mindset.You've got to learn a whole bunch of new things. And not only that, but you have to learn the cloud. You have to learn all the details of the cloud, right? You need to know all these different things. You need to know cloud formation or serverless framework or SAM or something like that, in order to get the stuff into the cloud. You need to understand the infrastructure that you're working with. You may not need to manage it, but you still have to understand it. You need to know what its limitations are. You need to know how it connects. You need to know what the failover states are like.There's so many things that you need to know. And to me, that's a burden. And that's adding new types of undifferentiated heavy-lifting that shouldn't be there. And that's the conversation that I would like to have continuing to move forward is, how do you go back to a developer experience where you're saying you're taking away all this stuff. And again, to call out Werner again, he constantly says serverless is about writing code, but ask anybody who builds serverless applications. You're doing a lot more than writing code right now. And I would love to see us bring the conversation back to how do we get back there?Rebecca: Yeah. I think it kind of goes back to ... You and I have talked about this notion of an ode to simplicity. And it's sort of what you want to write into your ode, right? If we're going to have an ode to simplicity, how do we make sure that we keep the simplicity inside of the ode?Jeremy: Right.Rebecca:So I've got ... I don't know if you've seen these.Jeremy: I don't know.Rebecca: But before I get to some wrap-up questions more from the brainwaves of Jeremy Daly, I don't want to forget to call out some long-time listener questions. And they wrote in a via Twitter and they wanted to perhaps pick your brain on a few things.Jeremy: Okay.Rebecca: So I don't know if you're ready for this.Jeremy: A-M-A. A-M-A.Rebecca: I don't know if you've seen these. Yeah, these are going to put you in the ...Jeremy: A-M-A-M. Wait, A-M-A-A? Asked me almost anything? No, go ahead. Ask me anything.Rebecca: A-M-A-A. A-M-J. No. Anyway, we got it. Ask Jeremy almost anything.Jeremy: There you go.Rebecca: So there's just three to tackle for today's episode that I'm going to lob at you. One is from Ken Collins. "What will it take to get you back to a relational database of Lambda?"Jeremy: Ooh, I'm going to tell you right now. And without a doubt, Aurora Serverless v2. I played around with that right after re:Invent 2000. What was it? 20. Yeah. Just came out, right? I'm trying to remember what year it is at this point.Rebecca: Yes. Indeed.Jeremy: When that just ... Right when that came out. And I had spent a lot of time with Aurora Serverless v1, I guess if you want to call it that. I spent a lot of time with it. I used it on a couple of different projects. I had a lot of really good success with it. I had the same pains as everybody else did when it came to scaling and just the slowness of the scaling and then ... And some of the step-downs and some of those things. There were certainly problems with it. But v2 just the early, early preview version of v2 was ... It was just a marvel of engineering. And the way that it worked was just ... It was absolutely fascinating.And I know it's getting ready or it's getting close, I think, to being GA. And when that becomes GA, I think I will have a new outlook on whether or not I can fit RDS into my applications. I will say though. Okay. I will say, I don't think that transactional applications should be using relational databases though. One of the things that was sort of a nice thing about moving to serverless, speak
Suite au RE:invent 2020 et à la sortie de notre hors série spécial AWS, notre journaliste Yves Grandmontage s'est entretenu avec Jeff Barr (évangéliste technique AWS) Interview en AnglaisHébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Ana Visneski is the senior director of communications and community at H2O.ai, which focuses on open source AI and machine learning solutions. Prior to this position, she worked at AWS for more than four years, serving as the principal of AWS disaster response, head of launch blog and podcast operations, and senior digital marketing manager there. She also served in the Coast Guard for nine years. Join Corey and Ana as they talk about democratizing AI and making it as transparent and accessible as water, why Ana believes AI has a lot of potential but also a lot of challenges, what it was like to be the founder of the Coast Guard’s social media program, how Ana ended up working with AWS, what it’s like to work during an Andy Jassy keynote, how half of Corey’s job is introducing people who work at AWS to each other, the hidden value veterans bring to tech, how Ana played guard dog for Jeff Barr, how the size of the Coast Guard makes everyone who serves a jack of all trades, and more.
On The Cloud Pod this week, the team discusses the conspiracy theory surrounding media coverage of daylight savings and continues counting down to re:Invent. A big thanks to this week's sponsors: Foghorn Consulting, which provides full-stack cloud solutions with a focus on strategy, planning and execution for enterprises seeking to take advantage of the transformative capabilities of AWS, Google Cloud and Azure. Cloud Academy, which provides an intuitive and scalable training platform to meet teams wherever they are along the cloud maturity curve. Use the code THECLOUDPOD for 50% off its training platform. This week's highlights Amazon sells a whole bunch of stuff on its website. Google is nosy and wants people to know what files you've been looking at. Azure wants people to think more with its new knowledge center. Amazon Web Services: Getting Excited for re:Invent Jeff Barr shares how AWS helped to make Prime Day a reality for its customers. Congratulations to the Amazon Ops and Dev teams for this amazing feat. AWS Global Accelerator announces the ability to override destination ports used to route traffic to an application endpoint. Pretty neat!
UTFOWLive_ Discussion w_ Jeff Barr on Cloud Computing, Technology, and Entrepreneurship See acast.com/privacy for privacy and opt-out information.
On this episode of The Six Five - Insiders Edition hosts Patrick Moorhead and Daniel Newman welcome Jeff Barr, Vice President and Chief Evangelist at AWS to discuss AWS’ response to COVID-19 and exciting new product announcements. AWS’ Response to COVID-19 During this COVID-19 pandemic, AWS has been focused on helping customers continue to operate as efficiently as possible. One of the first things the company did was make it easier for businesses to get access to Amazon Workspaces, a virtual desktop in the cloud. They also had special offers for Amazon Chime and Amazon WorkDocs to help companies facilitate collaboration. In addition to helping customers, AWS launched the Diagnostic Development Initiative (DDI) to provide support for innovation around both testing and development of different kinds of solutions. They’ve also made AWS compute power more available to researchers who are studying different possible solutions and vaccines. Finally, AWS launched a public data lake with curated data sets so experiments could actually run queries on real data which will hopefully allow scientists and researchers to find a cure faster. AWS Virtual Summit Traditionally, AWS hosts Global Summits throughout the year, but given the current stay-at-home orders still in place, they’ve had to pivot to a virtual summit the first of which was Wednesday, May 13. The summit is free, online and anyone interested can join. The event is designed to bring the cloud computing community together to connect, collaborate, and learn about AWS. Attendees will hear from CTO Werner Vogels, CEO Andy Jassy, and several other AWS employees who are subject matter experts in various AWS categories. Breaking Down AWS Announcements Jeff, Patrick and Daniel spent time discussing several of the new AWS announcements from the last few months that are making a difference for customers all over the world. Amazon Macie Macie is a security service that uses machine learning to automatically discover and protect sensitive data in AWS. This service has been around for about a year, but AWS has recently made some great additions including updating the machine learning models so customers can scan for even more types of private information. They’ve also added some customizability if customers have special data types that might have different kinds of proprietary or sensitive data inside. The best part is AWS has lowered the price down to a fifth of what it previously cost so more customers are able to benefit from the different services. Amazon Elasticsearch Service Data is growing exponentially in quantity and size and Amazon Elasticsearch Service customers are needing new ways to store and access data as efficiently as possible, specifically data that was collected for the long-term. The current storage tier was called Hot for quickly accessed storage. AWS just introduced a new tier — Ultra Warm — that will hold the more historic data that customers don’t need as often and it will take slightly longer to access. Amazon AppFlow SaaS applications have been highly functional, but the data created and collected across these many applications has effectively been in a silo. Amazon AppFlow is a service that allows customers to securely transfer data between SaaS applications. Customers can unlock the access to that data, making it easier for data to flow from the SaaS app into AWS as well as the other way around. and the other way around as well. Customers can run data flows on a schedule, in response to an event, or on demand — basically whenever they need it. Amazon Kendra AWS’ enterprise search tool Kendra gives customers powerful natural language search capabilities across websites and applications so users can easily find information in the data spread across the enterprise. While most search tools use keyword queries, Kendra is able to use natural language questions to search through portals, wikis, databases, and document repositories to find whatever is needed. It not only captures the data, but also the access permissions for the data too. Amazon Augmented AI (A2I) Many current machine learning applications require humans to review predictions to ensure results are correct. Amazon Augmented AI or A2I makes it easy to build the workflows required for these reviews and provides a built-in review system for common machine learning use cases. Customers are able to choose three different categories of human reviewers. They can use the 500,000 global workers that make use of Mechanical Turk. There's a set of third party organizations that have a base of pre-authorized workers, or organizations can make use of a private pool or workers. AWS Snow Family The Snow Family devices are physical devices that have both storage and local compute power making it easy to migrate data into and out of AWS. Recently AWS launched an improved version of the Snowball Edge Storage Optimized devices. These devices provide both block storage and Amazon S3-compatible object storage. AWS did a hardware refresh, added additional processing power, and added some additional SSD storage inside. Now if you launch EC2 instances on the Snowball Edge those instances have access to this SSD powered storage. You can use these devices for data collection, machine learning and processing, and storage in environments with limited connectivity giving customers the ability to use them basically anywhere. Finally, AWS also made it easier for our customers to set up and manage the Snowball Family devices with AWS OpsHub, a graphical user interface where customers can unlock, configure, copy data to and from the device via drag and drop even if they're not connected to the Internet. If you’d like to learn more about any of these announcements, be sure to visit the AWS website. Make sure to listen to the entire episode below and while you’re at it, be sure to hit subscribe so you never miss an episode.
Many listeners are working from home at the moment, often for the first time. Jeff and Simon discuss some techniques, approaches and tips that might come in handy!
Simon and Jeff get together face-to-face to discuss a new capability of the AWS Global Accelerator, AWS Community day and lots of other things! This was recorded "on the move" so apologies for the less-than-optimal audio. https://aws.amazon.com/blogs/aws/new-client-ip-address-preservation-for-aws-global-accelerator/
Customers have been running Windows workloads on AWS for over 10 years! In this episode Simon and Jeff explore some things you might not know about. They also take a trip down "memory lane" as well as give a teaser for a special podcast event at AWS Tokyo Summit! The Wide World of Windows on AWS: https://aws.amazon.com/blogs/aws/the-wide-world-of-microsoft-windows-on-aws/ Introducing the Amazon Simple Notification Service: https://aws.amazon.com/blogs/aws/introducing-the-amazon-simple-notification-service/ AWS Summits: https://aws.amazon.com/events/summits/
Lyft goes all in on AWS and commits big money to AWS in their IPO. Several new solutions for security from the cloud vendors at RSA this week, and Jeff Barr stops by Reddit to tell us all about cloud formation! Plus the lighting round and cool tools with Jonathan. Sponsors: Foghorn Consulting: fogops.io/thecloudpod Audible: audibletrial.com/thecloudpod Show Topics: Lyft goes all in on AWS Google Releases csp config management for k8 GCP introduces new KMS client libraries Instantly restore your machines with Azure Backup SuperMicro hardware weakness lets researches backdoor into an ibm cloud server RightScale state of the cloud reports indicates Azure gaining on AWS https://twitter.com/QuinnyPig/status/1100893328348831745 Maria DB ceo accuses hyperscalers of strip mining open source Azure announces preview of sentinel security Azure GA of Lab Services Jeff Barr stops by Reddit to drop a quick cloudformation update Original Thread Azure Security Center new Capabilities
Today, we’re talking to Jeff Barr, vice president and chief evangelist at Amazon Web Services (AWS). He founded the AWS Blog in 2004 and has written more than 2,900 posts for it and another 1,100 for his personal blog. As chief evangelist, Jeff strives to explain the benefits of Cloud computing and Web services to anyone who will listen. Jeff is the voice of AWS. He does what he does best - exploits his superpower of explaining technology in ways that people can understand it. Jeff tries to be the same person all the time. He loves to meet people and go out of his way to say “Hello.” So, if you see him at re:Invent, say “Cheese” and take a selfie with him! Some of the highlights of the show include: Jeff uses AWS Workspaces for his blog; one of Jeff’s blogging principles is to not take anybody else's word for anything to the absolute best of his technical ability Zero Client: Jeff has no rotating hardware, disk drives, just a zero client; wherever he is, it's the same workspace AWS has something for everyone; it build things in response to customers’ questions, requests, and feedback Naming Services and Products: Is it helpful? Is it descriptive? Does it have any hidden meanings? Amazonian DNA and Dog Friendly Workspace: Jeff went from super fearful to accepting, to now thinking of dogs as incredible creations because they add fun and excitement to the office As part of hiring, each interviewer is assigned Amazon leadership principles (LPs) to ask questions that measure a candidate against those LPs What is the secret to getting hired at Amazon? Study the LPs to understand what they're about and be able to express your philosophies and history with LPs re:Invent makes sure customers understand services - What is it? What does it do? How do they put it to work? What are the best use cases for it? Things can never be too simple; you start from zero, put a lot of different things in there, and then you need the feedback to build in simplicity AWS is following a more on-demand approach than traditional reserve instances; it opens the door to being used in a lot of ways AWS does a lot of work before a launch to make sure it’s got infrastructure, scaling, monitoring, and capacity in place If you are a customer, talk to AWS and let them know what they're doing right or wrong; write a blog post, tweet about it, share it with them in some way Is the breadth of product offerings from AWS too vast? Is it offering too many things? AWS was not explicit about where it was going with Cloud computing or do analyses or projections about it; it simply launched SQS and let it speak for itself Customer feedback shapes what Amazon works on; customers share and then AWS re-prioritizes to make sure it’s delivering the right thing at the right time Remember: It's not just bits and bytes, it's about the organic life form Links: Jeff Barr on Twitter Jeff Barr on LinkedIn AWS AWS Blog Jeff Barr’s Blog Amazon Machine Images Zero Client AWS Workspaces AWS Lambda Amazon Leadership principles re:Invent The Robot Uprising Will Have Very Clean Floors Serverlessly Storing My Dad Jokes in a Dadabase Days Until re:Invent
Simon is joined by Jeff Barr, Ana Visneski & Daniel Westermann-Clark to discuss why the AWS Blog exists, how it gets produced and a few other interesting things you might want to hear about!! The AWS Blog: https://aws.amazon.com/blogs/aws/
We explain the physics behind ZFS, DTrace switching to the GPL, Emacs debugging, syncookies coming to PF & FreeBSD's history on EC2. This episode was brought to you by Headlines 128 bit storage: Are you high? (https://blogs.oracle.com/bonwick/128-bit-storage:-are-you-high) For people who have heard about ZFS boiling oceans and wonder where that is coming from, we dug out this old piece from 2004 on the blog of ZFS co-creator Jeff Bonwick, originally from the Sun website. 64 bits would have been plenty ... but then you can't talk out of your ass about boiling oceans then, can you? Well, it's a fair question. Why did we make ZFS a 128-bit storage system? What on earth made us think it's necessary? And how do we know it's sufficient? Let's start with the easy one: how do we know it's necessary? Some customers already have datasets on the order of a petabyte, or 2^50 bytes. Thus the 64-bit capacity limit of 2^64 bytes is only 14 doublings away. Moore's Law for storage predicts that capacity will continue to double every 9-12 months, which means we'll start to hit the 64-bit limit in about a decade. Storage systems tend to live for several decades, so it would be foolish to create a new one without anticipating the needs that will surely arise within its projected lifetime. If 64 bits isn't enough, the next logical step is 128 bits. That's enough to survive Moore's Law until I'm dead, and after that, it's not my problem. But it does raise the question: what are the theoretical limits to storage capacity? Although we'd all like Moore's Law to continue forever, quantum mechanics imposes some fundamental limits on the computation rate and information capacity of any physical device. In particular, it has been shown that 1 kilogram of matter confined to 1 liter of space can perform at most 10^51 operations per second on at most 10^31 bits of information [see Seth Lloyd, "Ultimate physical limits to computation." Nature 406, 1047-1054 (2000)]. A fully-populated 128-bit storage pool would contain 2^128 blocks = 2^137 bytes = 2^140 bits; therefore the minimum mass required to hold the bits would be (2^140 bits) / (10^31 bits/kg) = 136 billion kg. That's a lot of gear. To operate at the 1031 bits/kg limit, however, the entire mass of the computer must be in the form of pure energy. By E=mc^2, the rest energy of 136 billion kg is 1.2x1028 J. The mass of the oceans is about 1.4x1021 kg. It takes about 4,000 J to raise the temperature of 1 kg of water by 1 degree Celcius, and thus about 400,000 J to heat 1 kg of water from freezing to boiling. The latent heat of vaporization adds another 2 million J/kg. Thus the energy required to boil the oceans is about 2.4x106 J/kg * 1.4x1021 kg = 3.4x1027 J. Thus, fully populating a 128-bit storage pool would, literally, require more energy than boiling the oceans. Best part of all: you don't have to understand any of this to use ZFS. Rest assured that you won't hit any limits with that filesystem for a long time. You still have to buy bigger disks over time, though... *** dtrace for Linux, Oracle relicenses dtrace (https://gnu.wildebeest.org/blog/mjw/2018/02/14/dtrace-for-linux-oracle-does-the-right-thing/) At Fosdem we had a talk on dtrace for linux in the Debugging Tools devroom. Not explicitly mentioned in that talk, but certainly the most exciting thing, is that Oracle is doing a proper linux kernel port: ``` commit e1744f50ee9bc1978d41db7cc93bcf30687853e6 Author: Tomas Jedlicka tomas.jedlicka@oracle.com Date: Tue Aug 1 09:15:44 2017 -0400 dtrace: Integrate DTrace Modules into kernel proper This changeset integrates DTrace module sources into the main kernel source tree under the GPLv2 license. Sources have been moved to appropriate locations in the kernel tree. ``` That is right, dtrace dropped the CDDL and switched to the GPL! The user space code dtrace-utils and libdtrace-ctf (a combination of GPLv2 and UPL) can be found on the DTrace Project Source Control page. The NEWS file mentions the license switch (and that it is build upon elfutils, which I personally was pleased to find out). The kernel sources (GPLv2+ for the core kernel and UPL for the uapi) are slightly harder to find because they are inside the uek kernel source tree, but following the above commit you can easily get at the whole linux kernel dtrace directory. The UPL is the Universal Permissive License, which according to the FSF is a lax, non-copyleft license that is compatible with the GNU GPL. Thank you Oracle for making everyone's life easier by waving your magic relicensing wand! Now there is lots of hard work to do to actually properly integrate this. And I am sure there are a lot of technical hurdles when trying to get this upstreamed into the mainline kernel. But that is just hard work. Which we can now start collaborating on in earnest. Like systemtap and the Dynamic Probes (dprobes) before it, dtrace is a whole system observability tool combining tracing, profiling and probing/debugging techniques. Something the upstream linux kernel hackers don't always appreciate when presented as one large system. They prefer having separate small tweaks for tracing, profiling and probing which are mostly separate from each other. It took years for the various hooks, kprobes, uprobes, markers, etc. from systemtap (and other systems) to get upstream. But these days they are. And there is now even a byte code interpreter (eBPF) in the mainline kernel as originally envisioned by dprobes, which systemtap can now target through stapbpf. So with all those techniques now available in the linux kernel it will be exciting to see if dtrace for linux can unite them all. Debugging Emacs or: How I Learned to Stop Worrying and Love DTrace (http://nullprogram.com/blog/2018/01/17/) For some time Elfeed was experiencing a strange, spurious failure. Every so often users were seeing an error (spoiler warning) when updating feeds: “error in process sentinel: Search failed.” If you use Elfeed, you might have even seen this yourself. From the surface it appeared that curl, tasked with the responsibility for downloading feed data, was producing incomplete output despite reporting a successful run. Since the run was successful, Elfeed assumed certain data was in curl's output buffer, but, since it wasn't, it failed hard. Unfortunately this issue was not reproducible. Manually running curl outside of Emacs never revealed any issues. Asking Elfeed to retry fetching the feeds would work fine. The issue would only randomly rear its head when Elfeed was fetching many feeds in parallel, under stress. By the time the error was discovered, the curl process had exited and vital debugging information was lost. Considering that this was likely to be a bug in Emacs itself, there really wasn't a reliable way to capture the necessary debugging information from within Emacs Lisp. And, indeed, this later proved to be the case. A quick-and-dirty work around is to use condition-case to catch and swallow the error. When the bizarre issue shows up, rather than fail badly in front of the user, Elfeed could attempt to swallow the error — assuming it can be reliably detected — and treat the fetch as simply a failure. That didn't sit comfortably with me. Elfeed had done its due diligence checking for errors already. Someone was lying to Elfeed, and I intended to catch them with their pants on fire. Someday. I'd just need to witness the bug on one of my own machines. Elfeed is part of my daily routine, so surely I'd have to experience this issue myself someday. My plan was, should that day come, to run a modified Elfeed, instrumented to capture extra data. I would have also routinely run Emacs under GDB so that I could inspect the failure more deeply. For now I just had to wait to hunt that zebra. Bryan Cantrill, DTrace, and FreeBSD Over the holidays I re-discovered Bryan Cantrill, a systems software engineer who worked for Sun between 1996 and 2010, and is most well known for DTrace. My first exposure to him was in a BSD Now interview in 2015. I had re-watched that interview and decided there was a lot more I had to learn from him. He's become a personal hero to me. So I scoured the internet for more of his writing and talks. Some interesting operating system technology came out of Sun during its final 15 or so years — most notably DTrace and ZFS — and Bryan speaks about it passionately. Almost as a matter of luck, most of it survived the Oracle acquisition thanks to Sun releasing it as open source in just the nick of time. Otherwise it would have been lost forever. The scattered ex-Sun employees, still passionate about their prior work at Sun, along with some of their old customers have since picked up the pieces and kept going as a community under the name illumos. It's like an open source flotilla. Naturally I wanted to get my hands on this stuff to try it out for myself. Is it really as good as they say? Normally I stick to Linux, but it (generally) doesn't have these Sun technologies available. The main reason is license incompatibility. Sun released its code under the CDDL, which is incompatible with the GPL. Ubuntu does infamously include ZFS, but other distributions are unwilling to take that risk. Porting DTrace is a serious undertaking since it's got its fingers throughout the kernel, which also makes the licensing issues even more complicated. Linux has a reputation for Not Invented Here (NIH) syndrome, and these licensing issues certainly contribute to that. Rather than adopt ZFS and DTrace, they've been reinvented from scratch: btrfs instead of ZFS, and a slew of partial options instead of DTrace. Normally I'm most interested in system call tracing, and my go to is strace, though it certainly has its limitations — including this situation of debugging curl under Emacs. Another famous example of NIH is Linux's epoll(2), which is a broken version of BSD kqueue(2). So, if I want to try these for myself, I'll need to install a different operating system. I've dabbled with OmniOS, an OS built on illumos, in virtual machines, using it as an alien environment to test some of my software (e.g. enchive). OmniOS has a philosophy called Keep Your Software To Yourself (KYSTY), which is really just code for “we don't do packaging.” Honestly, you can't blame them since they're a tiny community. The best solution to this is probably pkgsrc, which is essentially a universal packaging system. Otherwise you're on your own. There's also openindiana, which is a more friendly desktop-oriented illumos distribution. Still, the short of it is that you're very much on your own when things don't work. The situation is like running Linux a couple decades ago, when it was still difficult to do. If you're interested in trying DTrace, the easiest option these days is probably FreeBSD. It's got a big, active community, thorough documentation, and a huge selection of packages. Its license (the BSD license, duh) is compatible with the CDDL, so both ZFS and DTrace have been ported to FreeBSD. What is DTrace? I've done all this talking but haven't yet described what DTrace really is. I won't pretend to write my own tutorial, but I'll provide enough information to follow along. DTrace is a tracing framework for debugging production systems in real time, both for the kernel and for applications. The “production systems” part means it's stable and safe — using DTrace won't put your system at risk of crashing or damaging data. The “real time” part means it has little impact on performance. You can use DTrace on live, active systems with little impact. Both of these core design principles are vital for troubleshooting those really tricky bugs that only show up in production. There are DTrace probes scattered all throughout the system: on system calls, scheduler events, networking events, process events, signals, virtual memory events, etc. Using a specialized language called D (unrelated to the general purpose programming language D), you can dynamically add behavior at these instrumentation points. Generally the behavior is to capture information, but it can also manipulate the event being traced. Each probe is fully identified by a 4-tuple delimited by colons: provider, module, function, and probe name. An empty element denotes a sort of wildcard. For example, syscall::open:entry is a probe at the beginning (i.e. “entry”) of open(2). syscall:::entry matches all system call entry probes. Unlike strace on Linux which monitors a specific process, DTrace applies to the entire system when active. To run curl under strace from Emacs, I'd have to modify Emacs' behavior to do so. With DTrace I can instrument every curl process without making a single change to Emacs, and with negligible impact to Emacs. That's a big deal. So, when it comes to this Elfeed issue, FreeBSD is much better poised for debugging the problem. All I have to do is catch it in the act. However, it's been months since that bug report and I'm not really making this connection yet. I'm just hoping I eventually find an interesting problem where I can apply DTrace. Bryan Cantrill: Talks I have given (http://dtrace.org/blogs/bmc/2018/02/03/talks/) *** News Roundup a2k18 Hackathon preview: Syncookies coming to PF (https://undeadly.org/cgi?action=article;sid=20180207090000) As you may have heard, the a2k18 hackathon is in progress. As can be seen from the commit messages, several items of goodness are being worked on. One eagerly anticipated item is the arrival of TCP syncookies (read: another important tool in your anti-DDoS toolset) in PF. Henning Brauer (henning@) added the code in a series of commits on February 6th, 2018, with this one containing the explanation: ``` syncookies for pf. when syncookies are on, pf will blindly answer each and every SYN with a syncookie-SYNACK. Upon reception of the ACK completing the 3WHS, pf will reconstruct the original SYN, shove it through pf_test, where state will be created if the ruleset permits it. Then massage the freshly created state (we won't see the SYNACK), set up the sequence number modulator, and call into the existing synproxy code to start the 3WHS with the backend host. Add an - somewhat basic for now - adaptive mode where syncookies get enabled if a certain percentage of the state table is filled up with half-open tcp connections. This makes pf firewalls resilient against large synflood attacks. syncookies are off by default until we gained more experience, considered experimental for now. see http://bulabula.org/papers/2017/bsdcan/ for more details. joint work with sashan@, widely discussed and with lots of input by many ``` The first release to have this feature available will probably be the upcoming OpenBSD 6.3 if a sufficient number of people test this in their setups (hint, hint). More info is likely to emerge soon in post-hackathon writeups, so watch this space! [Pale Moon] A Perfect example of how not to approach OS developers/packagers Removed from OpenBSD Ports due to Licensing Issues (https://github.com/jasperla/openbsd-wip/issues/86) FreeBSD Palemoon branding violation (https://lists.freebsd.org/pipermail/freebsd-ports/2018-February/112455.html) Mightnight BSD's response (https://twitter.com/midnightbsd/status/961232422091280386) *** FreeBSD EC2 History (http://www.daemonology.net/blog/2018-02-12-FreeBSD-EC2-history.html) A couple years ago Jeff Barr published a blog post with a timeline of EC2 instances. I thought at the time that I should write up a timeline of the FreeBSD/EC2 platform, but I didn't get around to it; but last week, as I prepared to ask for sponsorship for my work I decided that it was time to sit down and collect together the long history of how the platform has evolved and improved over the years. Normally I don't edit blog posts after publishing them (with the exception of occasional typographical corrections), but I do plan on keeping this post up to date with future developments. August 25, 2006: Amazon EC2 launches. It supports a single version of Ubuntu Linux; FreeBSD is not available. December 13, 2010: I manage to get FreeBSD running on EC2 t1.micro instances. March 22, 2011: I manage to get FreeBSD running on EC2 "cluster compute" instances. July 8, 2011: I get FreeBSD 8.2 running on all 64-bit EC2 instance types, by marking it as "Windows" in order to get access to Xen/HVM virtualization. (Unfortunately this meant that users had to pay the higher "Windows" hourly pricing.) January 16, 2012: I get FreeBSD 9.0 running on 32-bit EC2 instances via the same "defenestration" trick. (Again, paying the "Windows" prices.) August 16, 2012: I move the FreeBSD rc.d scripts which handle "EC2" functionality (e.g., logging SSH host keys to the console) into the FreeBSD ports tree. October 7, 2012: I rework the build process for FreeBSD 9.1-RC1 and later to use "world" bits extracted from the release ISOs; only the kernel is custom-built. Also, the default SSH user changes from "root" to "ec2-user". October 31, 2012: Amazon launches the "M3" family of instances, which support Xen/HVM without FreeBSD needing to pay the "Windows" tax. November 21, 2012: I get FreeBSD added to the AWS Marketplace. October 2, 2013: I finish merging kernel patches into the FreeBSD base system, and rework the AMI build (again) so that FreeBSD 10.0-ALPHA4 and later use bits extracted from the release ISOs for the entire system (world + kernel). FreeBSD Update can now be used for updating everything (because now FreeBSD/EC2 uses a GENERIC kernel). October 27, 2013: I add code to EC2 images so that FreeBSD 10.0-BETA2 and later AMIs will run FreeBSD Update when they first boot in order to download and install any critical updates. December 1, 2013: I add code to EC2 images so that FreeBSD 10.0-BETA4 and later AMIs bootstrap the pkg tool and install packages at boot time (by default, the "awscli" package). December 9, 2013: I add configinit to FreeBSD 10.0-RC1 and later to allow systems to be easily configured via EC2 user-data. July 1, 2014: Amazon launches the "T2" family of instances; now the most modern family for every type of EC2 instance (regular, high-memory, high-CPU, high-I/O, burstable) supports HVM and there should no longer be any need for FreeBSD users to pay the "Windows tax". November 24, 2014: I add code to FreeBSD 10.2 and later to automatically resize their root filesystems when they first boot; this means that a larger root disk can be specified at instance launch time and everything will work as expected. April 1, 2015: I integrate the FreeBSD/EC2 build process into the FreeBSD release building process; FreeBSD 10.2-BETA1 and later AMIs are built by the FreeBSD release engineering team. January 12, 2016: I enable Intel 82599-based "first generation EC2 Enhanced Networking" in FreeBSD 11.0 and later. June 9, 2016: I enable the new EC2 VGA console functionality in FreeBSD 11.0 and later. (The old serial console also continues to work.) June 24, 2016: Intel 82599-based Enhanced Networking works reliably in FreeBSD 11.0 and later thanks to discovering and working around a Xen bug. June 29, 2016: I improve throughput on Xen blkfront devices (/dev/xbd*) by enabling indirect segment I/Os in FreeBSD 10.4 and later. (I wrote this functionality in July 2015, but left it disabled by default a first because a bug in EC2 caused it to hurt performance on some instances.) July 7, 2016: I fix a bug in FreeBSD's virtual memory initialization in order to allow it to support boot with 128 CPUs; aka. FreeBSD 11.0 and later support the EC2 x1.32xlarge instance type. January 26, 2017: I change the default configuration in FreeBSD 11.1 and later to support EC2's IPv6 networking setup out of the box (once you flip all of the necessary switches to enable IPv6 in EC2 itself). May 20, 2017: In collaboration with Rick Macklem, I make FreeBSD 11.1 and later compatible with the Amazon "Elastic File System" (aka. NFSv4-as-a-service) via the newly added "oneopenown" mount option (and lots of bug fixes). May 25, 2017: I enable support for the Amazon "Elastic Network Adapter" in FreeBSD 11.1 and later. (The vast majority of the work — porting the driver code — was done by Semihalf with sponsorship from Amazon.) December 5, 2017: I change the default configuration in FreeBSD 11.2 and later to make use of the Amazon Time Sync Service (aka. NTP-as-a-service). The current status The upcoming FreeBSD release (11.2) supports: IPv6, Enhanced Networking (both generations), Amazon Elastic File System, Amazon Time Sync Service, both consoles (Serial VGA), and every EC2 instance type (although I'm not sure if FreeBSD has drivers to make use of the FPGA or GPU hardware on those instances). Colin's Patreon' page if you'd like to support him (https://www.patreon.com/cperciva) X network transparency X's network transparency has wound up mostly being a failure (https://utcc.utoronto.ca/~cks/space/blog/unix/XNetworkTransparencyFailure) I was recently reading Mark Dominus's entry about some X keyboard problems, in which he said in passing (quoting himself): I have been wondering for years if X's vaunted network transparency was as big a failure as it seemed: an interesting idea, worth trying out, but one that eventually turned out to be more trouble than it was worth. [...] My first reaction was to bristle, because I use X's network transparency all of the time at work. I have several programs to make it work very smoothly, and some core portions of my environment would be basically impossible without it. But there's a big qualification on my use of X's network transparency, namely that it's essentially all for text. When I occasionally go outside of this all-text environment of xterms and emacs and so on, it doesn't go as well. X's network transparency was not designed as 'it will run xterm well'; originally it was to be something that should let you run almost everything remotely, providing a full environment. Even apart from the practical issues covered in Daniel Stone's slide presentation, it's clear that it's been years since X could deliver a real first class environment over the network. You cannot operate with X over the network in the same way that you do locally. Trying to do so is painful and involves many things that either don't work at all or perform so badly that you don't want to use them. In my view, there are two things that did in general X network transparency. The first is that networks turned out to not be fast enough even for ordinary things that people wanted to do, at least not the way that X used them. The obvious case is web browsers; once the web moved to lots of images and worse, video, that was pretty much it, especially with 24-bit colour. (It's obviously not impossible to deliver video across the network with good performance, since YouTube and everyone else does it. But their video is highly encoded in specialized formats, not handled by any sort of general 'send successive images to the display' system.) The second is that the communication facilities that X provided were too narrow and limited. This forced people to go outside of them in order to do all sorts of things, starting with audio and moving on to things like DBus and other ways of coordinating environments, handling sophisticated configuration systems, modern fonts, and so on. When people designed these additional communication protocols, the result generally wasn't something that could be used over the network (especially not without a bunch of setup work that you had to do in addition to remote X). Basic X clients that use X properties for everything may be genuinely network transparent, but there are very few of those left these days. (Not even xterm is any more, at least if you use XFT fonts. XFT fonts are rendered in the client, and so different hosts may have different renderings of the same thing, cf.) < What remains of X's network transparency is still useful to some of us, but it's only a shadow of what the original design aimed for. I don't think it was a mistake for X to specifically design it in (to the extent that they did, which is less than you might think), and it did help X out pragmatically in the days of X terminals, but that's mostly it. (I continue to think that remote display protocols are useful in general, but I'm in an usual situation. Most people only ever interact with remote machines with either text mode SSH or a browser talking to a web server on the remote machine.) PS: The X protocol issues with synchronous requests that Daniel Stone talks about don't help the situation, but I think that even with those edges sanded off X's network transparency wouldn't be a success. Arguably X's protocol model committed a lesser version of part of the NeWS mistake. X's network transparency was basically free at the time (https://utcc.utoronto.ca/~cks/space/blog/unix/XFreeNetworkTransparency) I recently wrote an entry about how X's network transparency has wound up mostly being a failure for various reasons. However, there is an important flipside to the story of X's network transparency, and that is that X's network transparency was almost free at the time and in the context it was created. Unlike the situation today, in the beginning X did not have to give up lots of performance or other things in order to get network transparency. X originated in the mid 1980s and it was explicitly created to be portable across various Unixes, especially BSD-derived ones (because those were what universities were mostly using at that time). In the mid to late 1980s, Unix had very few IPC methods, especially portable ones. In particular, BSD systems did not have shared memory (it was called 'System V IPC' for the obvious reasons). BSD had TCP and Unix sockets, some System V machines had TCP (and you could likely assume that more would get it), and in general your safest bet was to assume some sort of abstract stream protocol and then allow for switchable concrete backends. Unsurprisingly, this is exactly what X did; the core protocol is defined as a bidirectional stream of bytes over an abstracted channel. (And the concrete implementation of $DISPLAY has always let you specify the transport mechanism, as well as allowing your local system to pick the best mechanism it has.) Once you've decided that your protocol has to run over abstracted streams, it's not that much more work to make it network transparent (TCP provides streams, after all). X could have refused to make the byte order of the stream clear or required the server and the client to have access to some shared files (eg for fonts), but I don't think either would have been a particularly big win. I'm sure that it took some extra effort and care to make X work across TCP from a different machine, but I don't think it took very much. (At the same time, my explanation here is probably a bit ahistorical. X's initial development seems relatively strongly tied to sometimes having clients on different machines than the display, which is not unreasonable for the era. But it doesn't hurt to get a feature that you want anyway for a low cost.) I believe it's important here that X was intended to be portable across different Unixes. If you don't care about portability and can get changes made to your Unix, you can do better (for example, you can add some sort of shared memory or process to process virtual memory transfer). I'm not sure how the 1980s versions of SunView worked, but I believe they were very SunOS dependent. Wikipedia says SunView was partly implemented in the kernel, which is certainly one way to both share memory and speed things up. PS: Sharing memory through mmap() and friends was years in the future at this point and required significant changes when it arrived. Beastie Bits Grace Hopper Celebration 2018 Call for Participation (https://www.freebsdfoundation.org/news-and-events/call-for-papers/grace-hopper-celebration-2018-call-for-participation/) Google Summer of Code: Call for Project Ideas (https://www.freebsdfoundation.org/blog/google-summer-of-code-call-for-project-ideas/) The OpenBSD Foundation 2018 Fundraising Campaign (https://undeadly.org/cgi?action=article;sid=20180129190641) SSH Mastery 2/e out (https://blather.michaelwlucas.com/archives/3115) AsiaBSDcon 2018 Registration is open (https://2018.asiabsdcon.org/) Tarsnap support for Bitcoin ending April 1st; and a Chrome bug (http://mail.tarsnap.com/tarsnap-announce/msg00042.html) Feedback/Questions Todd - Couple Questions (http://dpaste.com/195HGHY#wrap) Seth - Tar Snap (http://dpaste.com/1N7NQVQ#wrap) Alex - sudo question (http://dpaste.com/3D9P1DW#wrap) Thomas - FreeBSD on ARM? (http://dpaste.com/24NMG47#wrap) Albert - Austria BSD User Group (http://dpaste.com/373CRX7#wrap)
Debating Wright Kinsella on Liberty Podcast, Episode 234. This is a debate on IP between me and a noted Bitcoin expert, Craig Wright, hosted and moderated by the Vin Armani show. Transcript below. After the debate I was in London to attend the inaugural 2018 meeting of Mises UK and to hang with my boys Lee Iglody, Jeff Barr, Doug French, and Hans Hoppe, and had challenged Wright to a debate during a few twitter run-ins (still on-going); I accepted and since I happened to be in London, Wright set it up and we did it at a local studio, with Armani moderating from Vegas. Further comments appear on my Facebook post and also on the Youtube post (below). Update [7/17/19]: I had my buddies Jeff Barr and Doug French in the room watching, and after the debate, invited Craig to drinks in the hotel bar. We had an interesting, if a bit bizarre and intense, discussion for an hour or so. But in the ensuing weeks, things between us devolved on Twitter. Wright had promised to produce "proof" of patents stimulating innovation during the debate, and apparently, like with many of his promises to produce something, never came through. I pointed that out on Twitter and he eventually ended up blocking me, as well as the podcast's host, Vin Armani, who at the time was, with Wright, a fellow BCH advocate (Vin is still a BCHer but Craig has split off again with his BSV). Of course, in the meantime, Wright has amped up his risible claims to be Satoshi and has been involved in a number of controversial issues in the bitcoin/crypto community. What a character. Also: during the debate I referred to him as Dr. Wright, since he claims to have several PhDs, but now I am not sure he has any legitimate PhDs, other perhaps than one in "theology", so I should not have called him "Dr." That was too deferential. On the other hand, he did pay for the venue and related costs, so I was being polite. Youtube (with captions): https://youtu.be/5ckcdnD9lFw Original Youtube (which contains a large number of comments; see below): ❧ TRANSCRIPT Intellectual Property Debate: Stephan Kinsella vs. Craig Wright Stephan Kinsella, Craig Wright, and Vin Armani Vin Armani Show, London and Las Vegas, Jan. 27, 2018 00:00:00 VIN ARMANI: Welcome everyone to today's debate. We are debating intellectual property. The two opponents are Stephan Kinsella and Craig Wright. Stephan Kinsella is an attorney in Houston, director of the Center for the Study of Innovative Freedom and editor of Libertarian Papers. He is one of the foremost libertarian experts on intellectual property. 00:00:23 And Dr. Craig Wright is an inventor, computer scientist, and businessman who is one of the earliest minds behind Bitcoin. He's the chief scientist at nChain research and development company involved in Bitcoin and blockchain technologies. So today what we are going to be debating is the following resolution resolved. Intellectual property law is a legitimate and useful institution that belongs in the emerging global sphere of blockchain technology and cryptocurrency. 00:00:54 Craig Wright will be arguing for the resolution, and Stephan Kinsella will be arguing against. This debate is going to consist of a series of five-minute statements and rebuttals, a series of rounds. The first round is going to be an opening statement from each of the debaters. We are going to start with – did we say we're starting with Craig Wright? So we will start with Craig Wright who is arguing for the resolution. Dr. Wright, if you will. 00:01:26 CRAIG WRIGHT: Thank you. So basically what we're looking at is the idea that intellectual property has no value from other people. Now, I would argue it does, not because of the common constraints and whatever else people put about scarcity and what they think about copying but for a number of reasons first as the scarcity of good ideas. There are many ideas out there in the world,
Debating Wright Kinsella on Liberty Podcast, Episode 234. This is a debate on IP between me and a noted Bitcoin expert, Dr. Craig Wright, hosted and moderated by the Vin Armani show. After the debate I was in London to attend the inaugural 2018 meeting of Mises UK and to hang with my boys Lee Iglody, Jeff Barr, Doug French, and Hans Hoppe, and had challenged Wright to a debate during a few twitter run-ins (still on-going); I accepted and since I happened to be in London, Wright set it up and we did it at a local studio, with Armani moderating from Vegas. Further comments appear on my Facebook post and also on the Youtube post (below). Update [7/17/19]: I had my buddies Jeff Barr and Doug French in the room watching, and after the debate, invited Craig to drinks in the hotel bar. We had an interesting, if a bit bizarre and intense, discussion for an hour or so. But in the ensuing weeks, things between us devolved on Twitter. Wright had promised to produce "proof" of patents stimulating innovation during the debate, and apparently, like with many of his promises to produce something, never came through. I pointed that out on Twitter and he eventually ended up blocking me, as well as the podcast's host, Vin Armani, who at the time was, with Wright, a fellow BCH advocate (Vin is still a BCHer but Craig has split off again with his BSV). Of course, in the meantime, Wright has amped up his risible claims to be Satoshi and has been involved in a number of controversial issues in the bitcoin/crypto community. What a character. Also: during the debate I referred to him as Dr. Wright, since he claims to have several PhDs, but now I am not sure he has any legitimate PhDs, other perhaps than one in "theology", so I should not have called him "Dr." That was too deferential. On the other hand, he did pay for the venue and related costs, so I was being polite.
Bawdy Storytelling returns to the scene of the crime with our pal, the Risk! podcast. Live onstage in Brooklyn with part two of the Risk! / Bawdy collaboration show at the Bell House, Dixie De La Tour and Kevin Allison co-host yet more pervy true stories from The Artist and The Pervert’s Mollena Williams-Haas, BexTalksSex’s Bex Caputo and music by Bawdy's own Rachel Lark. We’ve been creating a safe space for sex and story for nearly eleven years now with our live stage series, but Bawdy’s Patreon is what makes this podcast possible. Hear these tales wherever you are by supporting us on Patreon. Music: "Didn't See that Comin'" by Rachel Lark. Get more from Rachel at her website at rachellark.com. Thanks to our podcast producer, Matthew Martyr, our sound engineer for Bawdy Storytelling, David Grosof, sound engineer Jeff Barr of the Risk! podcast, Risk! podcast producer JC Cassis, and special thanks to host and creator of the Risk! podcast, Kevin Allison. Want more? Check out these show links! Risk! Kevin Allison Bex Talks SexMollena Williams-Haas
To learn more about Butterflies of Wisdom visit http://butterfliesofwisdom.weebly.com/ Be sure to FOLLOW this program https://itunes.apple.com/us/podcast/wins-women-of-wisdom/id1060801905. To find out how Win walk and about Ekso go to http://www.bridgingbionics.org/, or email Amanda Boxtel at amanda@bridgingbionics.org. On Butterflies of Wisdom today, Best-Selling Author, Win Kelly Charles and Juan Carlos Gill welcomes Kevin Allison. Kevin, creator, and the host of RISK!, started his comedy career on the legendary sketch series The State on MTV. But in 2009, everything changed. “I was doing a solo show out West, playing characters as usual,” he says. “Afterward, Michael Ian Black [also of The State] said, ‘I kept hoping you’d drop the act and tell some of your own stories.’ I said, ‘Yikes, that just seems so risky…’ But even as I said it, I could feel in my gut that that kind of risk could lead to the best stuff.” The very next week, Kevin was on stage telling his stories. “Suddenly, I was looking right into the eyes of audience members. We were reacting to each other, like friends. After the show, people didn’t just say, ‘That was funny,’ they said, ‘Thank you. That got to me.’ I was finding the meaning in my own experiences and the people listening felt like they’d lived through these things with me. The more I worried I was taking a risk with a story – because it was too emotional, too provocative, or just too nuts – the more the audience lit up.” In August of 2009, host Kevin and producer Michelle Walson started the live show RISK! “where people tell true stories they never thought they’d dare to share in public” at Arlene’s Grocery on the Lower East Side of Manhattan. It was an instant hit. Stories ran the gamut from the sacred to the profane, the hilarious to the horrific – and for the audience, it was a chance to re-connect with the things that make us human. It’s still just about the most cathartic, laugh-out-loud, anything-goes kind of smorgasbord you’re likely to see anywhere. The monthly RISK! Live show, winner of an ECNY Award for Best Variety Show, now lives at The Bell House Theater in Brooklyn and the Nerdmelt Theater in LA. RISK! also tours to sold-out international crowds. Many remarkable people have shown a side of themselves on RISK! that you probably haven’t seen elsewhere, like Michael Ian Black, Janeane Garofalo, R. Ben Garant, Lisa Lampanelli, Kevin Nealon, Margaret Cho, Marc Maron, Sarah Silverman, Michael Showalter, Maria Bamford, Nick Swardson, Lili Taylor, Adam McKay, Rachel Dratch, Andy Borowitz, Kerri Kenney-Silver, Joe LoTruglio, and more. The audio podcast of RISK! – also hosted by Kevin Allison – premiered online in October of 2009. The podcast includes not just the best stories from the live shows but also “radio-style” stories and interstitial music and comedy from artists all over the world. Most episodes of the show are free and easy to download from iTunes and other sources. With new episodes released each Monday, the RISK! The podcast is the winner of an ECNY Award for Best Podcast and has been downloaded tens of millions of times to date. In 2010, Chris Castiglione and Jeff Barr joined RISK! As producers (and co-founders). With the new team in place, the RISK! Podcast grew from being a bi-monthly release to a regularly occurring weekly podcast. Meanwhile, the RISK! Live show went bi-coastal with live performances in Hollywood at the NerdMelt Theater (hosted by Beowulf Jones). In 2011, Kevin and Chris created The Story Studio, at www.thestorystudio.org, a school dedicated to teaching people from all walks of life to turn their most meaningful experiences into powerful self-expression. “Practically anybody will benefit from this training,” Kevin says. “We always say that, from the bar to the boardroom, a good story well told is what leaves a lasting impression.” New workshops through The Story Studio start each month, and corporate workshops can be custom-tailored to a company’s needs. RISK! is a labor of love, a public groundswell, and a start-up with one hell of a future in the works. Be a part of it all. Or, as Kevin ends every episode of the podcast saying, “Folks, today’s the day. Take a risk!” To learn more about Kevin visit http://www.risk-show.com/. To find out more about Win Kelly Charles visit https://wincharles.wix.com/win-charles. Please send feedback to Win by email her atwinwwow@gmail.com, or go to http://survey.libsyn.com/winwisdom andhttp://survey.libsyn.com/thebutterfly. To be on the show, please fill out the intake athttp://bit.ly/1MLJSLG. To look at our sponsorships go to http://www.educents.com/daily-deals#wwow. To learn about the magic of Siri go to https://www.udemy.com/writing-a-book-using-siri/?utm_campaign=email&utm_source=sendgrid.com&utm_medium=email. If you want to donate Butterflies of Wisdom, please send a PayPal donation to aspenrosearts@gmail.com. Please send a check in the mail so 100% goes to Bridging Bionics Foundation. In the Memo section have people write: In honor of Win Charles. Send to: Bridging Bionics Foundation PO Box 3767 Basalt, CO 81621 Thank you Win
Jeff Barr & Simon Elisha discuss various aspects of the Amazon Web Services (AWS) offering. Each podcast include AWS news, tech tips, and interviews with startups, AWS partners, and AWS employees.
10 Years of AWS Ten Years in the AWS Cloud by Jeff Barr A Decade of Innovation by James Hamilton 10 Lessons from 10 Years of Amazon Web Services by Werner Vogels the story of hod ancient blog post talking about our old internal EMR-like workflow service
Web services are changing the fundamental nature of the web, as more and more companies offer their data for free. Rather than spending millions of dollars on complicated systems, entrepreneurs can tap into the existing services of companies like Amazon, and create innovative new enterprises for a fraction of the cost; enterprises that wouldn't have been economical otherwise. In this session, Amazon Web Services Evangelist, Jeff Barr, discusses the power of open APIs and how they are helping to fuel innovation and entrepreneurship. Jeff discusses Amazon's motivation for building AWS and some of the design decisions (such as their use of XSLT) they made along the way. Jeff touches on some of Amazon's current offerings such as S3 and the Mechanical Turk, before showing demonstrations of how these services are being used in the wild.
© 2020-2025 Ivy Podcast Discovery LLC
