Podcasts about OpenStack

Cloud computing software

  • 192PODCASTS
  • 674EPISODES
  • 39mAVG DURATION
  • 1EPISODE EVERY OTHER WEEK
  • Sep 5, 2022LATEST
OpenStack

POPULARITY

20152016201720182019202020212022

Categories



Best podcasts about OpenStack

Show all podcasts related to openstack

Latest podcast episodes about OpenStack

THE ONE'S CHANGING THE WORLD -PODCAST
BLOCKCHAIN & CRYPTO REPLACE THE BANKING INDUSTRY? - PRASANNA LOHAR- INDIA BLOCKCHAIN FORUM

THE ONE'S CHANGING THE WORLD -PODCAST

Play Episode Listen Later Sep 5, 2022 56:08


#blockchain #banking #crypto #banks #finance #dcbbank #toctw #podcast #defi #cryptocurrency, Blockchain tech is challenging the traditional Banking Industry, will blockchain be able to replace the banking industry, A report by Consulting Giant #deloitte claims Crypto will replace #fiatcurrency in the next 5 to 10 yrs......what is the future of the banking Industry. We spoke to Prasanna Lohar Innovation Head & Technical Architect at DCB Bank, practicing Innovation Implementation & Architecture Orchestration at DCB Bank. He has launched a Global Innovation program – “DCB Bank Innovation Carnival”. to bring on Unique Experience of Innovation generation thru Hackathons & Accelerator programs in India. Prasanna is working with various FINTECH & BLOCKCHAIN Forums in India to create a Robust Innovation Ecosystem in India. As part of DCB's Digital & Architecture Transformation, he is closely associated with New & latest technology Assimilation, Experimentation, Innovative Customer Servicing & Engagement, Robust Architecture Implementation, Fintech & Startup Alignment, Open Innovation practices, Collaboration with other Banks on various initiatives. At DCB Prasanna has worked as Digital Bank Head & is Part of various deliveries like India's first Aadhaar & Biometric enabled ATM, Paperless A/c Opening - Zippi, India's first Omni-Channel Framework for Bank, Mobile Banking & Mobile Apps, Open Banking & Internet Banking The initiative, Unified Payment Interface (UPI), Bharat Bill Payment, API Management, Switch & Cards relevant initiatives. I have Over 18 Years of Industry Experience in Engineering and Development, Product Development, Organization Strategy & Governance, Risk Audit Compliance Management, Business Process Management, Enterprise Architecture, Mobile Apps, Digital Transformation, Fintech, E-Commerce, Payments, Platform and Product Innovation, Data Science, Machine Learning, Artificial Intelligence, Open Stack, Cloud Computing, Analytics, Big Data, IoT, BlockChain, UI-UX, Product Roadmap Strategy, Business Development From 2017-2019, He has bagged many Leadership awards Most Influential Payment Professionals, TOP 50 CIOs, Top 100 Innovative CIOs, Digital Leader of the Year, Top 20 BFSI Leaders. He has appeared in many BFSI Conferences as Key-Note Speaker & contributed to the Blockchain, and Cryptocurrency ecosystem. https://in.linkedin.com/in/prasannalohar https://twitter.com/loharprasanna

IT Availability Now
What is the cyber kill chain and how can it keep your business secure?

IT Availability Now

Play Episode Listen Later Aug 10, 2022 17:38


The mounting threat of ransomware – a 13% increase in attacks year over year, per Verizon's 2022 Data Breach Investigation's Report – has organizations taking a closer look at the cyber kill chain. But what exactly is the cyber kill chain and how can it keep your business secure?On this episode of IT Availability Now, host Servaas Verbiest and guest Shannon Davis, Global Director of Partner Readiness at Alert Logic, discuss this hot-button topic and why businesses today can't neglect the kill chain. Listen to this full episode to learn:The origins of the cyber kill chain, including how the name came aboutHow the cyber kill chain has evolved The key components of the current cyber kill chainWhy the cyber kill chain is such an integral part of a company's security postureHow to ensure your organization maximizes the kill chainAs Director of Product Field Strategy at Sungard AS, Servaas Verbiest assists businesses and organizations in realizing the full potential of cloud computing by thinking strategically, deploying rapidly, and acting as an ambassador for the cloud ecosystem. While at Sungard AS, Servaas has worked with more than 1,000 unique clients across multiple industries on complex application deployments, re-platforming, public cloud integrations, private cloud deployments, application lifecycle, and hybrid cloud model development.Shannon Davis is Global Director of Partner Readiness at Alert Logic, regularly consulting with companies to increase awareness of the current threat landscape and the security solutions and best practices available to stay protected. He is focused on the development of and investment in strategic relationships that allow those concepts and conversations to scale globally across the network of Alert Logic partners. Shannon has over 10 years of IT sales and marketing experience with expertise in Cybersecurity, MSP, MSSP, AWS, Azure, VMware, OpenStack, managed hosting, and more.Listen and subscribe to IT Availability Now on Apple Podcasts, Spotify, Google Podcasts, Podchaser, deezer, Podcast Addict, Listen Notes, and more.

Packet Pushers - Briefings In Brief
Tech Bytes: Nokia Fabric Services System Streamlines Network Automation For Application Stacks (Sponsored)

Packet Pushers - Briefings In Brief

Play Episode Listen Later Jul 25, 2022 15:32


Today on the Tech Bytes podcast we welcome back sponsor Nokia to talk about a compelling feature in Nokia's Fabric Services System. This feature, called Connect, lets Fabric Services System integrate with platforms such as VMware, OpenStack, and Kubernetes to streamline the provisioning of network services in Top Of Rack switches when new workloads or services are instantiated. The post Tech Bytes: Nokia Fabric Services System Streamlines Network Automation For Application Stacks (Sponsored) appeared first on Packet Pushers.

Packet Pushers - Full Podcast Feed
Tech Bytes: Nokia Fabric Services System Streamlines Network Automation For Application Stacks (Sponsored)

Packet Pushers - Full Podcast Feed

Play Episode Listen Later Jul 25, 2022 15:32


Today on the Tech Bytes podcast we welcome back sponsor Nokia to talk about a compelling feature in Nokia's Fabric Services System. This feature, called Connect, lets Fabric Services System integrate with platforms such as VMware, OpenStack, and Kubernetes to streamline the provisioning of network services in Top Of Rack switches when new workloads or services are instantiated. The post Tech Bytes: Nokia Fabric Services System Streamlines Network Automation For Application Stacks (Sponsored) appeared first on Packet Pushers.

Packet Pushers - Fat Pipe
Tech Bytes: Nokia Fabric Services System Streamlines Network Automation For Application Stacks (Sponsored)

Packet Pushers - Fat Pipe

Play Episode Listen Later Jul 25, 2022 15:32


Today on the Tech Bytes podcast we welcome back sponsor Nokia to talk about a compelling feature in Nokia's Fabric Services System. This feature, called Connect, lets Fabric Services System integrate with platforms such as VMware, OpenStack, and Kubernetes to streamline the provisioning of network services in Top Of Rack switches when new workloads or services are instantiated. The post Tech Bytes: Nokia Fabric Services System Streamlines Network Automation For Application Stacks (Sponsored) appeared first on Packet Pushers.

TD Ameritrade Network
Overlooked Stock: Rackspace Technology (RXT)

TD Ameritrade Network

Play Episode Listen Later Jul 18, 2022 7:21


Rackspace Technology (RXT) designs, builds, and operates cloud environments across technology platforms. The company operates through three segments: multi-cloud services, apps and cross platform, and OpenStack public cloud. Rackspace Technology (RXT) enables public cloud and managed hosting platforms to work. George Tsilis weighs in on the RXT stock being downgraded from equal-weight at Barclays.

The Homelab Show
The Homelab Show Ep. 60 – Openstack

The Homelab Show

Play Episode Listen Later Jun 23, 2022 58:10


https://thehomelab.show/  The sponsor for today’s episode https://www.linode.com/homelabshow https://lawrencesystems.com/h ttps://www.learnlinux.tv/

DevZen Podcast
Открытая стопка — Episode 0386

DevZen Podcast

Play Episode Listen Later Jun 18, 2022 127:32


В этом выпуске: интервью с гостем об OpenStack и почему людям нравятся облака поменьше, чем AWS; тотальная защита печенек от FF; уязвимости PACMAN и Hertzbleed; что лучше — продираться к GCC через тернии, или прокатиться на роллс-ройсе; как СУБД хранят ваши данные на диске; а также интересный лонгрид про eBPF и темы наших слушателей. Шоуноты:… Читать далее →

Software Defined Talk
Episode 362: Are we using version control?

Software Defined Talk

Play Episode Listen Later Jun 10, 2022 67:50


This week we discuss work life balance, the State of Continuous Delivery Survey and recap WWDC. Plus, some thoughts on Buddha and parenting… Runner-up Titles The Buddha had no kids The Air Fryer is a PaaS. Rundown Work vs. Life Office workers get little reward for returning to the office – an idle factory is taboo (https://cote.io/2022/06/08/office-workers-get-little-reward-for-returning-to-work-an-idle-factory-is-taboo/) CEOs had a phenomenal year. Workers, less so (https://thehustle.co/05312022-CEO-vs-Worker-Pay/) Tesla monitored its employees on Facebook with help of PR firm during 2017 union push (https://www.cnbc.com/2022/06/02/tesla-paid-pr-firm-to-surveil-employees-on-facebook-in-2017-union-push.html) Elon Musk asks all Tesla employees to come back to the office or quit (https://electrek.co/2022/06/01/elon-musk-tesla-employees-come-back-office-or-quit/) Ford factory workers get 40-hour week (https://www.history.com/this-day-in-history/ford-factory-workers-get-40-hour-week) Survey Says State of Continuous Delivery (https://cd.foundation/wp-content/uploads/sites/78/2022/06/The-State-of-CD-Q1-2022.pdf) Chainguard raises $50M Series A for supply chain security (https://techcrunch.com/2022/06/02/chainguard-raises-50m-to-guard-supply-chains/) WWDC Apple WWDC 2022: the 16 biggest announcements (https://www.theverge.com/2022/6/6/23141939/apple-wwdc-2022-biggest-announcements-ios-16-macbook-air-macos-watchos) Create macOS or Linux virtual machines - WWDC22 - Videos (https://developer.apple.com/videos/play/wwdc2022/10002/) Apple will allow Linux VMs to run Intel apps with Rosetta in macOS Ventura (https://arstechnica.com/gadgets/2022/06/macos-ventura-will-extend-rosetta-support-to-linux-virtual-machines/) All the New Features Coming to Your Mac This Fall (https://www.wired.com/story/apple-ventura-macos-13-preview/) EU reaches deal to make USB-C a common charger for most electronic devices (https://www.engadget.com/eu-reaches-deal-to-make-usb-c-a-common-charger-for-most-electronic-devices-104605067.html) Relevant to your Interests Earnings HashiCorp quarter (https://siliconangle.com/2022/06/02/kubecost-launches-open-source-opencost-project-keep-lid-kubernetes-spending/https://twitter.com/jaminball/status/1532457687778312213?s=21&t=FiXLrZJc1LtYPQyeU27CEg) MongoDB quarter (https://twitter.com/jaminball/status/1532094080418607104) GitLab quarter (https://twitter.com/jaminball/status/1533906440695316480?s=21&t=K30ROu7mTJp1DgbvYxhDCA) Salesforce stock jumps as it raises profit forecast (https://www.cnbc.com/2022/05/31/salesforce-crm-earnings-q1-2023.html) Tech Valuations Tumble, but Business Software Stocks Are Cushioned by the Cloud (https://www.wsj.com/articles/tech-valuations-tumble-but-business-software-stocks-are-cushioned-by-the-cloud-11654164000?mod=djemalertNEWS) A Framework for Navigating Down Markets (https://future.com/framework-valuation-navigating-down-markets/) VMware Good thread (VMware history) (https://twitter.com/jdooley_clt/status/1528688334394077184) Broadcom buying VMware makes sense for IoT infrastructure (https://www.theregister.com/2022/05/26/broadcom_buying_vmware_makes_sense/) Broadcom plans 'rapid subscription transition' for VMware (https://www.theregister.com/2022/05/27/broadcom_vmware_subscriptions/) Broadcom buying VMware makes sense for IoT infrastructure (https://www.theregister.com/2022/05/26/broadcom_buying_vmware_makes_sense/) Brian Madden's brutal and unfiltered thoughts on the Broadcom / VMware deal (https://www.linkedin.com/pulse/brian-maddens-brutal-unfiltered-thoughts-broadcom-vmware-brian-madden/?trackingId=m%2FeClBkjQxSyYPzRVcnpHQ%3D%3D) Broadcom will tame the VMware beast (https://siliconangle.com/2022/05/27/broadcom-will-tame-vmware-beast/) VMware Blockchain (https://www.vmware.com/products/blockchain.html) Bolt, the payments start-up, has begun laying off employees. (https://www.nytimes.com/2022/05/25/business/bolt-layoffs.html) Layoffs.fyi - Tech Layoff Tracker and Startup Layoff Lists (https://layoffs.fyi/) Proton Is Trying to Become Google—Without Your Data (https://www.wired.com/story/proton-mail-calendar-drive-vpn/) OpenStack, except it's outer space, (https://twitter.com/Kemp/status/1530198772872933377) Microsoft confirms it's taking a 'new approach' with its game streaming device | Engadget (https://www.engadget.com/microsoft-confirms-its-taking-a-new-approach-to-its-game-streaming-device-090144247.html) How to do fun and interesting executive dinners, round tables, etc. – online and in-person (https://cote.io/2022/05/27/how-to-do-executive-dinners/) Over 380 000 open Kubernetes API servers | The Shadowserver Foundation (https://www.shadowserver.org/news/over-380-000-open-kubernetes-api-servers/) Twitter fined $150M for misusing 2FA data (https://www.techtarget.com/searchsecurity/news/252520746/Twitter-fined-150M-for-misusing-2FA-data) First she documented the alt-right. Now she's coming for crypto. (https://www.washingtonpost.com/technology/2022/05/29/molly-white-crypto/) Exclusive: Microsoft continues to iterate on an Xbox cloud streaming device codenamed 'Keystone' (https://www.windowscentral.com/gaming/xbox/exclusive-microsoft-continues-to-iterate-on-an-xbox-cloud-streaming-stick-codenamed-keystone) Microsoft won't lower software costs on AWS, Google clouds (https://www.techtarget.com/searchenterprisedesktop/news/252520735/Microsoft-wont-lower-software-costs-on-AWS-Google-clouds) A researcher's avatar was sexually assaulted on a metaverse platform owned by Meta, making her the latest victim of sexual abuse on Meta's platforms, watchdog says (https://www.businessinsider.com/researcher-claims-her-avatar-was-raped-on-metas-metaverse-platform-2022-5) Forget LinkedIn—Your Next Job Offer Could Come via Slack (https://www.wsj.com/articles/job-hunters-workers-use-slack-to-find-job-offers-fast-11653918510) Sheryl Sandberg will leave Meta after 14 years this fall (https://www.protocol.com/sheryl-sandberg-meta-coo) This crypto startup believes 'sex-to-earn' is the future of web3 (https://www.inputmag.com/tech/sexn-crypto-startup-sex-to-earn-web3-nfts) ExpressVPN rejects CERT-In directives, removes its India servers (https://economictimes.indiatimes.com/tech/technology/expressvpn-rejects-cert-in-directives-suspends-india-ops/articleshow/91956961.cms) MongoDB CTO on (no)SQL, Superapps, and Southeast Asia (https://future.com/mongodb-cto-cloud-providers-southeast-asia/) Google is combining Meet and Duo into a single app for voice and video calls (https://www.theverge.com/2022/6/1/23149832/google-meet-duo-combination-voice-video) This VR headset will measure a user's brain activity (https://www.pcgamer.com/this-vr-headset-will-measure-a-users-brain-activity) Tesla has to respond to increase in phantom braking complaints (https://electrek.co/2022/06/03/tesla-respond-increase-phantom-braking-complaints/) Amazon's retail CEO is resigning after 23 years (https://www.theverge.com/2022/6/3/23153327/amazon-ceo-consumer-retail-businesses-dave-clark-resigning) Zoom Hires Greg Tomb as President (https://www.globenewswire.com/news-release/2022/06/06/2457166/0/en/Zoom-Hires-Greg-Tomb-as-President.html?utm_source=newsletter&utm_medium=email&utm_campaign=newsletter_axioslogin&stream=top) Peloton hires Amazon Web Services executive Liz Coddington as new CFO in latest shakeup (https://techcrunch.com/2022/06/07/peloton-hires-amazon-executive-liz-coddington-new-cfo-latest-shakeup/) Musk accuses Twitter of 'resisting and thwarting' his right to information on fake accounts (https://www.cnbc.com/2022/06/06/musk-says-twitter-is-refusing-to-share-data-on-spam-accounts.html) ‘A new IBM': How the tech giant simplified its marketing (https://www.marketingweek.com/ibm-simplifying-marketing/) Coinbase extends hiring pause for 'foreseeable future' and plans to rescind some offers (https://www.cnbc.com/2022/06/02/coinbase-hiring-pause-for-foreseeable-future-and-will-rescind-offers.html) Evading the Big Blue Name Police (https://www.itjungle.com/2022/06/08/evading-the-big-blue-name-police/) IBM CEO explains why company offloaded Watson Health (https://www.theregister.com/2022/06/08/ibm_ceo_arvind_krishna_explains/) MongoDB fires up new cloud, on-premises releases (https://venturebeat.com/2022/06/07/mongodb-fires-up-new-cloud-on-premise-releases/) In reversal, Twitter plans to comply with Musk's demands for data (https://www.washingtonpost.com/technology/2022/06/08/elon-musk-twitter-bot-data/) OpenCost: Open Source Collaboration on Kubernetes Cost Standards (https://thenewstack.io/opencost-open-source-collaboration-on-kubernetes-cost-standards/) Kubecost launches open-source OpenCost project (https://siliconangle.com/2022/06/02/kubecost-launches-open-source-opencost-project-keep-lid-kubernetes-spending/) Datadog's 2022 State of Serverless repor (https://www.datadoghq.com/state-of-serverless/)t (https://www.datadoghq.com/state-of-serverless/) The IRS needs digital transformation (https://twitter.com/josephzeballos/status/1534189391328976897?s=21&t=uPoXtZtzX-q_GAtodVVbsg) Oracle quietly closes $28B deal to buy electronic health records company Cerner (https://techcrunch.com/2022/06/07/oracle-quietly-closes-28b-deal-to-buy-electronic-health-records-company-cerner/) Nonsense The Cast of HBO's 'Silicon Valley' Cast Explains What Real Startups Do (NSFW) (https://www.youtube.com/watch?v=5Y64UeNeiOM) WSJ News Exclusive | Justin Timberlake Sells Song Catalog to Blackstone-Backed Fund (https://www.wsj.com/articles/justin-timberlake-sells-song-catalog-to-blackstone-backed-fund-11653557400) Every person in the U.S. now receives an average of 65 packages a year. (https://twitter.com/mims/status/1529222322686672896) Spotify Podcasters Are Making $18,000 a Month With Nothing But White Noise (https://www.bloomberg.com/news/articles/2022-06-01/how-to-make-money-on-spotify-a-white-noise-podcast-could-bring-you-big-bucks) Flying ice cream? Unilever links with drone delivery service Flytrex (https://www.fooddive.com/news/flying-ice-cream-unilever-links-with-drone-delivery-service-flytrex/624541/) Texas to reclaim home of the largest Buc-ee's (https://www.kxan.com/news/texas/texas-to-reclaim-home-of-the-largest-buc-ees/) Sponsors Teleport — The easiest, most secure way to access infrastructure. (https://goteleport.com/?utm_campaign=eg&utm_medium=partner&utm_source=sdt) Listener Feedback / Jobs Tim wants you to work at Biogen as a Global DevOps Lead, Commercial & Medical IT (https://jobs.smartrecruiters.com/Biogen/743999821251393-global-devops-lead-commercial-medical-it) Walmart is hiring Principal Software Engineer - Linux Kernel in Sunnyvale, California (https://www.linkedin.com/jobs/view/2945555862) Ryan wants you to work at DataDog as the Vice President, Events and Field Marketing (https://www.datadoghq.com/careers/detail/?gh_jid=4252681) J&J Senior Algorithm Analytics Engineer in Redwood City, California | Medical Devices (https://jobs.jnj.com/jobs/2206008429W?lang=en-us) NYTimes is hiring a Staff Software Engineer - CI/CD Platform (https://nytimes.wd5.myworkdayjobs.com/Tech/job/New-York-NY/Staff-Software-Engineer---CI-CD-Platform_REQ-012710) Conferences FinOps X (https://events.linuxfoundation.org/finops-x/), June 20-21, 2022, Matt's there! DevOps Loop (https://devopsloop.io), June 22nd. Free! Coté put the agenda together. Open Source Summit North America (https://events.linuxfoundation.org/open-source-summit-north-america/), June 21-24, 2022, Matt's there! DevOpsDayLA (https://www.socallinuxexpo.org/scale/19x/devops-day-la) is happening at SCALE19x (https://www.socallinuxexpo.org/scale/19x), July, 29th, 2022 Discount code: DEVOP THAT Conference Wisconsin (https://that.us/call-for-counselors/wi/2022/), July 25, 2022 Discount code: SDTFriendsWI50 - $50 off 4-Day everything ticket Discount code:: SDTFriendsWI25 - $25 off 3-Day Camper ticket VMware Explore 2022, August 29 – September 1, 2022 (https://www.vmware.com/explore.html?src=so_623a10693ceb7&cid=7012H000001Kb0hQAC) SpringOne Platform (https://springone.io/?utm_source=cote&utm_medium=podcast&utm_content=sdt), SF, December 6–8, 2022 THAT Conference Texas Call For Counselors (https://that.us/call-for-counselors/tx/2023/) Jan 16-19, 2023, SDT news & hype Join us in Slack (http://www.softwaredefinedtalk.com/slack). Get a SDT Sticker! Send your postal address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and we will send you free laptop stickers! Follow us on Twitch (https://www.twitch.tv/sdtpodcast), Twitter (https://twitter.com/softwaredeftalk), Instagram (https://www.instagram.com/softwaredefinedtalk/), LinkedIn (https://www.linkedin.com/company/software-defined-talk/) and YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured). Use the code SDT to get $20 off Coté's book, (https://leanpub.com/digitalwtf/c/sdt) Digital WTF (https://leanpub.com/digitalwtf/c/sdt), so $5 total. Become a sponsor of Software Defined Talk (https://www.softwaredefinedtalk.com/ads)! Recommendations Brandon: Apple Watch SE (https://www.apple.com/apple-watch-se/?afid=p238%7CsZvcBV5q2-dc_mtid_1870765e38482_pcrid_584606532877_pgrid_117189313172_pntwk_g_pchan__pexid__&cid=aos-us-kwgo-watch--slid---product-) for Tweens Coté: Matt Levine interview on (https://longform.org/posts/longform-podcast-490-matt-levine) The Longform podcast (https://longform.org/posts/longform-podcast-490-matt-levine). Photo Credits Banner (https://unsplash.com/photos/88IMbX3wZmI) ArtWork (https://unsplash.com/photos/5cFwQ-WMcJU)

Screaming in the Cloud
Conveying Authenticity in Marketing with Sharone Zitzman

Screaming in the Cloud

Play Episode Listen Later Jun 2, 2022 32:16


About SharoneI'm Sharone Zitzman, a marketing technologist and open source community builder, who likes to work with engineering teams that are building products that developers love. Having built both the DevOps Israel and Cloud Native Israel communities from the ground up, today I spend my time finding the places where technology and people intersect and ensuring that this is an excellent experience. You can find my talks, articles, and employment experience at rtfmplease.dev. Find me on Twitter or Github as @shar1z.Links Referenced: Personal Twitter: https://twitter.com/shar1z Website: https://rtfmplease.dev LinkedIn: https://www.linkedin.com/in/sharonez/ @TLVCommunity: https://twitter.com/TLVcommunity @DevOpsDaysTLV: https://twitter.com/devopsdaystlv 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: DoorDash had a problem as their cloud native environment scaled and developers delivered new features, their monitoring system kept breaking down. In an organization where data is used to make better decisions about technology and about the business, losing observability means the entire company loses their competitive edge. With Chronosphere, DoorDash is no longer losing visibility into their applications suite. The key? Chronosphere is an open source compatible, scalable, and reliable observability solution that gives the observability lead at DoorDash business, competence, and peace of mind. Read the full success story at snark.cloud/chronosphere. That's snark.cloud/C-H-R-O-N-O-S-P-H-E-R-E.Corey: The company 0x4447 builds products to increase standardization and security in AWS organizations. They do this with automated pipelines that use well-structured projects to create secure, easy-to-maintain and fail-tolerant solutions, one of which is their VPN product built on top of the popular OpenVPN project which has no license restrictions; you are only limited by the network card in the instance. To learn more visit: snark.cloud/deployandgoCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn and I have been remiss by not having today's guest on years ago because back before I started this ridiculous nonsense that, well, whatever it is you'd call what I do for a living, I did other things instead. I did the DevOps, which means I was sad all the time. And the thing that I enjoyed was the chance to go and speak on conference stages. One of those stages, early on in my speaking career, was at DevOpsDays Tel Aviv.My guest today is Sharone Zitzman, who was an organizer of DevOpsDays Tel Aviv, who started convincing me to come back. And today is in fact, in the strong tradition here of making up your own job titles in ways that make people smile, she is the Chief Manual Reader at RTFM Please Ltd. Sharone, thank you for joining me.Sharone: Thank you for having me, Corey. Israelis love the name of my company, but Americans think it has a lot of moxie and chutzpah. [laugh].Corey: It seems a little direct and aggressive. It's like, oh, good, you are familiar with how this is going to go. There's something to be said for telling people what you do on the tin upfront. I've never been a big fan of trying to hide that. I mean, the first iteration of my company was the Quinn Advisory Group because I thought, you know, let's make it look boring and sedate and like I can talk to finance people. And yeah, that didn't last more than ten seconds of people talking to me.Also, in hindsight, the logo of a big stylized Q. Yeah, I would have had to change that anyway, for the whole QAnon nonsense because I don't want to be mistaken for that particular brand of nuts.Sharone: Yeah, I decided to do away with the whole formalities and upfront, just go straight [laugh]. For the core of who we are, Corey; you are very similar in that. So, yes. Being a dev first company, I thought the developers would appreciate such a title and name for my company. And I have to give a shout out here to Avishai Ish-Shalom, who's my friend from the community who you also know from the DevOpsDays community.Corey: Oh, yeah @nukemberg on Twitter—Sharone: Yes exactly.Corey: For those who are not familiar.Sharone: [laugh]. Yep. He coined the name.Corey: The problem that I found is that people when they start companies or they manage their careers, they don't bias for the things that they're really good at. And it took me a long time to realize this, I finally discovered, “Ah, what am I the best at? That's right, getting myself fired for my personality, so why don't I build a business where that stops being a liability?” So, I started my own company. And I can tell this heroic retcon of what happened, but no, it's because I had nowhere else to go at that point.And would you hire me? Think about this for a minute. You, on the other hand, had options. You are someone with a storied history in community building, in marketing to developers without that either coming across as insincere or that marked condescending accent that so many companies love to have of, “Oh, you're a developer. Let me look at you and get down on my hands and knees like we're going camping and tell a story in ways that actively and passively insult you.”No, you have always gotten that pitch-perfect. The world was your oyster. And for some godforsaken reason, you looked around and decided, “Ah, I'm going to go out independently because you know what I love? Worrying.” Because let's face it, running your own company is an exercise in finding new and exciting things to worry about that 20 minutes ago, you didn't know existed. I say this from my own personal experience. Why would you ever do such a thing?Sharone: [laugh]. That's a great question. It was a long one, but a good one. And I do a thing where I hit the mic a lot because I also have. I can't control my hand motions.Corey: I too speak with my hands. It's fine.Sharone: [laugh]. Yeah, so it's interesting because I wanted to be independent for a really long time. And I wasn't sure, you know, if it was something that I could do if I was a responsible enough adult to even run my own company, if I could make it work, if I could find the business, et cetera. And I left the job in December 2020, and it was the first time that I hadn't figured out what I was doing next yet. And I wanted to take some time off.And then immediately, like, maybe a week after I started to get a lot of, like, kind of people reaching out. And I started to interview places and I started to look into possibly being a co-founder at places and I started to look at all these different options. And then just, I was like, “Well…. This is an opportunity, right? Maybe I should finally—that thing that's gnawing at the back of my head to see if, like, you know if I should go for this dream that I've always wanted, maybe now I can just POC it and see if, you know, it'll work.”And it just, like, kind of exploded on me. It was like there was so much demand, like, I just put a little, like, signal out to the world that this is something that I'm interested in doing, and everyone was like, “Ahh, I need that.” [laugh]. I wanted to take a quarter off and I signed my first clients already on February 1st, which was, like, a month after. I left in December and that—it was crazy. And since then, I've been in business. So, yeah. So, and since then, it's also been a really crazy ride; I got to discover some really exciting companies. So.Corey: How did you get into this? I found myself doing marketing-adjacent work almost entirely by accident. I started the newsletter and this podcast, and I was talking to sponsors periodically and they'd come back with, “Here's the thing we want you to talk about in the sponsor read.” And it's, “Okay, you want to give people a URL to go to that has four sub-directories and entire UTM code… okay, have you considered, I don't know, not?” And because so much of what they were talking about did not resonate.Because I have the engineering background, and it was, I don't understand what your company does and you're spending all your time talking about you instead of my painful problem. Because as your target market, I don't give the slightest of shits about you, I care about my problem, so tell me how you're going to solve my problem and suddenly I'm all ears. Spend the whole time talking about you, and I could not possibly care less and I'll fast-forward through the nonsense. That was my path to it. How did you get into it?Sharone: How did I get into it? It's interesting. So, I started my journey in typical marketing, enterprise B2B marketing. And then at GigaSpaces, we kickstarted the open-source project Cloudify, and that's when I found myself leading this project as the open-source community team leader, building, kind of, the community from the ground floor. And I discovered a whole new world of, like, how to build experience into your marketing, kind of making it really experiential and making sure that everyone has a really, really easy and frictionless way of using your product, and that the product—putting the product at the center and letting it speak for itself. And then you discover this whole new world of marketing where it's—and today, you know, it has more of a name and a title, PLG, and people—it has a whole methodology and practice, but then it was like we were—Corey: PLG? I'm unfamiliar with the acronym. I thought tech was bad for acronyms.Sharone: Right? [laugh]. So, product-led growth. But then, you know, like, kind of wasn't solidified yet. And so, a lot of what we were doing was making sure that developers had a really great experience with the product then it kind of sold itself and marketed itself.And then you understood what they wanted to hear and how they wanted to consume the product and how they wanted it to be and to learn about it and to kind of educate themselves and get into it. And so, a lot of the things that I learned in the context of marketing was very guerilla, right, from the ground up and kind of getting in front of people and in the way they wanted to consume it. And that taught me a lot about how developers consume technology, the different channels that they're involved in, and the different tools that they need in order to succeed, and the different, you know, all the peripheral experience, that makes marketing really, really great. And it's not about what you're selling to somebody; it's making your product shine and making the experience shine, making them ensure that it's a really, really easy and frictionless experience. You know, I like how [Donald Bacon 00:08:00] says it; he calls it, like, mean time to hello world, and that to me is the best kind of marketing, right? When you enable people to succeed very, very quickly.Corey: Yeah, there's something to be said for the ring of authenticity and the rest. Periodically I'll promote guest episodes on this, where it's a sponsored episode where people get up and they talk about what they're working on. And they're like, “Great. So, here's the sales pitch I want to give,” and it's no you won't because first, it won't work. And secondly, I'm sorry, whether it's a promoted episode or not, I will not publish something that isn't good because I have a reputation to uphold here.And people run into challenges an awful lot when they're trying to effectively tell their story. If you have a startup that was founded by an engineer, for example, as so many of these technical startups were, the engineer is often so deeply and profoundly in love with this problem space and the solution and the rest, but if they talk about that, no one cares about the how. I mean, I fix AWS bills, and people don't care—as a general rule—how I do that at all if they're in my target market. They don't care if it's through clever optimization, amazing tooling, doing it on-site, or taking hostages in Seattle. They care about their outcome much more than they ever do about the how.The only people who care about the how are engineers who very often are going to want to build it themselves, or work for you, or start a competitor. And it doesn't resonate in quite the same way. It's weird because all these companies are in slightly different spaces; all of them tend to do slightly different things—or very different things—but so many of the challenges that I see in the way that they're articulating what they do to customers rhymes with one another.Sharone: Yeah. So, I agree completely that developers will talk often about how it works. How it works. How does it work under the hood? What are the bits and bytes, you know?Like, nobody cares about how it works. People care about how will this make my life better, right? How will this improve my life? How will this change my life? [laugh]. As an operations engineer, if I'm, you know, crunching through logs, how will this tool change that? What my days look like? What will my on-call rotation look like? What will—you know, how are you changing my life for the better?So, I think that that's the question. When you learn how to crystallize the answer to that question and you hit it right on the mark—you know, and it takes a long time to understand the market, and to understand the buying persona, and t—and there's so much that you have to do in the background, and so much research you have to do to understand who is that person that needs to have that question answered? But once you do and you crystallize that answer, it lands. And that's the fun part about marketing, really trying to understand the person who's going to consume your product and how you can help them understand that you will make their life better.Corey: Back when I was starting out as a consultant myself, I would tell stories that I had seen in the AWS billing environment, and I occasionally had clients reach out to me, “Hey, why don't you tell our story in public?” It's, “Because that wasn't your story. That was something I saw on six different accounts in the same month. It is something that everyone is feeling.” It's, people think that you're talking about them.So, with that particular mindset on this, without naming specific companies, what themes are you seeing emerging? What are companies getting wrong when they are attempting and failing to market effectively to developers?Sharone: So, exactly what we're talking about in terms of the product pitch, in that they're talking at developers from this kind of marketing speak and this business language that, you know, developers often—you know, unless a company does a really, really good job of translating, kind of, the business value—which they should do, by the way—to engineers, but oftentimes, it's a little bit far from them in the chain, and so it's very hard for them to understand the business fluff. If you talk to them in bits and bytes of this is what my day-to-day developer workflow looks like and if we do these things, it'll cut down the time that I'm working on these things, it'll make these things easier, it'll help streamline whatever processes that are difficult, remove these bottlenecks, and help them understand, like I said, how it improves their life.But the things that I've seen breakdown is also in the authenticity, right? So obviously, the world is built on a lot of the same gimmicks and it's just a matter of whether you're doing it right or not, right? So, there's so much content out there and webcasts and webinars, and I don't know what and podcasts and whatever it is, but a lot of the time, people, their most valuable asset is their time. And if you end up wasting their time, without it being, like, really deeply valuable—if you're going to write content, make sure that there is a valuable takeaway; if you're going to create a webinar, make sure that somebody learned something. That if they're investing their time to join your marketing activities, make sure that they come away with something meaningful and then they'll really appreciate you.And it's the same idea behind the whole DevOpsDays movement with the law of mobility and open spaces that people if they find value, they'll join this open space and they'll participate meaningfully and they'll be a part of your event, and they'll come back to your event from year to year. But if you're not going to provide that tangible value that somebody takes away, and it's like, okay, well, I can practically apply this in my specific tech stack without using your tool, without having to have this very deterministic or specific kind of tech stack that they're talking about. You want to give people something—or even if it is, but even how to do it with or without, or giving them, like, kind of practical tools to try it. Or if there's an open-source project that they can check out first, or some kind of lean utility that gives them a good indication of the value that this will give them, that's a lot more valuable, I think. And practically understandable to somebody who wants to eventually consume your product or use your products.Corey: The way that I see things, at least in the past couple of years, the pandemic has sharpened an awful lot of the messaging that needs to happen. Because in most environments, you're sitting at a DevOpsDays in the front row or whatnot, and it's time for the sponsor talks and someone gets up and starts babbling and wasting your time, most people are not going to get up and leave. Okay, they will in Israel, but in most places, they're not going to get up and leave, whereas in pandemic land, it's you are one tab away from something I actually want—Sharone: Exactly.Corey: To be doing, so if you become even slightly boring, it's not going to go well. So, you have to be on message, you have to be on point or no one cares. People are like, “Oh, well what if we say the wrong thing and people wind up yelling about us on Twitter?” It's like unless it is for something horrifying, you should be so lucky because people are then talking about you. The failure mode isn't that people don't like your product, it's no one talks about it.Sharone: Yeah. No such thing as bad publicity [crosstalk 00:14:32] [laugh]—Corey: Oh, there very much is such a thing is bad publicity. Like, “I could be tweeting about your product most days,” is apparently a version of that, according to some folks. But it's a hard problem to solve for. And one of the things that continually surprises me is the things I'm still learning about this entire industry. The reason that people sponsor this show—and the rates they pay, to be direct—have little bearing to the actual size of the audience—as best we can tell; lies, damn lies, and podcast statistics; if you're listening to this, let me know. I'd love to know if anyone listens to this nonsense—but when you see all of that coming out, why are we able to charge the rates that we do?It's because the long-term value of someone who is going to buy a long-term subscription or wind up rolling out something like ChaosSearch or whatnot that is going to be a fundamental tenet of their product, one prospect becoming a customer pays for anything, I can sell a company, it will sponsor—they can pay me to sponsor for the next ten years, as opposed to the typical mass-market audience where well, I'm here to sling Casper mattresses today or something. It's a different audience and there's a different perception there. People are starting to figure out the value of—in an age where tracking is getting harder and harder to do and attribution will drive you nuts, instead of go where your audience is. Go where the people who care about the problem that you have and will experience that problem are going to hang out. And it always is wild to me to see companies missing out on that.It's, “Okay, so you're going to do a $25 million billboard ad in spotted in airports around the world talking about your company… but looking at your billboard, it makes no sense. I don't understand what it's there for.” Even as a brand awareness play, it fails because your logo is tiny in the corner or something. It's you spent that much money on ads, and maybe a buck on messaging because it seems like with all that attention you just bought, you had nothing worthwhile to say. That's the cardinal sin to me at least.Sharone: Yeah. One thing that I found—and back to our community circuit and things that we've done historically—but that's one thing that, you know, as a person comes from community, I've seen so much value, even from the smaller events. I mean, today, like with Covid and the pandemic and everything has changed all the equilibrium and the way things are happening. But some meetups are getting smaller, face-to-face events are getting smaller, but I've had people telling me that even from small, 30 to 40 people events, they'll go up and they'll do a talk and great, okay, a talk; everybody does talks, but it's like, kind of, the hallway track or the networking that you do after the talk and you actually talk to real users and hear their real problems and you tap into the real community. And some people will tell me like, I had four concrete leads from a 30-person meet up just because they didn't even know that this was a real challenge, or they didn't know that there was a tool that solves this problem, or they didn't understand that this can actually be achieved today.Or there's so many interesting technologies and emerging technologies. I'm privileged to be able to be at the forefront of that and discover it all, and I if I could, I would drop names of all of the awesome companies that work for me, that I work with, and just give them a shout out. But really, there's so many amazing companies doing, like, developer metrics, and all kinds of troubleshooting and failure analysis that's, like, deeply intelligent—and you're going to love this one: I have a Git replacement client apropos to your closing keynote of DevOpsDays 2015—and tapping into the communities and tapping into the real users.And sometimes, you know, it's just a matter of really understanding how developers are working, what processes look like, what workflows look like, what teams look like, and being able to architect your products and things around real use cases. And that you can only discover by really getting in front of actual users, or potential users, and learning from them and feedback loops, and that's the little core behind DevRel and developer advocacy is really understanding your actual users and your consumers, and encouraging them to you know, give you feedback and try things, and beta programs and a million things that are a lot more experiential today that help you understand what your users need, eventually, and how to actually architect that into your products. And that's the important part in terms of marketing. And it's a whole different marketing set. It's a whole different skill set. It's not talking at people, it's actually… ingesting and understanding and hearing and implementing and bringing it into your products.Corey: And it takes time. And you have to make yourself synonymous with a painful problem. And those problems are invariably very point-in-time specific. I don't give a crap about log aggregation today, but in two weeks from now, when I'm trying to chase down 18 different Lambdas function trying to figure out what the hell's broken this week, I suddenly will care very much about log aggregation. Who was that company that's in that space that's doing interesting things? And maybe it's Cribl, for example; they do a lot of stuff in that space and they've been a good sponsor. Great.I start thinking about those things in that light because it is—when I started having these problems, it sticks in your head and it resonates. And there's value and validity to that, but you're never going to be able to attribute that either, which is where people often lose their minds. Because for anything even slightly complicated—you're going to be selling things to big bank—great, good on you. Most of those customers are not going to go and spin up a trial in the dead of night. They're going to hear about you somewhere and think, “Ohh, this is interesting.”They're going to talk about a meeting, they're going to get approval, and at that point, you have long since lost any tracking opportunity there. So, the problem is that by saying it like this, as someone who is a publisher, let's be very clear here, it sounds like you're trying to justify your entire business model. I feel like that half the time, but I've been reassured by people who are experts in doing these things, like, oh, yeah, we have data on this; it's working. So, the alternative is either I accept that they're right or I sit here and arrogantly presume I know more about marketing than people who've devoted their entire careers to it. I'm not that bold. I am a white guy in tech, but not that much.Sharone: Yeah, I mean, the DevRel measurement problem is a known problem. We have people like [unintelligible 00:20:21] who have written about it. We have [Sarah Drasner 00:20:23], we have a million people that have written really, really great content about how do you really measure DevRel and the quality. And one of the things that I liked, Philipp Krenn, the dev advocate at Elastic once said in one of his talks that, you know, “If you're measuring your developer advocates on leads, you're a marketing organization. If you're measuring them on revenue, you're a sales organization. It's about reach, engagement, and awareness, and a lot of things that it's much, much harder to measure.”And I can say that, like, once upon a time, I used to try and attribute it at Cloudify. Like, I remember thinking, like, “Okay, maybe I could really track this back to, you know, the first touch that I actually had with this user.” It's really, really difficult, but I do remember, like, when we used to go out into the events and we were really active in the OpenStack community, in the DevOps community, and many other things, and I remember, like, even after events, like, you get all those lead gen emails. All I would say now is, like, “Hey, if you missed us at the booth, you know, and you want still want a t-shirt, you know, reach out and I'll ship it to you.” And some of those eventually, after we continued the relationship, and we, you know, when we were friends and community friends, six months later, when they moved to their next role at their next job, they were like, “Oh, now I have an opportunity to use Cloudify and I'm going to check it out.”And it's very long relationship that you have to cultivate. It has to be, you know, mutual. You have to be, you have to give be giving something and eventually is going to come back to you. Good deeds come back to you. So, I—that's my credo, by the way, good deeds come back to you. I believe in that and I try to live by that.Corey: This episode is sponsored in parts by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now EnterpriseDB has you covered wherever you deploy PostgreSQL on-premises, private cloud, and they just announced a fully-managed service on AWS and Azure called BigAnimal, all one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half-dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money, they can even help you migrate legacy applications—including Oracle—to the cloud. To learn more, try BigAnimal for free. Go to biganimal.com/snark, and tell them Corey sent you.Corey: So, I have one last question for you and it is pointed and the reason I buried it this deep in the episode is so that if I open with it, I will get letters and I'm hoping to get fewer of them. But I met you, again, at DevOpsDays Tel Aviv, and it was glorious. And then you said, “This is fun. Come help me organize it next year.”And I, like an idiot said, “Sure, that sounds awesome because I love going to conferences and it's great. So, what's involved?” “Oh, a whole bunch of meetings.” “Okay, great.” “And planning”—things I'm terrible at—“Okay.” And then the big day finally arrives where, “Great, when do we get to get on stage and tell a story?” Like, “That's the neat part. We don't.” So, I have to ask, given that it is all behind-the-scenes work that is fairly thankless unless you really screw it up because then it's very visible, what is the point of being so involved in the community?Sharone: Wow, that's a big question, Corey.Corey: It really is.Sharone: [laugh].Corey: Because you've been involved in community for a long time and you're very good at it.Sharone: It's true. It's true. Appreciate it, thank you. So, for me, first of all, I enjoy, kind of, the people aspect of it, absolutely. And that people aspect of it actually has played out in so many different ways.Corey: Oh, you mean great people, and also me.Sharone: [laugh]. Particularly you, Corey, and we will bring you back. [laugh]. And we will make sure you chop wood and carry water because eventually it'll fill your soul, you'll see. [laugh] one of the things that really I have had the privilege and honor, and having come out of, like, kind of all my community work is really the network I've built and the people that I've met.And I've learned so much and I've grown so much, but I've also had the opportunity to connect people, connect things that you wouldn't imagine, un—seemingly-related things. So, there are so many friends of mine that have grown up with me in this community, it's been already ten years now, and a lot of folks have now been going on to new adventures and are looking to kickstart their new startup and I can connect them to this investor, I can connect them to this other person who is maybe a good, you know, partner for their startup, and hiring opportunities, and something—I've had this, like, privilege of kind of being able to connect Israel to the outer world and other things and the global kind of community, and also bring really intelligent folks into the community. And this has just created this amazing flywheel of opportunity that I'm really happy to be at the center of. And I think I've grown as a person, I think our community has grown, has learned, and there's a lot of value in that, I think, yeah. We got to meet wonderful folks like you, Corey. [laugh].Corey: It has its moments. Again, you're one of those rarities in that it's almost become a trope in VC land where VCs always like, “How may I be useful?” And it's this self-serving transparent thing. Every single time you have deigned to introduce me to someone, it's been a productive conversation and I'm always glad I took the meeting. That is no small thing.A lot of people say, “I'm good at community,” which is sort of cover for, “I'm not good at anything,” but in your case, it—Sharone: [laugh]. [I'm an entrepreneur 00:24:48].—Corey: Is very much not true. Oh, yeah. I'm a big believer that ‘entrepreneur' and ‘hero' and other terms like that are things people call you; you don't call yourself that. It always feels weird for, “Oh, he's an entrepreneur.” It's like, that's a pretty lofty word for shitposting, but okay, we'll roll with it.It doesn't work that way. You've clearly invested long-term in a building reputation for yourself by building a name for yourself in the space, and I know that whenever you reach out to me as a result, you are not there to waste my time or shill some bullshit. It is always something that is going to, even if I don't love every aspect of it or agree with the core of the message you're sending, great, it is never not going to be worth my time, which is why I'm so glad I got the chance to talk to you this show.Sharone: I appreciate that. It's something that I really believe in, I don't want to waste people's time and I really only will connect folks or only really will reach out to someone if I do think that there's something meaningful for both sides. It's never only what's in it for me, also. I also want to make sure that there's something in it for the other person and it's something that makes sense and it's meaningful for both sides. I've had the opportunity of meeting such interesting folks, and sometimes it's just like, “You must meet. [laugh]. You will love each other.” You will have so much to do together or it's so much collaboration opportunity.And so yeah, I really am that type of person. And I'll even say from a personal perspective, you know, I know a lot of people, and I've even been asked from the flip side, “Okay, is this a toxic manager? Or is this a, you know, a good hire? Is this”—and I tried to provide really authentic input so people make the right decisions, or make, you know, the right contacts, or make—and that's something I really value. And I managed to build trust with a lot of really great folks—Corey: And also me—Sharone: —and it's come back to me, also. And—[laugh] and particularly you, again. [laugh].Corey: If people want to learn more about how you see the world and the space and otherwise bask in your wisdom, where's the best place to find you?Sharone: So, I'm on Twitter as @shar1z, which is SharoneZ. Basically, everyone thinks it's such a smart, or I don't know what, like, or an esoteric screen name. And I'm like, no, it's just my name, I just—the O-N-E is… the one. [laugh].So yes, shar1z on Twitter, but also my website, rtfmplease.dev, you can reach out, there's a contact form there. You can find me on the web anywhere—LinkedIn. Reach out, I answer almost all my DMs when I can. It's very rare that I don't answer DMs. Maybe there'll be a slight lag, but I do. And I really do like when folks reach out to me. I do like it when people try and make contact.Corey: And you can also be found, of course, wherever find DevOps products are sold, on stage apparently.Sharone: [laugh]. The DevOps community, that's right. @TLVCommunity, @DevOpsDaysTLV—don't out me. All those are—yes, those are also handles that I run on Twitter, it's true.Corey: Excellent.Sharone: So, when you see them all retweeting the same tweet, yes, it's happening within same five minutes, it's me.Corey: Oh, that would have made it way easier to go viral. My God, I should have just thought of that earlier.Sharone: [laugh].Corey: Thank you so much for your time. I appreciate it.Sharone: Thank you, Corey, for having me. It's been a privilege and honor being on your show and I really do think that you are doing wonderful things in the cloud space. You're teaching us, and we're all learning, and you—keep up the good work.Corey: Well, thank you. I appreciate that.Sharone: I also want to add that on proposed marketing and whatever, I do actually listen to all of your openings of all of your shows because they're not fluffy and I like that you do, like, kind of a deep explanation, a deep technical explanation of what your sponsoring product does, and it gives a lot more insight into why is this important. So, I think you're doing that right. So, anybody who's sponsoring this show, listen. Corey knows what he's doing.Corey: Well, thank you. I appreciate that. Yay, “I know what I'm doing.” That one's going in the testimonial kit. My God.Sharone: [laugh]. That's the name of this episode, “Corey knows what he's doing.”Corey: We're going to roll with it, you know. No take-backsies. Sharone Zitzman, Chief Manual Reader at RTFM Please. 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 of your podcast platform of choice, or if it's on the YouTubes smash the like and subscribe buttons, whereas if you've hated this show, exact same thing—five-star review wherever you happen to find it, smash both the buttons—but also leave an insulting comment telling me that I'm completely wrong which then devolves into an 18-page diatribe about exactly how your nonsense, bullshit product is built and works.Sharone: [laugh].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.

Great Things with Great Tech!
Episode 46 - StorPool

Great Things with Great Tech!

Play Episode Listen Later May 11, 2022 41:37


In this episode I talk with Boyan Krosnov Chief Product Officer and co-founder at StorPool. StorPool a market leading Software defined storage vendor, offering reliable and speedy storage platforms with a focus on low latency throughput... covering Public and private clouds platforms, servicing managed cloud and Service providers as well as enterprises, and SaaS vendors. Boyan an myself talk about how StorPool leverages an agnostic approach to hardware to allow StorPool to run across multiple hardware platforms and configurations while still maintaining reliable and speedy storage and how they have ridden the alternative new age IT stacks to success. StorPool was founded in 2011 and is Head Quartered out of the Sofia, Bulgaria. ☑️ Technology and Technology Partners Mentioned: Block Storage, Storage, NVMe, Object Storage, Kubernetes, VMware, KVM, Hyper-V, OpenStack, Cloudstack, Software Defined Storage ☑️ Raw Talking Points: MSP Angle Cloud Platforms SDS 2.0 Hows it designed and architected Filesystem? Object Storage Based? Pooling of capacity and performance Standard storage, storage and compute PERFORMANCE methodology IOPS/Latency/Storage Consumption Decreasing latency Proper Benchmarking Resiliency Failure domains/resolution Differential? Storage Protocols Distributed Storage? Running on any hardware Future of storage with public cloud and more managed data platforms Continuous Improvement process New-Age IT Stacks ☑️ Web: https://storpool.com/ ☑️ Interested in being on #GTwGT? Contact via Twitter @GTwGTPodcast or go to https://www.gtwgt.com ☑️ Music: https://www.bensound.com

Cloud Talk
Episode 106: Building Tech Culture at Rackspace Technology

Cloud Talk

Play Episode Listen Later Mar 23, 2022 28:33


Join our new EVP & Chief Technology Officer, Srini Koushik, alongside our host, Jeff DeVerter, on #RackspaceLive to take a deep dive into building tech culture at Rackspace Technology and the latest and greatest trends in the industry! Technology #Culture #TechCulture #Innovation

Software Defined Talk
Episode 349: The Janitor Strategy for Developer-led Sales, also, The School of the Philosophy of Rocks and Time

Software Defined Talk

Play Episode Listen Later Mar 18, 2022 67:15


The Janitor Strategy for Developer-led Sales, also, The School of the Philosophy of Rocks and Time This week, Coté and Matt define three sales model for doing developer-led sales. Also, we know that clown fish are optional, but do rocks need to exist? Register here to be invited to future Software Defined Meetups (https://docs.google.com/forms/d/1HabWg2nxKf2-qAavMSihlHbACjpr-qVDJFeBTKAJZJQ/edit). Mood Board: How many of you watch streaming? hotdogheadexplosion37 - “I'm your host, exploding hotdog.” hotdogheadexplosion37 solves agile financing problems. I'm your host, ExplodingHotDogMan What if rocks didn't exist? I didn't take “Philosophy of Rocks 101 in college, but I did take hydrobiology 379.” This is what happens when Brandon's not here Legal week B to D sales The Janitorial Sales Model - vendor creates mess, drives uncontrolled/ungoverned/decentralized viral spread. The Mary Poppins Model Graffiti Proof Paint Model ## Rundown Rocks. The End of Daylight Saving Time? (https://twitter.com/senatecloakroom/status/1503797632745025542) Dell Striving To ‘Embrace Developers In A Big Way': Michael Dell (https://www.crn.com/news/data-center/dell-striving-to-embrace-developers-in-a-big-way-michael-dell) ## Relevant to your Interests Congratulations to The Cloudcast, 600 Shows! (https://twitter.com/thecloudcastnet/status/1504070851376910341?s=20&t=g_261CFiP9bXnIgAxGhG6A) Death by PowerPoint: the slide that killed seven people — mcdreeamie-musings (https://mcdreeamiemusings.com/blog/2019/4/13/gsux1h6bnt8lqjd7w2t2mtvfg81uhx) Birdeye Raises $60M Series C Funding Led by Accel-KKR to Help Local Businesses Grow (https://www.prnewswire.com/news-releases/birdeye-raises-60m-series-c-funding-led-by-accel-kkr-to-help-local-businesses-grow-301499886.html) Commercial satellites test the rules of war in Russia-Ukraine conflict (https://www.washingtonpost.com/technology/2022/03/10/commercial-satellites-ukraine-russia-intelligence/) Google Cloud and VMware expand partnership with focus on cloud migrations (https://siliconangle.com/2022/03/16/google-cloud-vmware-expand-partnership-focus-cloud-migrations/) The Conversation: Twitter Trends 2022 (https://marketing.twitter.com/en/insights/the-conversation-twitter-trends-2022-btc) Google's domain name registrar is out of beta after seven years (https://www.engadget.com/google-domains-beta-201056792.html?src=rss) Amazon just introduced a bizarre metaverse-like game to train people how to use AWS (https://www.cnbc.com/2022/03/15/amazon-launches-metaverse-like-game-to-train-people-how-to-use-aws.html) The first RISC-V portable computer is now available (https://lunduke.substack.com/p/the-first-risc-v-portable-computer) Launching Valid Capital (https://zachholman.com/posts/launching-valid-capital) Veracode Announces Significant Growth Investment From TA Associates | Veracode (https://www.veracode.com/blog/security-news/veracode-announces-significant-growth-investment-ta-associates?mkt_tok=NzkwLVpLVy0yOTEAAAGDLUxgknNx2RnwA_RGOOCwibpdAPgKpM0oYFV4AIIlXQjBpYcPVvt3195gmAPK_qM8s9R_biDaz_muNzwGiEN1PbUqWtqKcfbsXiZDkm14z9aOAg) Canonical bullish on OpenStack (https://www.theregister.com/2022/03/14/canonical_bullish_on_openstack/) Facebook's Parent Company Will Make Employees Do Their Own Laundry (https://www.nytimes.com/2022/03/11/technology/facebook-meta-perks.html) The next big SaaS player will be the company that solves enterprise billing (https://www.protocol.com/enterprise/enterprise-saas-billing-market-sequoia#toggle-gdpr) The long-term strategy behind IBM's Red Hat purchase (https://www.theregister.com/2022/03/11/ibm_redhat_strategy/) HashiCorp beats expectations in first quarterly earnings report since going public (https://siliconangle.com/2022/03/10/hashicorp-beats-expectations-first-quarterly-earnings-call-since-going-public/) Oracle's cloud business seen as 'the driver,' of Q3 results (https://seekingalpha.com/news/3811176-oracle-q3-results-on-tap-cloud-still-the-driver-moness-crespi-hardt-says) ## Nonsense Facebook Libra: the inside story of how the company's cryptocurrency dream died (https://www.ft.com/content/a88fb591-72d5-4b6b-bb5d-223adfb893f3) Winamp joins LimeWire in the emerging "legacy software comes back from the dead to do NFTs" trope (https://web3isgoinggreat.com/?id=2022-03-16-0) One of the greatest videos in all of sports (https://twitter.com/CJToledano/status/1502095289628332034) The time Vladimir Putin stole Robert Kraft's Super Bowl ring (https://twitter.com/kendallbaker/status/1304007930975457280) ## Sponsors strongDM — Manage and audit remote access to infrastructure. Start your free 14-day trial today at strongdm.com/SDT (http://strongdm.com/SDT) Postlight — Postlight co-founders Paul Ford and Rich Ziade talk tech, business, ethics, and culture. Subscribe to the Postlight Podcast: https://postlight.com/podcast ## Conferences .Net Beyond conference (https://tanzu.vmware.com/developer/tv/dotnet-beyond?utm_source=cote&utm_medium=podcast&utm_content=sdt), March 30–31, 2022, online. THAT Conference comes to Texas (https://that.us/events/tx/2022/), May 23-26, 2022 Discount Codes: Everything Ticket ($75 off): SDTFriends75 3 Day Camper Ticket ($50 off): SDTFriends50 Virtual Ticket ($75 off): SDTFriendsON75 THAT Conference Wisconsin (https://that.us/call-for-counselors/wi/2022/), July 25, 2022 DevOps Days Birmingham AL, (https://www.papercall.io/devopsdays-2022-birmingham-al), April 18 & 19th, 2022 Spring Tour Chicago (https://tanzu.vmware.com/developer/springone-tour/2022/chicago/), April 26th to 27th. DevOpsDays Austin 2022 (https://devopsdays.org/events/2022-austin/welcome/), May 4 - 5, 2022 DevOpsDays Chicago 2022: (https://sessionize.com/devopsdays-chicago-2022/), May 10 & 11th, 2022 Splunk's ,conf (http://Splunk's ,conf June 13-16, 2022), June 13-16, 2022 SpringOne Platform (https://springone.io/?utm_source=cote&utm_medium=podcast&utm_content=sdt), SF, December 6–8, 2022. ## SDT news & hype Join us in Slack (http://www.softwaredefinedtalk.com/slack). Get a SDT Sticker! Send your postal address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and we will send you free laptop stickers! Follow us on Twitch (https://www.twitch.tv/sdtpodcast), Twitter (https://twitter.com/softwaredeftalk), Instagram (https://www.instagram.com/softwaredefinedtalk/), LinkedIn (https://www.linkedin.com/company/software-defined-talk/) and YouTube (https://www.youtube.com/channel/UCi3OJPV6h9tp-hbsGBLGsDQ/featured). Use the code SDT to get $20 off Coté's book, (https://leanpub.com/digitalwtf/c/sdt) Digital WTF (https://leanpub.com/digitalwtf/c/sdt), so $5 total. Become a sponsor of Software Defined Talk (https://www.softwaredefinedtalk.com/ads)! ## Recommendations Coté: Amazon Fresh store in London Matt: The Kubernetes Podcast 170 (https://kubernetespodcast.com/episode/170-kubernetes-the-documentary/): The Kubernetes Documentary (https://kubernetespodcast.com/episode/170-kubernetes-the-documentary/)

Percona's HOSS Talks FOSS:  The Open Source Database Podcast
Talking About Open Source Community, the CNCF, Rancher & Suse - Percona Podcast #56 /w Matt Farina

Percona's HOSS Talks FOSS: The Open Source Database Podcast

Play Episode Listen Later Mar 17, 2022 43:25


This is a double Matt episode of the HOSS talks FOSS! The Head of Open Source Strategy at Percona, Matt Yonkovit, sits down with Matt Farina, Distinguished Engineer at SUSE to talk about starting out in open source, what helped Matt become a better contributor in the community, and his work on many projects including OpenStack, Kubernetes, and Rancher.  Matt Farina talks about how his drive to understand how things work lead him into the depths of some open source code (from Drupal to OpenStack, to Rancher).  Matt was drawn to containers, orchestration, docker, and technologies like Kubernetes, etc. The pair of Matts dig into the ongoing and upcoming projects at Rancher and Suse, their shared experience in Kubernetes,  and Matt's ( Farina ) work with the CNCF as part of their Technical Oversight Committee (TOC).

Great Things with Great Tech!
Episode 42 - Mirantis Lens

Great Things with Great Tech!

Play Episode Listen Later Mar 17, 2022 43:35


In this episode I talk with Miska Kaipiainen, VP Engineering, Strategy & Open Source Software at Mirantis. Mirantis helps organizations ship code faster on public and private clouds. They provide a public cloud experience on any infrastructure from the data center to the edge. Miska focuses in on Lens which empowers a new breed of Kubernetes developers by removing infrastructure and operations complexity and providing one cohesive cloud experience for complete app and DevOps portability. We also cover the current state of Kubernetes adoption and how focusing on developers with Lens as a Kubernetes IDE has seen tremendous growth for the product, which is Open Source. Mirantis was founded in 1999 and is headquartered in Campbell, California. ☑️ Technology and Technology Partners Mentioned: Kubernetes, Mesosphere, Docker Enterprise, Docker Swarm, OpenStack, Open Source ☑️ Raw Talking Points: Container Orchestration Kontena days Origin of Lens Mirantis Len acquisition Strong community support Operations vs Development Why is a Kubernetes IDE important Where is Kubernetes uptake today Enterprise Adoption OpenSource - Organic growth Community stop marketing Service and Support K0s DevOps Care Team Spaces Managed Dev Cluster Multi-Cluster manangement Multi-platform ☑️ Web: https://www.mirantis.com/ https://k8slens.dev/ ☑️ Interested in being on #GTwGT? Contact via Twitter @GTwGTPodcast or go to https://www.gtwgt.com☑️ Music: https://www.bensound.com

tech STACK$
As investor interest in crypto grows, Betterment acquires Makara to meet the demand

tech STACK$

Play Episode Listen Later Mar 10, 2022 26:54


Sean dives back into the world of crypto, talking to  Mike Reust, president at Betterment, and Jesse Proudman, Makara CEO, about Betterment's purchase of Makara. They discuss how important crypto has become to portfolios and Makara's future plans. Guest Bios: Jesse Proudman is a Seattle-based entrepreneur. He founded Blue Box, which provided private cloud as a service based on OpenStack technology. The company was sold to IBM in 2015. In 2018, after leaving IBM, he founded Strix Leviathan, which builds an investment management platform for crypto currencies. In 2021, he founded Makara, which aims to make it more simple to invest in crypto by creating “thematic baskets” that can meet various goals and interests, such as the largest coins or emerging trends. Mike Reust is president at Betterment. His goal is to lead the retail business at Betterment, helping deliver solutions to customers that wrangle the complexity of the American financial system. He has been with Betterment since 2016.  

FLOSS Weekly (MP3)
FLOSS Weekly 668: Marketing Open Source - Rob La Gessee, OpenStack, AWS

FLOSS Weekly (MP3)

Play Episode Listen Later Feb 16, 2022 67:00


Rob La Gesse, whose career spans business, military, politics and other fields, tells Doc Searls and Katherine Druckman how inventive marketing helped make Rackspace a social media star while the company also teamed up with NASA and others on OpenStack, which is still helping grow the cloud business outside of Amazon. Hosts: Doc Searls and Katherine Druckman Guest: Rob La Gesse Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsors: kolide.com/twit itpro.tv/twit promo code TWIT30 Compiler - FLOSS

FLOSS Weekly (Video HD)
FLOSS Weekly 668: Marketing Open Source - Rob La Gessee, OpenStack, AWS

FLOSS Weekly (Video HD)

Play Episode Listen Later Feb 16, 2022 67:19


Rob La Gesse, whose career spans business, military, politics and other fields, tells Doc Searls and Katherine Druckman how inventive marketing helped make Rackspace a social media star while the company also teamed up with NASA and others on OpenStack, which is still helping grow the cloud business outside of Amazon. Hosts: Doc Searls and Katherine Druckman Guest: Rob La Gesse Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsors: kolide.com/twit itpro.tv/twit promo code TWIT30 Compiler - FLOSS

All TWiT.tv Shows (Video LO)
FLOSS Weekly 668: Marketing Open Source

All TWiT.tv Shows (Video LO)

Play Episode Listen Later Feb 16, 2022 67:19


Rob La Gesse, whose career spans business, military, politics and other fields, tells Doc Searls and Katherine Druckman how inventive marketing helped make Rackspace a social media star while the company also teamed up with NASA and others on OpenStack, which is still helping grow the cloud business outside of Amazon. Hosts: Doc Searls and Katherine Druckman Guest: Rob La Gesse Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsors: kolide.com/twit itpro.tv/twit promo code TWIT30 Compiler - FLOSS

All TWiT.tv Shows (MP3)
FLOSS Weekly 668: Marketing Open Source

All TWiT.tv Shows (MP3)

Play Episode Listen Later Feb 16, 2022 67:00


Rob La Gesse, whose career spans business, military, politics and other fields, tells Doc Searls and Katherine Druckman how inventive marketing helped make Rackspace a social media star while the company also teamed up with NASA and others on OpenStack, which is still helping grow the cloud business outside of Amazon. Hosts: Doc Searls and Katherine Druckman Guest: Rob La Gesse Download or subscribe to this show at https://twit.tv/shows/floss-weekly Think your open source project should be on FLOSS Weekly? Email floss@twit.tv. Thanks to Lullabot's Jeff Robbins, web designer and musician, for our theme music. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Sponsors: kolide.com/twit itpro.tv/twit promo code TWIT30 Compiler - FLOSS

Innovation Now
Plugging into the Cloud

Innovation Now

Play Episode Listen Later Jan 25, 2022


Researchers built this cloud controller from scratch using technology that is free and available to all.

linkmeup. Подкаст про IT и про людей
LTE №17. Как запустить публичное облако

linkmeup. Подкаст про IT и про людей

Play Episode Listen Later Jan 9, 2022


Начинаем 2022-й с эпизода LTE. История о том, как зарождалось публичное Облако, и как оно из стартапа превратилось в коммерческий продукт, увеличившись с one-pizza team до нескольких сотен человек. В гостях Валенинтин Синицын и Полиевкт Пчелинцев - два инженера и два руководителя, стоявшие у истоков. Поговорили про: Openstack в Яндексе - крупнейший кластер в России. Почему он не стал фундаментом публичного Облака? POC на Openstack всё же был. И он всё ещё шлёт уведомления о своём здоровье Компонентная база - де-факто стандарты в индустрии, Open-Source и In-house решения Откуда взять Control Plane? Роль личности. Ян Лещинский Что за слова такие: гиперконвергентность, догфудинг, селф-хостинг, текникал-превью За 3 месяца до запуска все диаграммы гантта и берндауны перестают работать Экстремальный канбан, в котором порой за день съезжаешь на день-два Technical preview - даже в тестовом кластере нельзя отобрать то, что дали Взросление: то, что было нормой в первые месяцы, в последующие стало инцидентом Стабильность — это тоже фича. Сообщение LTE №17. Как запустить публичное облако появились сначала на linkmeup.

Giant Robots Smashing Into Other Giant Robots
405: RackN Digital Rebar with Rob Hirschfeld

Giant Robots Smashing Into Other Giant Robots

Play Episode Listen Later Dec 23, 2021 47:24


Chad talks to Rob Hirschfeld, the Founder and CEO of RackN, which develops software to help automate data centers, which they call Digital Rebar. RackN is focused on helping customers automate infrastructure. They focus on customer autonomy and self-management, and that's why they're a software company, not a services or as-a-service platform company. Digital Rebar is a platform that helps connect all of the different pieces and tools that people use to manage infrastructure into infrastructure pipelines through the seamless multi-component automation across all of the different pieces and parts that have to be run to bring up infrastructure. RackN's Website (https://rackn.com/); Digial Rebar (https://rackn.com/rebar/) Follow Rob on Twitter (https://twitter.com/zehicle) or LinkedIn (https://www.linkedin.com/in/rhirschfeld/). Visit his website at robhirschfeld.com (https://robhirschfeld.com/). Follow RackN on Twitter (https://twitter.com/rackngo), LinkedIn (https://www.linkedin.com/company/rackn/), or YouTube (https://www.youtube.com/channel/UCr3bBtP-pMsDQ5c0IDjt_LQ). Follow thoughtbot on Twitter (https://twitter.com/thoughtbot), or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Rob Hirschfeld, Founder, and CEO of RackN, which develops software to help automate data centers, which they call Digital Rebar. Rob, welcome to the show ROB: Chad, it is a pleasure to be here. Looking forward to the conversation. CHAD: Why don't we start with a little bit more information about what RackN and the Digital Rebar platform actually is. ROB: I would be happy to. RackN is focused on helping customers automate infrastructure. And for us, it's really important that the customers are doing the automation. We're very focused on customer autonomy and self-management. It's why we're a software company, not a services or as a service platform company. But fundamentally, what Digital Rebar does is it is the platform that helps connect all of the different pieces and tools that people use to manage infrastructure into infrastructure pipelines through the seamless multi-component automation across all of the different pieces and parts that have to be run to bring up infrastructure. And we were talking data centers do a lot of on-premises all the way from the bare metal up. But multi-cloud, you name it, we're doing infrastructure at that level. CHAD: So, how agnostic to the actual bare metal are you? ROB: We're very agnostic to the bare metal. The way we look at it is data centers are heterogeneous, diverse places. And that the thing that sometimes blocks companies from being innovative is when they decide, oh, we're going to use this one vendor for this one platform. And that keeps them actually from moving forward. So when we look at data centers, the heterogeneity and sometimes the complexity of that environment is a feature. It's not a bug from that perspective. And so it's always been important to us to be multi-vendor, to do things in a vendor-neutral way to accommodate the quirks and the differences between...and it's not just vendors; it's actually user choice. A lot of companies have a multi-vendor problem (I'm air quoting) that is actually a multi-team problem where teams have chosen to make different choices. TerraForm has no conformance standard built into it. [laughs] And so you might have everybody in your company using TerraForm and Ansible happily but all differently. And that's the problem that we walk into when we walk into a data center challenge. And you can't sweep that under the rug. So we embraced it. CHAD: What kind of companies are your primary customers? ROB: We're very wide-ranging, from the top banks use us and deploy us, telcos, service providers, very large scale service providers use us under the covers, media companies. It really runs the gamut because it's fundamentally for us just about infrastructure. And our largest customers are racing to be the first to deploy. And it's multi-site, but 20,000 machines that they're managing under our Digital Rebar management system. CHAD: It's easy, I think, depending on where you sit and your experiences. The cloud providers today can overshadow the idea that there are even people who still have their own data centers or rent a portion of a data center. In today's ecosystem, what are some of the factors that cause someone to do that who isn't an infrastructure provider themselves? ROB: You know the funny thing about these cloud stories (And we're talking just the day after Amazon had a day-long outage.) is that even the cloud providers don't have you give up operation. You're still responsible for the ops. And for our customers, it's not like they can all just use Lambdas and API gateways. At the end of the day, they're actually doing multi-site distributed operations. And they have these estates that are actually it's more about how do I control distributed infrastructure as much as it is about repatriating. Now, we do a lot to help people repatriate. And they do that because they want more control. Cost savings is a significant component with this. You get into the 1000s of machines, and that's a big deal. Even at hundreds of machines, you can save a lot of money compared to what you get in cloud. And I think people get confused with it being an or choice. It really is an and choice. Our best customers are incredibly savvy cloud users. They want that dynamic, resilient very API-driven environment. And they're looking to bring that throughout the organization. And so those are the ones that get excited when they see what we've done because we spend a lot of time doing infrastructure as code and API-driven infrastructure. That's really what they want. CHAD: Cool. So, how long have you been working on RackN? When did you found it? ROB: [laughs] Oh my goodness. So RackN is seven years old. Digital Rebar, we consider it to be at its fourth generation, but those numbers actually count back before that. They go back to 2009. The founding team was actually at Dell together in the OpenStack heyday and even before the OpenStack heyday. And we were trying to ship clouds from the Dell Factory. And what we found was that every customer had this bespoke data center we've already talked about. And we couldn't write automation that would work customer to customer to customer. And it was driving us nuts. We're a software team, not a hardware team inside of Dell. And the idea that if I fixed something in the delivery or in their data center, and couldn't go back to their data center because it was different than what the next customer needed and the next customer needed, we knew that we would never have a community. It's very much about this community and reuse pattern. There's an interesting story that I picked up from SREcon actually where they were talking about the early days of boilers. This is going back a few centuries ago. But when they first started putting boilers into homes and buildings, there was no pattern, there was no standard. And everybody would basically hire a plumber or a heating architect. Heating architect was a thing. But you'd build a boiler and every one was custom, and every one was different. And no surprise, they blew up a lot, and they caused fires. And buildings were incredibly unsafe because they were working on high-pressure systems with no pattern. And it took regulation and laws and standards. And now nobody even thinks about it. You just take standard parts, and you connect them together in standard ways. And that creates actually a much more innovative system. You wouldn't want every house to be wired uniquely either. And so when we look at the state of automation today, we see it as this pre-industrial pre-standardization process and that companies are actually harmed and harming themselves because they don't have standards, and patterns, and practices that they can just roll and know they work. And so that philosophy started way back in 2009 with the first generation which was called Crowbar. Some of your audience might even remember this from the OpenStack days. It was the first OpenStack installer built around Chef. And it had all sorts of challenges in it, but it showed us the way. And then we iterated up to where Digital Rebar is today. Really fully infrastructure as code, building infrastructure pipelines, and a lot of philosophical pieces we've learned along the way. CHAD: So you were at Dell working on this thing. How did you decide to leave Dell and start something new? ROB: Dell helped me with that decision. [laughs] So the challenge of being a software person inside of Dell especially at the time, Crowbar was open-source which did make it easier for us to say, "Hey, we want to part ways but keep the IP." And the funny thing is there's not a scrap of Crowbar in Digital Rebar except one or two naming conventions that we pulled forward and the nod of the name, that Rebar is a nod to Crowbar. But what happened was Dell when it went private, really did actually double down on the hardware and the more enterprise packaged things. They didn't want to invest in DevOps and that conversation that you need to have with your customers on how they operate, the infrastructure you sold them. And that made Dell not a very good place for me and the team. And so we left Dell, looked at the opportunity to take what we'd been building with Crowbar and then make it into a product. That's been a long journey. CHAD: Now, did you bootstrap, or did you take investment? ROB: We took [laughs] a little bit of investment. We raised some seed funding. Certainly not what was in hindsight was going to be sufficient for us to do it. But we thought at the time that we had something that was much more product-ready for customers than it was. CHAD: And what was the challenge that you found? What was the surprise there that it wasn't as ready as you thought? ROB: So what we've learned in our space specifically...and there are some things that I think apply to everybody, and there are some things that you might be able to throw on the floor and ignore. I was a big fan of Minimum Viable Product. And it turned out that the MVP strategy was not at all workable with customers in data centers. Our product is for people running production data centers. And nobody's going to put in software to run a data center that is MVP. It has to be resilient. It has to be robust. It has to be simple enough that they can understand it and solve some core problems, which is still sort of an MVP idea. But it can't be oops. [laughs] You can't have a lot of oops moments when you're dealing with enterprise infrastructure automation software. It has to work. And importantly, and as a design note, this has been a lesson for us. If it does break, it has to break in very transparent, obvious ways. And I can't emphasize that enough. There's so much that when we build it, we come back and like, was it obvious that it broke? Is it obvious that it broke in a way that you can fix? CHAD: And it's part of the culture too to do detailed post mortems with explanations and be as transparent as possible or at least find the root cause so that you can address it. That's part of the culture of the space too, right? ROB: You'd like to hope so. [laughs] CHAD: Okay. [laughs] In my experience, that's the culture of the space. ROB: You're looking more at a developer experience. But even with a developer, you've got to be in a post mortem or something. And it's like everybody's pointing to the person to the left and the right sort of by human nature. You don't walk into that room assuming that it was your fault, and you should, but that's not how it usually is approached. And what we find in the ops space, and I would tell people to work around this pattern if they can, is that if you're the thing doing the automation, you're always the first cause of the problem. So we run into situations where we're doing a configuration, and we find a vendor bug or a glitch or there's something, and we found it. It's our problem whether we were the cause or not. And that's super hard. I think that people on every side of any type of issue need to look through and figure out what the...the blameless post mortem is a really important piece in all this. At the end of the day, it's always a human system that made a mistake or has something like that. But it's not as simple as the thing that told you the bad news that the messenger was at fault. And there's a system design element to that. That's what we're talking about here is that when you're exposing errors or when something's not behaving the way you expect, our philosophy is to stop. And we've had some very contentious arguments with customers who were like, "Just retry until it fixes itself," or vendors who were like, "Yeah, if you retry that thing three times, [laughs] then it'll magically go away." And we're like, that's not good behavior. Fix the problem. It actually took us years to put a retry element into the tasks so that you can say, yeah, this does need three retries. Just go do it. We've resisted for a long time for this reason. CHAD: So you head out into the market. And did you get initial customers, or was there so much resistance to the product that you had that you struggled to get even first customers? ROB: We had first customers. We had a nice body of code. The problem is actually pretty well understood even by our customers. And so it wasn't hard for them to get a trial going. So we actually had a very profitable customer doing...it was in object storage, public object storage space. And they were installing us. They wanted to move us into all their data centers. But for it to work, we ended up having an engineer who basically did consulting and worked with them for the better part of six months and built a whole bunch of stuff, got it working. They could plug in servers, and everything would set itself up. And they could hit a button and reset all the servers, and they would talk to the switches. It was an amazing amount of automation. But, and this happens a lot, the person we'd been working with was an SRE. And when they went to turn it over to the admins in the ops team, they said, [laughs] "We can't operate. There's too much going on, too complex." And we'd actually recognized...and this is a really serious challenge. It's a challenge now that we're almost five years into the generation that came after that experience. And we recognized there was a problem. And that this wasn't going to create that repeatable experience that we were looking for if it took that much. At the same time, we had been building what is now Digital Rebar in this generation that was a single Golang binary. All the services were bundled into the system. So it listened on different ports but provide all the services, very easy to install, really, really simple. We literally stripped everything back to the basics and restarted. And we had this experience where we sat down with a customer who had...I'm going to take a second and tell the story because this is such a compelling story from a product experience. So we took our first product. We were in a bake-off with another bare metal focus provisioning at the time. And they were in a lab, and they set our stuff up. And they turned it on, and they provisioned. And they set up the competitor, and they turned it on and provisioned. And both products worked. Our product took 20 minutes to go through the cycle and the competitor took 3. And the customer came back and said, "I can't use this. I like your product better. It has more controls with all this stuff." But it took 20 minutes instead of 3. We actually logged into the system, looked at it and we were like, "Well, that's because it recognized that your BIOS was out of date, patched your BIOS, updated the system, checked that it was right, and then rebooted the systems and then continued on its way because it recognized your systems were outdated automatically. And he said, "I didn't want it to do that. I needed it to boot as quickly as possible." And literally, [laughs] we were in the middle of a team retreat. So it's like, the CTO is literally excusing himself on the table to talk to the guy to make this stuff, try and make it right. And he's like, "Well, we've got this new thing. Why don't you install this, what's now Digital Rebar, on the system and repeat the experiment?" And he did and Digital Rebar was even faster than the competitor. And it did exactly just install, booted, and was done. And he came back to the table, and it took 15 minutes to have the whole conversation to make everything work. It was that much of a simpler design. And he sat down and told the story. And I was in the middle of it. I'm just like, "We're going to have to pivot and put everything into the new version," which is what we did. And we just ripped out the complexity. And then over the last couple of years now, we've built the complexity back into the system to do all those additional but much more customer-driven from that perspective. CHAD: How did you make sure that as you were changing your focus, putting all of your energy into the new version that you [laughs] didn't introduce too much risk in that process or didn't take too long? ROB: [laughs] We did take too long and introduced too much risk, and we did run out of money. [laughs] All those things happened. This was a very difficult decision. We thought we could get it done much faster. The challenge of the simpler product was that it was too simple to be enough in customers' data centers. And so yeah, we almost went out of business in the middle of all this cycle. We had a time where RackN went back down to just the two founders. And at this point, we'd gotten far enough with the product that we knew it was the right thing. And we'd also embedded a degree...with the way we do the UX, we have this split. The UX runs on a hosted system. It doesn't have to but by default, it does. And then we have the back end. So we were very careful about how we collected metrics because you really need to know who's downloading and using your products. And we had enough data from that to realize that we had some very committed early users and early customers, just huge brand names that were playing around. So we knew that we'd gotten this mix right, that we were solving a problem in a unique way. But it was going to take time because big companies don't make decisions quickly. We have a joke. We call it the reorg half-life problem. So the half-life of a reorg in any of our customers is about nine months. And either you're successful inside of that reorg half-life, or you have to be resilient across this reorg half. And so initially, it was taking more than nine months. We had to be able to get the product in play. And once we did, we had some customers who came in with very big checks and let us come back and basically build back up. And we've been adding some really nice names into our customer roster. Unfortunately, it's all private. I can tell you their industries and their scale, but I can't name them. But that engagement helped drive us towards the feature set and the capabilities and building things up along that process. But it was frustrating. And some of them, especially at the time we were open-source, were very happy to say, "No, we are a super big brand name. We don't pay for software." I'm like, "Most profitable, highest valued companies in the world you don't want to pay for this operational software?" And they're like, "No, we don't have to." And that didn't sit very well with us. Very hard, as a starting startup, it was hard. CHAD: At the time, everything you were doing was open source. ROB: So in the Digital Rebar era, we were trying to do Open Core. Digital Rebar itself was open. And then we were trying to hold back the BIOS patches, integrate enterprise single sign-on. So there was a degree of integration pieces that we held back as RackN and then left the core open. So you could use Digital Rebar and run it, which we had actually had a lot of success with people downloading, installing, and running Digital Rebar, not as much success in getting them to pay us for that privilege. CHAD: So, how did you adjust to that reality? ROB: We inverted the license. After we landed a couple of big banks and we had several others and some hyperscalers too who were like, "This is really good software. We love it. We're embedding it in our service, but we're not going to pay you." And then they would show up with bugs and complaints and issues and all sorts of stuff still. And what happened is we started seeing them replicating the closed pieces. The APIs were open. We actually looked at it and listening to our communities, they wanted to see what was in the closed pieces. That was actually operationally important for them to understand how that stuff worked. They never contributed or asked to see anything in the core. And, there's an important and here, and they needed performance improvements in the core that were radically different. So the original open-source stuff went to maybe 500 machines, and then it started to cap out. And we were like, all right, we're going to have to really rewrite the data store mechanisms that go with this. And the team looked at each other and were like, "We're not going to open source that. That's really complex and challenging IP." And so we said the right model for us is going to be to make the core closed and then allow our community and users to see all the things that they are actually using to interact with their environment. And it ends up being a little bit of a filter. There are people who only use open-source software. But those companies also don't necessarily want to pay. When I was an open-source evangelist, this was always a problem. You're pounding on the table saying, "If you're using open-source software, you need to understand who to pay for that service, that software that you're getting. If you're not paying for it, that software is going to go away." In a lot of cases, we're a walking example of that. And it's funny, more of the codebase is open today than it was then. [chuckles] But the challenge is that it's really an open ecosystem now because none of that software is particularly useful without the core to run it and glue everything together. CHAD: Was that a difficult decision to make? Was it controversial? ROB: Incredibly difficult. It was something I spent a lot of time agonizing about. My CTO is much clear-eyed on this. From his perspective, he and the other engineers are blood, sweat, and tears putting this in. And it was very frustrating for them to see it running people's production data centers who told us, and this is I think the key, who just said to us, "You know, we're not going to pay money for that." And so for them, it was very clear-eyed it's their work, their sweat equity, very gut feeling for that. For me, I watched communities with open-source routes, you know, the Kubernetes community. I was in OpenStack. I was on the board for that. And there is definitely a lift that you get from having free software and not having the strings. And I also like the idea that from a support perspective, if you're using open-source software, you could conceivably not care for the vendor that went away. You could find another life for it. But years have gone by and that's not actually a truism that when you are using open-source software if you're getting it from a vendor, you're not necessarily protected from that vendor making decisions for you. CentOS is a great...the whole we're about to hit the CentOS deadlines, which is the Streams, and you can't get other versions. And we now have three versions of CentOS, at least three versions of CentOS with Rocky, and Alma, and CentOs Streams. Those are very challenging decisions for people running enterprise data centers, not that simple. And nobody in our communities is running charity data centers. There's no goodwill charity. I'm running a data center out of the goodness of my heart. [laughs] They are all production systems, enterprise. They're doing real production work. And that's a commercial engagement. It's not a feel-good thing. CHAD: So what did you do in your decision-making process? What pushed you, or what did you come to terms with in order to make that change? ROB: I had to admit I was wrong. [laughter] I had to think back on statements I'd made and the enthusiasm that I'd had and give up some really hard beliefs. Being a CEO or a founder is the same process. So I wish I could say this was the only time [laughs] I had to question, you know, hard-made assumptions, or some core beliefs in what I thought. I've had to get really good at questioning when am I projecting this is the way I want the world to be therefore it will be? That's a CEO skill set and a founder skill set...and when that projection is having you on thin ice. And so you constantly have to make that balance. And this was one of those ones where I'm like, all right, let's do it. And I still wake up some mornings and look at people who are open source only and see how much press they get or how easy it is for them to get mentions and things like that. And I'm like, ah, God, that'd be great. It feels like it's much harder for us because we're commercial to get the amplification. There are conferences that will amplify open-source TerraForm, great example. It gets tons of amplification for being a single vendor project that's really tightly controlled by HashiCorp. But nobody is afraid to go talk about TerraForm and mention TerraForm and do all this stuff, the amazing use of open source by that company. But they could turn it and twist it, and they could change it. It's not a guarantee by any stretch of the imagination. CHAD: Well, one of the things that I've come to terms with, and maybe this is a very positive way of looking at it, instead of that you were wrong, [laughter] is to realize that well, you weren't necessarily wrong. It got you to where you were at that point. But maybe in order to go to the next level, you need to do something different. And that's how I come to terms with some things where I need to change my thinking. ROB: [laughs] I like that. It's good. Sometimes you can look back and be like, yeah, that wasn't the right thing and just own it. But yeah, it does help you to know the path. Part of the reason why I love talking about it with you like this is it's not just Rob was wrong; we're actually walking the path through that decision. And it's easy to imagine us sitting in...we're in a tiny, little shared office listening to calls where...I'll tell you this as a story to make it incredibly concrete because it's exactly how this happened. We were on a call. Everybody was in the room. And we were talking to a major bank saying, "We love your software." We're like, "Great, we're looking forward to working with you," all this stuff. And they're like, "Yeah, we need you to show us how you built this plugin because we want to write our own version of it." CHAD: [chuckles] ROB: We're like, "If you did that, you wouldn't need to buy our software." And they're like, "That's right. We're not going to buy your software." CHAD: Exactly. [laughs] ROB: And we're like, "Well, we won't show you how to use it. Then we won't show you how to do that." And they're like, "Well, okay. We'll figure it out ourselves." And so I'm the cheerful, sunny, positive, sort of managing the call, and I'm not just yelling at them. My CTO is sitting next to me literally tearing his hair. This was literally a tearing his hair out moment. And we hung up the call, and we went on a walk around the neighborhood. And he was just like, "What more do you need to hear for you to understand?" And so it's moments like that. But instead of being like, no, you're wrong, we got to do it this way, I was ready to say, "Okay, what do you think we can do? How do we think we can do it?" And then he left me with a big pile of PR messaging to explain what we're doing, conversations like this. Two years ago when we made this change, almost three, I felt like I was being handed a really hard challenge. As it turns out, it hasn't been as big a deal. The market has changed about how they perceive open source. And for enterprise customers, they're like, "All right, how do we deal with the licensing for this stuff?" And we're like, "You just buy it from us." And they're like, "That's it?" And I'm like, "Yes." And you guarantee every..." "Yes." They're like, "Oh. Well, that's pretty straightforward. I don't have to worry about..." We could go way down an open-source rabbit hole and the consulting pieces and who owns the IP, and I used to deal with all that stuff. Now it's very straightforward. [laughs] Like, "You want to buy and use the software to run your data center?" "Yes, I do." "Great." CHAD: Well, I think this is generally applicable even beyond your specific product but to products in general. It's like, when you're not talking to people who are good customers or who are even going to be your customers who are going to pay for what you want, you can spend a lot of time and energy trying to please them. But you're not going to be successful because they're not going to be your customers no matter what you do. ROB: And that ends up being a bit of a filter with the open-source pieces is that there are customers who were dyed in the wool open source. And this used to be more true actually as the markets moved a lot. We ended up just not talking to many. But they do, they want a lot. They definitely would ask for features or things and additions and help, things like that. And it's hard to say no. Especially as a startup founder, you want to say yes a lot. We try to not say yes to things that we don't...and this puts us at a disadvantage I feel like from a marketing perspective. If we don't do something, we tend to say we don't do it, or we could do it, but it would take whatever. I wish more people in the tech space were as disciplined about this does work, this doesn't work, this is a feature. This is something we're working on. It's not how tech marketing typically works sadly. That's why we focus on self-trials so people can use the product. Mid-roll Ad I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. CHAD: So you have the core and then you have the ecosystem. And you also mentioned earlier that it is an actual software package that people are buying and installing in their data center. But then you have the UI which is in the cloud and what's in the data center is reporting up to that. ROB: Well, this is where I'm going to get very technical [laughs] so hang on for a second. We actually use a cross-domain approach. So the way this works...and our UX is written in React. And everything's...boy, there's like three or four things I have to say all at once. So forgive me as I circle. Everything we do at Digital Rebar is API-first, really API only, so the Golang service with an API, which is amazing. It's the right way to do software. So for our UX, it is a React application that can talk to that what we call an endpoint, that Digital Rebar endpoint. And so the UX is designed to talk directly to the Digital Rebar endpoint, and all of the information that it gets comes from that Digital Rebar endpoint. We do not have to relay it. Like, you have to be inside that network to get access to that endpoint. And the UX just talks to it. CHAD: Okay. And so the UX is just being served from your centralized servers, but you're just delivering the React for the JavaScript app. And that is talking to the local APIs. ROB: Right. And so we do use that browser as a bridge. And so when you want to download new content packs...so Digital Rebar is a platform. So you have to download content and automation and pieces into it. The browser is actually your bridge to do that. So the browser can connect to our catalog, pull down our catalog, and then send things into that browser. So it's super handy for that. But yeah, it's fundamentally...it's all behind your firewall software except...and this is where people get confused because you're downloading it from rackn.io. That download or the URL on the browser looks like it's a RackN URL even though all the traffic is network local. CHAD: Do your customers tend to stay up to date? Are they updating to the latest version right away all the time? ROB: [laughs] No, of course not. CHAD: I figured that was the answer. ROB: And we maintain patches on old versions and things like that. I wish they were a little faster. I'm not always sad that they're...I'm actually very glad when we do a release like we did yesterday...And in that release, I don't expect any of our production customers to go patch everything. So in a SaaS, you might actually have to deal with the fact that you've got...and we're back to our heterogeneity story. And this is why it's important that we don't do this. If we were to push that, if we didn't handle every situation for every customer exactly right, there would be chaos. And it would all come back to our team. The way we do it means that we don't have to deal with that. Customers are in control of when they upgrade and when they migrate, except in the UX case. CHAD: So how do you manage that if someone goes to the UI and their local thing is an old version? Are you detecting that and doing things differently? ROB: Yes, one of the decisions we made that I'm really happy with is we embedded feature flags into the API. When you log in, it will pull back. We know what the versions are. But versions are really problematic as a way to determine what's in software, not what's not in software. So instead, we get an array back that has feature flags as we add features into the core. And we've been doing this for years. And it's an amazingly productive process. And so what the UX does is as we add new things into the UX, it will look for those feature flags. And if the feature flag isn't there, it will show you a message that says, "This feature is not available for your endpoint," or show you the thing appropriate without that. And so the UX has gone through years of this process. And so there are literally just places where the UX changes behavior based on what you've installed on your system. And remember, our customers it's multi-site. So our customers do have multiple versions of Digital Rebar installed across there. So this behavior is really important also for them to be able to do it. And it goes back to LaunchDarkly. I was talking to Edith back in the early days of LaunchDarkly and feature flags, and I got really excited about that. And that's why we embedded it into the product. Everybody should do it. It's amazing. CHAD: One of the previous episodes a few ago was with actually the thoughtbot CTO, Joe Ferris. And we're on a project together where it's a different way of working but especially when you need it... so much of what I had done previously was versioned APIs. Maybe that works at a certain scale. But you get to a certain scale of software and way of working and wanting to do continuous deployment and continually update features and all that stuff. And it's a really good way of working when instead you are communicating on the level of feature availability. ROB: And from an ops person's perspective, and this was true with OpenStack, they were adding feature flags down at the metadata for the...it was incredible. They went deep into the versioned API hellscape. It's the only way I can describe it [laughs] because we don't do that. But the thing that that does not help you with is a lot of times the changes that you're looking at from an API perspective are behavior changes, not API changes. Our API over years now has been additive. And as long as you're okay with new objects showing up, new fields showing up in an object, you could go back to four-year-old software, talk to our API, and it would still work just fine. So all your integrations are going to be good, but the behavior might change. And that's what people don't...they're like, oh, I can make my API version, and everything's good. But the behavior that you're putting behind the scenes might be different. You need a way to express that even more than the APIs in my opinion. CHAD: I do think you really see that when you...if you're just building a monolithic web app, it's harder to see. But once you separate your UI from your back end...and where I first hit this was with mobile applications. The problem becomes more obvious to you as a developer I think. ROB: Yes. CHAD: Because you have some people out there who are actually running different versions of your UI too. So your back end is the same for everybody but your UI is different. ROB: [laughs] CHAD: And so you need a back end that can respond to different clients. And a better way to do that rather than versioning your API is to have the clients tell you what they're capable of while they're making the requests and to respond differently. It's much more of a flexible way. ROB: We do track what UX. We have customers who don't want to use that. They don't even want us changing the UX...or actually normal enterprise. And so they will run...the nice thing about a React app is you can just run it. The Digital Rebar can host its UX, and that's perfectly reasonable. We have customers who do that. But every core adds more operational complexity. And then if they don't patch the UX, they can fall behind or not get features. So we see that it's...you're describing a real, you know, the more information you're exchanging between the clients and the servers, the better for you to track what's really going on. CHAD: And I think overall once you can get a little...in my experience, especially people who haven't worked that way, joining the team, it can take a little bit for them to get comfortable with that approach and the flexibility you need to be building into your system. But once people are comfortable with it and the team is comfortable, it really starts to hum. In my experience, a lot of what we've advocated for in terms of the way software should be built and deployed and that kind of thing is it actually makes it so that you can leave that even easier. And you can really be agile because you can roll things out in a very agile way. ROB: So are you thinking like an actual rolling deployment where the deployed software has multiple versions coming through? CHAD: Yep. And you can also have different users seeing different things at different times as well. You can say, "We're going to be doing continual deployment and have code continually deployed." But that doesn't mean that it's part of the release yet, that it's available to users to use. ROB: Yeah, that ability to split and feature flag is a huge deal. CHAD: Yeah. What I'm trying to figure out is does this apply to every project even the small like, this just changes the way you should build software? Or is there a time in a product to start introducing that thing? ROB: I am a big fan of doing it first and fast. There are decisions that we made early that have proven out really well. Feature flags is one of them. We started right away knowing that this would be an important thing for us to do. And same thing with tracking dependencies and being able to say, "I need..." actually, it's helpful because you can write automation that says, "I need this feature in the product." This flag and the product it's not just a version thing. That makes the automation a little bit more portable, easier to maintain. The other thing we did that I really like is all of our objects have documentation embedded in them. So as I write a parameter or an ask or really anything in the system, everything has a documentation field. And so I can write the documentation for that component right there. And then we modified our build scripts so that they will pull in all of that documentation and create an aggregated view. And so the ability to do just-in-time documentation is very, very high. And so I'm a huge fan of that. Because then you have the burden of like, oh, I need to go back and write up a whole bunch of documentation really lessened when you can be like, okay, for this parameter, I can explain its behavior, or I can tell you what it does and know that it's going to show up as part of a documentation set that explains it. That's been something I've been a big fan of in what we build. And not everybody [laughs] is as much a fan. And you can see people writing stuff without particularly crisp documentation behind it. But at least we can go back and add that documentation or lessons learned or things like that. And it's been hugely helpful to have a place to do that. From a design perspective, one other thing I would say that we did that...and you can imagine the conversation. I have a UX usability focus. I'm out selling the product. So for me, it's how does it demo? How does it show? What's that first experience like? And so for me having icons and colors in the UX, in the experience is really important. Because there's a lot of semantic meaning that people get just looking down a list of icons and seeing that they are different colors and different shapes. But from the CTO's perspective, that's window dressing. Who cares? It doesn't have functional purpose. And we're both right. There's a lot of times when to me, both people can be right. So we added that as a metafield into all of our objects. And so we have the functional part of the definition of the API. And then we have these metaobjects that you can add in or meta definitions that you can add in behind the scenes to drive icons and colors. But sometimes UX rendering hints and things like that that from an API perspective, you're like, I don't care, not really an API thing. But from a do I show...this is sensitive information. Do I turn it into a password field? Or should this have a clipboard so I can clipboard icon it, or should I render it in this type of viewer or a plain text viewer? And all that stuff we have a place for. CHAD: And so it's actually being delivered by the API that's saying that. ROB: Correct. CHAD: That's cool. ROB: It's been very helpful. You can imagine the type of stuff we have, and it's easy to influence UX behaviors without asking for UI change. CHAD: Now, are these GraphQL APIs? ROB: No. We looked at doing that. That's probably a whole nother...I might get our CTO on the line for that. CHAD: [laughs] It's a whole nother episode for that. ROB: But we could do that. But we made some decisions that it wasn't going to provide a lot of lift for us in navigation at the moment. It's funny, there's stuff that we think is a really cool idea, but we've learned not to jump on them without having really specific customer use cases or validations. CHAD: Well, like you said, you've got to say no. You've got to make decisions about what is important, and what isn't important now, and what you'll get to later, and that requires discipline. ROB: This may be a way to bring it full circle. If you go back to the stories of every customer having a unique data center, there's this heterogeneity and multi-vendor pieces that are really important. The unicycle we have to ride for this is we want our customers to have standard operating processes, standard infrastructure pipelines for this and use those and follow that process. Because we know if they do, then they'll keep improving as we improve the pipelines. And they're all unique. So there has to be a way in those infrastructure pipelines to do extensions that allow somebody to say, "I need to make this call here in the middle of this pipeline." And we have ways to do that address those needs. The challenge becomes providing enough opinionated like, this is how you should do things. And it's okay if you have to extend it or change it a little bit or tweak it without it just becoming an open-ended tool where people show up and they're like, "Oh, yeah, I get how to build something." And we have people do this, but they run out of gas in the long journey. They end up writing bespoke workflows. They write their own pipelines; they do their own integrations. And for them, it's very hard to support them. It's very hard to upgrade them. It's very hard for them to survive the reorg, your nine-month reorg windows. And so yeah, there's a balance between go do whatever you want, which you have to enable and do it our way because these processes are going to let your teams collaborate, let you reuse software. And we've actually over time been erring more and more on the side of you really need to do it the way we want you to do; reinforce the infrastructure as code processes. And this is the key, right? I mean, you're coming from a development mindset. You want your tooling to reinforce good behavior, CICD, infrastructure as code, all these things. You need those to be easier to do [laughs] than writing it yourself. And over time, we've been progressing more and more towards the let's make it easier to do it within the opinionated way that we have and less easy to do it within the Wild West pattern. CHAD: Cool. Well, I think with that, we'll start to wrap up. So if people want to find out more, where are some places that they could do that or get in touch with you? ROB: The simplest thing is of course rackn.com is the website. We encourage people to just, if this is interesting, download and try the software. If they have a cloud account, it's super easy to play with it, all things RackN through that. I am very active on Twitter under the handle @zehicle Z-E-H-I-C-L-E. And I'm happy to have conversations around these topics and data center and operations and even the future of cloud and edge computing. So please look me up. I'm excited to have conversations like that. CHAD: Awesome. And you can subscribe to the show and find notes and transcripts for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Deploy Friday: hot topics for cloud technologists and developers
#52: OpenStack in the Enterprise; the Path to Your Own Cloud

Deploy Friday: hot topics for cloud technologists and developers

Play Episode Play 42 sec Highlight Listen Later Dec 2, 2021 58:38


OpenStack: scalable, automated cloud infrastructureWe introduced OpenStack, powerful open source software that automates the management of hardware and infrastructure, in our 50th episode. Organizations like Sardina Systems use OpenStack to offer their clients scalable, pay-as-you-grow cloud infrastructure. Today we have two guests from Sardina Systems, Kenneth Tan and Mihaela Constantinescu, who manage OpenStack installations for their customers. Our other guest, Dr. Jens Krüger, uses Sardina to deploy OpenStack for the University of Tübingen, Germany.Sardina Systems deploys OpenStack to private cloud customersSardina Systems knew they needed an open source cloud infrastructure base to build on. They researched the market and ended up picking OpenStack due to its “tremendous velocity of development,” as Kenneth puts it.Sardina Systems' flexibility, ability to scale, and attention to privacy and security are desirable to organizations in industries with particular needs regarding security and privacy. Sardina Systems' enterprise cloud platform, Fish OS, is specifically geared toward creating private clouds for finance, telecommunications, healthcare, and government clients. Sardina Systems is also highly cost-effective compared to many big-name competitors — a private cloud is a fraction of the cost compared to others like Azure or Google Compute Cloud. The University of Tübingen chose Sardina Systems because, according to Dr. Kruger, “Sardina provides a supportive environment for rolling updates with, theoretically, zero downtime, and practically, something very close to that. It saves the university a lot of headaches.” Open Source creating natural alliances where the competition can'tPlatform.sh also uses OpenStack, enabling us to offer public and private cloud services to various customers. Since OpenStack is open source, it can bring together ecosystems of cloud infrastructure service providers like Sardina Systems and Platform.sh in a way that public (often proprietary) cloud can't. There are alternatives to OpenStack, such as NFS, which work well for storage. But they tend to be slower, and they lack the self-healing and re-balancing that OpenStack offers.Try powerful open source software OpenStack to help manage your cloud infrastructure.Platform.shLearn more about us.Get started with a free trial.Have a question? Get in touch!Platform.sh on social mediaTwitter @platformshTwitter (France): @platformsh_frLinkedIn: Platform.shLinkedIn (France): Platform.shFacebook: Platform.shWatch, listen, subscribe to the Platform.sh Deploy Friday podcast:YouTubeApple PodcastsBuzzsproutPlatform.sh is a robust, reliable hosting platform that gives development teams the tools to build and scale applications efficiently. Whether you run one or one thousand websites, you can focus on creating features and functionality with your favorite tech stack.

Deploy Friday: hot topics for cloud technologists and developers

The Open Infrastructure FoundationJulia Kreger, Mark Collier, and Mohammed Naser are all part of the Open Infrastructure Foundation (OIF), a nonprofit that builds communities around IaaS, Infrastructure-as-a-Service. The OIF is vast and global — it spans 100,000 members across over 180 countries, and it focuses on projects in multiple areas, including:Edge computingContainer InfrastructurePublic/Private hybrid cloudAI and Machine LearningCI/CDThe OIF origin storyThe Foundation traces its roots to another open source project, OpenStack, which provides software for creating private and public clouds. Julia describes OpenStack. “OpenStack is a whole slew of projects that we've had to build, orchestrate, and integrate, which allow you to use software to manage your infrastructure.” These projects include Airship, Kata Containers, and Zuul, an open source CI/CD platform for gating changes across multiple systems.OpenStack accelerated and began to build a larger community. “Since its inception, over 8,500 developers have contributed to OpenStack.” says Mark. The team wanted to take their work with OpenStack even further. Mark explains the journey from OpenStack to OIF. “We wanted to apply the things we learned with OpenStack to make an even bigger impact, so we became the Open Infrastructure Foundation.”The Four OpensThe OIF follows a set of guiding principles dubbed “The Four Opens.” Mohammed explains them in the quotes below.Open source: “All the software we build is 100% open source — no paywalls and all with open source licenses.”Open design: “You have to have a public conversation about what you intend to do, you have to get that documented as a spec, that the community needs to all agree on together to make sure that it works for everybody. The community controls the roadmap of each project.” Open development: “All code commits and code review are done in public, nothing is behind any walls, nothing that you have to be invited to do.”Open community: “Any and all discussions are locked and made public. There's no discussion you can't be a part of.”Learn more about the Open Infrastructure Foundation or try one of their projects.Platform.shLearn more about us.Get started with a free trial.Have a question? Get in touch!Platform.sh on social mediaTwitter @platformshTwitter (France): @platformsh_frLinkedIn: Platform.shLinkedIn (France): Platform.shFacebook: Platform.shWatch, listen, subscribe to the Platform.sh Deploy Friday podcast:YouTubeApple PodcastsBuzzsproutPlatform.sh is a robust, reliable hosting platform that gives development teams the tools to build and scale applications efficiently. Whether you run one or one thousand websites, you can focus on creating features and functionality with your favorite tech stack.

Screaming in the Cloud
Making Multi-Cloud Waves with Betty Junod

Screaming in the Cloud

Play Episode Listen Later Nov 3, 2021 35:13


About Betty Betty Junod is the Senior Director of Multi-Cloud Solutions at VMware helping organizations along their journey to cloud. This is her second time at VMware, having previously led product marketing for end user computing products.  Prior to VMware she held marketing leadership roles at Docker and solo.io in following the evolution of technology abstractions from virtualization, containers, to service mesh. She likes to hang out at the intersection of open source, distributed systems, and enterprise infrastructure software. @bettyjunod  Links: Twitter: https://twitter.com/BettyJunod Vmware.com/cloud: https://vmware.com/cloud 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: You know how git works right?Announcer: Sorta, kinda, not really Please ask someone else!Corey: Thats all of us. Git is how we build things, and Netlify is one of the best way I've found to build those things quickly for the web. Netlify's git based workflows mean you don't have to play slap and tickle with integrating arcane non-sense and web hooks, which are themselves about as well understood as git. Give them a try and see what folks ranging from my fake Twitter for pets startup, to global fortune 2000 companies are raving about. If you end up talking to them, because you don't have to, they get why self service is important—but if you do, be sure to tell them that I sent you and watch all of the blood drain from their faces instantly. You can find them in the AWS marketplace or at www.netlify.com. N-E-T-L-I-F-Y.comCorey: This episode is sponsored in part by our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats v-u-l-t-r.com slash screaming.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Periodically, I like to poke fun at a variety of different things, and that can range from technologies or approaches like multi-cloud, and that includes business functions like marketing, and sometimes it extends even to companies like VMware. My guest today is the Senior Director of Multi-Cloud Solutions at VMware, so I'm basically spoilt for choice. Betty Junod, thank you so much for taking the time to speak with me today and tolerate what is no doubt going to be an interesting episode, one way or the other.Betty: Hey, Corey, thanks for having me. I've been a longtime follower, and I'm so happy to be here. And good to know that I'm kind of like the ultimate cross-section of all the things [laugh] that you can get snarky about.Corey: The only thing that's going to make that even better is if you tell me, “Oh, yeah, and I moonlight on a contract gig by naming AWS services.” And then I just won't even know where to go. But I'll assume they have to generate those custom names in-house.Betty: Yes. Yes, I think they do those there. I may comment on it after the fact.Corey: So, periodically I am, let's call it miscategorized, in my position on multi-cloud, which is that it's a worst practice that when you're designing something from scratch, you should almost certainly not be embracing unless you're targeting a very specific corner case. And I stand by that, but what that has been interpreted as by the industry, in many cases because people lack nuance when you express your opinions in tweet-sized format—who knew—as me saying, “Multi-cloud bad.” Maybe, maybe not. I'm not interested in assigning value judgment to it, but the reality is that there are an awful lot of multi-cloud deployments out there. And yes, some of them started off as, “We're going to migrate from one to the other,” and then people gave up and called it multi-cloud, but it is nuanced. VMware is a company that's been around for a long time. It has reinvented itself in a few different ways at different periods of its evolution, and it's still highly relevant. What is the Multi-Cloud Solutions group over at VMware? What do you folks do exactly?Betty: Yeah. And so I will start by multi-cloud; we're really taking it from a position of meeting the customer where they are. So, we know that if anything, the only thing that's a given in our industry is that there will be something new in the next six months, next year, and the whole idea of multi-cloud, from our perspective, is giving customers the optionality, so don't make it so that it's a closed thing for them. But if they decide—it's not that they're going to start, “Hey, I'm going to go to cloud, so day one, I'm going to go all-in on every cloud out there.” That doesn't make sense, right, as—Corey: But they all gave me such generous free credit offers when I founded my startup; I feel obligated to at this point.Betty: I mean, you can definitely create your account, log in, play around, get familiar with the console, but going from zero to being fully operationalized team to run production workloads with the same kind of SLAs you had before, across all three clouds—what—within a week is not feasible for people getting trained up and actually doing that. Our position is that meeting customers where they are and knowing that they may change their mind, or something new will come up—a new service—and they really want to use a new service from let's say GCP or AWS, they want to bring that with an application they already have or build a new app somewhere, we want to help enable that choice. And whether that choice applies to taking an existing app that's been running in their data center—probably on vSphere—to a new place, or building new stuff with containers, Kubernetes, serverless, whatever. So, it's all just about helping them actually take advantage of those technologies.Corey: So, it's interesting to me about your multi-cloud group, for lack of a better term, is there a bunch of things fall under its umbrella? I believe Bitnami does—or as I insist on calling it, ‘bitten-A-M-I'—I believe that SaltStack—which I wrote a little bit of once upon a time, which tells me you folks did no due diligence whatsoever because everything I've ever written is molten garbage—Betty: Not [unintelligible 00:04:33].Corey: And—so to be clear, SaltStack is good; just the parts that I wrote are almost certainly terrible because have you met me?Betty: I'll make a note. [laugh].Corey: You have Wavefront, you have CloudHealth, you have a bunch of other things in the portfolio, and yeah, all those things do work across multiple clouds, but there's nothing that makes using any of those things a particularly bad idea even if you're all-in on one cloud provider, too. So, it's a portfolio that applies to a whole bunch have different places from your perspective, but it can be used regardless of where folks stand ideologically.Betty: Yes. So, this goes back to the whole idea that we meet the customers where they are and help them do what they want to do. So, with that, making sure these technologies that we have work on all the clouds, whether that be in the data center or the different vendors, so that if a customer wants to just use one, or two, or three, it's fine. That part's up to them.Corey: The challenge I've run into is that—and maybe this is a ‘Twitter Bubble' problem, but unfortunately, having talked to a whole bunch of folks in different contexts, I know it isn't—there's almost this idea that you have to be incredibly dogmatic about a particular technology that you're into. I joke periodically about the Rust Evangelism Strikeforce where their entire job is talking about using Rust; their primary IDE is PowerPoint because they're giving talks all the time about it rather than writing code. And great, that's a bit of an exaggeration, but there are the idea of a technology purist who is taking, “Things must be this way,” well past a point of being reasonable, and disregarding the reality that, yeah, the world is messy in a way that architectural diagrams never are.Betty: Yeah. The architectural diagrams are always 2D, right? Back to that PowerPoint slide: how can I make pretty boxes? And then I just redraw a line because something new came out. But you and I have been in this industry for a long time, there's always something new.And I think that's where the dogmatism gets problematic because if you say we're only going to do containers this way—you know, I could see Swarm and Kubernetes, or all-in on AWS and we're going to use all the things from AWS and there's only this way. Things are generational and so the idea that you want to face the reality and say that there is a little bit of everything. And then it's kind of like, how do you help them with a part of that? As a vendor, it could be like, “I'm going to help us with a part of it, or I'm going to help address certain eras of it.” That's where I think it gets really bad to be super dogmatic because it closes you off to possibly something new and amazing, new thinking, different ways to solve the same problem.Corey: That's the problem is left to our own devices, most of us who are building things, especially for random ideas, yeah, there's a whole modern paradigm of how I can build these things, but I'm going to shortcut to the thing I know best, which may very well the architectures that I was using 15 years ago, maybe tools that I was using 15 years ago. There's a reason that Vim is still as popular as it is. Would I recommend it to someone who's a new user? Absolutely not; it's user-hostile, but back in my days of being a grumpy sysadmin, you learned vi because it was on everything you could get into, and you never knew in what environment you were going to be encountering stuff. These days, you aren't logging in to remote systems to manage them, in most cases, and when it happens, it's a rarity and a bug.The world changes; different approaches change, but you have to almost reinvent your entire philosophy on how things work and what your career trajectory looks like. And you have to give up aspects of what you've considered to be part of your identity and embrace something new. It was hard for me to accept that, for example, Docker and the wave of containerization that was rolling out was effectively displacing the world that I was deep in of configuration management with Puppet and with Salt. And the world changes; I said, “Okay, now I'll work on cloud.” And if something else happens, and mainframes are coming back again, instead, well, I'm probably not going to sit here railing against the tide. It would be ridiculous to do that from my perspective. But I definitely understand the temptation to fight against it.Betty: Mm-hm. You know, we spend so much time learning parts of our craft, so it's hard to say, “I'm now not going to be an expert in my thing,” and I have to admit that something else might be better and I have to be a newbie again. That can be scary for someone who's spent a lot of time to be really well-versed in a specific technology. It's funny that you bring up the whole Docker and Puppet config management; I just had a healthy discussion over Slack with some friends. Some people that we know and comment about some of the newer areas of config management, and the whole idea is like, is it a new category or an evolution of? And I went back to the point that I made earlier is like, it's generations. We continually find new ways to solve a problem, and one thing now is it [sigh] it just all goes so much faster, now. There's a new thing every week. [laugh] it seems sometimes.Corey: It is, and this is the joy of having been in this industry for a while—toxic and broken in many ways though it is—is that you go through enough cycles of seeing today's shiny, new, amazing thing become tomorrow's legacy garbage that we're stuck supporting, which means that—at least from my perspective—I tend to be fairly conservative with adopting new technologies with respect to things that matter. That means that I'm unlikely to wind up looking at the front page of Hacker News to pick a framework to build a banking system in, and I'm unlikely to be the first kid on my block to update to a new file system or database, just because, yeah, if I break a web server, we all laugh, we make fun of the fact that it throws an error for ten minutes, and then things are back up and running. If I break the database, there's a terrific chance that we don't have a company anymore. So, it's the ‘mistakes will show' area and understanding when to be aggressive and when to hold back as far as jumping into new technologies is always a nuanced decision. And let's be clear as well, an awful lot of VMware's customers are large companies that were founded, somehow—this is possible—before 2010. Imagine that. Did people—Betty: [laugh]. I know, right?Corey: —even have businesses or lives back then? I thought we all used horse-driven carriages and whatnot. And they did not build on cloud—not because of any perception of distrust; because it functionally did not exist at the time that they were building these things. And, “Oh, come out into the cloud. It's fine now.” It… yeah, that application is generating hundreds of millions in revenue every quarter. Maybe we treat that with a little bit of respect, rather than YOLO-ing it into some Lambda-driven monster that's constructed—Betty: One hundred—Corey: —out of popsicle sticks and glue.Betty: —percent. Yes. I think people forget that. And it's not that these companies don't want to go to cloud. It's like, “I can't break this thing. That could be, like, millions of dollars lost, a second.”Corey: I write my weekly newsletters in a custom monstrosity of a system that has something like 30-some-odd Lambda functions, a bunch of API gateways that are tied together with things, and periodically there are challenges with it that break as the system continues to evolve. And that's fine. And I'm okay with using something like that as a part of my workflow because absolute worst case, I can go back to the way that my newsletter was originally written: in Google Docs, and it doesn't look anywhere near the same way, and it goes back to just a text email that starts off with, “I have messed up.” And that would be a better story than most of the stuff I put out as a common basis. Similarly, yeah, durability is important.If this were a serious life-critical app, it would not just be hanging out in a single region of a single provider; it would probably be on one provider, as I've talked about, but going multi-region and having backups to a different cloud provider. But if AWS takes a significant enough outage to us-west-2 in Oregon, to the point where my ridiculous system cannot function to write the newsletter, that too, is a different handwritten email that goes out that week because there's no announcement they've made that anyone's going to give the slightest toss about, given the fact that it's basically Cloud Armageddon. So, we'll see. It's about understanding the blast radius and understanding your use case.Betty: Yep. A hundred percent.Corey: So, you've spent a fair bit of time doing interesting things in your career. This is your second outing at VMware, and in the interim, you were at solo.io for a bit, and before that you were in a marketing leadership role at Docker. Let's dive in, if you will. Given that you are no longer working at Docker, they recently made an announcement about a pricing model change, whereas it is free to use Docker Desktop for anyone's personal projects, and for small companies.But if you're a large company, which they define is ten million in revenue a year or 250 employees—those two things don't go alike, but okay—then you have to wind up having a paid plan. And I will say it's a novel approach, but I'm curious to hear what you have to say about it.Betty: Well, I'd say that I saw that there was a lot of flutter about that news, and it's kind of a, it doesn't matter where you draw the line in the sand for the tier, there's always going to be some pushback on it. So, you have to draw a line somewhere. I haven't kept up with the details around the pricing models that they've implemented since I left Docker a few years ago, but monetization is a really important part for a startup. You do have to make money because there are people that you have to pay, and eventually, you want to get off of raising money from VCs all the time. Docker Desktop has been something that has been a real gem from a local developer experience, right, giving the—so that has been well-received by the community.I think there was an enterprise application for it, but when I saw that, I was like, yeah, okay, cool. They need to do something with that. And then it's always hard to see the blowback. I think sometimes with the years that we've had with Docker, it's kind of like no matter what they do, the Twitterverse and Hacker News is going to just give them a hard time. I mean, that is my honest opinion on that. If they didn't do it, and then, say, they didn't make the kind of revenue they needed, people would—that would become another Twitter thread and Hacker News blow up, and if they do it, you'll still have that same reaction.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 https://snark.cloud/oci-free that's https://snark.cloud/oci-free.Corey: It seems to be that Docker has been trying to figure out how to monetize for a very long time because let's be clear here; I think it is difficult to overstate just how impactful and transformative Docker was to the industry. I gave a talk “Heresy in the Church of Docker” that listed a bunch of things that didn't get solved with Docker, and I expected to be torn to pieces for it, and instead I was invited to give it at ContainerCon one year. And in time, a lot of those things stopped being issues because the industry found answers to it. Now, unfortunately, some of those answers look like Kubernetes, but that's neither here nor there. But now it's, okay, so giving everything that you do that is core and central away for free is absolutely part of what drove the adoption that it saw, but goodwill from developers is not the sort of thing that generally tends to lead to interesting revenue streams.So, they had to do something. And they've tried a few different things that haven't seemed to really pan out. Then they spun off that pesky part of their business that made money selling support contracts, over to Mirantis, which was apparently looking for something now that OpenStack was no longer going to be a thing, and Kubernetes is okay, “Well, we'll take Docker enterprise stuff.” Great. What do they do, as far as turning this into a revenue model?There's a lot of the, I guess, noise that I tend to ignore when it comes to things like this because angry people on Twitter, or on Hacker News, or other terrible cesspools on the internet, are not where this is going to be decided. What I'm interested in is what the actual large companies are going to say about it. My problem with looking at it from the outside is that it feels as if there's significant ambiguity across the board. And if there's one thing that I know about large company procurement departments, it's that they do not like ambiguity. This change takes effect in three or four months, which is underwear-outside-the-pants-superhero-style speed for a lot of those companies, and suddenly, for a lot of developers, they're so far removed from the procurement side of the house that they are never going to have a hope of getting that approved on a career-wide timespan.And suddenly, for a lot of those companies, installing and running Docker Desktop just became a fireable offense because from the company's perspective, the sheer liability side of it, if they were getting subject to audit, is going to be a problem. I don't believe that Docker is going to start pulling Oracle-like audit tactics, but no procurement or risk management group in the world is going to take that on faith. So, the problem is not that it's expensive because that can be worked around; it's not that there's anything inherently wrong with their costing model. The problem is the ambiguity of people who just don't know, “Does this apply to me or doesn't this apply to me?” And that is the thing that is the difficult, painful part.And now, as a result, the [unintelligible 00:17:28] groups and their champions of Docker Desktop are having to spend a lot more time, energy, and thought on this than it would simply be for cutting a check because now it's a risk org-wide, and how do we audit to figure out who's installed this previously free open-source thing? Now what?Betty: Yeah, I'll agree with you on that because once you start making it into corporate-issued software that you have to install on the desktop, that gets a lot harder. And how do you know who's downloaded it? Like my own experience, right? I have a locked-down laptop; I can't just install whatever I want. We have a software portal, which lets me download the approved things.So, it's that same kind of model. I'd be curious because once you start looking at from a large enterprise perspective, your developers are working on IP, so you don't want that on something that they've downloaded using their personal account because now it sits—that code is sitting with their personal account that's using this tool that's super productive for them, and that transition to then go to an enterprise, large enterprise and going through a procurement cycle, getting a master services agreement, that's no small feat. That's a whole motion that is different than someone swiping a credit card or just downloading something and logging in. It's similar to what you see sometimes with the—how many people have signed up for and paid 99 bucks for Dropbox, and then now all of a sudden, it's like, “Wow, we have all of megacorp [laugh] signed up, and then now someone has to sell them a plan to actually manage it and make sure it's not just sitting on all these personal drives.”Corey: Well, that's what AWS's original sales motion looked a lot like they would come in and talk to the CTO or whatnot at giant companies. And the CTO would say, “Great, why should we pick AWS for our cloud needs?” And the answer is, “Oh, I'm sorry. You have 87 distinct accounts within your organization that we've [unintelligible 00:19:12] up for you. We're just trying to offer you some management answers and unify the billing and this, and probably give you a discount as well because there is price breaks available at certain sizing.” It was a different conversation. It's like, “I'm not here to sell you anything. We're already there. We're just trying to formalize the relationship.” And that is a challenge.Again, I'm not trying to cast aspersions on procurement groups. I mean, I do sell enterprise consulting here at The Duckbill Group; we deal with an awful lot of procurement groups who have processes and procedures that don't often align to the way that we do things as a ten-person, fully remote company. We do not have commercial vehicle insurance, for example, because we do not have a commercial vehicle and that is a prerequisite to getting the insurance, for one. We're unlikely to buy one to wind up satisfying some contractual requirements, so we have to go back and forth and get things like that removed. And that is the nature of the beast.And we can say yes, we can say no on a lot of those questionnaires, but, “It depends,” or, “I don't know,” is the sort of thing that's going to cause giant red flags and derail everything. But that is exactly what Docker is doing. Now, it's the well, we have a sort of sloppy, weird set of habits with some of our engineers around the bring your own device to work thing. So, that's the enterprise thing. Let me be very clear, here at The Duckbill Group, we have a policy of issuing people company machines, we manage them very lightly just to make sure the drives are encrypted, so they—and that the screensaver comes out with a password, so if someone loses a laptop, it's just, “Replace the hardware,” not, “We have a data breach.”Let's be clear here; we are responsible about these things. But beyond that, it's oh, you want to have some personal thing installed on your machine or do some work on that stuff? Fine. By all means. It's a situation of we have no policy against it; we understand this is how work happens, and we trust people to effectively be grownups.There are some things I would strongly suggest that any employee—ours or anyone else—not cross the streams on for obvious IP ownership rights and the rest, we have those conversations with our team for a reason. It's, understand the nuances of what you're doing, and we're always willing to throw hardware at people to solve these problems. Not every company is like that. And ten million in revenue is not necessarily a very large company. I was doing the math out for ten million in revenue or 250 employees; assuming that there's no outside investment—which with VC is always a weird thing—it's possible—barely—to have a $10 million in revenue company that has 250 employees, but if they're full time they are damn close to a $15 an hour minimum wage. So, who does it apply to? More people than you might believe.Betty: Yeah, I'm really curious to how they're going to like—like you say, if it takes place in three or four months, roll that out, and how would you actually track it and true that up for people? So.Corey: Yeah. And there are tools and processes to do this, but it's also not in anyone's roadmap because people are not sitting here on their annual planning periods—which is always aspirational—but no one's planning for, “Oh, yeah, Q3, one of our software suppliers is going to throw a real procurement wrench at us that we have to devote time, energy, resources, and budget to figure out.” And then you have a problem. And by resources, I do mean resources of basically assigning work and tooling and whatnot and energy, not people. People are humans, they are not resources; I will die on that hill.Betty: Well, you know, actually resource-wise, the thing that's interesting is when you say supplier, if it's something that people have been able to download for free so far, it's not considered a supplier. So, it's—now they're going to go from just a thing I can use and maybe you've let your developers use to now it has to be something that goes through the official internal vetting as being a supplier. So, that's just—it's a whole different ball game entirely.Corey: My last job before I started this place, was a highly regulated financial institution, and even grabbing things were available for free, “Well, hang on a minute because what license is it using and how is it going to potentially be incorporated?” And this stuff makes sense, and it's important. Now, admittedly, I have the advantage of a number of my engineering peers in that I've been married to a corporate attorney for 11 years and have insight into that side of the world, which to be clear, is all about risk mitigation which is helpful. It is a nuanced and difficult field to—as are most things once you get into them—and it's just the uncertainty that befuddles me a bit. I wish them well with it, truly I do. I think the world is better with an independent Docker in it, but I question whether this is going to find success. That said, it doesn't matter what I think; what matters is what customers say and do, and I'm really looking forward to seeing how it plays out.Betty: A hundred percent; same here. As someone who spent a good chunk of my life there, their mark on the industry is not to be ignored, like you said, with what happened with containers. But I do wish them well. There's lot of good people over there, it's some really cool tech, and I want to see a future for them.Corey: One last topic I want to get into before we wind up wrapping this episode is that you are someone who was nominated to come on the show by a couple of folks, which is always great. I'm always looking for recommendations on this. But what's odd is that you are—if we look at it and dig a little bit beneath the titles and whatnot, you even self-describe as your history is marketing leadership positions. It is uncommon for engineering-types to recommend that I talk to marketing folks.s personally I think that is a mistake; I consider myself more of a marketer than not in some respects, but it is uncommon, which means I have to ask you, what is your philosophy of marketing because it very clearly is differentiated in the public eye.Betty: I'm flattered. I will say that—and this goes to how I hire people and how I coach teams—it's you have to be super curious because there's a ton of bad marketing out there, where it's just kind of like, “Hey, we do these five things and we always do these five things: blah, blah, blah, blah, blah.” But I think it's really being curious about what is the thing that you're marketing? There are people who are just focused on the function of marketing and not the thing. Because you're doing your marketing job in the service of a thing, this new widget, this new whatever, and you got to be super curious about it.And I'll tell you that, for me, it's really hard for me to market something if I'm not excited about it. I have to personally be super excited about the tech or something happening in the industry, and it's, kind of like, an all-in thing for me. And so in that sense, I do spend a ton of time with engineers and end-users, and I really try to understand what's going on. I want to understand how the thing works, and I always ask them, “Well”—so I'll ask the engineers, like, “So… okay, this sounds really cool. You just described this new feature and you're super excited about it because you wrote it, but how is your end-user, the person you're building this for, how did they do this before? Help me understand. How did they do this before and why is this better?”Just really dig into it because for me, I want to understand it deeply before I talk about it. I think the thing is, it shows a tremendous amount of respect for the builder, and then to try to really be empathetic, to understand what they're doing and then partner with them—I mean, this sounds so business-y the way I'm talking about this—but really be a partner with them and just help them make their thing really successful. I'm like the other end; you're going to build this great thing and now I'm going to make it sound like it's the best thing that's ever happened. But to do that, I really need to deeply understand what it is, and I have to care about it, too. I have to care about it in the way that you care about it.Corey: I cannot effectively market or sell something that I don't believe in, personally. I also, to be clear because you are a marketing professional—or at least far more of one than I ever was—I do not view what I do is marketing; I view it as spectacle. And it's about telling stories to people, it's about learning what the market thinks about it, and that informs product design in many respects. It's about understanding the product itself. It's about being able to use the product.And if people are listening to this and think, “Wait a minute, that sounds more like DevRel.” I have news for you. DevRel is marketing, they're just scared to tell you that. And I know people are going to disagree with me on that. You're wrong. But that's okay; reasonable people can disagree.And that's how I see it is that, okay, I'll talk to people building the service, I'll talk to people using the service, but then I'm going to build something with the service myself because until then, it's all a game of who sounds the most convincing in the stories that they tell. But okay, you can tell an amazing story about something, but if it falls over when I tried to use it, well, I'm sorry, you're not being accurate in your descriptions of it.Betty: A hundred percent. I hate to say, like, you're storytellers, but that's a big part of it, but it's kind of like you want to tell the story, so you do something to that people believe a certain thing. But that's part of a curated experience because you want them to try this thing in a certain way. Because you've designed it for something. “I built a spoon. I want you to use that to eat your soup because you can't eat soup with a fork.”So, then you'll have this amazing soup-eating experience, but if I build you a spoon and then not give you any directions and you start throwing it at cars, you're going to be like, “This thing sucks.” So, I kind of think of it in that way. To your point of it has to actually work, it's like, but they also need to know, “What am I supposed to use it for?”Corey: The problem I've always had on some visceral level with formal marketing departments for companies is that they can say that a product that they sell is good, they can say that the product is great, or they can choose to say nothing at all about that product, but when there's a product in the market that is clearly a turd, a marketing department is never going to be able to say that, which I think erodes its authenticity in many respects. I understand the constraints behind, that truly I do, but it's the one superpower I think that I bring to the table where even when I do sponsorship stuff it's, you can buy my attention but not my opinion. Because the authenticity of me being trusted to call them like I see them, for lack of a better term, to my mind at least outweighs any short-term benefit from saying good things about a product that doesn't deserve them. Now, I've been wrong about things, sure. I have also been misinformed in both directions, thinking something is great when it's not, or terrible when it isn't or not understanding the use case, and I am thrilled to engage in those debates. “But this is really expensive when you run for this use case,” and the answer can be, “Well, it's not designed for that use case.” But the answer should not be, “No it's not.” I promise you, expensive is in the eye of the customer not the person building the thing.Betty: Yes. This goes back to I have to believe in the thing. And I do agree it's, like not [sigh]—it's not a panacea. You're not going to make Product A and it's going to solve everything. But being super clear and focused on what it is good for, and then please just try it in this way because that's what we built it for.Corey: I want to thank you for taking the time to have a what for some people is no doubt going to be perceived as a surprisingly civil conversation about things that I have loud, heated opinions about. If people want to learn more, where can they find you?Betty: Well, they can follow me on Twitter. But um, I'd say go to vmware.com/cloud for our work thing.Corey: Exactly. VM where? That's right. VM there. And we will, of course, put links to that in the [show notes 00:30:07].Betty: [laugh].Corey: Thank you so much for taking the time to speak with me. I appreciate it.Betty: Thanks, Corey.Corey: Betty Junod, Senior Director of Multi-Cloud Solutions at VMware. 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 loud, ranting comment at the end. Then, if you work for a company that is larger than 250 people or $10 million in revenue, please also Venmo me $5.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.

Electro Monkeys
OpenStack, l'état de l'art avec Thierry Carrez et Christophe Sauthier

Electro Monkeys

Play Episode Listen Later Oct 12, 2021 67:18


C'est l'épisode 100, et pour cet épisode, j'ai choisi de parler d'un projet qui me tient à cœur depuis longtemps, et ce projet c'est OpenStack. Je sais que ces dernières années, l'attention s'est terriblement tournée vers Kubernetes, mais avant l'arrivée de Kubernetes, tous les regards étaient tournés vers OpenStack. Il est légitime de se demander où en est le projet aujourd'hui ? A-t-il disparu, est-il toujours aussi actif ou a-t-il simplement atteint le stade de la large adoption ? Pour répondre à ces questions, j'ai le plaisir de recevoir Thierry Carrez, VP of Engineering at the Open Infrastructure Foundation, et Christophe Sauthier Directeur du conseil pour LinkByNet Amérique du Nord. Ensemble, nous revenons sur l'origine du projet, avant de parler plus en détails de son évolution, ce qu'il est aujourd'hui, et ce vers quoi il se dirige demain.

The Daily Crunch – Spoken Edition
OpenStack gains new momentum, as deployments increase during the pandemic

The Daily Crunch – Spoken Edition

Play Episode Listen Later Oct 7, 2021 4:49


OpenStack, the open-source project that gives large enterprises and public cloud providers the tools to run their own AWS-like private clouds in their data centers, today announced the release of OpenStack 24. Codenamed Xena, the release focuses on polishing many of the system's sharper edges.

So klingt Wirtschaft
Wie die Cloud entstand - und was sie uns noch bringen wird

So klingt Wirtschaft

Play Episode Listen Later Aug 18, 2021 17:17


Die Nutzung einer Cloud ist privat und beruflich für viele zum Alltag geworden. Doch wie kam es eigentlich zur Erfindung der Cloud? Und wie hat sie sich seitdem entwickelt?

MLOps.community
Creating MLOps Standards // Alex Chung and Srivathsan Canchi // MLOps Coffee Sessions #50

MLOps.community

Play Episode Listen Later Aug 12, 2021 47:55


Coffee Sessions #50 with Alex Chung and Srivathsan Canchi, Creating MLOps Standards. // Abstract With the explosion in tools and opinionated frameworks for machine learning, it's very hard to define standards and best practices for MLOps and ML platforms. Based on their building AWS SageMaker and Intuit's ML Platform respectively, Alex Chung and Srivathsan Canchi talk with Demetrios and Vishnu about their experience navigating "tooling sprawl". They discuss their efforts to solve this problem organizationally with Social Good Technologies and technically with mlctl, the control plane for MLOps. // Bio Alex Chung Alex is a former Senior Product Manager at AWS Sagemaker and an ML Data Strategy and Ops lead at Facebook. He's passionate about the interoperability of MLOps tooling for enterprises as an avenue to accelerate the industry. Srivathsan Canchi Srivathsan leads the machine learning platform engineering team at Intuit. The ML platform includes real-time distributed featurization, scoring, and feedback loops. He has a breadth of experience building high scale mission-critical platforms. Srivathsan also has extensive experience with K8s at Intuit and previously at eBay, where his team was responsible for building a PaaS on top of K8s and OpenStack. --------------- ✌️Connect With Us ✌️ ------------- Join our slack community: https://go.mlops.community/slack Follow us on Twitter: @mlopscommunity Sign up for the next meetup: https://go.mlops.community/register Connect with Demetrios on LinkedIn: https://www.linkedin.com/in/dpbrinkm/ Connect with Vishnu on LinkedIn: https://www.linkedin.com/in/vrachakonda/ Connect with Alex on LinkedIn: https://linkedin.com/in/alex-chung-gsd Connect with Sri on LinkedIn: https://www.linkedin.com/in/srivathsancanchi/

Secure Talk - Cybersecurity
Emil Sayegh, CEO of Ntirety

Secure Talk - Cybersecurity

Play Episode Listen Later Aug 9, 2021 41:15


Emil Sayegh, CEO and President of Ntirety, talks about managed security and compliance services. Ntirety is one of the largest managed cloud service platforms in the world. Emil is an early pioneer of Cybersecurity and Cloud Computing, recognized as one of the industry's cloud visionaries and "fathers of OpenStack," having launched and led successful cloud computing and hosting businesses for HP and Rackspace.

The Tech Blog Writer Podcast
1672: Talking AI, 5G, Edge Evolutions With Wind River CTO Paul Miller

The Tech Blog Writer Podcast

Play Episode Listen Later Jul 31, 2021 27:37


Paul Miller is the Chief Technology Officer at Wind River, a global leader in delivering software for intelligent connected systems. With nearly three decades of telecommunications and advanced technology leadership at both large companies and successful startups, he is currently focused on Wind River's edge virtualization and AI solutions, including Wind River's market-leading 5G cloud offering based on StarlingX. Prior to joining Wind River, he was the Chief Technology Officer of GENBAND. He has led the architecture and development of various switching, IMS, IP media, call control, and web applications solutions employed by multiple tier-one operators worldwide. His last eight years have been focused on OpenStack, SDN, and NFV automation technology, including operation of a multi-site, multi-cloud infrastructure, multiple Tier one CSP VNF deployments, and a significant NFV patent history. Paul's contributions throughout his career have enabled many communications service providers worldwide to create new revenue streams while dramatically reducing operating costs. In today's episode, we explore 5G applications and use cases beyond telecom and how they can enable new revenue streams for operators. We also discuss disruption around cloud-native networks and what businesses should be thinking about when building intelligent systems in the era of 5G and AI.  

Cloud with Chris
Lessons Learned From Cultivating Open Source Projects and Communities

Cloud with Chris

Play Episode Listen Later Jul 23, 2021 46:14


In this episode, Chris is joined by JJ Asghar as they talk through lessons learned from cultivating open source projects and communities. Over the last decade, JJ has had the privilege professionally of building and cultivating some Open Source projects and communities.This isn't a tools talk. This is a talk about the soft skills you have to have to be able to succeed as a leader in an Open Source project. JJ's journey started tending the frequently asked questions for a small Linux Distribution called CRUX, and then years later professionally moved to the OpenStack-Chef project to build OpenStack clouds. He has grown other projects along the way, helped build tooling and communities, some successful and still running today, others were just flashes in the pan. He's learned a ton on this journey; and still is, but has some lessons that are hard-learned and hopefully will warn against pitfalls that can cause wasted cycles and pain.

Screaming in the Cloud
Innovations and the Changing DevOps Tides of Tech with Nigel Kersten

Screaming in the Cloud

Play Episode Listen Later Jul 22, 2021 41:12


About NigelNigel Kersten's day job is Field CTO at Puppet where he leads a group of engineers who work with Puppet's largest customers on cultural and organizational changes necessary for large-scale DevOps implementations - among other things. He's a co-author of the industry-leading State Of DevOps Report and likes to evenly talk about what went right with DevOps and what went wrong based on this research and his experience in the field. He's held multiple positions at Puppet across product and engineering and came to Puppet from the Google SRE organization, where he was responsible for one of the largest Puppet deployments in the world.  Nigel is passionate about behavioral economics, electronic music, synthesizers, and Test cricket. Ask him about late-stage capitalism, and shoes.Links: Puppet: https://puppet.com 2020 State of DevOps Report: https://puppet.com/resources/report/2020-state-of-devops-report/ 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 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: 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: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted episode is sponsored by a long time… I wouldn't even say friends so much as antagonist slash protagonist slash symbiotic company with things I have done as I have staggered through the ecosystem. There's a lot of fingers of blame that I can point throughout the course of my career at different instances, different companies, different clients, et cetera, et cetera, that have shaped me into the monstrosity than I am today. But far and away, the company that has the most impact on the way that I speak publicly, is Puppet.Here to accept the recrimination for what I become and how it's played out is Nigel Kersten, a field CTO at Puppet—or the field CTO; I don't know how many of them they have. Nigel, welcome to the show, and how unique are you?Nigel: Thank you, Corey. Well, I—you know, reasonably unique. I think that you get used to being one of the few Australians living in Portland who's decided to move away from the sunny beaches and live in the gray wilderness of the Pacific Northwest.Corey: So, to give a little context into that ridiculous intro, I was a traveling contract trainer for the Puppet fundamentals course for an entire summer back in I want to say 2014, but don't hold me to it. And it turns out that when you're teaching a whole bunch of students who have paid in many cases, a couple thousand dollars out of pocket to learn a new software where, in some cases, they feel like it's taking their job away because they view their job, rightly or wrongly, is writing the same script again and again. And then the demo breaks and people are angry, and if you don't get a good enough rating, you're not invited to continue, and then the company you're contracting through hits you with a stick, it teaches you to improvise super quickly. So, I wasn't kidding when I said that Puppet was in many ways responsible for the way that I give talks now. So, what do you have to say for yourself?Nigel: Well, I have to say, congratulations for surviving, opinionated defensive nerds who think not only you but your entire product you're demoing could be replaced by a shell script. It's a tough crowd.Corey: It was an experience. And some of these were community-based, and some of them were internal to a specific company. And if people have heard more than one episode of this show, I'm sure they can imagine how that went. I gave a training at Comcast once and set a personal challenge for myself of how many times could I use the word ‘comcastic' in a three-day training. And I would work it in and talk about things like the schedule parameter in Puppet where it doesn't guarantee something's going to execute in a time window; it's the only time it may happen.If it doesn't fire off, and then it isn't going to happen. It's like a Comcast service appointment. And then they just all kind of stared at me for a while and, credit where due, that was the best user rating I ever got from people sitting through one of my training. So, thanks for teaching me how to improve at, basically, could have been a very expensive mistake on Puppet's part. It accidentally worked out for everyone.Nigel: Brilliant, brilliant. Yes, you would have survived teaching the spaceship operator to that sort of a crowd.Corey: Oh, I mostly avoided that thing. That was an advanced Puppet-ism, and this was Puppet fundamentals because I just need to be topically good at things, not deep-dive good at things. But let's dig into that a little bit. For those who have not had the pleasure of working with Puppet, what is it?Nigel: Sure? So, Puppet is a pretty simple DSL. You know, DSLs aren't necessarily in favor these days.Corey: Domain-specific language, for those who have not—Nigel: Yep.Corey: —caught up on that acronym. Yes.Nigel: So, a programming language designed for a specific task. And, you know, instead, we've decided that the world will rest on YAML. And we've absorbed a fair bit of YAML into our ecosystem, but there are things that I will still stand by are just better to do in a programming language. ‘if x then y,' for example, it's just easier to express when you have actual syntax around you and you're not, sort of, forcing everything to be in a data specification language. So, Puppet's pretty simple in that it's a language that lets you describe the state that infrastructure should be.And you can do this in a modular and composable way. So, I can build a little chunk of automation code; hand it to Corey; Corey can build something slightly bigger with it; hand it to someone else. And really, this sort of collaboration is one of the reasons why Puppet's, sort of, being at the center of the DevOps movement, which at its core is not really about tools. It's about reducing friction between different groups.Corey: Back when I was doing my traveling training shtick, I found that I had to figure out a way to describe what Puppet did to folks who were not deep in the space, and the analogy that I came up with that I was particularly partial to was, imagine you get a brand new laptop. Well, what do you do with it? You install your user account and go through the setup; you install the programs that you use, some which have licenses on it; you copy your data onto it; you make sure that certain programs always run on startup because that's the way that you work with these things; you install Firefox because that's the browser of choice that you go with, et cetera, et cetera. Now, imagine having to do that for, instead of one computer, a thousand of them, and instead of a laptop, they're servers. And that is directionally what Puppet does.Nigel: Absolutely. This is the one I use for my mother as well. Like, I was working around Puppet for years before—and the way I explained it was, “You know when you get a new iPad, you've got to set up your Facebook account and your email. Imagine you had ten thousand of these.” And she was like—I was like, “You know, companies like Google, company like big banks, they all have lots and lots and lots of computers.” And she was like, “They run all those things on iPads.” And I was like, “This is not really where my analogy was going.” But.Corey: Right. And increasingly, though, it seems like the world has shifted in some direction where, when you explain that to your mother and she comes back with, “Well, wouldn't they just put the application into Docker and be done with it?” Oh, dear. But that seems to be in many ways that the direction that the zeitgeist has moved in, whether or not that is the reality in many environments, where when you're just deploying containers everywhere—through the miracle of Kubernetes—if you'll pardon the dismissive scorn there, that you just package up your application, shove into a container, and then hurl it from the application team over the operations team, like a dead dog cast into your neighbor's yard for him to worry about. And then it sort of takes up the space of you don't have to manage state anymore because everything is mostly stateless in theory. How have you seen it play out in practice in the last five years?Nigel: I mean, that's a real trend. And, you know, the size of a container should be [laugh] smaller than an operating system. And the reality is, I'm a sysadmin; I love operating systems, I nerded out on operating systems. They're a necessary evil, they're terrible, terrible things: registry keys, config files, they're a pain in the neck to deal with. And if you look at, I think what a lot of operations folks missed about Docker when it started was that it didn't make their life better. It was worse.It was, like, this actual, sort of, terrible toolchain where you sort of tied together all these different things. But really importantly, what it did is it put control into the hands of the developers, and it was the developers who were trying to do stuff who were trying to shift into applications. And I think Docker was a really great technology, in the sense of, you know, developers could ship value on their own. And that was the huge, huge leveling up. It wasn't the interface, it wasn't the user experience, it wasn't all these things, it was just that the control got taken away from the IT trolls in their basement going, “No, don't touch my servers,” and instead given straight to the developers. And that's huge because it let us ship things faster. And that's ultimately the whole goal of things.Corey: The thing that really struck me the most from conducting the trainings that I did was meeting a whole bunch of people across the country, in different technological areas of specialty, in different states of their evolution as technologists, and something that struck me was just how much people wound up identifying with the technology that they worked on. When someone is the AIX admin, and the AIX machines are getting replaced with Linux boxes, there's this tendency to fight against that and rebel, rather than learning Linux. And I get it; I'm as subject to this as anyone is. And in many cases, that was the actual pushback that I saw against adopting something like Puppet. If I identify my job as being the person that runs all these carefully curated scripts that I've spent five years building, and now that all gets replaced with something that is more of a global solution to my local problem, then it feels like a thing that made me special is eroding.And we see that with the migration to cloud as well. When you're the storage admin, and it just becomes an API call to S3, that's kind of a scary thing. And when you're one of the server hugger types—and again, as guilty as anyone of this—and you start to see cloud coming in as, like, a rising tide that eats up what it was that you became known for, it's scary and it becomes a foundational shift in how you view yourself. What I really had a lot of sympathy for was the folks who've been doing this for 20 years. They were, in some cases, a few years away from retirement, and they've been doing basically the same set of tasks every year for 25 years.It's one year of experience repeated 25 times. And they don't have that much time left in their career, intentionally, so they want to retire, but they also don't really want to learn a whole bunch of new technologies just to get through those last few years. I feel for them. But at the same time—Nigel: No, me too, totally. But what are you going to do? But without sounding too dismissive there, I think it's a natural tendency for us to identify with the technology if that's what you're around all the time. You know, mechanics do this, truck drivers with brands of trucks, people, like, to build attachments to the technology they work with because we fit them into this bigger techno-social system. But I have a lot of empathy for the people in enterprise jobs who are being asked to change radically because the cycle of progress is speeding up faster and faster.And as you say, they might be a few years away from retirement. I think I used to feel more differently about this when I was really hot-headed and much more of a tech enthusiast, and that's what I identified with. In terms of, it's okay for a job to just be a job for people. It's okay for someone to be doing a job because they get good health care and good benefits and it's feeding their family. That's an important thing. You can't expect everyone to always be incredibly passionate about technology choices in the same way that I think many of us who live on Twitter and hanging out in this space are.Corey: Oh, I have no problem whatsoever with people who want to show up for 40 hours a week-ish, work on their job, and then go home and have lives and not think about computers at all. There's this dark mass of developers out there that basically never show up on Twitter, they aren't on IRC, they don't go to conferences, and that's fine. I have no problem with that, and I hope I don't come across as being overly dismissive of those folks. I honestly wish I could be content like that. I just don't hold still very well.Nigel: [laugh]. Yeah, so I think you touched on a few interesting things there. And some of those we sort of cover in the State of DevOps Report, which is coming out in the next few weeks.Corey: Indeed, and the State of DevOps Report started off at Puppet, and they've now done it for, what, 10 years?Nigel: This is the 10th year, which is completely crazy. So, I was looking at the stats as I was writing it, and it's 10 years of State of DevOps Reports; I think it's 11 years of DevOps Weekly, Gareth Rushgrove's newsletter; it's 12 or 13 years of DevOpsDays that have been going on. This is longer than I spent in primary and high school put together. It's kind of crazy that the DevOps movement is still, kind of, chugging along, even if it's not necessarily the coolest kid on the block, now that GitOps, SRE flavor of the month, various kinds of permutations of how we work with technology, have perhaps got a little bit cooler. But it's still very, very relevant to a lot of enterprises out there.Corey: Yeah. As I frequently say, legacy is a condescending engineering term for ‘it makes money,' and there's an awful lot of that out there. Forget cloud, there are still companies wrestling with do we explore this virtualization thing? And that was something I was very against back in 2006, let's be very honest. I am very bad at predicting the future of technology.And, “I can see this for small niche edge workload cases, where you have a bunch of idle servers, but for the most part, who's really going to use this in production?” Well, basically everyone because that, in turn, is what the cloud runs on. Yeah, I think we can safely say I got that one hilariously wrong. But hey, if you're aren't going to make predictions, then what's it matter?Nigel: But the industry pushes you in these directions. So, there was this massive bank in Asia who I've been working with for a long time and they were always resistant to adopting virtualization. And then it was only four or five years ago that I visited them; they're like, “Right. Okay. It's time. We're rolling out VMware.” And I was like, “So, I'm really curious. What exactly changed in the last year or two in, like, 2014, 2015 that you decided virtualization was the key?” And I'm like—Corey: Oh, there was this jackwagon who conducted this training? Yeah, no, no, sorry. I can't take credit for that one.Nigel: They couldn't order one rack unit servers with CD drives anymore because their whole process was actually provisioning with CDs before that point.Corey: Welcome to the brave new world of PXE booting, which is kind of hard, so yeah, virtualization is easier. You know, sometimes people have to be dragged into various ways of technological advancement. Which gets to the real thing I want to cover, since this is a promoted episode, where you're talking about the State of DevOps Report, I'm almost less interested in what this year's has to say specifically, than what you've seen over the last decade. What's changed? What was true 10 years ago that is very much not true now? Bonus points if you can answer that without using the word Kubernetes more than twice.Nigel: So, I think one of the big things was the—we've definitely passed peak DevOps team, if you may remember, there was a lot of arguments and there's still regular, is DevOps a job title? Is it a team title? Is it a [crosstalk 00:14:33]—Corey: Oh, I was much on the no side until I saw how much more I would get paid as a DevOps engineer instead of a systems administrator for the exact same job. So, you know, I shut up and I took the money. I figured that the semantic arguments are great, but yeah.Nigel: And that's exactly what we've written in the report. And I think it's great. The sysadmins, we were unloved. You know, we were in the basement, we weren't paid as much as programmers. The running joke used to be for developers, DevOps meant, “I don't need ops anymore.” But for ops people, it was, “I can get paid like a developer.”Corey: In many cases, “Oh, well, systems administrators don't want to learn how to code.” It's, yeah, you're remembering a relatively narrow slice of time between the modern era, where systems administrator types need to be able to write in the lingua franca of everything—which is, of course, YAML, as far as programming languages go—and before that, to be a competent systems administrator, you needed to have a functional grasp of C. And—Nigel: Yeah.Corey: —there is only a limited window in which a bunch of bash scripts and maybe a smidgen of Perl would have carried you through. But the deeper understanding is absolutely necessary, and I would argue, always has been.Nigel: And this is great because you've just linked up with one of the things we found really interesting about the report is that you know when we talk about legacy we don't actually mean the oldest shit. Because the oldest shit is the mainframes; it's a lot of bare metal applications. A lot of that in big enterprises—Corey: We're still waiting for an AWS/400 to replace some of that.Nigel: Well, it's administered by real systems engineers, you know, like, the people who wrote C, who wrote kernel extensions, who could debug things. What we actually mean by legacy is we mean late '90s to late 2000s, early 2010s. Stuff that was put together by kids who, like me, happened to get a job because you grew up with a computer, and then the dotcom explosion happened. You weren't necessarily particularly skilled, and a lot of people, they didn't go through the apprenticeships that mainframe folks and systems engineers actually went through. And everyone just held this stuff together with, you know, duct tape and dental floss. And then now we're paying the price of it all, like, way back down the track. So, the legacy is really just a certain slice of rapid growth in applications and infrastructure, that's sort of an unmanageable mess now.Corey: Oh, here in San Francisco, legacy is anything prior to last night's nightly build. It's turned into something a little ridiculous. I feel like the real power move as a developer now is to get a job, go in on day one, rebase everything in the Git repository to a single commit with a message, ‘legacy code' and then force push it to the main branch. And that's the power move, and that's how it works, and that's also the attitude we wind up encountering in a lot of places. And I don't think it serves anyone particularly well to tie themselves so tightly to that particular vision.Nigel: Yep, absolutely. This is a real problem in this space. And one of the things we found in the State of DevOps Report is that—let me back up a little and give a little bit of methodology of what we actually do. We survey people about their performance metrics, you know, like how quickly can you do deploys? What's your mean time to recovery? Those sorts of things, and what practices do you actually employ?And we essentially go through and do statistical analysis on this, and everyone tends to end up in three cohorts, they separate pretty easily, of low, medium, and high evolution. And so one of the things we found is that everyone at the low level has all sorts of problems. They have issues with what does my team do? What does the team next to me do? How do I talk to the team next to me?How do I actually share anything? How do I even know what my goals are? Like, fundamental company problems. But everyone at all levels of evolution is stuck on two big things: not being able to find enough people with the right skills for what they need, and their legacy infrastructure holding them back.Corey: The thing that I find the most compelling is the idea of not being able to find enough people with the skills that they need. And I'm going to break my own rule and mentioned Kubernetes as a prime example of this. If you are effective at managing Kubernetes in production, you will make a very comfortable living in any geographical location on the planet because it is incredibly complex. And every time we've seen this in previous trends, where you need to get more and more complexity, and more and more expertise just to run something, it looks like a sawtooth curve, where at some point that complexity, it gets abstracted away and compressed down into something that is basically a single line somewhere, or it happens below the surface level of awareness. My argument has been that Kubernetes is something no one's going to care about in roughly three years from now, not because we're not using it anymore, but because it's below the level of awareness that we have to think about, in the same way that there aren't a whole lot of people on the planet these days who have to think about the Linux virtual memory management subsystem. It's there and a few people really care about it, but for the rest of us, we don't have to think about that. That is the infrastructure underneath our infrastructure.Nigel: Absolutely. I used to make a living—and it's ridiculous looking back at this—for a year or two, doing high-performance custom compiled Apaches for people. Like, I was really really good at this.Corey: Well yeah, Apache is a great example of this, where back in the '90s, to get a web server up and running you needed to have three days to spare, an in-depth knowledge of GCC compiler flags, and hope for the best. And then RPM came out and then, okay, then YUM or other things like that—Nigel: Exactly.Corey: —on top of it. And then things like Puppet started showing up, and we saw, all right now, [unintelligible 00:20:01] installed. Great. And then we had—it took a step beyond that, and it was, “Oh, now it's just a Docker-run whatever it is,” and these days, yeah, it's a checkbox in S3.Nigel: So, let me get your Kubernetes prediction down, right. So, you're predicting Kubernetes is going to go away like Apache and highly successful things. It's not an OpenStack failure state; it's Apache invisibility state?Corey: Absolutely. My timeline is a bit questionable, let's be fair, but—it's a little on the aggressive side, but yeah, I think that Kubernetes is inherently too complex for most people to have to wind up thinking about it in that way. And we're not talking small companies; we're talking big ones where you're not in a position, if you're a giant blue-chip Fortune 50, to hire 2000 people who all know Kubernetes super well, and you shouldn't have to. There needs to be some flattening of all of that high level of complexity. Without the management tools, though, with things like Puppet and the things that came before and a bunch of different ways, we would all not be able to get anything done because we'd be too busy writing in assembly. There's always going to be those abstractions on top abstractions on top abstractions, and very few people understand how it works all the way down. But that's, in many cases, okay.Nigel: That's civilization, you know? Do you understand what happens when you plug in something to your electricity socket? I don't want to know; I just want light.Corey: And more to the point, whenever you flip the switch, you don't have that doubt in your mind that the light is going to come on. So, if it doesn't, that's notable, and your first thought is, “Oh, the light bulb is out,” not, “The utility company is down.” And we talk about the cloud being utility computing.Nigel: Has someone put a Kubernetes operator in this light switch that may break this process?Corey: Well, okay, IoT does throw a little bit of a crimp into those works. But yeah. So, let's talk more about the State of DevOps Report. What notable findings were there this year?Nigel: So, one of the big things that we've seen for the last couple of years has been that most companies are stuck in the middle of the evolutionary progress. And anyone who deals with large enterprises knows this is true. Whatever they've adopted in terms of technology, in terms of working methods, you know, agile, various different things, most companies don't tend to advance to the high levels; most places stay mired in mediocrity. So, we wanted to dive into that and try and work out why most companies actually stuck like this when they hit a certain size. And it turns out, the problems aren't technology or DevOps, they really fundamental problems like, “We don't have clear goals. I don't understand what the teams next to me do.”We did a bunch of qualitative interviews as well as the quantitative work in the survey with this report, and we talked to one group of folks at a pretty large financial services company who are like, “Our teams have all been renamed so many times, if I need to go and ask someone for something, I literally page up and down through ServiceNow, trying to find out where to put the change request.” And they're like, “How do I know where to put a network port opening request for this particular service when there are 20 different teams that might be named the right thing, and some are obsolete, and I get no feedback whether I've sent it off to the right thing or to a black hole of enterprise despair?”Corey: I really love installing, upgrading, and fixing security agents in my cloud estate! Why do I say that? Because I sell things, because I sell things for a company that deploys an agent, there's no other reason. Because let's face it. Agents can be a real headache. Well, now Orca Security gives you a single tool that detects basically every risk in your cloud environment -- and that's as easy to install and maintain as a smartphone app. It is agentless, or my intro would've gotten me into trouble here, but  it can still see deep into your AWS workloads, while guaranteeing 100% coverage. With Orca Security, there are no overlooked assets, no DevOps headaches, and believe me you will hear from those people if you cause them headaches. and no performance hits on live environments. Connect your first cloud account in minutes and see for yourself at orca.security. Thats “Orca” as in whale, “dot” security as in that things you company claims to care about but doesn't until right after it really should have.Corey: That doesn't get better with a lot of modernization. I mean, I feel like half of my job—and I'm not exaggerating—is introducing Amazonians to one another. Corporate communication between departments and different groups is very far from a solved problem. I think the tooling can help but I've never been a big believer in solving political problems with technology. It doesn't work. People don't work that way.Nigel: Absolutely. One of my earliest times working at Puppet doing, sort of, higher-level sales and services and support, huge national telco walk in there; we've got the development team, the QA team, the infrastructure team. In the course of this conversation, one of them makes a comment about using apt-get, and the others were like, “What do you mean? We're on RHEL.” And it turned out, production was running on RHEL, the QA team running on CentOS and the developers were all building everything on Ubuntu. And because it was Java wraps, they almost didn't have to care. But write once, debug everywhere.Corey: History doesn't repeat, but it rhymes; before Docker, so much of development in startup-land was how do I make my MacBook Pro look a lot more like an EC2 Linux instance? And it turns out that there's an awful lot of work that goes into that maybe isn't the best use of people's time. And we start to see these breakthroughs and these revelations in a bunch of different ways. I have to ask. This is the tenth year that you've done the State of DevOps Report. At this point, why keep doing it? Is it inertia? Are you still discovering new insights every year on top of it? Or is it one of those things where well someone in marketing says we have to do it, so here we are?Nigel: No, actually, it's not that at all. So definitely, we're going to take stock after this year because ten years feels like a really good point to, sort of—it's a nice round number in certain kind of number system. Mainly the reason is, a lot of my job is going and helping big enterprises just get better at using technology. And it's funny how often I just get folks going, “Oh, I read this thing,” like people who aren't on the bleeding edge, constantly discussing these things on Twitter or whatever, but the State of DevOps Report makes its way to them, and they're like, “Oh, I read a thing there about how much better it is if we standardized on one operating system. And that made a really huge difference to what we were actually doing because you had all this data in there showing that that is better.”And honestly, that's the biggest reason why I ended up doing it. It's the fact that it seems to be a tool that has made its way through to very hard to penetrate enterprise folks. And they'll read it and managers will read things that are like, “If you set clear goals for your team and get them to focus on optimizing the legacy environment, you will see returns on it.” And I'm being a little bit facetious in the tone that I'm saying because a lot of this stuff does feel obvious if you're constantly swimming in this stuff day-to-day, but it's not just the practitioners who it's just a job for in a lot of big companies. It's true, a lot of the management chain as well. They're not necessarily going out and reading up on modern agile IT management practices day-to-day, for fun; they go home and do something else.Corey: One of my favorite conferences is Gene Kim's DevOps Enterprise Summit, and the specific reason behind that is, these are very large companies that go beyond companies, in some cases, to institutions, where you have the US Air Force as a presenter one year and very large banks that are 200 years old. And every other conference, it seems, more or less involves people getting on stage, deliver conference-ware and tell stories that make people at those companies feel bad about themselves. Where it's, “We're Twitter for Pets, and this is how we deploy software,” or the ever-popular, “This is how Netflix does stuff.” Yeah, Netflix has basically no budget constraints as far as hiring engineering folks go, and lest we forget, their failure mode is someone can't watch a movie right now. It's not exactly the same thing as the ATM starts spitting out the wrong balance in the streets.And I think that there's an awful lot of discussion where people look at the stories people tell on conference stages and come away feeling bad from it. Very often, I'll see someone from a notable tech companies talk about how they do things. And, “Wow, I wish my group did things like that.” And the person next to me says, “Yeah, me too.” And I check and they work at the same company.And the stories we tell are not necessarily the stories that we live. And it's very easy to come away discouraged from these things. And that goes triply so for large enterprises that are regulated, that have significant downside risk if the technology fails them. And I love watching people getting a chance to tell those stories.Nigel: Let me jump in on that really quickly because—Corey: Please, by all means.Nigel: —one is, you know, having done four years at Google, things are a shitshow internally there, too—Corey: You're talking about it like it's prison. I like it.Nigel: —you know. [laugh]. People get horrified when they turn up and they're like, “Oh, what it's not all gleaming, perfect software artifacts, delivered from the hand of Urs.” But I think what Gene has done with DevOps Enterprise Summit is fantastic in how people share more openly their failure states, but even there—and this is an interesting result we found from a few years ago, State of DevOps Report—even those executives are being more optimistic because it's so beaten into you as the senior executive; you're putting on a public face, and even when they're trying to share the warts-and-all story, they can't help but put a little bit of a positive spin on it. Because I've had exactly the same experience there where someone's up there telling a war story, and then I look, turn to the person next to me, and they work at that same 300-year-old bank, and they're like, “Actually, it's much, much worse than this, and we didn't fix it quite as well as that.” So, I think the big tech companies have terrible inside unless they're Netflix, and the big enterprises are also terrible. But they're also—Corey: No, no, I've talked to Netflix people, too. They do terrible things internally there, too. No one talks about the fact that their internal environments are always tire fires, and there are two stories: the stories we tell publicly, and the reality. And if you don't believe me on that, look at any company in the world's billing system. As much as we all talk about agile and various implementations thereof when it comes to things that charge customers money, we're all doing waterfall.Nigel: Absolutely. [laugh].Corey: Because mistakes show when you triple-charge someone's credit card for the cost of a small country's GDP. It's a problem. I want to normalize those sorts of things more. I'm looking forward to reading this year's report, just because it's interesting to see how folks who are in environments that differ from the ones that I get to see experience in this stuff and how they talk about it.Nigel: Yeah. And so one of the big results I think there for big companies that's really interesting is that one of the, sort of, anti-patterns is having lots of different types of teams. And I kind of touched on this before about having confusing team titles being a real problem. And not being able to cross organizational boundaries quickly is really, really—you know, it's a huge inhibitor and cause, source of friction. But turns out the pattern that is actually really great is one that the Team Topologies guys have discovered.If you've been following what Matthew Skelton and Manuel Pais have been doing for a while, they've basically been documenting a pattern in software organizations of a small number of team types, of a platform team, value stream teams, complicated subtest system teams, and enabling teams. And so we worked with Manuel and Matt on this year's report and asked a whole bunch of questions to try and validate the Team Topologies model, and the results came back and they were just incredibly strong. Because I think this speaks to some of the stuff you mentioned before that no one can afford to hire an army of Kubernetes developers, and whatever the hottest technology is in five years, most big companies can't hire an army of those people either. And so the way you get scale internally before those things become commoditized is you build a small team and create the situation where they can have outsized leverage inside their organization, like get rid of all the blockers to fast flow and make their focus self-service to other people. Because if you're making all of your developers learn distributed systems operations arcane knowledge, that's not a good use of their time, either.Corey: It's really not. And I think that's something that gets lost a lot is, I've never yet seen a company beyond the very early startup stage, where the AWS bill exceeded the cost of the people working on the AWS bill. Payroll is always a larger expense than infrastructure unless you're doing something incredibly strange. And, oh, I want to save some money on the cloud bill is very often offset by the sheer amount of time that you're going to have to pay people to work on that because, contrary to what we believe as engineering hobbyists, people's time is very far from free. And it's also the opportunity cost of if you're going to work on this thing instead of something else, well, is that really the best choice? It comes down to contextualizing what technology is doing as well as with what's happening over in the world of business strategy. And without having a bridge between those, it doesn't seem to work very well.Nigel: Absolutely. It's insane. It's literally insane that, as an industry, we will optimize 5%, 3% of our infrastructure bill or application workload and yet not actually reexamine business processes that are causing your people to spend 10% of their time in synchronous meetings. You can save so much more money and achieve so much more by actually optimizing for fast flow, and getting out of the way of the people who cost lots of money.Corey: So, one last topic that I want to cover before we call it an episode. You talk to an awful lot of folks, and it's easy to point at the aspirational stories of folks doing things the right way. But let's dish for a minute. What are you seeing in terms of people not using the cloud properly? I feel like you might have a story or two on that one.Nigel: I do have a few stories. So, in this year's report, one of the things we wanted to find out of, like, are people using the cloud in the way we think of cloud; you know, elastic, consumption-based, all of these sorts of things. We use the NIST metrics, which I recognize can be a little controversial, but I think you've got to start somewhere as a certain foundation. It turns out just about everyone is using the public cloud. And when I say cloud, I'm not really talking about people's internal VMware that they rebadged as cloud; I'm talking about the public cloud providers.Everyone's using it, but almost no one is taking advantage of the functionality of the cloud. They're instead treating it like an on-premise VMware installation from the mid-2000s, they're taking six weeks to provision instances, they're importing all of their existing processes, they keep these things running for a long time if they fall over, one person is tasked with, “Hey, do you know how pet number 45 is actually doing here?” They're not really treating any of these things in the way that they're actually meant to. And I think we forget about this a lot of the time when we talk about cloud because we jump straight to cloud-native, you know, the sort of bleeding edge of folks in serverless, highly orchestrated containers. I think if you look at the actual numbers, the vast majority of cloud usage, it's still things like EC2 instances on AWS. And there's a reason: because it's a familiar paradigm for people. We're definitely going to progress past there, but I think it's easy to leave the people in the middle behind when we're talking about cloud and how to improve the ecosystem that they all operate in.Corey: Part of the problem, too, is that whenever we look at how folks are misusing cloud, it's easy to lose sight of context. People don't generally wake up and decide I'm going to do a terrible job today unless they work in, you know, Facebook's ethics department or something. Instead, it's very much a people are shaped by the constraints they're laboring under from a bunch of different angles, and they're trying to do the best with what they have. Very often, the reason that a practice or a policy exists is because, once upon a time, there was a constraint that may or may not still be there, and going forward the way that they have seemed like the best option at the time. I found that the default assumption that people are generally smart and doing the right thing with the information they have carries you a lot further, in many respects than what I did is a terrible junior consultant, which is, “Oh, what moron built this?” Invariably to said moron, and then the rest of the engagement rapidly goes downhill from there. Try and assume good faith, and if you see something that makes no sense, ask, “Why is it like this?” Rather than, “Why is it like this?” Tone counts for a lot.Nigel: It's the fundamental attribution bias. It's why we think all other drivers on the road are terrible, but we actually had a good reason for swerving into that lane.Corey: “This isn't how I would have built it. So, it's awful.”Nigel: Yeah, exactly.Corey: Yeah. And in some cases, though, there are choices that are objectively bad, but I tried to understand where they came from there. Company policy, historically, around things like data centers, trying to map one-to-one to cloud often miss some nuances. But hey, there's a reason it's called the digital transformation, not a project that we did.Nigel: [laugh]. And I think you've got to always have empathy for the people on the ground. I quite often have talked to folks who've got, like, a terrible cloud architecture with the deployment and I'm like, “Well, what happened here?” And they went, “Well, we were prepared to deploy this whole thing on AWS, but then Microsoft's salespeople got to the CTO and we got told at the last minute we're redeploying everything on Azure.” And so these people were often—you know, you're given a week or two to pivot around the decision that doesn't necessarily make any sense to them.And there may have been a perfectly good reason for the CTO to do this: they got given really good kickbacks in terms of bonuses for, like, how much they were spending on the infrastructure—I mean, discounts—but people on the ground are generally doing the best with what they can do. If they end up building crap, it's because our system, society, capitalism, everything else is at fault.Corey: [laugh]. I have to say, I'm really looking forward to seeing the observations that you wound up putting into this report as soon as it drops. I'm hoping that I get a chance to speak with you again about the findings, and then I can belligerently tell you to justify yourself. Those are my favorite follow-ups.Nigel: [unintelligible 00:37:05].Corey: If people want to get a copy of the report for themselves or learn more about you, where can they find you?Nigel: Just head straight to puppet.com, and it will be on the banner on the front of the site.Corey: Excellent. And will, of course, put a link to that in the show notes, if people can't remember puppet.com. Thank you so much for taking the time to speak with me. I really appreciate it.Nigel: Awesome. No worries. It was good to catch up.Corey: Nigel Kersten, field CTO at Puppet. 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 as well as an insulting comment telling me that ‘comcastic' isn't a funny word, and tell me where you work, though we already know.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.