POPULARITY
5 episodes with senior principal engineer
9 episodes with senior principal engineer
3 episodes with senior principal engineer
4 episodes with senior principal engineer
3 episodes with senior principal engineer
2 episodes with senior principal engineer
2 episodes with senior principal engineer
2 episodes with senior principal engineer
2 episodes with senior principal engineer
Hosts Chandra and Paul engage in a conversation with guest Clayton Seeley, Senior Principal Engineer and Product Manager for EnterpriseOne Foundation and Lifecycle Management at Oracle. The discussion centers around the basic concepts of Configurable Network Computing (CNC) and the architecture of JD Edwards EnterpriseOne, including components such as the database server, enterprise server, and web application server. Clayton explains the role of the system administrator (or CNC) and the different servers involved in the system, highlighting the complexities and tasks managed by CNC professionals. 01:43 Introducing Clayton Seeley 05:15 What is CNC? 07:00 EnterpriseOne Architecture 10:40 Servers for your Administrator 14:36 Summary of EnterpriseOne Server Types 16:56 Knowing where to start with log capture. 19:54 Load Balancing 21:20 Midwesternism Resources JD Edwards EnterpriseOne Administration - https://docs.oracle.com/en/applications/jd-edwards/administration/index.html JD Edwards EnterpriseOne Architecture - https://docs.oracle.com/cd/E84502_01/learnjde/architecture.html Chilly Open - https://chillyopen.wayzatawestmetrochamber.com/events/photo/?eventDisplay=past If you have concerns or feedback on this episode or ideas for future episodes, please contact us at thejdeconnection@questoraclecommunity.org.
Nick Sonnentag is a Senior Principal Engineer at Oshkosh, where he contributes to the development of some of the world's toughest vehicles using additive manufacturing (AM). Drawing on experience from ATI, DuPont, and more, Nick possesses broad and deep expertise in 3D printing. In this episode of the 3DPOD, we discuss alloys, vehicle manufacturing, applications, and the readiness of directed energy deposition technology for widespread use. Not limiting his exploration of 3D printing to his work at Oshkosh, Nick founded Sunnyday Technologies to tackle the significant challenges in construction 3D printing. Rather than focusing on machines, he concentrates on the binders and the precise formulations needed to achieve specific properties in final structures. This approach stands out for its elegance and promise, diverging from conventional methods of discovering applications and materials. It makes this episode especially insightful. Nick also wanted to clarify that at one point, he mistakenly referenced General Atomics instead of General Dynamics and asked me to note this for accuracy.
In this episode of the Clean Power Hour, host Tim Montague sits down with Jon Previtali, Senior Principal Engineer at VDE Americas, to discuss the growing challenge of hail damage in large-scale solar projects. As hail-related insurance claims skyrocket and premiums increase, the solar industry is searching for innovative solutions to protect their investments.Jon shares his extensive experience in the solar industry and explains how VDE Americas is developing new testing methods to assess module resilience to hail damage accurately. The conversation covers the limitations of current module testing standards, the importance of tracker angles in mitigating hail damage, and the development of sophisticated hail monitoring and stow protocols.Listeners will gain valuable insights into the economic impact of hail damage on solar farms, the role of insurance in the industry, and cutting-edge strategies employed to combat this growing threat. Whether you're a solar developer, asset owner, or simply interested in the challenges facing the renewable energy sector, this episode provides crucial information on an often-overlooked aspect of solar farm management.Tune in to learn about the latest advancements in hail protection technology, the importance of preemptive action, and how the solar industry is adapting to ensure the long-term viability of projects in hail-prone regions.Social Media HandlesJon Previtali LinkedInVDE AmericasDTN Weather MonitoringFEMA Hail MapVDE Americas Hail Risk Assessment Map Support the showConnect with Tim Clean Power Hour Clean Power Hour on YouTubeTim on TwitterTim on LinkedIn Email tim@cleanpowerhour.com Review Clean Power Hour on Apple PodcastsThe Clean Power Hour is produced by the Clean Power Consulting Group and created by Tim Montague. Contact us by email: CleanPowerHour@gmail.com Corporate sponsors who share our mission to speed the energy transition are invited to check out https://www.cleanpowerhour.com/support/The Clean Power Hour is brought to you by CPS America, maker of North America's number one 3-phase string inverter, with over 6GW shipped in the US. With a focus on commercial and utility-scale solar and energy storage, the company partners with customers to provide unparalleled performance and service. The CPS America product lineup includes 3-phase string inverters from 25kW to 275kW, exceptional data communication and controls, and energy storage solutions designed for seamless integration with CPS America systems. Learn more at www.chintpowersystems.com
Mozilla Firefox is an open-source web browser developed by the Mozilla Foundation. Since its first major release in 2004, it has stood out on the browser landscape for its emphasis on privacy, security, and customization. Brian Grinstead is a Senior Principal Engineer at Mozilla. He joins the podcast with Kevin Ball to talk about the The post Firefox Software Architecture with Brian Grinstead appeared first on Software Engineering Daily.
Mozilla Firefox is an open-source web browser developed by the Mozilla Foundation. Since its first major release in 2004, it has stood out on the browser landscape for its emphasis on privacy, security, and customization. Brian Grinstead is a Senior Principal Engineer at Mozilla. He joins the podcast with Kevin Ball to talk about the The post Firefox Software Architecture with Brian Grinstead appeared first on Software Engineering Daily.
In today's rapidly evolving tech landscape, safeguarding AI systems from security threats is more critical than ever. Join me on Tech People Podcast as I dive into the complexities of AI security with Steve Orrin, Chief Technology Officer and Senior Principal Engineer at Intel Federal. Steve shares his expertise on the evolving threat landscape, real-world solutions to AI vulnerabilities, and the challenges of securing AI in a world where technology is constantly changing. Tune in to learn how to outsmart security threats in the AI era and gain valuable insights for protecting your organization's digital assets!
Is there true value in using cloud optimization tools when they may be phased out in the near future? You may be surprised. In this Summer Replay of Screaming of the Cloud, Corey is joined by former VMware Senior Staff Engineer Bryan Liles. Since this episode was originally released, Bryan wasn't just promoted to the Vice President of Principal Engineering at VMware, he's also transitioned to a new role as a Senior Principal Engineer with AWS! Listen as the pair talk about the long-term viability of Kubernetes, what's in a tech company's name, flipping the script surrounding the discussion of diversity in the field, and why the words you use matter the most in criticism. If anything, this throwback will show the value of intention, whether in the tech industry or your everyday life. Show Highlights: (0:00) Intro to episode(0:30) Backblaze sponsor read(0:56) The struggles of setting up interview times(2:22) What Bryan does at VMware(4:14) What Kubernetes has accomplished(5:39) Corey's qualms with Kubernetes(8:16) The shelf life of Kubernetes(10:36) Optimizing Kubernetes in the cloud(13:25) What is Project Pacific?(15:28) Firefly sponsor read(16:04) Woes of the multicloud(19:09) VMware's branding and Tanzu(21:00) Mispronouncing company names(22:07) Punching down and diversity discourse in tech(25:18) Intentional language in company critiques(28:50) Learning lessons from getting fired(30:36) Where you can find BryanAbout Bryan LilesBryan Liles is a Senior Principal Engineer with AWS where his team oversees all of S3. When not working, Bryan builds and races cars and drones.Over the past 20 years, Bryan has worked around cloud technology and distributed systems. His approaches to technology are: simplify with fidelity and technology should give access to all.Links Referenced: https://vmware.comSponsorsBackblaze: https://www.backblaze.com/Firefly: https://www.firefly.ai/
In this episode of the People Solve Problems podcast, host Jamie Flinchbaugh is joined by Patrick Elwer, a Senior Principal Engineer at Intel Corporation. Patrick brings over 34 years of experience to the table, with a significant portion of his career dedicated to improving Intel's work processes using lean product development principles and agile software development practices. The conversation centers on operationalizing problem-solving within a large-scale engineering culture, highlighting the methodologies and challenges faced in such an environment. Patrick begins by sharing his foundational approach to problem solving, which starts with a deep understanding of the current state and a clear articulation of the problem at hand. He emphasizes the importance of defining what success looks like from the outset, even though the problem statement may evolve as more information is gathered. Key elements in Patrick's problem-solving toolkit include root cause analysis, casting a wide net for solutions, and utilizing decision matrices to narrow down options. He stresses the importance of running experiments to validate improvements and standardizing successful changes to prevent recurrence. One of the challenges Patrick addresses is maintaining a balance between striving for perfection and knowing when a problem is adequately solved. In a technical environment where precision is paramount, Patrick advises setting initial targets—such as aiming to cut defects by 50%—to prevent the problem-solving process from dragging on indefinitely. This approach ensures continuous learning and improvement without getting bogged down in the pursuit of an unattainable ideal. Patrick also discusses the complexities of global collaboration. With teams spread across different time zones and geographies, having a standard problem-solving approach is crucial. He describes Intel's method of solving problems in pairs, pairing a mentor focused on the process with an owner of the problem. This system not only facilitates better problem resolution but also promotes skill development among team members. Patrick's role often involves coaching both the mentors and the problem solvers, ensuring that everyone adheres to the structured approach while allowing room for creative solutions. One insightful part of the discussion is Patrick's take on intuition in problem-solving. He acknowledges that while a structured approach is essential, it's important not to stifle intuitive ideas that arise during the process. Patrick encourages his teams to document these insights as they occur, integrating them into the decision-making framework without letting the process become a constraint. Patrick's extensive coaching experience also comes to the fore as he shares stories of mentoring individuals at different levels within the organization. He highlights the importance of flexibility and listening, especially when the initial problem statement doesn't align with the real issues faced by team members. By pivoting the focus of coaching sessions to address the most pressing concerns of his coachees, he ensures that the problem-solving process remains relevant and impactful. Patrick's insights offer a rich blend of practical strategies and philosophical perspectives on problem solving in a large-scale, technical environment. His emphasis on structured yet flexible approaches, combined with a deep understanding of human factors in engineering, provides valuable lessons for anyone looking to improve their problem-solving skills. For more about Patrick Elwer and his work at Intel, visit Intel Corporation and connect with him on LinkedIn.
Kyler Middleton, a Senior Principal Engineer at Veradigm and co-host of the Day Two Cloud podcast, joins Corey in this Screaming in the Cloud episode to talk about how tech careers are changing and the big impact of AI on starting in tech. Kyler, who once wanted to be a librarian, tells her story of becoming a tech pro. She highlights the importance of learning and sharing what you know, especially in tech. Corey and Kyler also get into how AI is changing the game for new techies and what that means if you're starting. Kyler's take on using and teaching tech offers some really helpful tips for anyone looking to get into or move up in the tech world.Show Highlights: (00:00) - Introduction(01:49) - Kyler describes her multiple roles(03:21) - Discussion on the realities of 'Day Two' operations in cloud environments(07:38) - Insights into technical debt and the concept of 'Day Two' in DevOps (13:54) - The importance of sharing knowledge and learning in public to benefit others in the tech community(20:07) - The use and limitations of AI in professional settings(26:41) - Debate on the overreliance on AI technology in decision-making processes and its potential consequences(32:05) - Closing remarks & where listeners can connect with KylerAbout Kyler:Kyler grew up in rural Western Nebraska, fixing neighboring farmers' computers in exchange for brownies and Rice Krispies. Then she was going to be a librarian to help people find the information they need. Then she discovered computers were a real job, and more than just a fix for her munchies, and she's now been a systems, network, call center, and security engineer, and is now a DevOps lead, and software engineer. She speaks at any conference that will have her, hosts Day Two Cloud podcast from Packet Pushers, and writes up cool projects with approachable language and pictures as part of her Medium series, Let's Do DevOps, with the intention to upskill anyone of any skill level. I have an insatiable curiosity and desire to help the folks around me succeed and grow. So - Let's Do DevOps.Links Referenced:Day Two Cloud Podcast: https://packetpushers.net/podcast/day-two-cloud/Kyler on LinkedIn: https://www.linkedin.com/in/kylermiddleton/Kyler's Blog on Medium: https://kymidd.medium.com/SponsorPanoptica: https://www.panoptica.app/
On this episode of the Futurum Tech Webcast, host David Nicholson welcomes Delmar Hernandez, Senior Principal Engineer at Dell Technologies and Steen Graham, Founder at Scalers AI for a conversation on the democratization of AI, focusing on the scalability and versatility of heterogeneous AI inferencing. Their discussion covers: The current trends and challenges in AI democratization and how companies are navigating these waters How Dell Technologies and Scalers AI are advancing the field of AI inferencing with innovative solutions The importance of scalable and heterogeneous AI systems in unlocking new opportunities and applications Best practices for implementing AI technologies in various sectors Predictions for the future of AI development and its impact on industries Learn more at Dell Technologies and Scalers AI. Download our related report, Dell POC for Scalable and Heterogeneous Gen-AI Platform, here.
On this episode of the Futurum Tech Webcast, host David Nicholson welcomes Delmar Hernandez, Senior Principal Engineer at Dell Technologies and Steen Graham, Founder at Scalers AI for a conversation on the democratization and scaling out of generative AI platforms. Our discussion covers: The current state of generative AI technology and its accessibility Strategies for scaling out generative AI platforms to support widespread adoption Challenges and solutions in making AI tools more available to non-experts Insights into future directions for AI democratization and its impact on various industries Collaboration between Dell Technologies and Scalers AI to promote AI accessibility
In this episode of the IoT For All Podcast, Steve Orrin, Federal CTO at Intel, joins Ryan Chacon to discuss IoT, AI, and edge computing in the public sector. The conversation covers integrating cutting-edge technologies to meet federal and public sector needs, the importance of security, reliability, and real-time data processing at the edge, smart city initiatives, advancements in defense logistics, the challenges of managing diverse IoT infrastructures, the role of commercial off-the-shelf IoT solutions, and the impact of leadership in driving technology adoption. Steve Orrin is one of the industry's most trusted advisers in his role as Federal CTO and Senior Principal Engineer for Intel, where he leads federal solution architecture, strategy, and technology engagements. Steve oversees the development of solution architectures that address critical challenges for civilian, defense, and national security agencies. Steve has strongly influenced the evolution of Intel's public sector cybersecurity strategy and has led multiple security initiatives within product groups - assisting in the adoption and modernization of platform, cloud, and device security capabilities for government initiatives and programs. Steve is a widely-recognized expert on cybersecurity and next-generation architectures. He is Intel's representative for security standards and guidance and has contributed to several NIST publications. Steve also advises on supply chain threat and risk management for the Department of Defense. Intel's mission is to shape the future of technology to help create a better future for the entire world. By pushing forward in fields like AI, analytics, and cloud-to-edge technology, Intel's work is at the heart of countless innovations. From major breakthroughs like self-driving cars and rebuilding the coral reefs, to things that make everyday life better like blockbuster effects and improved shopping experiences - they're all powered by Intel technology. Discover more about IoT at https://www.iotforall.com More about Intel: https://www.intel.com Connect with Steve: https://www.linkedin.com/in/sorrin/ (00:00) Intro (00:12) Steve Orrin and Intel (01:39) What role does Intel play in IoT, AI, and edge? (04:01) How does Intel view digital transformation? (05:40) The growth of edge computing (07:29) IoT and AI in the public sector (13:23) Perception of emerging technology and security (17:32) Challenges of IoT deployment in the public sector (21:11) Smart cities and leadership in technology adoption (23:00) The IoT journey for the public sector (26:59) The exciting future of IoT, AI, and edge computing (29:34) Learn more and follow up SUBSCRIBE TO THE CHANNEL: https://bit.ly/2NlcEwm Join Our Newsletter: https://www.iotforall.com/iot-newsletter Follow Us on Social: https://linktr.ee/iot4all Check out the IoT For All Media Network: https://www.iotforall.com/podcast-overview
One of the key actions companies of all sizes have to take is to ensure that their cybersecurity is constantly up to date; but for many, the true scale of the risks surrounding poor cybersecurity remain largely unknown;so to help us unpack the risks and opportunities associated with cybersecurity, we are thrilled to be joined by Steve Orrin.Steve Orrin is Intel's Federal CTO and a Senior Principal Engineer.Steve is a cybersecurity expert, and a leading authority on Public Sector/Federal mission and enterprise systems and solutions. He is the Intel representative to on security standards and guidance and has contributed to several NIST standards and guidance publications. He is a fellow at the Center for Advanced Defense Studies and the chair of the Int Nat SseA alliance Cyber Committee. Links to some of the resources Steve mentions in this episode can be found here:NIST SP 800-207 - Zero Trust Architecturehttps://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdfNIST Implementing a Zero Trust Architecture - Practice Guide (Vol A-E)https://www.nccoe.nist.gov/projects/implementing-zero-trust-architectureESF: Securing the Software Supply Chain for Customers - Part 1https://media.defense.gov/2022/Nov/17/2003116445/-1/-1/0/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_CUSTOMER.PDFESF: Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption - Part 2https://media.defense.gov/2023/Nov/09/2003338086/-1/-1/0/SECURING%20THE%20SOFTWARE%20SUPPLY%20CHAIN%20RECOMMENDED%20PRACTICES%20FOR%20SOFTWARE%20BILL%20OF%20MATERIALS%20CONSUMPTION.PDF
Mark Lavach, the Senior Principal Engineer and Manager of Polymer, Separations, and Systems Sciences for Arkema and Julia Farber, the Senior Strategic Manager of Circular Economy & Standards for Eastman, sit down with host Dave Walsh to talk about the future of plastics. From compostable to biodegradable, they discuss the latest material developments and the standards that are helping these advancements in plastics. Later, JP Ervin discusses the fascinating world of sensory evaluation and the ways in which it is being used to improve the products in our lives.Follow Us Twitter @ASTMIntl Facebook @ASTMInternational Instagram @astmintl YouTube @ASTMIntl LinkedIn @ASTM International Presented by ASTM International www.astm.org
https://www.paypal.me/Truelifepodcast?locale.x=en_UShttps://www.shehnazsoni.com/Introducing Shehnaz, a visionary in aerospace engineering with a fervent commitment to advancing humanity's presence on Earth, Moon, and Mars through sustainable and innovative technological solutions. With a rich background in complex System of System (SOS) projects, including Human Rated Space Missions, Shehnaz has seamlessly navigated diverse roles, from Senior Principal Engineer to Lead Project Engineer, demonstrating expertise in hardware-software integration testing, Human Machine Interface (HMI), and Military Warfighter CONOPS scenarios.Known for her adept problem-solving skills and an ability to exceed expectations, Shehnaz is a seasoned professional working within cross-functional environments. Fluent in English, Hindi, Urdu, and Gujarati, she not only excels in technical prowess but also brings a holistic approach to her work.Currently supporting NASA on the Artemis lunar exploration program, specifically the Human Landing System (HLS), Shehnaz is deeply involved in the innovative technological solution for space exploration. As a Senior System Engineer, her role involves developing and executing strategies to ensure mission success within strict timelines. Utilizing her proficiency in Model Based System Engineering tools like Magic Draw, MATLAB, and Simulink State Flow, Shehnaz navigates the complexities of creating sustainable environments on the Moon and paving the way for exploration on Mars.In the quest to understand the universe, Shehnaz is instrumental in the Artemis III missions, ensuring astronauts' well-being and spacecraft efficiency throughout the mission. With her comprehensive approach and utilization of cutting-edge tools, Shehnaz stands at the forefront of advancing aerospace technology for the benefit of humanity.shehnazsoni.comhttps://geni.us/QuantumBeinghttp://linkedin.com/in/shehnaz-soni-9b37874 https://www.paypal.me/Truelifepodcast?locale.x=en_US
An interview with Betina Pavri, Senior Principal Engineer at the Paiahu-Robinson Research Institute, Victoria University of Wellington. Betina is supporting the development of high-temperature superconducting magnet technologies for space applications. Prior to moving to New Zealand, Betina has had a long and illustrious career at NASA Jet Propulsion Laboratory where she worked on many pioneering planetary missions including the Magellan mission to Venus, the Mars reconnaissance orbiter, the asteroid Dawn mission, and aspects of the Curiosity Mars rover mission as a spacecraft integration and operations engineer and manager. Bettina holds a BA and BS degrees in Physics, Engineering, and Applied Science, and a Masters in Geological Sciences.ResourcesNASA Jet Propulsion LaboratoryNASA Magellan Mission to VenusMars Reconnaissance OrbiterDawn Asteriods MissionMars Curiosity Rover Mission and image dataVideo: Seven Minutes of Terror: The Challenges of Getting to MarsRobinson Research Institute and Internship ProgrammeNASA Education ProgrammesEuropean Space Agency Education ProgrammesHosted by: Emeline Paat-Dahlstrom, Co-Founder and CEO, SpaceBaseMusic: reCreation by airtone (c) copyright 2019 Licensed under a Creative Commons (3.0)If you like our work, please consider donating to SpaceBase through the SpaceBase Open Collective. Or be a SpaceBase Patreon sponsor. (E.g. $3 dollars a month or $36 NZD a year will go a long way in supporting the production of the podcast.)
Our Excellence Spotlight series celebrates and showcases the remarkable journeys and achievements of RQM+ employees; the same employees who are committed to technical excellence and make a significant impact on our clients.
Please Rate and Review us on your podcast app of choice!Get involved with Data Mesh Understanding's free community roundtables and introductions: https://landing.datameshunderstanding.com/If you want to be a guest or give feedback (suggestions for topics, comments, etc.), please see hereEpisode list and links to all available episode transcripts here.Provided as a free resource by Data Mesh Understanding. Get in touch with Scott on LinkedIn if you want to chat data mesh.Transcript for this episode (link) provided by Starburst. See their Data Mesh Summit recordings here and their great data mesh resource center here. You can download their Data Mesh for Dummies e-book (info gated) here.Emily's LinkedIn: https://www.linkedin.com/in/emily-gorcenski-0a3830200/Amy's LinkedIn: https://www.linkedin.com/in/amytobey/Alex's LinkedIn: https://www.linkedin.com/in/alex-hidalgo-6823971b7/Alex's Book Implementing Service Level Objectives: https://www.alex-hidalgo.com/the-slo-bookIn this episode, guest host Emily Gorcenski, Head of Data and AI for Thoughtworks Europe (guest of episode #72) facilitated a discussion with Amy Tobey, Senior Principal Engineer at Equinix and Alex Hidalgo, Principal Reliability Advocate at Nobl9. As per usual, all guests were only reflecting their own views.The topic for this panel was applying reliability engineering practices to data. This is different than engineering for data reliability which is focused on data quality specifically. The overall concept is taking what we've learned from reliability engineering across disciplines but mostly in software, especially SRE/site reliability engineering, and bringing those learnings to data to make data - especially data production and serving - more reliable and scalable. Scott note: this is probably one of the most frustrating topics in data for me because it feels like it's basic foundational work yet most organizations aren't tackling this well yet if at all really. The best starting...
Jonathan Courtois is a Senior Principal Engineer at Sky (UK), leading the development in C++/Qt of the immersive UI experience of Entertainment OS, the operating system powering Sky Glass and Sky Stream.In today's episode:• What makes a great Product and Engineering relationship through the lens of a Senior Principal Engineer• How Sky how approaches product feature development• The future of TV and streaming experiences—Jonathan's contact info:• LinkedIn: https://www.linkedin.com/in/jonathan-courtois-8a9ab98/—Where to find the host, Adam Wakeling:• Twitter: https://twitter.com/adamjwakeling• LinkedIn: https://www.linkedin.com/in/adam-wakeling-26494b35/—In this episode, we cover:(00:00) Introduction(01:33) What the Senior Principal Engineer does at Sky and Jonathan's professional journey(05:55) Having a strong alignment with business direction(06:54) The Engineering and Product relationship(09:38) How Squads and Crew function at Sky(11:07) Some tactics on product-engineering alignment(13:04) Advice to Product Managers(14:36) Typical product feature development approach at Sky(20:11) Trimming MVPs(24:00) Accessibility within product development(24:52) The future of TV and streaming experiences(32:32) The power of generative AI (34:30) Social Media (36:22) The end of traditional TV?(37:46) Where the ad money goes and impact of individual content creators(41:39) What emerging tech Jonathan is most excited by (43:51) OutroFollow the podcast on Twitter: @proddevpodcastGet in touch with the host, Adam Wakeling, on Twitter: @adamjwakeling
Our Excellence Spotlight series celebrates and showcases the remarkable journeys and achievements of RQM+ employees.
Guest: Kelly Shortridge, Senior Principal Engineer in the Office of the CTO at Fastly Topics: So what is Security Chaos Engineering? “Chapter 5. Operating and Observing” is Anton's favorite. One thing that mystifies me, however, is that you outline how to fail with alerts (send too many), but it is not entirely clear how to practically succeed with them? How does chaos engineering help security alerting / detection? How chaos engineering (or is it really about software resilience?) intersects with Cloud security - is this peanut butter and chocolate or more like peanut butter and pickles? How can organizations get started with chaos engineering for software resilience and security? What is your favorite chaos engineering experiment that you have ever done? We often talk about using the SRE lessons for security, and yet many organizations do security the 1990s way. Are there ways to use chaos engineering as a forcing function to break people out of their 1990s thinking and time warp them to 2023? Resources: Video (LinkedIn, YouTube) “Security Chaos Engineering: Sustaining Resilience in Software and Systems” by Kelly Shortridge, Aaron Rinehart “Cybersecurity Myths and Misconceptions” book “Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems“ book “Normal Accidents: Living with High-Risk Technologies” book “Deploy Security Capabilities at Scale: SRE Explains How” (ep85) “The Good, the Bad, and the Epic of Threat Detection at Scale with Panther” (ep123) “Can a Small Team Adopt an Engineering-Centric Approach to Cybersecurity?” (ep117) IKEA Effect “Modernizing SOC ... Introducing Autonomic Security Operations” blog
GPUs vs CPUs, chip design and the importance of chips in AI research: This highly technical episode is for anyone who wants to learn what goes into chip development and how to get into the competitive industry of accelerator design. With advice from expert guest Ron Diamant, Senior Principal Engineer at AWS, you'll get a breakdown of the need-to-know technical terms, what chip engineers need to think about during the design phase and what the future holds for processing hardware. This episode is brought to you by Posit, the open-source data science company (https://posit.co), by the AWS Insiders Podcast (https://pod.link/1608453414), and by https://WithFeeling.ai, the company bringing humanity into AI. Interested in sponsoring a SuperDataScience Podcast episode? Visit JonKrohn.com/podcast for sponsorship information. In this episode you will learn: • What CPUs and GPUs are [05:29] • The differences between accelerators used for deep learning [14:31] • Trainium and Inferentia: AWS's A.I. Accelerators [22:10] • If model optimizations will lead to lower demand for hardware to process them [43:14] • How a chip designer goes about production [48:34] • Breaking down the technical terminology for chips (accelerator interconnect, dynamic execution, collective communications) [55:29] • The importance of AWS Neuron, a software development kit [1:15:42] • How Ron got his foot in the door with chip design [1:26:40] Additional materials: www.superdatascience.com/691
Kelly Shortridge, Senior Principal Engineer at Fastly, joins Corey on Screaming in the Cloud to discuss their recently released book, Security Chaos Engineering: Sustaining Resilience in Software and Systems. Kelly explains why a resilient strategy is far preferable to a bubble-wrapped approach to cybersecurity, and how developer teams can use evidence to mitigate security threats. Corey and Kelly discuss how the risks of working with complex systems is perfectly illustrated by Jurassic Park, and Kelly also highlights why it's critical to address both system vulnerabilities and human vulnerabilities in your development environment rather than pointing fingers when something goes wrong.About KellyKelly Shortridge is a senior principal engineer at Fastly in the office of the CTO and lead author of "Security Chaos Engineering: Sustaining Resilience in Software and Systems" (O'Reilly Media). Shortridge is best known for their work on resilience in complex software systems, the application of behavioral economics to cybersecurity, and bringing security out of the dark ages. Shortridge has been a successful enterprise product leader as well as a startup founder (with an exit to CrowdStrike) and investment banker. Shortridge frequently advises Fortune 500s, investors, startups, and federal agencies and has spoken at major technology conferences internationally, including Black Hat USA, O'Reilly Velocity Conference, and SREcon. Shortridge's research has been featured in ACM, IEEE, and USENIX, spanning behavioral science in cybersecurity, deception strategies, and the ROI of software resilience. They also serve on the editorial board of ACM Queue.Links Referenced: Fastly: https://www.fastly.com/ Personal website: https://kellyshortridge.com Book website: https://securitychaoseng.com LinkedIn: https://www.linkedin.com/in/kellyshortridge/ Twitter: https://twitter.com/swagitda_ Bluesky: https://shortridge.bsky.social 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: Have you listened to the new season of Traceroute yet? Traceroute is a tech podcast that peels back the layers of the stack to tell the real, human stories about how the inner workings of our digital world affect our lives in ways you may have never thought of before. Listen and follow Traceroute on your favorite platform, or learn more about Traceroute at origins.dev. My thanks to them for sponsoring this ridiculous podcast. Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. My guest today is Kelly Shortridge, who is a Senior Principal Engineer over at Fastly, as well as the lead author of the recently released Security Chaos Engineering: Sustaining Resilience in Software and Systems. Kelly, welcome to the show.Kelly: Thank you so much for having me.Corey: So, I want to start with the honest truth that in that title, I think I know what some of the words mean, but when you put them together in that particular order, I want to make sure we're talking about the same thing. Can you explain that like I'm five, as far as what your book is about?Kelly: Yes. I'll actually start with an analogy I make in the book, which is, imagine you were trying to rollerblade to some destination. Now, one thing you could do is wrap yourself in a bunch of bubble wrap and become the bubble person, and you can waddle down the street trying to make it to your destination on the rollerblades, but if there's a gust of wind or a dog barks or something, you're going to flop over, you're not going to recover. However, if you instead do what everybody does, which is you know, kneepads and other things that keep you flexible and nimble, the gust you know, there's a gust of wind, you can kind of be agile, navigate around it; if a dog barks, you just roller-skate around it; you can reach your destination. The former, the bubble person, that's a lot of our cybersecurity today. It's just keeping us very rigid, right? And then the alternative is resilience, which is the ability to recover from failure and adapt to evolving conditions.Corey: I feel like I am about to torture your analogy to death because back when I was in school in 2000, there was an annual tradition at the school I was attending before failing out, where a bunch of us would paint ourselves green every year and then bike around the campus naked. It was the green bike ride. So, one year I did this on rollerblades. So, if you wind up looking—there's the bubble wrap, there's the safety gear, and then there's wearing absolutely nothing, which feels—Kelly: [laugh]. Yes.Corey: —kind of like the startup approach to InfoSec. It's like, “It'll be fine. What's the worst that happens?” And you're super nimble, super flexible, until suddenly, oops, now I really wish I'd done things differently.Kelly: Well, there's a reason why I don't say rollerblade naked, which other than it being rather visceral, what you described is what I've called YOLOSec before, which is not what you want to do. Because the problem when you think about it from a resilience perspective, again, is you want to be able to recover from failure and adapt. Sure, you can oftentimes move quickly, but you're probably going to erode software quality over time, so to a certain point, there's going to be some big incident, and suddenly, you aren't fast anymore, you're actually pretty slow. So, there's this, kind of, happy medium where you have enough, I would like security by design—we can talk about that a bit if you want—where you have enough of the security by design baked in and you can think of it as guardrails that you're able to withstand and recover from any failure. But yeah, going naked, that's a recipe for not being able to rollerblade, like, ever again, potentially [laugh].Corey: I think, on some level, that the correct dialing in of security posture is going to come down to context, in almost every case. I'm building something in my spare time in the off hours does not need the same security posture—mostly—as we are a bank. It feels like there's a very wide gulf between those two extremes. Unfortunately, I find that there's a certain tone-deafness coming from a lot of the security industry around oh, everyone must have security as their number one thing, ever. I mean, with my clients who I fixed their AWS bills, I have to care about security contractually, but the secrets that I hold are boring: how much money certain companies pay another very large company.Yes, I'll get sued into oblivion if that leaks, but nobody dies. Nobody is having their money stolen as a result. It's slightly embarrassing in the tech press for a cycle and then it's over and done with. That's not the same thing as a brief stint I did running tech ops at Grindr ten years ago where, leak that database and people will die. There's a strong difference between those threat models, and on some level, being able to act accordingly has been one of the more eye-opening approaches to increasing velocity in my experience. Does that align with the thesis of your book, since my copy has not yet arrived for this recording?Kelly: Yes. The book, I am not afraid to say it depends on the book, and you're right, it depends on context. I actually talk about this resilience potion recipe that you can check out if you want, these ingredients so we can sustain resilience. A key one is defining your critical functions, just what is your system's reason for existence, and that is what you want to make sure it can recover and still operate under adverse conditions, like you said.Another example I give all the time is most SaaS apps have some sort of reporting functionality. Guess what? That's not mission-critical. You don't need the utmost security on that, for the most part. But if it's processing transactions, yeah, probably you want to invest more security there. So yes, I couldn't agree more that it's context-dependent and oh, my God, does the security industry ignore that so much of the time, and it's been my gripe for, I feel like as long as I've been in the industry.Corey: I mean, there was a great talk that Netflix gave years ago where they mentioned in passing, that all developers have root in production. And that's awesome and the person next to him was super excited and I looked at their badge, and holy hell, they worked at an actual bank. That seems like a bad plan. But talking to the Netflix speaker after the fact, Dave Hahn, something that I found that was extraordinarily insightful, was that, yeah, well we just isolate off the PCI environment so the rest and sensitive data lives in its own compartmentalized area. So, at that point, yeah, you're not going to be able to break much in that scenario.It's like, that would have been helpful context to put in talk. Which I'm sure he did, but my attention span had tripped out and I missed that. But that's, on some level, constraining blast radius and not having compliance and regulatory issues extending to every corner of your environment really frees you up to do things appropriately. But there are some things where you do need to care about this stuff, regardless of how small the surface area is.Kelly: Agreed. And I introduced the concept of the effort investment portfolio in the book, which is basically, that is where does it matter to invest effort and where can you kind of like, maybe save some resources up. I think one thing you touched on, though, is, we're really talking about isolation and I actually think people don't think about isolation in as detailed or maybe as expansively as they could. Because we want both temporal and logical and spatial isolation. What you talked about is, yeah, there are some cases where you want to isolate data, you want to isolate certain subsystems, and that could be containers, it could also be AWS security groups.It could take a bunch of different forms, it could be something like RLBox in WebAssembly land. But I think that's something that I really try to highlight in the book is, there's actually a huge opportunity for security engineers starting from the design of a system to really think about how can we infuse different forms of isolation to sustain resilience.Corey: It's interesting that you use the word investment. When fixing AWS bills for a living, I've learned over the last almost seven years now of doing this that cost and architecture and cloud are fundamentally the same thing. And resilience is something that comes with a very real cost, particularly when you start looking at what the architectural choices are. And one of the big reasons that I only ever work on a fixed-fee basis is because if I'm charging for a percentage of savings or something, it inspires me to say really uncomfortable things like, “Backups are for cowards.” And, “When was the last time you saw an entire AWS availability zone go down for so long that it mattered? You don't need to worry about that.” And it does cut off an awful lot of cost issues, at the price of making the environment more fragile.That's where one of the context thing starts to come in. I mean, in many cases, if AWS is having a bad day in a given region, well does your business need that workload to be functional? For my newsletter, I have a publication system that's single-homed out of the Oregon region. If that whole thing goes down for multiple days, I'm writing that week's issue by hand because I'm going to have something different to talk about anyway. For me, there is no value in making that investment. But for companies, there absolutely is, but there's also seems to be a lack of awareness around, how much is a reasonable investment in that area when do you start making that investment? And most critically, when do you stop?Kelly: I think that's a good point, and luckily, what's on my side is the fact that there's a lot of just profligate spending in cybersecurity and [laugh] that's really what I'm focused on is, how can we spend those investments better? And I actually think there's an opportunity in many cases to ditch a ton of cybersecurity tools and focus more on some of the stuff he talked about. I agree, by the way that I've seen some threat models where it's like, well, AWS, all regions go down. I'm like, at that point, we have, like, a severe, bigger-than-whatever-you're-thinking-about problem, right?Corey: Right. So, does your business continuity plan account for every one of your staff suddenly quitting on the spot because there's a whole bunch of companies with very expensive consulting, like, problems that I'm going to go work for a week and then buy a house in cash. It's one of those areas where, yeah, people are not going to care about your environment more than they are about their families and other things that are going on. Plan accordingly. People tend to get so carried away with these things with tabletop planning exercises. And then of course, they forget little things like I overwrote the database by dropping the wrong thing. Turns out that was production. [laugh]. Remembering for [a me 00:10:00] there.Kelly: Precisely. And a lot of the chaos experiments that I talk about in the book are a lot of those, like, let's validate some of those basics, right? That's actually some of the best investments you can make. Like, if you do have backups, I can totally see your argument about backups are for cowards, but if you do have them, like, maybe you conduct experiments to make sure that they're available when you need them, and the same thing, even on the [unintelligible 00:10:21] side—Corey: No one cares about backups, but everyone really cares about restores, suddenly, right after—Kelly: Yeah.Corey: —they really should have cared about backups.Kelly: Exactly. So, I think it's looking at those experiments where it's like, okay, you have these basic assumptions in place that you assume to be invariance or assume that they're going to bail you out if something goes wrong. Let's just verify. That's a great place to start because I can tell you—I know you've been to the RSA hall floor—how many cybersecurity teams are actually assessing the efficacy and actually experimenting to see if those tools really help them during incidents. It's pretty few.Corey: Oh, vendors do not want to do those analyses. They don't want you to do those analyses, either, and if you do, for God's sakes, shut up about it. They're trying to sell things here, mostly firewalls.Kelly: Yeah, cybersecurity vendors aren't necessarily happy about my book and what I talk about because I have almost this ruthless focus on evidence and [unintelligible 00:11:08] cybersecurity vendors kind of thrive on a lack of evidence. So.Corey: There's so much fear, uncertainty, and doubt in that space and I do feel for them. It's a hard market to sell in without having to talk about here's the thing that you're defending against. In my case, it's easy to sell the AWS bill is high because if I don't have to explain why more or less setting money on fire as a bad thing, I don't really know what to tell you. I'm going to go look for a slightly different customer profile. That's not really how it works in security, I'm sure there are better go-to-market approaches, but they're hard to find, at least, ones that work holistically.Kelly: There are. And one of my priorities with the book was to really enumerate how many opportunities there are to take software engineering practices that people already know, let's say something like type systems even, and how those can actually help sustain resilience. Even things like integration testing or infrastructure as code, there are a lot of opportunities just to extend what we already do for systems reliability to sustain resilience against things that aren't attacks and just make sure that, you know, we cover a few of those cases as well. A lot of it should be really natural to software engineering teams. Again, security vendors don't like that because it turns out software engineering teams don't particularly like security vendors.Corey: I hadn't noticed that. I do wonder, though, for those who are unaware, chaos engineering started off as breaking things on purpose, which I feel like one person had a really good story and thought about it super quickly when they were about to get fired. Like, “No, no, it's called Chaos Engineering.” Good for them. It's now a well-regarded discipline. But I've always heard of it in the context of reliability of, “Oh, you think your site is going to work if the database falls over? Let's push it over and see what happens.” How does that manifest in a security context?Kelly: So, I will clarify, I think that's a slight misconception. It's really about fixing things in production, and that's the end goal. I think we should not break things just to break them, right? But I'll give a simple example, which I know it's based on what Aaron Rinehart conducted at UnitedHealth Group, which is, okay, let's inject a misconfigured port as an experiment and see what happens, end-to-end. In their case, the firewall only detected the misconfigured port 60% of the time, so 60% of the time, it works every time.But it was actually the cloud, the very common, like, Cloud configuration management tool that caught the change and alerted responders. So, it's that kind of thing where we're still trying to verify those assumptions that we have about our systems and how they behave, again, end-to-end. In a lot of cases, again, with security tools, they are not behaving as we expect. But I still argue security is just a subset of software quality, so if we're experimenting to verify, again, our assumptions and observe system behavior, we're benefiting software quality, and security is just a subset of that. Think about C code, right? It's not like there's, like, a healthy memory corruption, so it's bad for both the quality and security reason.Corey: One problem that I've had in the security space for a while is—let's [unintelligible 00:14:05] on this to AWS for a second because that is the area in which I spend the most of my time, which probably explains a lot about my personality challenges. But the problem that I keep smacking into is if I go ahead and configure everything the way that I should according to best practices and the rest, I wind up with a firehose torrent of information in terms of CloudTrail logs, et cetera. And it's expensive in its own right. But then to sort through it or to do a lot of things in security, there are basically two options. I can either buy a vendor's product, which generally tends to start around $12,000 a year and goes up rapidly from there on my current $6,000 a year bill, so okay, twice as much as the infrastructure for security monitoring. Okay.Or alternately, find a bunch of different random scripts and tools on GitHub of wildly diverging quality and sort of hope for the best on that. It feels like there's nothing in between. And the reason I care about this is not because I'm cheap but because when you have an individual learner who is either a student or a career switcher or someone just trying to experiment with this, you want them to begin as you want them to go on, and things that are no money for an enterprise are all the money to them. They're going to learn to work with the tools that they can afford. That feels like it's a big security swing and a miss. Do you agree or disagree? What's the nuance I'm missing here?Kelly: No, I don't think there's nuance you're missing. I think security observability, for one, isn't a buzzword that particularly exists. I've been trying to make it a thing, but I'm solely one individual screaming into the void. But observability just hasn't been a thing. We haven't really focused on, okay, so what, like, we get data and what do we do with it?And I think, again, from a software engineering perspective, I think there's a lot we can do. One, we can just avoid duplicating efforts. We can treat observability, again, of any sort of issue as similar, whether that's an attack or a performance issue. I think this is another place where security, or any sort of chaos experiment, shines though because if you have an idea of here's an adverse scenario we care about, you can actually see how does it manifest in the logs and you can start to figure out, like, what signals do we actually need to be looking for, what signals mattered to be able to narrow it down. Which again, it involves time and effort, but also, I can attest when you're buying the security vendor tool and, in theory, absolving some of that time and effort, it's maybe, maybe not, because it can be hard to understand what the outcomes are or what the outputs are from the tool and it can also be very difficult to tune it and to be able to explain some of the outputs. It's kind of like trading upfront effort versus long-term overall overhead if that makes sense.Corey: It does. On that note, the title of your book includes the magic key phrase ‘sustaining resilience.' I have found that security effort and investment tends to resemble a fire drill in—Kelly: [laugh].Corey: —an awful lot of places, where, “We care very much about security,” says the company, right after they very clearly failed to care about security, and I know this because I'm reading getting an email about a breach that they've just sent me. And then there's a whole bunch of running around and hair-on-fire moments. But then there's a new shiny that always comes up, a new strategic priority, and it falls to the wayside again. What do you see the drives that sustained effort and focus on resilience in a security context?Kelly: I think it's really making sure you have a learning culture, which sounds very [unintelligible 00:17:30], but things again, like, experiments can help just because when you do simulate those adverse scenarios and you see how your system behaves, it's almost like running an incident and you can use that as very fresh, kind of, like collective memory. And I even strongly recommend starting off with prior incidents in simulating those, just to see like, hey, did the improvements we make actually help? If they didn't, that can be kind of another fire under the butt, so to speak, to continue investing. So, definitely in practice—and there's some case studies in the book—it can be really helpful just to kind of like sustain that memory and sustain that learning and keep things feeling a bit fresh. It's almost like prodding the nervous system a little, just so it doesn't go back to that complacent and convenient feeling.Corey: It's one of the hard problems because—I'm sure I'm going to get castigated for this by some of the listeners—but computers are easy, particularly compared to the people. There are deterministic ways to solve almost any computer problem, but people are always going to be a little bit different, and getting them to perform the same way today that they did yesterday is an exercise in frustration. Changing the culture, changing the approach and the attitude that people take toward a lot of these things feels, from my perspective, like, something of an impossible job. Cultural transformations are things that everyone talks about, but it's rare to see them succeed.Kelly: Yes, and that's actually something that I very strongly weaved throughout the book is that if your security solutions rely on human behavior, they're going to fail. We want to either reduce hazards or eliminate hazards by design as much as possible. So, my view is very much again, like, can you make processes more repeatable? That's going to help security. I definitely do not think that if anyone takes away from my book that they need to have, like, a thousand hours of training to change hearts and minds, then they have completely misunderstood most of the book.The idea is very much like, what are practices that we want for other outcomes anyway—again, reliability or faster time to market—and how can we harness those to also be improving resilience or security at the same time? It's very much trying to think about those opportunities rather than, you know, trying to drill into people's heads, like, “Thou shalt not,” or, “Thou shall.”Corey: Way back in 2018, you gave a keynote at some conference or another and you built the entire thing on the story of Jurassic Park, specifically Ian Malcolm as one of your favorite fictional heroes, and you tied it into security in a bunch of different ways. You hadn't written this book then unless the authorship process is way longer than I think it is. So, I'm curious to get your take on what Jurassic Park can teach us about software security.Kelly: Yes, so I talk about Jurassic Park as a reference throughout the book, frequently. I've loved that book since I was a very young child. Jurassic Park is a great example of a complex system gone wrong because you can't point to any one thing. Like there's Dennis Nedry, you know, messing up the power system, but then there's also the software was looking for a very specific count of dinosaurs and they didn't anticipate there could be more in the count. Like, there are so many different factors that influenced it, you can't actually blame just, like, human error or point fingers at one thing.That's a beautiful example of how things go wrong in our software systems because like you said, there's this human element and then there's also how the humans interact and how the software components interact. But with Jurassic Park, too, I think the great thing is dinosaurs are going to do dinosaur things like eating people, and there are also equivalents in software, like C code. C code is going to do C code things, right? It's not a memory safe language, so we shouldn't be surprised when something goes wrong. We need to prepare accordingly.Corey: “How could this happen? Again?” Yeah.Kelly: Right. At a certain point, it's like, there's probably no way to sufficiently introduce isolation for dinosaurs unless you put them in a bunker where no one can see them, and it's the same thing sometimes with things like C code. There's just no amount of effort you can invest, and you're just kind of investing for a really unclear and generally not fortuitous outcome. So, I like it as kind of this analogy to think about, okay, where do our effort investments make sense and where is it sometimes like, we really just do need to refactor because we're dealing with dinosaurs here.Corey: When I was a kid, that was one of my favorite books, too. The problem is, I didn't realize I was getting a glimpse of my future at a number of crappy startups that I worked at. Because you have John Hammond, who was the owner of the park talking constantly about how, “We spared no expense,” but then you look at what actually happened and he spared every frickin expense. You have one IT person who is so criminally underpaid that smuggling dinosaur embryos off the island becomes a viable strategy for this. He wound up, “Oh, we couldn't find the right DNA, so we're just going to, like, splice some other random stuff in there. It'll be fine.”Then you have the massive overconfidence because it sounds very much like he had this almost Muskian desire to fire anyone who disagreed with him, and yeah, there was a certain lack of investment that could have been made, despite loud protestations to the contrary. I'd say that he is the root cause, he is the proximate reason for the entire failure of the park. But I'm willing to entertain disagreement on that point.Kelly: I think there are other individuals, like Dr. Wu, if you recall, like, deciding to do the frog DNA and not thinking that maybe something could go wrong. I think there was a lot of overconfidence, which you're right, we do see a lot in software. So, I think that's actually another very important lesson is that incentives matter and incentives are very hard to change, kind of like what you talked about earlier. It doesn't mean that we shouldn't include incentives in our threat model.So like, in the book I talked about, our threat models should include things like maybe yeah, people are underpaid or there is a ton of pressure to deliver things quickly or, you know, do things as cheaply as possible. That should be just as much of our threat models as all of the technical stuff too.Corey: I think that there's a lot that was in that movie that was flat-out wrong. For example, one of the kids—I forget her name; it's been a long time—was logging in and said, “Oh, this is Unix. I know Unix.” And having learned Unix as my first basically professional operating system, “No, you don't. No one knows Unix. They get very confused at some point, the question is, just how far down what rabbit hole it is.”I feel so sorry for that kid. I hope she wound up seeking therapy when she was older to realize that, no, you don't actually know Unix. It's not that you're bad at computers, it's that Unix is user-hostile, actively so. Like, the raptors, like, that's the better metaphor when everything winds up shaking out.Kelly: Yeah. I don't disagree with that. The movie definitely takes many liberties. I think what's interesting, though, is that Michael Creighton, specifically, when he talks about writing the book—I don't know how many people know this—dinosaurs were just a mechanism. He knew people would want to read it in airport.What he cared about was communicating really the danger of complex systems and how if you don't respect them and respect that interactivity and that it can baffle and surprise us, like, things will go wrong. So, I actually find it kind of beautiful in a way that the dinosaurs were almost like an afterthought. What he really cared about was exactly what we deal with all the time in software, is when things go wrong with complexity.Corey: Like one of his other books, Airframe, talked about an air disaster. There's a bunch of contributing factors in the rest, and for some reason, that did not receive the wild acclaim that Jurassic Park did to become a cultural phenomenon that we're still talking about, what, 30 years later.Kelly: Right. Dinosaurs are very compelling.Corey: They really are. I have to ask though—this is the joy of having a kid who is almost six—what is your favorite dinosaur? Not a question most people get asked very often, but I am going to trot that one out.Kelly: No. Oh, that is such a good question. Maybe a Deinonychus.Corey: Oh, because they get so angry they spit and kill people? That's amazing.Kelly: Yeah. And I like that, kind of like, nimble, smarter one, and also the fact that most of the smaller ones allegedly had feathers, which I just love this idea of, like, feather-ful murder machines. I have the classic, like, nerd kid syndrome, though, where I read all these dinosaur names as a kid and I've never pronounced them out loud. So, I'm sure there are others—Corey: Yep.Kelly: —that I would just word salad. But honestly, it's hard to go wrong with choosing a favorite dinosaur.Corey: Oh, yeah. I'm sure some paleontologist is sitting out there in the field on the dig somewhere listening to this podcast, just getting very angry at our pronunciation and things. But for God's sake, I call the database Postgres-squeal. Get in line. There's a lot of that out there where looking at a complex system failures and different contributing factors and the rest makes stuff—that's what makes things interesting.I think that there's this the idea of a root cause is almost always incorrect. It's not, “Okay, who tripped over the buried landmine,” is not the interesting question. It's, “Who buried the thing?” What were all the things that wound up contributing to this? And you can't even frame it that way in the blaming context, just because you start doing that and people clam up, and good luck figuring out what really happened.Kelly: Exactly. That's so much of what the cybersecurity industry is focused on is how do we assign blame? And it's, you know, the marketing person clicked on a link. And it's like, they do that thousands of times, like a month, and the one time, suddenly, they were stupid for doing it? That doesn't sound right.So, I'm a big fan of, yes, vanquishing root cause, thinking about contributing factors, and in particular, in any sort of incident review, you have to think about, was there a designer process problem? You can't just think about the human behavior; you have to think about where are the opportunities for us to design things better, to make this secure way more of the default way.Corey: When you talk about resilience and reliability and big, notable outages, most forward-thinking companies are going to go and do a variety of incident reviews and disclosures around everything that happened to it, depending upon levels of trust and whether your NDA'ed or not, and how much gets public is going to vary from place to place. But from a security perspective, that feels like the sort of thing that companies will clam up about and never say a word.Kelly: Yes.Corey: Because I can wind up pouring a couple of drinks into people and get the real story of outages, or the AWS bill, but security stuff, they start to wonder if I'm a state actor, on some level. When you were building all of this, how did you wind up getting people to talk candidly and forthrightly about issues that if it became tied to them that they were talking to this in public would almost certainly have negative career impact for them?Kelly: Yes, so that's almost like a trade secret, I feel like. A lot of it is yes, over the years talking with people over, generally at a conference where you know, things are tipsy. I never want to betray confidentiality, to be clear, but certainly pattern-matching across people's stories.Corey: Yeah, we're both in positions where if even the hint of they can't be trusted enters the ecosystem, I think both of our careers explode and never recover. Like it's—Kelly: Exactly.Corey: —yeah. Oh, yeah. They play fast and loose with secrets is never the reputation you want as a professional.Kelly: No. No, definitely not. So, it's much more pattern matching and trying to generalize. But again, a lot of what can go wrong is not that different when you think about a developer being really tired and making a bunch of mistakes versus an attacker. A lot of times they're very much the same, so luckily there's commonality there.I do wish the security industry was more forthright and less clandestine because frankly, all of the public postmortems that are out there about performance issues are just such, such a boon for everyone else to improve what they're doing. So, that's a change I wish would happen.Corey: So, I have to ask, given that you talk about security, chaos engineering, and resilience-and of course, software and systems—all in the title of the O'Reilly book, who is the target audience for this? Is it folks who have the word security featured three times in their job title? Is it folks who are new to the space? What is your target audience start and stop?Kelly: Yes, so I have kept it pretty broad and it's anyone who works with software, but I'll talk about the software engineering audience because that is, honestly, probably out of anyone who I would love to read the book the most because I firmly believe that there's so much that software engineering teams can do to sustain resilience and security and they don't have to be security experts. So, I've tried to demystify security, make it much less arcane, even down to, like, how attackers, you know, they have their own development lifecycle. I try to demystify that, too. So, it's very much for any team, especially, like, platform engineering teams, SREs, to think about, hey, what are some of the things maybe I'm already doing that I can extend to cover, you know, the security cases as well? So, I would love for every software engineer to check it out to see, like, hey, what are the opportunities for me to just do things slightly differently and have these great security outcomes?Corey: I really want to thank you for taking the time to talk with me about how you view these things. If people want to learn more, where's the best place for them to find you?Kelly: Yes, I have all of the social media which is increasingly fragmented, [laugh] I feel like, but I also have my personal site, kellyshortridge.com. The official book site is securitychaoseng.com as well. But otherwise, find me on LinkedIn, Twitter, [Mastodon 00:30:22], Bluesky. I'm probably blanking on the others. There's probably already a new one while we've spoken.Corey: Blue-ski is how I insist on pronouncing it as well, while we're talking about—Kelly: Blue-ski?Corey: Funhouse pronunciation on things.Kelly: I like it.Corey: Excellent. And we will, of course, put links to all of those things in the [show notes 00:30:37]. Thank you so much for being so generous with your time. I really appreciate it.Kelly: Thank you for having me and being a fellow dinosaur nerd.Corey: [laugh]. Kelly Shortridge, Senior Principal Engineer at Fastly. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an insulting comment about how our choice of dinosaurs is incorrect, then put the computer away and struggle to figure out how to open a door.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.
In the first of three Traceroute minisodes, Technical Storyteller Grace Ewura-Esi introduces a new co-host for Season 2, Amy Tobey, Senior Principal Engineer at Equinix. In an insightful conversation, the two hosts reveal more about themselves, their roles, and the stories they're looking forward to telling on the new season of Traceroute. Additional ResourcesConnect with Amy Tobey: LinkedIn or Twitter.Connect with Grace Ewura-Esi: LinkedIn or Twitter.Visit Origins.dev for more informationEnjoyed This Episode?If you did, be sure to follow and share it with your friends!Post a review and share it! If you enjoyed tuning in, then leave us a review. You can also share this with your friends and colleagues! Introduce them to the people and organizations who played a role in inventing the internet. For more episode updates, tune in on Apple Podcasts, Spotify, and wherever you get your podcasts.
Cyberattacks can happen to an individual computer or an entire network. It's vital to have well-tested plans in place before ransomware rears its ugly head. Today's guest is Steve Orrin. Steve is Intel's Federal CTO and Senior Principal Engineer. He leads public sector solutions architecture, strategy, and engagement and has held technology leadership positions at Intel. Steve was previously CTO, CSO, and co-founder of several successful security startups and is a recognized expert and frequent lecturer on enterprise security. Show Notes: [1:01] - Steve shares what his current role is at Intel Corporation and how he became drawn to the field. [2:52] - There are risks everywhere. Where do we start when it comes to cybersecurity for a business? [3:54] - Steve describes risk profiles and what you need to understand what you're trying to protect. [5:21] - Once you know your environment and risk profile, it's time to look at the key things above security “hygiene” and the processes to raise the bar. [7:48] - There are benefits to microsegmentation, including smaller network enclaves. [9:44] - Steve makes a suggestion for network segmentation when it comes to state of the art equipment. [12:07] - Ideally, you want sensors in every network enclave but that isn't always realistic. [13:57] - Having network segmentation will also give you the information needed to find which part of your business receives an attack. [15:39] - How do we protect data in the cloud? [17:04] - It all goes back to understanding the data you need to protect. [21:01] - Just like in your business, you need to know how your IT resources are being used and which ones are not right. [23:20] - These building blocks help you see how you are utilizing security and it needs to be built in from the beginning. [24:55] - Changing approaches in large organizations can seem challenging, but Steve says they are constantly modernizing and it's all about perception. [26:24] - Literally any type of company can be attacked because of every industry's reliance on digital tools and infrastructure. [28:16] - There are different types of attackers - those who target someone specific, those who are opportunistic, and those who are purely automated. [29:44] - Everyone is a potential target even if you aren't being targeted. [31:33] - Planning will also help answer the question of how to continue running the business while ransomware is active. [33:21] - Companies need to adopt a gamified system to train everyone in the organization on how to respond to an attack. [35:13] - Supply chain issues exist in cybersecurity, but it's not the same as other industries. They are problems that they are actively searching for a solution for. [38:26] - When it becomes a requirement and in a contract, it will be adhered to. [40:26] - There are a lot of programs out there looking for the anomaly, but Steve says we aren't looking in the right place. [42:33] - Take all reports of suspicious activity seriously. Thanks for joining us on Easy Prey. Be sure to subscribe to our podcast on iTunes and leave a nice review. Links and Resources: Podcast Web Page Facebook Page whatismyipaddress.com Easy Prey on Instagram Easy Prey on Twitter Easy Prey on LinkedIn Easy Prey on YouTube Easy Prey on Pinterest Steve Orrin on LinkedIn Public Sector on Intel's Website
In this episode of What That Means, Camille gets into data center demand with Allison Goodman, Senior Principal Engineer and Director of Optane Solutions Architecture at Intel. They talk about how data centers work and the ever-growing demands of compute, memory, storage, and networking in data centers. The views and opinions expressed are those of the guests and author and do not necessarily reflect the official policy or position of Intel Corporation.
In this episode, I was joined by Ian Cooper to chat about the Brighter and Darker frameworks.Brighter is a framework for building messaging applications with .NET and C#. It can be used with an in-memory bus, or for interoperability in a microservices architecture allowing out of process messaging via a wider range of middleware transports. And Darker is the query counterpart to Brighter.Ian is a Senior Principal Engineer at Just Eat Takeaway, frequent public speaker, and organiser of London .NET user group.For a full list of show notes, or to add comments - please see the website here
This week we talk to Tanya Reilly, Senior Principal Engineer at Squarespace, about having a growth mindset. Having a growth mindset includes recognizing our limitations and challenging ourselves to learn at any stage of our coding journey. We also talked about interviewing and advocating for ourselves. Show Links Compiler (sponsor) Porkbun (sponsor) Growth Mindset and Code System Design Linux Memoization Graph Traversal Project Euler Stanford Computer Science Platform Engineering
Steve Orrin, Federal Chief Technology Officer & Senior Principal Engineer for Intel talks about how he works with various government agencies to develop and deliver cybersecurity solutions. He explains the differences between working with enterprise customers compared to working with government agencies. He also explains how the federal government is implementing Zero Trust across all agencies, how AI is affecting cybersecurity and the cyber threat landscape, and gives some great book recommendations related to sci-fi and cybersecurity. Intel https://www.intel.com/ Intel Government Cybersecurity https://www.intel.com/content/www/us/en/government/cybersecurity.html The Secure Talk Cybersecurity Podcast https://securetalkpodcast.com/ Thank you for listening to The Secure Talk Cybersecurity Podcast!
Dragan Stepanović is a Senior Principal Engineer at Talabat. Dragan has experience working at different sizes of companies, from small to large corporates. He became interested in Extreme Programming (XP) early on in his career. Then, he started diving into architecture, Domain Driven Design (DDD) and LEAN as tools to enable engineers to maximise their throughput for their stakeholders.Renato Rodrigues de Araujo is a Senior Software Engineer at Form3. Renato is part of the Tooling Team, which is responsible for making the lives of engineers easier by maintaining internal tools.Our .tech series invites guests inside and outside of Form3, discussing current trends in the engineering world alongside shedding light into some of the engineering practices here at Form3. Get in touch with us via this short form if you'd like to be a podcast guest.
As Chief Technology Officer and Senior PE for Intel Corporation, Steve Orrin orchestrates and executes customer engagements in the Federal space, overseeing the development of federal solution architectures to address challenges in a government enterprise, national security, and other federal areas of focus. In today's episode of Tech Talks Daily, Steve joins me in a discussion about the key trends in cybersecurity. Steve reveals the latest threats and techniques used against corporations and governments and shares the best practices to help. We also discuss the security/risk concerns around supply chain security and what organizations can do today and in the future to address or reduce this risk. With trust being top of mind for CISOs, Steve also advises how organizations can adopt Zero Trust Architectures and what new security innovations are waiting on the horizon. About Steve Orrin Steve Orrin offers three decades of extraordinary success in a series of high-level roles at top-tier companies that include Intel Corporation, Sarvega, Watchfire Inc., Sanctum Inc., First Genetic Trust Inc., Lockstar Inc., and SynData Technologies Inc. He has developed a reputation as an industry leader, leveraging a history of delivering results in Innovation, Intrapreneurship, and Entrepreneurship. He is a Tech-enabled business professional who has launched and scaled companies and brought innovative industry-leading products to market. Steve's invaluable expertise and broad business range have powered a history of developing successful products, technologies, and new markets. Such traits have consistently enabled Steve to achieve an impressive command of the skills needed to manage ongoing business planning processes while developing strategies to meet future challenges.
Stacy Devino, Senior Principal Engineer at Stitch Fix, shares, "You Don't Have to Be a Manager." She discusses career growth opportunities in tech that expand beyond “people management.” She also outlines the responsibilities of staff, principal, and distinguished engineers in key areas like coding, leadership, and technical skills.
As AI continues to play an ever-increasing role in applications and decision-making, the challenges facing developers of these AI workloads continue to expand higher and higher. Through this talk, gain a deeper understanding of the current landscape and challenges facing AI developers and data scientists today, and Intel and Red Hat's perspectives on the most pressing issues in this area. Learn how Intel and Red Hat's partnership is addressing these challenges from local devices to the cloud by enabling Intel's most popular AI developer optimizations on Red Hat OpenShift Data Science, and the potential opportunities for developers using this solution. Intel-Redhat Partner page: intel.com/content/www/us/en/developer/partner/red-hat.html Intel AI Analytics Tookit Operator: catalog.redhat.com/software/operators/detail/60d2745bfea5217cbb0f319a Boost OpenShift Data Science with the Intel®AI Analytics Tookit: developers.redhat.com/articles/2022/09/21/boost-openshift-data-science-intel-ai-analytics-toolkit Intel AI/ML Overview intel.com/content/www/us/en/developer/topic-technology/artificial-intelligence/overview.html Guests Audrey Reznik. – Senior Principal Engineer at Red Hat linkedin.com/in/audrey-reznik-570a9542 Rachel Oberman – AI Software Solutions Engineer at Intel linkedin.com/in/racheloberman
About AmyAmy Tobey has worked in tech for more than 20 years at companies of every size, working with everything from kernel code to user interfaces. These days she spends her time building an innovative Site Reliability Engineering program at Equinix, where she is a principal engineer. When she's not working, she can be found with her nose in a book, watching anime with her son, making noise with electronics, or doing yoga poses in the sun.Links Referenced: Equinix: https://metal.equinix.com Twitter: https://twitter.com/MissAmyTobey 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: Welcome to Screaming in the Cloud, I'm Corey Quinn, and this episode is another one of those real profiles in shitposting type of episodes. I am joined again from a few months ago by Amy Tobey, who is a Senior Principal Engineer at Equinix, back for more. Amy, thank you so much for joining me.Amy: Welcome. To your show. [laugh].Corey: Exactly. So, one thing that we have been seeing a lot over the past year, and you struck me as one of the best people to talk about what you're seeing in the wilderness perspective, has been the idea of cloud repatriation. It started off with something that came out of Andreessen Horowitz toward the start of the year about the trillion-dollar paradox, how, at a certain point of scale, repatriating to a data center is the smart and right move. And oh, my stars that ruffle some feathers for people?Amy: Well, I spent all this money moving to the cloud. That was just mean.Corey: I know. Why would I want to leave the cloud? I mean, for God's sake, my account manager named his kid after me. Wait a minute, how much am I spending on that? Yeah—Amy: Good question.Corey: —there is that ever-growing problem. And there have been the examples that people have given of Dropbox classically did a cloud repatriation exercise, and a second example that no one can ever name. And it seems like okay, this might not necessarily be the direction that the industry is going. But I also tend to not be completely naive when it comes to these things. And I can see repatriation making sense on a workload-by-workload basis.What that implies is that yeah, but a lot of other workloads are not going to be going to a data center. They're going to stay in a cloud provider, who would like very much if you never read a word of this to anyone in public.Amy: Absolutely, yeah.Corey: So, if there are workloads repatriating, it would occur to me that there's a vested interest on the part of every major cloud provider to do their best to, I don't know if saying suppress the story is too strongly worded, but it is directionally what I mean.Amy: They aren't helping get the story out. [laugh].Corey: Yeah, it's like, “That's a great observation. Could you maybe shut the hell up and never make it ever again in public, or we will end you?” Yeah. Your Amazon. What are you going to do, launch a shitty Amazon Basics version of what my company does? Good luck. Have fun. You're probably doing it already.But the reason I want to talk to you on this is a confluence of a few things. One, as I mentioned back in May when you were on the show, I am incensed and annoyed that we've been talking for as long as we have, and somehow I never had you on the show. So, great. Come back, please. You're always welcome here. Secondly, you work at Equinix, which is, effectively—let's be relatively direct—it is functionally a data center as far as how people wind up contextualizing this. Yes, you have higher level—Amy: Yeah I guess people contextualize it that way. But we'll get into that.Corey: Yeah, from the outside. I don't work there, to be clear. My talking points don't exist for this. But I think of oh, Equinix. Oh, that means you basically have a colo or colo equivalent. The pricing dynamics have radically different; it looks a lot closer to a data center in my imagination than it does a traditional public cloud. I would also argue that if someone migrates from AWS to Equinix, that would be viewed—arguably correctly—as something of a repatriation. Is that directionally correct?Amy: I would argue incorrectly. For Metal, right?Corey: Ah.Amy: So, Equinix is a data center company, right? Like that's why everybody knows us as. Equinix Metal is a bare metal primitive service, right? So, it's a lot more of a cloud workflow, right, except that you're not getting the rich services that you get in a technically full cloud, right? Like, there's no RDS; there's no S3, even. What you get is bare metal primitives, right? With a really fast network that isn't going to—Corey: Are you really a cloud provider without some ridiculous machine-learning-powered service that's going to wind up taking pictures, perform incredibly expensive operations on it, and then return something that's more than a little racist? I mean, come on. That's not—you're not a cloud until you can do that, right?Amy: We can do that. We have customers that do that. Well, not specifically that, but um—Corey: Yeah, but they have to build it themselves. You don't have the high-level managed service that basically serves as, functionally, bias laundering.Amy: Yeah, you don't get it in a box, right? So, a lot of our customers are doing things that are unique, right, that are maybe not exactly fit into the cloud well. And it comes back down to a lot of Equinix's roots, which is—we talk but going into the cloud, and it's this kind of abstract environment we're reaching for, you know, up in the sky. And it's like, we don't know where it is, except we have regions that—okay, so it's in Virginia. But the rule of real estate applies to technology as often as not, which is location, location, location, right?When we're talking about a lot of applications, a challenge that we face, say in gaming, is that the latency from the customer, so that last mile to your data center, can often be extremely important, right, so a few milliseconds even. And a lot of, like, SaaS applications, the typical stuff that really the cloud was built on, 10 milliseconds, 50 milliseconds, nobody's really going to notice that, right? But in a gaming environment or some very low latency application that needs to run extremely close to the customer, it's hard to do that in the cloud. They're building this stuff out, right? Like, I see, you know, different ones [unintelligible 00:05:53] opening new regions but, you know, there's this other side of the cloud, which is, like, the edge computing thing that's coming alive, and that's more where I think about it.And again, location, location, location. The speed of light is really fast, but as most of us in tech know, if you want to go across from the East Coast to the West Coast, you're talking about 80 milliseconds, on average, right? I think that's what it is. I haven't checked in a while. Yeah, that's just basic fundamental speed of light. And so, if everything's in us-east-1—and this is why we do multi-region, sometimes—the latency from the West Coast isn't going to be great. And so, we run the application on both sides.Corey: It has improved though. If you want to talk old school things that are seared into my brain from over 20 years ago, every person who's worked in data centers—or in technology, as a general rule—has a few IP addresses seared. And the one that I've always had on my mind was 130.111.32.11. Kind of arbitrary and ridiculous, but it was one of the two recursive resolvers provided at the University of Maine where I had my first help desk job.And it lives on-prem, in Maine. And generally speaking, I tended to always accept that no matter where I was—unless I was in a data center somewhere—it was about 120 milliseconds. And I just checked now; it is 85 and change from where I am in San Francisco. So, the internet or the speed of light have improved. So, good for whichever one of those it was. But yeah, you've just updated my understanding of these things. All of this is, which is to say, yes, latency is very important.Amy: Right. Let's forget repatriation to really be really honest. Even the Dropbox case or any of them, right? Like, there's an economic story here that I think all of us that have been doing cloud work for a while see pretty clearly that maybe not everybody's seeing that—that's thinking from an on-prem kind of situation, which is that—you know, and I know you do this all the time, right, is, you don't just look at the cost of the data center and the servers and the network, the technical components, the bill of materials—Corey: Oh, lies, damned lies, and TCO analyses. Yeah.Amy: —but there's all these people on top of it, and the organizational complexity, and the contracts that you got to manage. And it's this big, huge operation that is incredibly complex to do well that is almost nobody's business. So the way I look at this, right, and the way I even talk to customers about it is, like, “What is your produ—” And I talk to people internally about this way? It's like, “What are you trying to build?” “Well, I want to build a SaaS.” “Okay. Do you need data center expertise to build a SaaS?” “No.” “Then why the hell are you putting it in a data center?” Like we—you know, and speaking for my employer, right, like, we have Equinix Metal right here. You can build on that and you don't have to do all the most complex part of this, at least in terms of, like, the physical plant, right? Like, right, getting a bare metal server available, we take care of all of that. Even at the primitive level, where we sit, it's higher level than, say, colo.Corey: There's also the question of economics as it ties into it. It's never just a raw cost-of-materials type of approach. Like, my original job in a data center was basically to walk around and replace hard drives, and apparently, to insult people. Now, the cloud has taken one of those two aspects away, and you can follow my Twitter account and figure out which one of those two it is, but what I keep seeing now is there is value to having that task done, but in a cloud environment—and Equinix Metal, let's be clear—that has slipped below the surface level of awareness. And well, what are the economic implications of that?Well, okay, you have a whole team of people at large companies whose job it is to do precisely that. Okay, we're going to upskill them and train them to use cloud. Okay. First, not everyone is going to be capable or willing to make that leap from hard drive replacement to, “Congratulations and welcome to JavaScript. You're about to hate everything that comes next.”And if they do make that leap, their baseline market value—by which I mean what the market is willing to pay for them—approximately will double. And whether they wind up being paid more by their current employer or they take a job somewhere else with those skills and get paid what they are worth, the company still has that economic problem. Like it or not, you will generally get what you pay for whether you want to or not; that is the reality of it. And as companies are thinking about this, well, what gets into the TCO analysis and what doesn't, I have yet to see one where the outcome was not predetermined. They're less, let's figure out in good faith whether it's going to be more expensive to move to the cloud, or move out of the cloud, or just burn the building down for insurance money. The outcome is generally the one that the person who commissioned the TCO analysis wants. So, when a vendor is trying to get you to switch to them, and they do one for you, yeah. And I'm not saying they're lying, but there's so much judgment that goes into this. And what do you include and what do you not include? That's hard.Amy: And there's so many hidden costs. And that's one of the things that I love about working at a cloud provider is that I still get to play with all that stuff, and like, I get to see those hidden costs, right? Like you were talking about the person who goes around and swaps out the hard drives. Or early in my career, right, I worked with someone whose job it was this every day, she would go into data center, she'd swap out the tapes, you know, and do a few things other around and, like, take care of the billing system. And that was a job where it was kind of going around and stewarding a whole bunch of things that kind of kept the whole machine running, but most people outside of being right next to the data center didn't have any idea that stuff even happen, right, that went into it.And so, like you were saying, like, when you go to do the TCO analysis, I mean, I've been through this a couple of times prior in my career, where people will look at it and go like, “Well, of course we're not going to list—we'll put, like, two headcount on there.” And it's always a lie because it's never just to headcount. It's never just the network person, or the SRE, or the person who's racking the servers. It's also, like, finance has to do all this extra work, and there's all the logistic work, and there is just so much stuff that just is really hard to include. Not only do people leave it out, but it's also just really hard for people to grapple with the complexity of all the things it takes to run a data center, which is, like, one of the most complex machines on the planet, any single data center.Corey: I've worked in small-scale environments, maybe a couple of mid-sized ones, but never the type of hyperscale facility that you folks have, which I would say is if it's not hyperscale, it's at least directionally close to it. We're talking thousands of servers, and hundreds of racks.Amy: Right.Corey: I've started getting into that, on some level. Now, I guess when we say ‘hyperscale,' we're talking about AWS-size things where, oh, that's a region and it's going to have three dozen data center facilities in it. Yeah, I don't work in places like that because honestly, have you met me? Would you trust me around something that's that critical infrastructure? No, you would not, unless you have terrible judgment, which means you should not be working in those environments to begin with.Amy: I mean, you're like a walking chaos exercise. Maybe I would let you in.Corey: Oh, I bring my hardware destruction aura near anything expensive and things are terrible. It's awful. But as I looked at the cloud, regardless of cloud, there is another economic element that I think is underappreciated, and to be fair, this does, I believe, apply as much to Equinix Metal as it does to the public hyperscale cloud providers that have problems with naming things well. And that is, when you are provisioning something as a customer of one of these places, you have an unbounded growth problem. When you're in a data center, you are not going to just absentmindedly sign an $8 million purchase order for new servers—you know, a second time—and then that means you're eventually run out of power, space, places to put things, and you have to go find it somewhere.Whereas in cloud, the only limit is basically your budget where there is no forcing function that reminds you to go and clean up that experiment from five years ago. You have people with three petabytes of data they were using for a project, but they haven't worked there in five years and nothing's touched it since. Because the failure mode of deleting things that are important, or disasters—Amy: That's why Glacier exists.Corey: Oh, exactly. But that failure mode of deleting things that should not be deleted are disastrous for a company, whereas if you've leave them there, well, it's only money. And there's no forcing function to do that, which means you have this infinite growth problem with no natural limit slash predator around it. And that is the economic analysis that I do not see playing out basically anywhere. Because oh, by the time that becomes a problem, we'll have good governance in place. Yeah, pull the other one. It has bells on it.Amy: That's the funny thing, right, is a lot of the early drive in the cloud was those of us who wanted to go faster and we were up against the limitations of our data centers. And then we go out and go, like, “Hey, we got this cloud thing. I'll just, you know, put the credit card in there and I'll spin up a few instances, and ‘hey, I delivered your product.'” And everybody goes, “Yeah, hey, happy.” And then like you mentioned, right, and then we get down the road here, and it's like, “Oh, my God, how much are we spending on this?”And then you're in that funny boat where you have both. But yeah, I mean, like, that's just typical engineering problem, where, you know, we have to deal with our constraints. And the cloud has constraints, right? Like when I was at Netflix, one of the things we would do frequently is bump up against instance limits. And then we go talk to our TAM and be like, “Hey, buddy. Can we have some more instance limit?” And then take care of that, right?But there are some bounds on that. Of course, in the cloud providers—you know, if I have my cloud provider shoes on, I don't necessarily want to put those limits to law because it's a business, the business wants to hoover up all the money. That's what businesses do. So, I guess it's just a different constraint that is maybe much too easy to knock down, right? Because as you mentioned, in a data center or in a colo space, I outgrow my cage and I filled up all that space I have, I have to either order more space from my colo provider, I expand to the cloud, right?Corey: The scale I was always at, the limit was not the space because I assure you with enough shoving all things are possible. Don't believe me? Look at what people are putting in the overhead bin on any airline. Enough shoving, you'll get a Volkswagen in there. But it was always power constrained is what I dealt with it. And it's like, “Eh, they're just being conservative.” And the whole building room dies.Amy: You want blade servers because that's how you get blade servers, right? That movement was about bringing the density up and putting more servers in a rack. You know, there were some management stuff and [unintelligible 00:16:08], but a lot of it was just about, like, you know, I remember I'm picturing it, right—Corey: Even without that, I was still power constrained because you have to remember, a lot of my experiences were not in, shall we say, data center facilities that you would call, you know, good.Amy: Well, that brings up a fun thing that's happening, which is that the power envelope of servers is still growing. The newest Intel chips, especially the ones they're shipping for hyperscale and stuff like that, with the really high core counts, and the faster clock speeds, you know, these things are pulling, like, 300 watts. And they also have to egress all that heat. And so, that's one of the places where we're doing some innovations—I think there's a couple of blog posts out about it around—like, liquid cooling or multimode cooling. And what's interesting about this from a cloud or data center perspective, is that the tools and skills and everything has to come together to run a, you know, this year's or next year's servers, where we're pushing thousands of kilowatts into a rack. Thousands; one rack right?The bar to actually bootstrap and run this stuff successfully is rising again, compared to I take my pizza box servers, right—and I worked at a gaming company a long time ago, right, and they would just, like, stack them on the floor. It was just a stack of servers. Like, they were in between the rails, but they weren't screwed down or anything, right? And they would network them all up. Because basically, like, the game would spin up on the servers and if they died, they would just unplug that one and leave it there and spin up another one.It was like you could just stack stuff up and, like, be slinging cables across the data center and stuff back then. I wouldn't do it that way now, but when you add, say liquid cooling and some of these, like, extremely high power situations into the mix, now you need to have, for example, if you're using liquid cooling, you don't want that stuff leaking, right? And so, it's good as the pressure fittings and blind mating and all this stuff that's coming around gets, you still have that element of additional training, and skill, and possibility for mistakes.Corey: The thing that I see as I look at this across the space is that, on some level, it's gotten harder to run a data center than it ever did before. Because again, another reason I wanted to have you on this show is that you do not carry a quota. Although you do often carry the conversation, when you have boring people around you, but quotas, no. You are not here selling things to people. You're not actively incentivized to get people to see things a certain way.You are very clearly an engineer in the right ways. I will further point out though, that you do not sound like an engineer, by which I mean, you're going to basically belittle people, in many cases, in the name of being technically correct. You're a human being with a frickin soul. And believe me, it is noticed.Amy: I really appreciate that. If somebody's just listening to hearing my voice and in my name, right, like, I have a low voice. And in most of my career, I was extremely technical, like, to the point where you know, if something was wrong technically, I would fight to the death to get the right technical solution and maybe not see the complexity around the decisions, and why things were the way they were in the way I can today. And that's changed how I sound. It's changed how I talk. It's changed how I look at and talk about technology as well, right? I'm just not that interested in Kubernetes. Because I've kind of started looking up the stack in this kind of pursuit.Corey: Yeah, when I say you don't sound like an engineer, I am in no way shape or form—Amy: I know.Corey: —alluding in any respect to your technical acumen. I feel the need to clarify that statement for people who might be listening, and say, “Hey, wait a minute. Is he being a shithead?” No.Amy: No, no, no.Corey: Well, not the kind you're worried I'm being anyway; I'm a different breed of shithead and that's fine.Amy: Yeah, I should remember that other people don't know we've had conversations that are deeply technical, that aren't on air, that aren't context anybody else has. And so, like, I bring that deep technical knowledge, you know, the ability to talk about PCI Express, and kilovolts [unintelligible 00:19:58] rack, and top-of-rack switches, and network topologies, all of that together now, but what's really fascinating is where the really big impact is, for reliability, for security, for quality, the things that me as a person, that I'm driven by—products are cool, but, like, I like them to be reliable; that's the part that I like—really come down to more leadership, and business acumen, and understanding the business constraints, and then being able to get heard by an audience that isn't necessarily technical, that doesn't necessarily understand the difference between PCI, PCI-X, and PCI Express. There's a difference between those. It doesn't mean anything to the business, right, so when we want to go and talk about why are we doing, for example, multi-region deployment of our application? If I come in and say, “Well, because we want to use Raft.” That's going to fall flat, right?The business is going to go, “I don't care about Raft. What does that have to do with my customers?” Which is the right question to always ask. Instead, when I show up and say, “Okay, what's going on here is we have this application sits in a single region—or in a single data center or whatever, right? I'm using region because that's probably what most of the people listening understand—you know, so I put my application in a single region and it goes down, our customers are going to be unhappy. We have the alternative to spend, okay, not a little bit more money, probably a lot more money to build a second region, and the benefit we will get is that our customers will be able to access the service 24x7, and it will always work and they'll have a wonderful experience. And maybe they'll keep coming back and buy more stuff from us.”And so, when I talk about it in those terms, right—and it's usually more nuanced than that—then I start to get the movement at the macro level, right, in the systemic level of the business in the direction I want it to go, which is for the product group to understand why reliability matters to the customer, you know? For the individual engineers to understand why it matters that we use secure coding practices.[midroll 00:21:56]Corey: Getting back to the reason I said that you are not quota-carrying and you are not incentivized to push things in a particular way is that often we'll meet zealots, and I've never known you to be one, you have always been a strong advocate for doing the right thing, even if it doesn't directly benefit any given random employer that you might have. And as a result, one of the things that you've said to me repeatedly is if you're building something from scratch, for God's sake, put it in cloud. What is wrong with you? Do that. The idea of building it yourself on low-lying, underlying primitives for almost every modern SaaS style workload, there's no reason to consider doing something else in almost any case. Is that a fair representation of your position on this?Amy: It is. I mean, the simpler version right, “Is why the hell are you doing undifferentiated lifting?” Right? Things that don't differentiate your product, why would you do it?Corey: The thing that this has empowered then is I can build an experiment tonight—I don't have to wait for provisioning and signed contracts and do all the rest. I can spend 25 cents and get the experiment up and running. If it takes off, though, it has changed how I move going forward as well because there's no difference in the way that there was back when we were in data centers. I'm going to try and experiment I'm going to run it in this, I don't know, crappy Raspberry Pi or my desktop or something under my desk somewhere. And if it takes off and I have to scale up, I got to do a giant migration to real enterprise-grade hardware. With cloud, you are getting all of that out of the box, even if all you're doing with it is something ridiculous and nonsensical.Amy: And you're often getting, like, ridiculously better service. So, 20 years ago, if you and I sat down to build a SaaS app, we would have spun up a Linux box somewhere in a colo, and we would have spun up Apache, MySQL, maybe some Perl or PHP if we were feeling frisky. And the availability of that would be one machine could do, what we could handle in terms of one MySQL instance. But today if I'm spinning up a new stack for some the same kind of SaaS, I'm going to probably deploy it into an ASG, I'm probably going to have some kind of high availability database be on it—and I'm going to use Aurora as an example—because, like, the availability of an Aurora instance, in terms of, like, if I'm building myself up with even the very best kit available in databases, it's going to be really hard to hit the same availability that Aurora does because Aurora is not just a software solution, it's also got a team around it that stewards that 24/7. And it continues to evolve on its own.And so, like, the base, when we start that little tiny startup, instead of being that one machine, we're actually starting at a much higher level of quality, and availability, and even security sometimes because of these primitives that were available. And I probably should go on to extend on the thought of undifferentiated lifting, right, and coming back to the colo or the edge story, which is that there are still some little edge cases, right? Like I think for SaaS, duh right? Like, go straight to. But there are still some really interesting things where there's, like, hardware innovations where they're doing things with GPUs and stuff like that.Where the colo experience may be better because you're trying to do, like, custom hardware, in which case you are in a colo. There are businesses doing some really interesting stuff with custom hardware that's behind an application stack. What's really cool about some of that, from my perspective, is that some of that might be sitting on, say, bare metal with us, and maybe the front-end is sitting somewhere else. Because the other thing Equinix does really well is this product we call a Fabric which lets us basically do peering with any of the cloud providers.Corey: Yeah, the reason, I guess I don't consider you as a quote-unquote, “Cloud,” is first and foremost, rooted in the fact that you don't have a bandwidth model that is free and grass and criminally expensive to send it anywhere that isn't to you folks. Like, are you really a cloud if you're not just gouging the living piss out of your customers every time they want to send data somewhere else?Amy: Well, I mean, we like to say we're part of the cloud. And really, that's actually my favorite feature of Metal is that you get, I think—Corey: Yeah, this was a compliment, to be very clear. I'm a big fan of not paying 1998 bandwidth pricing anymore.Amy: Yeah, but this is the part where I get to do a little bit of, like, showing off for Metal a little bit, in that, like, when you buy a Metal server, there's different configurations, right, but, like, I think the lowest one, you have dual 10 Gig ports to the server that you can get either in a bonded mode so that you have a single 20 Gig interface in your operating system, or you can actually do L3 and you can do BGP to your server. And so, this is a capability that you really can't get at all on the other clouds, right? This lets you do things with the network, not only the bandwidth, right, that you have available. Like, you want to stream out 25 gigs of bandwidth out of us, I think that's pretty doable. And the rates—I've only seen a couple of comparisons—are pretty good.So, this is like where some of the business opportunities, right—and I can't get too much into it, but, like, this is all public stuff I've talked about so far—which is, that's part of the opportunity there is sitting at the crossroads of the internet, we can give you a server that has really great networking, and you can do all the cool custom stuff with it, like, BGP, right? Like, so that you can do Anycast, right? You can build Anycast applications.Corey: I miss the days when that was a thing that made sense.Amy: [laugh].Corey: I mean that in the context of, you know, with the internet and networks. These days, it always feels like the network engineering as slipped away within the cloud because you have overlays on top of overlays and it's all abstractions that are living out there right until suddenly you really need to know what's going on. But it has abstracted so much of this away. And that, on some level, is the surprise people are often in for when they wind up outgrowing the cloud for a workload and wanting to move it someplace that doesn't, you know, ride them like naughty ponies for bandwidth. And they have to rediscover things that we've mostly forgotten about.I remember having to architect significantly around the context of hard drive failures. I know we've talked about that a fair bit as a thing, but yeah, it's spinning metal, it throws off heat and if you lose the wrong one, your data is gone and you now have serious business problems. In cloud, at least AWS-land, that's not really a thing anymore. The way EBS is provisioned, there's a slight tick in latency if you're looking at just the right time for what I think is a hard drive failure, but it's there. You don't have to think about this anymore.Migrate that workload to a pile of servers in a colo somewhere, guess what? Suddenly your reliability is going to decrease. Amazon, and the other cloud providers as well, have gotten to a point where they are better at operations than you are at your relatively small company with your nascent sysadmin team. I promise. There is an economy of scale here.Amy: And it doesn't have to be good or better, right? It's just simply better resourced—Corey: Yeah.Amy: Than most anybody else can hope. Amazon can throw a billion dollars at it and never miss it. In most organizations out there, you know, and most of the especially enterprise, people are scratching and trying to get resources wherever they can, right? They're all competing for people, for time, for engineering resources, and that's one of the things that gets freed up when you just basically bang an API and you get the thing you want. You don't have to go through that kind of old world internal process that is usually slow and often painful.Just because they're not resourced as well; they're not automated as well. Maybe they could be. I'm sure most of them could, in theory be, but we come back to undifferentiated lifting. None of this helps, say—let me think of another random business—Claire's, whatever, like, any of the shops in the mall, they all have some kind of enterprise behind them for cash processing and all that stuff, point of sale, none of this stuff is differentiating for them because it doesn't impact anything to do with where the money comes in. So again, we're back at why are you doing this?Corey: I think that's also the big challenge as well, when people start talking about repatriation and talking about this idea that they are going to, oh, that cloud is too expensive; we're going to move out. And they make the economics work. Again, I do firmly believe that, by and large, businesses do not intentionally go out and make poor decisions. I think when we see a company doing something inscrutable, there's always context that we're missing, and I think as a general rule of thumb, that at these companies do not hire people who are fools. And there are always constraints that they cannot talk about in public.My general position as a consultant, and ideally as someone who aspires to be a decent human being, is that when I see something I don't understand, I assume that there's simply a lack of context, not that everyone involved in this has been foolish enough to make giant blunders that I can pick out in the first five seconds of looking at it. I'm not quite that self-confident yet.Amy: I mean, that's a big part of, like, the career progression into above senior engineer, right, is, you don't get to sit in your chair and go, like, “Oh, those dummies,” right? You actually have—I don't know about ‘have to,' but, like, the way I operate now, right, is I remember in my youth, I used to be like, “Oh, those business people. They don't know, nothing. Like, what are they doing?” You know, it's goofy what they're doing.And then now I have a different mode, which is, “Oh, that's interesting. Can you tell me more?” The feeling is still there, right? Like, “Oh, my God, what is going on here?” But then I get curious, and I go, “So, how did we get here?” [laugh]. And you get that story, and the stories are always fascinating, and they always involve, like, constraints, immovable objects, people doing the best they can with what they have available.Corey: Always. And I want to be clear that very rarely is it the right answer to walk into a room and say, look at the architecture and, “All right, what moron built this?” Because always you're going to be asking that question to said moron. And it doesn't matter how right you are, they're never going to listen to another thing out of your mouth again. And have some respect for what came before even if it's potentially wrong answer, well, great. “Why didn't you just use this service to do this instead?” “Yeah, because this thing predates that by five years, jackass.”There are reasons things are the way they are, if you take any architecture in the world and tell people to rebuild it greenfield, almost none of them would look the same as they do today because we learn things by getting it wrong. That's a great teacher, and it hurts. But it's also true.Amy: And we got to build, right? Like, that's what we're here to do. If we just kind of cycle waiting for the perfect technology, the right choices—and again, to come back to the people who built it at the time used—you know, often we can fault people for this—used the things they know or the things that are nearby, and they make it work. And that's kind of amazing sometimes, right?Like, I'm sure you see architectures frequently, and I see them too, probably less frequently, where you just go, how does this even work in the first place? Like how did you get this to work? Because I'm looking at this diagram or whatever, and I don't understand how this works. Maybe that's a thing that's more a me thing, like, because usually, I can look at a—skim over an architecture document and be, like, be able to build the model up into, like, “Okay, I can see how that kind of works and how the data flows through it.” I get that pretty quickly.And comes back to that, like, just, again, asking, “How did we get here?” And then the cool part about asking how did we get here is it sets everybody up in the room, not just you as the person trying to drive change, but the people you're trying to bring along, the original architects, original engineers, when you ask, how did we get here, you've started them on the path to coming along with you in the future, which is kind of cool. But until—that storytelling mode, again, is so powerful at almost every level of the stack, right? And that's why I just, like, when we were talking about how technical I bring things in, again, like, I'm just not that interested in, like, are you Little Endian or Big Endian? How did we get here is kind of cool. You built a Big Endian architecture in 2022? Like, “Ohh. [laugh]. How do we do that?”Corey: Hey, leave me to my own devices, and I need to build something super quickly to get it up and running, well, what I'm going to do, for a lot of answers is going to look an awful lot like the traditional three-tier architecture that I was running back in 2008. Because I know it, it works well, and I can iterate rapidly on it. Is it a best practice? Absolutely not, but given the constraints, sometimes it's the fastest thing to grab? “Well, if you built this in serverless technologies, it would run at a fraction of the cost.” It's, “Yes, but if I run this thing, the way that I'm running it now, it'll be $20 a month, it'll take me two hours instead of 20. And what exactly is your time worth, again?” It comes down to the better economic model of all these things.Amy: Any time you're trying to make a case to the business, the economic model is going to always go further. Just general tip for tech people, right? Like if you can make the better economic case and you go to the business with an economic case that is clear. Businesses listen to that. They're not going to listen to us go on and on about distributed systems.Somebody in finance trying to make a decision about, like, do we go and spend a million bucks on this, that's not really the material thing. It's like, well, how is this going to move the business forward? And how much is it going to cost us to do it? And what other opportunities are we giving up to do that?Corey: I think that's probably a good place to leave it because there's no good answer. We can all think about that until the next episode. I really want to thank you for spending so much time talking to me again. If people want to learn more, where's the best place for them to find you?Amy: Always Twitter for me, MissAmyTobey, and I'll see you there. Say hi.Corey: Thank you again for being as generous with your time as you are. It's deeply appreciated.Amy: It's always fun.Corey: Amy Tobey, Senior Principal Engineer at Equinix Metal. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment that tells me exactly what we got wrong in this episode in the best dialect you have of condescending engineer with zero people skills. I look forward to reading it.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.
What RTOS dominates the embedded space? Your first guess might be Linux, but you would be wrong, by a wide margin. FreeRTOS is the winner. If you're wondering how and why FreeRTOS came to be, this is the podcast for you. Today i'm speaking with the RTOS's original creator, Richard Barry. Richard is now part of Amazon Web Services (AWS), but he is still leading the charge for FreeRTOS. Hear how it came about, and where Richard thinks it's going on this this week's Embedded Executives podcast.
About AmyAmy Tobey has worked in tech for more than 20 years at companies of every size, working with everything from kernel code to user interfaces. These days she spends her time building an innovative Site Reliability Engineering program at Equinix, where she is a principal engineer. When she's not working, she can be found with her nose in a book, watching anime with her son, making noise with electronics, or doing yoga poses in the sun.Links Referenced: Equinix Metal: https://metal.equinix.com Personal Twitter: https://twitter.com/MissAmyTobey Personal Blog: https://tobert.github.io/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at Vultr. Optimized cloud compute plans have landed at Vultr to deliver lightning-fast processing power, courtesy of third-gen AMD EPYC processors without the IO or hardware limitations of a traditional multi-tenant cloud server. Starting at just 28 bucks a month, users can deploy general-purpose, CPU, memory, or storage optimized cloud instances in more than 20 locations across five continents. Without looking, I know that once again, Antarctica has gotten the short end of the stick. Launch your Vultr optimized compute instance in 60 seconds or less on your choice of included operating systems, or bring your own. It's time to ditch convoluted and unpredictable giant tech company billing practices and say goodbye to noisy neighbors and egregious egress forever. Vultr delivers the power of the cloud with none of the bloat. “Screaming in the Cloud” listeners can try Vultr for free today with a $150 in credit when they visit getvultr.com/screaming. That's G-E-T-V-U-L-T-R dot com slash screaming. My thanks to them for sponsoring this ridiculous podcast.Corey: Finding skilled DevOps engineers is a pain in the neck! And if you need to deploy a secure and compliant application to AWS, forgettaboutit! But that's where DuploCloud can help. Their comprehensive no-code/low-code software platform guarantees a secure and compliant infrastructure in as little as two weeks, while automating the full DevSecOps lifestyle. Get started with DevOps-as-a-Service from DuploCloud so that your cloud configurations are done right the first time. Tell them I sent you and your first two months are free. To learn more visit: snark.cloud/duplo. Thats's snark.cloud/D-U-P-L-O-C-L-O-U-D.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Every once in a while I catch up with someone that it feels like I've known for ages, and I realize somehow I have never been able to line up getting them on this show as a guest. Today is just one of those days. And my guest is Amy Tobey who has been someone I've been talking to for ages, even in the before-times, if you can remember such a thing. Today, she's a Senior Principal Engineer at Equinix. Amy, thank you for finally giving in to my endless wheedling.Amy: Thanks for having me. You mentioned the before-times. Like, I remember it was, like, right before the pandemic we had beers in San Francisco wasn't it? There was Ian there—Corey: Yeah, I—Amy: —and a couple other people. It was a really great time. And then—Corey: I vaguely remember beer. Yeah. And then—Amy: And then the world ended.Corey: Oh, my God. Yes. It's still March of 2020, right?Amy: As far as I know. Like, I haven't checked in a couple years.Corey: So, you do an awful lot. And it's always a difficult question to ask someone, so can you encapsulate your entire existence in a paragraph? It's—Amy: [sigh].Corey: —awful, so I'd like to give a bit more structure to it. Let's start with the introduction: You are a Senior Principal Engineer. We know it's high level because of all the adjectives that get put in there, and none of those adjectives are ‘associate' or ‘beginner' or ‘junior,' or all the other diminutives that companies like to play games with to justify paying people less. And you're at Equinix, which is a company that is a bit unlike most of the, shall we say, traditional cloud providers. What do you do over there and both as a company, as a person?Amy: So, as a company Equinix, what most people know about is that we have a whole bunch of data centers all over the world. I think we have the most of any company. And what we do is we lease out space in that data center, and then we have a number of other products that people don't know as well, which one is Equinix Metal, which is what I specifically work on, where we rent you bare-metal servers. None of that fancy stuff that you get any other clouds on top of it, there's things you can get that are… partner things that you can add-on, like, you know, storage and other things like that, but we just deliver you bare-metal servers with really great networking. So, what I work on is the reliability of that whole system. All of the things that go into provisioning the servers, making them come up, making sure that they get delivered to the server, make sure the API works right, all of that stuff.Corey: So, you're on the Equinix cloud side of the world more so than you are on the building data centers by the sweat of your brow, as they say?Amy: Correct. Yeah, yeah. Software side.Corey: Excellent. I spent some time in data centers in the early part of my career before cloud ate that. That was sort of cotemporaneous with the discovery that I'm the hardware destruction bunny, and I should go to great pains to keep my aura from anything expensive and important, like, you know, the SAN. So—Amy: Right, yeah.Corey: Companies moving out of data centers, and me getting out was a great thing.Amy: But the thing about SANs though, is, like, it might not be you. They're just kind of cursed from the start, right? They just always were kind of fussy and easy to break.Corey: Oh, yeah. I used to think—and I kid you not—that I had a limited upside to my career in tech because I sometimes got sloppy and I was fairly slow at crimping ethernet cables.Amy: [laugh].Corey: That is very similar to growing up in third grade when it became apparent that I was going to have problems in my career because my handwriting was sloppy. Yeah, it turns out the future doesn't look like we predicted it would.Amy: Oh, gosh. Are we going to talk about, like, neurological development now or… [laugh] okay, that's a thing I struggle with, too right, is I started typing as soon as they would let—in fact, before they would let me. I remember in high school, I had teachers who would grade me down for typing a paper out. They want me to handwrite it and I would go, “Cool. Go ahead and take a grade off because if I handwrite it, you're going to take two grades off my handwriting, so I'm cool with this deal.”Corey: Yeah, it was pretty easy early on. I don't know when the actual shift was, but it became more and more apparent that more and more things are moving towards a world where you could type. And I was almost five when I started working on that stuff, and that really wound up changing a lot of aspects of how I started seeing things. One thing I think you're probably fairly well known for is incidents. I want to be clear when I say that you are not the root cause as—“So, why are things broken?” “It's Amy again. What's she gotten into this time?” Great.Amy: [laugh]. But it does happen, but not all the time.Corey: Exa—it's a learning experience.Amy: Right.Corey: You've also been deeply involved with SREcon and a number of—a lot of aspects of what I will term—and please don't yell at me for this—SRE culture—Amy: Yeah.Corey: Which is sometimes a challenging thing to wind up describing or putting a definition around. The one that I've always been somewhat partial to is, “SRE is DevOps, except you worked at Google for a while.” I don't know how necessarily accurate that is, but it does rile people up.Amy: Yeah, it does. Dave Stanke actually did a really great talk at SREcon San Francisco just a couple weeks ago, about the DORA report. And the new DORA report, they split SRE out into its own function and kind of is pushing against that old model, which actually comes from Liz Fong-Jones—I think it's from her, or older—about, like, class SRE implements DevOps, which is kind of this idea that, like, SREs make DevOps happen. Things have evolved, right, since then. Things have evolved since Google released those books, and we're all just figured out what works and what doesn't a little bit.And so, it's not that we're implementing DevOps so much. In fact, it's that ops stuff that kind of holds us back from the really high impact work that SREs, I think, should be doing, that aren't just, like, fixing the problems, the symptoms down at the bottom layer, right? Like what we did as sysadmins 20 years ago. You know, we'd go and a lot of people are SREs that came out of the sysadmin world and still think in that mode, where it's like, “Well, I set up the systems, and when things break, I go and I fix them.” And, “Why did the developers keep writing crappy code? Why do I have to always getting up in the middle of the night because this thing crashed?”And it turns out that the work we need to do to make things more reliable, there's a ceiling to how far away the platform can take us, right? Like, we can have the best platform in the world with redundancy, and, you know, nine-way replicated data storage and all this crazy stuff, and still if we put crappy software on top, it's going to be unreliable. So, how do we make less crappy software? And for most of my career, people would be, like, “Well, you should test it.” And so, we started doing that, and we still have crappy software, so what's going on here? We still have incidents.So, we write more tests, and we still have incidents. We had a QA group, we still have incidents. We send the developers to training, and we still have incidents. So like, what is the thing we need to do to make things more reliable? And it turns out, most of it is culture work.Corey: My perspective on this stems from being a grumpy old sysadmin. And at some point, I started calling myself a systems engineer or DevOps or production engineer, or SRE. It was all from my point of view, the same job, but you know, if you call yourself a sysadmin, you're just asking for a 40% pay cut off the top.Amy: [laugh].Corey: But I still tended to view the world through that lens. I tended to be very good at Linux systems internals, for example, understanding system calls and the rest, but increasingly, as the DevOps wave or SRE wave, or Google-isation of the internet wound up being more and more of a thing, I found myself increasingly in job interviews, where, “Great, now, can you go wind up implementing a sorting algorithm on the whiteboard?” “What on earth? No.” Like, my lingua franca is shitty Bash, and no one tends to write that without a bunch of tab completions and quick checking with manpages—die.net or whatnot—on the fly as you go down that path.And it was awful, and I felt… like my skill set was increasingly eroding. And it wasn't honestly until I started this place where I really got into writing a fair bit of code to do different things because it felt like an orthogonal skill set, but the fullness of time, it seems like it's not. And it's a reskilling. And it made me wonder, does this mean that the areas of technology that I focused on early in my career, was that all a waste? And the answer is not really. Sometimes, sure, in that I don't spend nearly as much time worrying about inodes—for example—as I once did. But every once in a while, I'll run into something and I looked like a wizard from the future, but instead, I'm a wizard from the past.Amy: Yeah, I find that a lot in my work, now. Sometimes things I did 20 years ago, come back, and it's like, oh, yeah, I remember I did all that threading work in 2002 in Perl, and I learned everything the very, very, very hard way. And then, you know, this January, did some threading work to fix some stability issues, and all of it came flooding back, right? Just that the experiences really, more than the code or the learning or the text and stuff; more just the, like, this feels like threads [BLEEP]-ery. Is a diagnostic thing that sometimes we have to say.And then people are like, “Can you prove it?” And I'm like, “Not really,” because it's literally thread [BLEEP]-ery. Like, the definition of it is that there's weird stuff happening that we can't figure out why it's happening. There's something acting in the system that isn't synchronized, that isn't connected to other things, that's happening out of order from what we expect, and if we had a clear signal, we would just fix it, but we don't. We just have, like, weird stuff happening over here and then over there and over there and over there.And, like, that tells me there's just something happening at that layer and then have to go and dig into that right, and like, just basically charge through. My colleagues are like, “Well, maybe you should look at this, and go look at the database,” the things that they're used to looking at and that their experiences inform, whereas then I bring that ancient toiling through the threading mines experiences back and go, “Oh, yeah. So, let's go find where this is happening, where people are doing dangerous things with threads, and see if we can spot something.” But that came from that experience.Corey: And there's so much that just repeats itself. And history rhymes. The challenge is that, do you have 20 years of experience, or do you have one year of experience repeated 20 times? And as the tide rises, doing the same task by hand, it really is just a matter of time before your full-time job winds up being something a piece of software does. An easy example is, “Oh, what's your job?” “I manually place containers onto specific hosts.” “Well, I've got news for you, and you're not going to like it at all.”Amy: Yeah, yeah. I think that we share a little bit. I'm allergic to repeated work. I don't know if allergic is the right word, but you know, if I sit and I do something once, fine. Like, I'll just crank it out, you know, it's this form, or it's a datafile I got to write and I'll—fine I'll type it in and do the manual labor.The second time, the difficulty goes up by ten, right? Like, just mentally, just to do it, be like, I've already done this once. Doing it again is anathema to everything that I am. And then sometimes I'll get through it, but after that, like, writing a program is so much easier because it's like exponential, almost, growth in difficulty. You know, the third time I have to do the same thing that's like just typing the same stuff—like, look over here, read this thing and type it over here—I'm out; I can't do it. You know, I got to find a way to automate. And I don't know, maybe normal people aren't driven to live this way, but it's kept me from getting stuck in those spots, too.Corey: It was weird because I spent a lot of time as a consultant going from place to place and it led to some weird changes. For example, “Oh, thank God, I don't have to think about that whole messaging queue thing.” Sure enough, next engagement, it's message queue time. Fantastic. I found that repeating myself drove me nuts, but you also have to be very sensitive not to wind up, you know, stealing IP from the people that you're working with.Amy: Right.Corey: But what I loved about the sysadmin side of the world is that the vast majority of stuff that I've taken with me, lives in my shell config. And what I mean by that is I'm not—there's nothing in there is proprietary, but when you have a weird problem with trying to figure out the best way to figure out which Ruby process is stealing all the CPU, great, turns out that you can chain seven or eight different shell commands together through a bunch of pipes. I don't want to remember that forever. So, that's the sort of thing I would wind up committing as I learned it. I don't remember what company I picked that up at, but it was one of those things that was super helpful.I have a sarcastic—it's a one-liner, except no sane editor setting is going to show it in any less than three—of a whole bunch of Perl, piped into du, piped into the rest, that tells you one of the largest consumers of files in a given part of the system. And it rates them with stars and it winds up doing some neat stuff. I would never sit down and reinvent something like that today, but the fact that it's there means that I can do all kinds of neat tricks when I need to. It's making sure that as you move through your career, on some level, you're picking up skills that are repeatable and applicable beyond one company.Amy: Skills and tooling—Corey: Yeah.Amy: —right? Like, you just described the tool. Another SREcon talk was John Allspaw and Dr. Richard Cook talking about above the line; below the line. And they started with these metaphors about tools, right, showing all the different kinds of hammers.And if you're a blacksmith, a lot of times you craft specialized hammers for very specific jobs. And that's one of the properties of a tool that they were trying to get people to think about, right, is that tools get crafted to the job. And what you just described as a bespoke tool that you had created on the fly, that kind of floated under the radar of intellectual property. [laugh].So, let's not tell the security or IP people right? Like, because there's probably billions and billions of dollars of technically, like, made-up IP value—I'm doing air quotes with my fingers—you know, that's just basically people's shell profiles. And my God, the Emacs automation that people have done. If you've ever really seen somebody who's amazing at Emacs and is 10, 20, 30, maybe 40 years of experience encoded in their emacs settings, it's a wonder to behold. Like, I look at it and I go, “Man, I wish I could do that.”It's like listening to a really great guitar player and be like, “Wow, I wish I could play like them.” You see them just flying through stuff. But all that IP in there is both that person's collection of wisdom and experience and working with that code, but also encodes that stuff like you described, right? It's just all these little systems tricks and little fiddly commands and things we don't want to remember and so we encode them into our toolset.Corey: Oh, yeah. Anything I wound up taking, I always would share it with people internally, too. I'd mention, “Yeah, I'm keeping this in my shell files.” Because I disclosed it, which solves a lot of the problem. And also, none of it was even close to proprietary or anything like that. I'm sorry, but the way that you wind up figuring out how much of a disk is being eaten up and where in a more pleasing way, is not a competitive advantage. It just isn't.Amy: It isn't to you or me, but, you know, back in the beginning of our careers, people thought it was worth money and should be proprietary. You know, like, oh, that disk-checking script as a competitive advantage for our company because there are only a few of us doing this work. Like, it was actually being able to, like, manage your—[laugh] actually manage your servers was a competitive advantage. Now, it's kind of commodity.Corey: Let's also be clear that the world has moved on. I wound up buying a DaisyDisk a while back for Mac, which I love. It is a fantastic, pretty effective, “Where's all the stuff on your disk going?” And it does a scan and you can drive and collect things and delete them when trying to clean things out. I was using it the other day, so it's top of mind at the moment.But it's way more polished than that crappy Perl three-liner. And I see both sides, truly I do. The trick also, for those wondering [unintelligible 00:15:45], like, “Where is the line?” It's super easy. Disclose it, what you're doing, in those scenarios in the event someone is no because they believe that finding the right man page section for something is somehow proprietary.Great. When you go home that evening in a completely separate environment, build it yourself from scratch to solve the problem, reimplement it and save that. And you're done. There are lots of ways to do this. Don't steal from your employer, but your employer employs you; they don't own you and the way that you think about these problems.Every person I've met who has had a career that's longer than 20 minutes has a giant doc somewhere on some system of all of the scripts that they wound up putting together, all of the one-liners, the notes on, “Next time you see this, this is the thing to check.”Amy: Yeah, the cheat sheet or the notebook with all the little commands, or again the Emacs config, sometimes for some people, or shell profiles. Yeah.Corey: Here's the awk one-liner that I put that automatically spits out from an Apache log file what—the httpd log file that just tells me what are the most frequent talkers, and what are the—Amy: You should probably let go of that one. You know, like, I think that one's lifetime is kind of past, Corey. Maybe you—Corey: I just have to get it working with Nginx, and we're good to go.Amy: Oh, yeah, there you go. [laugh].Corey: Or S3 access logs. Perish the thought. But yeah, like, what are the five most high-volume talkers, and what are those relative to each other? Huh, that one thing seems super crappy and it's coming from Russia. But that's—hmm, one starts to wonder; maybe it's time to dig back in.So, one of the things that I have found is that a lot of the people talking about SRE seem to have descended from an ivory tower somewhere. And they're talking about how some of the best-in-class companies out there, renowned for their technical cultures—at least externally—are doing these things. But there's a lot more folks who are not there. And honestly, I consider myself one of those people who is not there. I was a competent engineer, but never a terrific one.And looking at the way this was described, I often came away thinking, “Okay, it was the purpose of this conference talk just to reinforce how smart people are, and how I'm not,” and/or, “There are the 18 cultural changes you need to make to your company, and then you can do something kind of like we were just talking about on stage.” It feels like there's a combination of problems here. One is making this stuff more accessible to folks who are not themselves in those environments, and two, how to drive cultural change as an individual contributor if that's even possible. And I'm going to go out on a limb and guess you have thoughts on both aspects of that, and probably some more hit me, please.Amy: So, the ivory tower, right. Let's just be straight up, like, the ivory tower is Google. I mean, that's where it started. And we get it from the other large companies that, you know, want to do conference talks about what this stuff means and what it does. What I've kind of come around to in the last couple of years is that those talks don't really reach the vast majority of engineers, they don't really apply to a large swath of the enterprise especially, which is, like, where a lot of the—the bulk of our industry sits, right? We spend a lot of time talking about the darlings out here on the West Coast in high tech culture and startups and so on.But, like, we were talking about before we started the show, right, like, the interior of even just America, is filled with all these, like, insurance and banks and all of these companies that are cranking out tons of code and servers and stuff, and they're trying to figure out the same problems. But they're structured in companies where their tech arm is still, in most cases, considered a cost center, often is bundled under finance, for—that's a whole show of itself about that historical blunder. And so, the tech culture is tend to be very, very different from what we experience in—what do we call it anymore? Like, I don't even want to say West Coast anymore because we've gone remote, but, like, high tech culture we'll say. And so, like, thinking about how to make SRE and all this stuff more accessible comes down to, like, thinking about who those engineers are that are sitting at the computers, writing all the code that runs our banks, all the code that makes sure that—I'm trying to think of examples that are more enterprise-y right?Or shoot buying clothes online. You go to Macy's for example. They have a whole bunch of servers that run their online store and stuff. They have internal IT-ish people who keep all this stuff running and write that code and probably integrating open-source stuff much like we all do. But when you go to try to put in a reliability program that's based on the current SRE models, like SLOs; you put in SLOs and you start doing, like, this incident management program that's, like, you know, you have a form you fill out after every incident, and then you [unintelligible 00:20:25] retros.And it turns out that those things are very high-level skills, skills and capabilities in an organization. And so, when you have this kind of IT mindset or the enterprise mindset, bringing the culture together to make those things work often doesn't happen. Because, you know, they'll go with the prescriptive model and say, like, okay, we're going to implement SLOs, we're going to start measuring SLIs on all of the services, and we're going to hold you accountable for meeting those targets. If you just do that, right, you're just doing more gatekeeping and policing of your tech environment. My bet is, reliability almost never improves in those cases.And that's been my experience, too, and why I get charged up about this is, if you just go slam in these practices, people end up miserable, the practices then become tarnished because people experienced the worst version of them. And then—Corey: And with the remote explosion as well, it turns out that changing jobs basically means their company sends you a different Mac, and the next Monday, you wind up signing into a different Slack team.Amy: Yeah, so the culture really matters, right? You can't cover it over with foosball tables and great lunch. You actually have to deliver tools that developers want to use and you have to deliver a software engineering culture that brings out the best in developers instead of demanding the best from developers. I think that's a fundamental business shift that's kind of happening. If I'm putting on my wizard hat and looking into the future and dreaming about what might change in the world, right, is that there's kind of a change in how we do leadership and how we do business that's shifting more towards that model where we look at what people are capable of and we trust in our people, and we get more out of them, the knowledge work model.If we want more knowledge work, we need people to be happy and to feel engaged in their community. And suddenly we start to see these kind of generational, bigger-pie kind of things start to happen. But how do we get there? It's not SLOs. It maybe it's a little bit starting with incidents. That's where I've had the most success, and you asked me about that. So, getting practical, incident management is probably—Corey: Right. Well, as I see it, the problem with SLOs across the board is it feels like it's a very insular community so far, and communicating it to engineers seems to be the focus of where the community has been, but from my understanding of it, you absolutely need buy-in at significantly high executive levels, to at the very least by you air cover while you're doing these things and making these changes, but also to help drive that cultural shift. None of this is something I have the slightest clue how to do, let's be very clear. If I knew how to change a company's culture, I'd have a different job.Amy: Yeah. [laugh]. The biggest omission in the Google SRE books was [Ers 00:22:58]. There was a guy at Google named Ers who owns availability for Google, and when anything is, like, in dispute and bubbles up the management team, it goes to Ers, and he says, “Thou shalt…” right? Makes the call. And that's why it works, right?Like, it's not just that one person, but that system of management where the whole leadership team—there's a large, very well-funded team with a lot of power in the organization that can drive availability, and they can say, this is how you're going to do metrics for your service, and this is the system that you're in. And it's kind of, yeah, sure it works for them because they have all the organizational support in place. What I was saying to my team just the other day—because we're in the middle of our SLO rollout—is that really, I think an SLO program isn't [clear throat] about the engineers at all until late in the game. At the beginning of the game, it's really about getting the leadership team on board to say, “Hey, we want to put in SLIs and SLOs to start to understand the functioning of our software system.” But if they don't have that curiosity in the first place, that desire to understand how well their teams are doing, how healthy their teams are, don't do it. It's not going to work. It's just going to make everyone miserable.Corey: It feels like it's one of those difficult to sell problems as well, in that it requires some tooling changes, absolutely. It requires cultural change and buy-in and whatnot, but in order for that to happen, there has to be a painful problem that a company recognizes and is willing to pay to make go away. The problem with stuff like this is that once you pay, there's a lot of extra work that goes on top of it as well, that does not have a perception—rightly or wrongly—of contributing to feature velocity, of hitting the next milestone. It's, “Really? So, we're going to be spending how much money to make engineers happier? They should get paid an awful lot and they're still complaining and never seem happy. Why do I care if they're happy other than the pure mercenary perspective of otherwise they'll quit?” I'm not saying that it's not worth pursuing; it's not a worthy goal. I am saying that it becomes a very difficult thing to wind up selling as a product.Amy: Well, as a product for sure, right? Because—[sigh] gosh, I have friends in the space who work on these tools. And I want to be careful.Corey: Of course. Nothing but love for all of those people, let's be very clear.Amy: But a lot of them, you know, they're pulling metrics from existing monitoring systems, they are doing some interesting math on them, but what you get at the end is a nice service catalog and dashboard, which are things we've been trying to land as products in this industry for as long as I can remember, and—Corey: “We've got it this time, though. This time we'll crack the nut.” Yeah. Get off the island, Gilligan.Amy: And then the other, like, risky thing, right, is the other part that makes me uncomfortable about SLOs, and why I will often tell folks that I talk to out in the industry that are asking me about this, like, one-on-one, “Should I do it here?” And it's like, you can bring the tool in, and if you have a management team that's just looking to have metrics to drive productivity, instead of you know, trying to drive better knowledge work, what you get is just a fancier version of more Taylorism, right, which is basically scientific management, this idea that we can, like, drive workers to maximum efficiency by measuring random things about them and driving those numbers. It turns out, that doesn't really work very well, even in industrial scale, it just happened to work because, you know, we have a bloody enough society that we pushed people into it. But the reality is, if you implement SLOs badly, you get more really bad Taylorism that's bad for you developers. And my suspicion is that you will get worse availability out of it than you would if you just didn't do it at all.Corey: This episode is sponsored by our friends at Revelo. Revelo is the Spanish word of the day, and its spelled R-E-V-E-L-O. It means “I reveal.” Now, have you tried to hire an engineer lately? I assure you it is significantly harder than it sounds. One of the things that Revelo has recognized is something I've been talking about for a while, specifically that while talent is evenly distributed, opportunity is absolutely not. They're exposing a new talent pool to, basically, those of us without a presence in Latin America via their platform. It's the largest tech talent marketplace in Latin America with over a million engineers in their network, which includes—but isn't limited to—talent in Mexico, Costa Rica, Brazil, and Argentina. Now, not only do they wind up spreading all of their talent on English ability, as well as you know, their engineering skills, but they go significantly beyond that. Some of the folks on their platform are hands down the most talented engineers that I've ever spoken to. Let's also not forget that Latin America has high time zone overlap with what we have here in the United States, so you can hire full-time remote engineers who share most of the workday as your team. It's an end-to-end talent service, so you can find and hire engineers in Central and South America without having to worry about, frankly, the colossal pain of cross-border payroll and benefits and compliance because Revelo handles all of it. If you're hiring engineers, check out revelo.io/screaming to get 20% off your first three months. That's R-E-V-E-L-O dot I-O slash screaming.Corey: That is part of the problem is, in some cases, to drive some of these improvements, you have to go backwards to move forwards. And it's one of those, “Great, so we spent all this effort and money in the rest of now things are worse?” No, not necessarily, but suddenly are aware of things that were slipping through the cracks previously.Amy: Yeah. Yeah.Corey: Like, the most realistic thing about first The Phoenix Project and then The Unicorn Project, both by Gene Kim, has been the fact that companies have these problems and actively cared enough to change it. In my experience, that feels a little on the rare side.Amy: Yeah, and I think that's actually the key, right? It's for the culture change, and for, like, if you really looking to be, like, do I want to work at this company? Am I investing my myself in here? Is look at the leadership team and be, like, do these people actually give a crap? Are they looking just to punt another number down the road?That's the real question, right? Like, the technology and stuff, at the point where I'm at in my career, I just don't care that much anymore. [laugh]. Just… fine, use Kubernetes, use Postgres, [unintelligible 00:27:30], I don't care. I just don't. Like, Oracle, I might have to ask, you know, go to finance and be like, “Hey, can we spend 20 million for a database?” But like, nobody really asks for that anymore, so. [laugh].Corey: As one does. I will say that I mostly agree with you, but a technology that I found myself getting excited about, given the time of the recording on this is… fun, I spent a bit of time yesterday—from when we're recording this—teaching myself just enough Go to wind up being together a binary that I needed to do something actively ridiculous for my camera here. And I found myself coming away deeply impressed by a lot of things about it, how prescriptive it was for one, how self-contained for another. And after spending far too many years of my life writing shitty Perl, and shitty Bash, and worse Python, et cetera, et cetera, the prescriptiveness was great. The fact that it wound up giving me something I could just run, I could cross-compile for anything I need to run it on, and it just worked. It's been a while since I found a technology that got me this interested in exploring further.Amy: Go is great for that. You mentioned one of my two favorite features of Go. One is usually when a program compiles—at least the way I code in Go—it usually works. I've been working with Go since about 0.9, like, just a little bit before it was released as 1.0, and that's what I've noticed over the years of working with it is that most of the time, if you have a pretty good data structure design and you get the code to compile, usually it's going to work, unless you're doing weird stuff.The other thing I really love about Go and that maybe you'll discover over time is the malleability of it. And the reason why I think about that more than probably most folks is that I work on other people's code most of the time. And maybe this is something that you probably run into with your business, too, right, where you're working on other people's infrastructure. And the way that we encode business rules and things in the languages, in our programming language or our config syntax and stuff has a huge impact on folks like us and how quickly we can come into a situation, assess, figure out what's going on, figure out where things are laid out, and start making changes with confidence.Corey: Forget other people for a minute they're looking at what I built out three or four years ago here, myself, like, I look at past me, it's like, “What was that rat bastard thinking? This is awful.” And it's—forget other people's code; hell is your own code, on some level, too, once it's slipped out of the mental stack and you have to re-explore it and, “Oh, well thank God I defensively wound up not including any comments whatsoever explaining what the living hell this thing was.” It's terrible. But you're right, the other people's shell scripts are finicky and odd.I started poking around for help when I got stuck on something, by looking at GitHub, and a few bit of searching here and there. Even these large, complex, well-used projects started making sense to me in a way that I very rarely find. It's, “What the hell is that thing?” is my most common refrain when I'm looking at other people's code, and Go for whatever reason avoids that, I think because it is so prescriptive about formatting, about how things should be done, about the vision that it has. Maybe I'm romanticizing it and I'll hate it and a week from now, and I want to go back and remove this recording, but.Amy: The size of the language helps a lot.Corey: Yeah.Amy: But probably my favorite. It's more of a convention, which actually funny the way I'm going to talk about this because the two languages I work on the most right now are Ruby and Go. And I don't feel like two languages could really be more different.Syntax-wise, they share some things, but really, like, the mental models are so very, very different. Ruby is all the way in on object-oriented programming, and, like, the actual real kind of object-oriented with messaging and stuff, and, like, the whole language kind of springs from that. And it kind of requires you to understand all of these concepts very deeply to be effective in large programs. So, what I find is, when I approach Ruby codebase, I have to load all this crap into my head and remember, “Okay, so yeah, there's this convention, when you do this kind of thing in Ruby”—or especially Ruby on Rails is even worse because they go deep into convention over configuration. But what that's code for is, this code is accessible to people who have a lot of free cognitive capacity to load all this convention into their heads and keep it in their heads so that the code looks pretty, right?And so, that's the trade-off as you said, okay, my developers have to be these people with all these spare brain cycles to understand, like, why I would put the code here in this place versus this place? And all these, like, things that are in the code, like, very compact, dense concepts. And then you go to something like Go, which is, like, “Nah, we're not going to do Lambdas. Nah”—[laugh]—“We're not doing all this fancy stuff.” So, everything is there on the page.This drives some people crazy, right, is that there's all this boilerplate, boilerplate, boilerplate. But the reality is, I can read most Go files from top to the bottom and understand what the hell it's doing, whereas I can go sometimes look at, like, a Ruby thing, or sometimes Python and e—Perl is just [unintelligible 00:32:19] all the time, right, it's there's so much indirection. And it just be, like, “What the [BLEEP] is going on? This is so dense. I'm going to have to sit down and write it out in longhand so I can understand what the developer was even doing here.” And—Corey: Well, that's why I got the Mac Studio; for when I'm not doing A/V stuff with it, that means that I'll have one core that I can use for, you know, front-end processing and the rest, and the other 19 cores can be put to work failing to build Nokogiri in Ruby yet again.Amy: [laugh].Corey: I remember the travails of working with Ruby, and the problem—I have similar problems with Python, specifically in that—I don't know if I'm special like this—it feels like it's a SRE DevOps style of working, but I am grabbing random crap off a GitHub constantly and running it, like, small scripts other people have built. And let's be clear, I run them on my test AWS account that has nothing important because I'm not a fool that I read most of it before I run it, but I also—it wants a different version of Python every single time. It wants a whole bunch of other things, too. And okay, so I use ASDF as my version manager for these things, which for whatever reason, does not work for the way that I think about this ergonomically. Okay, great.And I wind up with detritus scattered throughout my system. It's, “Hey, can you make this reproducible on my machine?” “Almost certainly not, but thank you for asking.” It's like ‘Step 17: Master the Wolf' level of instructions.Amy: And I think Docker generally… papers over the worst of it, right, is when we built all this stuff in the aughts, you know, [CPAN 00:33:45]—Corey: Dev containers and VS Code are very nice.Amy: Yeah, yeah. You know, like, we had CPAN back in the day, I was doing chroots, I think in, like, '04 or '05, you know, to solve this problem, right, which is basically I just—screw it; I will compile an entire distro into a directory with a Perl and all of its dependencies so that I can isolate it from the other things I want to run on this machine and not screw up and not have these interactions. And I think that's kind of what you're talking about is, like, the old model, when we deployed servers, there was one of us sitting there and then we'd log into the server and be like, I'm going to install the Perl. You know, I'll compile it into, like, [/app/perl 558 00:34:21] whatever, and then I'll CPAN all this stuff in, and I'll give it over to the developer, tell them to set their shebang to that and everything just works. And now we're in a mode where it's like, okay, you got to set up a thousand of those. “Okay, well, I'll make a tarball.” [laugh]. But it's still like we had to just—Corey: DevOps, but [unintelligible 00:34:37] dev closer to ops. You're interrelating all the time. Yeah, then Docker comes along, and add dev is, like, “Well, here's the container. Good luck, asshole.” And it feels like it's been cast into your yard to worry about.Amy: Yeah, well, I mean, that's just kind of business, or just—Corey: Yeah. Yeah.Amy: I'm not sure if it's business or capitalism or something like that, but just the idea that, you know, if I can hand off the shitty work to some other poor schlub, why wouldn't I? I mean, that's most folks, right? Like, just be like, “Well”—Corey: Which is fair.Amy: —“I got it working. Like, my part is done, I did what I was supposed to do.” And now there's a lot of folks out there, that's how they work, right? “I hit done. I'm done. I shipped it. Sure. It's an old [unintelligible 00:35:16] Ubuntu. Sure, there's a bunch of shell scripts that rip through things. Sure”—you know, like, I've worked on repos where there's hundreds of things that need to be addressed.Corey: And passing to someone else is fine. I'm thrilled to do it. Where I run into problems with it is where people assume that well, my part was the hard part and anything you schlubs do is easy. I don't—Amy: Well, that's the underclass. Yeah. That's—Corey: Forget engineering for a second; I throw things to the people over in the finance group here at The Duckbill Group because those people are wizards at solving for this thing. And it's—Amy: Well, that's how we want to do things.Corey: Yeah, specialization works.Amy: But we have this—it's probably more cultural. I don't want to pick, like, capitalism to beat on because this is really, like, human cultural thing, and it's not even really particularly Western. Is the idea that, like, “If I have an underclass, why would I give a shit what their experience is?” And this is why I say, like, ops teams, like, get out of here because most ops teams, the extant ops teams are still called ops, and a lot of them have been renamed SRE—but they still do the same job—are an underclass. And I don't mean that those people are below us. People are treated as an underclass, and they shouldn't be. Absolutely not.Corey: Yes.Amy: Because the idea is that, like, well, I'm a fancy person who writes code at my ivory tower, and then it all flows down, and those people, just faceless people, do the deployment stuff that's beneath me. That attitude is the most toxic thing, I think, in tech orgs to address. Like, if you're trying to be like, “Well, our liability is bad, we have security problems, people won't fix their code.” And go look around and you will find people that are treated as an underclass that are given codes thrown over the wall at them and then they just have to toil through and make it work. I've worked on that a number of times in my career.And I think just like saying, underclass, right, or caste system, is what I found is the most effective way to get people actually thinking about what the hell is going on here. Because most people are just, like, “Well, that's just the way things are. It's just how we've always done it. The developers write to code, then give it to the sysadmins. The sysadmins deploy the code. Isn't that how it always works?”Corey: You'd really like to hope, wouldn't you?Amy: [laugh]. Not me. [laugh].Corey: Again, the way I see it is, in theory—in theory—sysadmins, ops, or that should not exist. People should theoretically be able to write code as developers that just works, the end. And write it correct the first time and never have to change it again. Yeah. There's a reason that I always like to call staging environments in places I work ‘theory' because it works in theory, but not in production, and that is fundamentally the—like, that entire job role is the difference between theory and practice.Amy: Yeah, yeah. Well, I think that's the problem with it. We're already so disconnected from the physical world, right? Like, you and I right now are talking over multiple strands of glass and digital transcodings and things right now, right? Like, we are detached from the physical reality.You mentioned earlier working in data centers, right? The thing I miss about it is, like, the physicality of it. Like, actually, like, I held a server in my arms and put it in the rack and slid it into the rails. I plugged into power myself; I pushed the power button myself. There's a server there. I physically touched it.Developers who don't work in production, we talked about empathy and stuff, but really, I think the big problem is when they work out in their idea space and just writing code, they write the unit tests, if we're very lucky, they'll write a functional test, and then they hand that wad off to some poor ops group. They're detached from the reality of operations. It's not even about accountability; it's about experience. The ability to see all of the weird crap we deal with, right? You know, like, “Well, we pushed the code to that server, but there were three bit flips, so we had to do it again. And then the other server, the disk failed. And on the other server…” You know? [laugh].It's just, there's all this weird crap that happens, these systems are so complex that they're always doing something weird. And if you're a developer that just spends all day in your IDE, you don't get to see that. And I can't really be mad at those folks, as individuals, for not understanding our world. I figure out how to help them, and the best thing we've come up with so far is, like, well, we start giving this—some responsibility in a production environment so that they can learn that. People do that, again, is another one that can be done wrong, where it turns into kind of a forced empathy.I actually really hate that mode, where it's like, “We're forcing all the developers online whether they like it or not. On-call whether they like it or not because they have to learn this.” And it's like, you know, maybe slow your roll a little buddy because the stuff is actually hard to learn. Again, minimizing how hard ops work is. “Oh, we'll just put the developers on it. They'll figure it out, right? They're software engineers. They're probably smarter than you sysadmins.” Is the unstated thing when we do that, right? When we throw them in the pit and be like, “Yeah, they'll get it.” [laugh].Corey: And that was my problem [unintelligible 00:39:49] the interview stuff. It was in the write code on a whiteboard. It's, “Look, I understood how the system fundamentally worked under the hood.” Being able to power my way through to get to an outcome even in language I don't know, was sort of part and parcel of the job. But this idea of doing it in artificially constrained environment, in a language I'm not super familiar with, off the top of my head, it took me years to get to a point of being able to do it with a Bash script because who ever starts with an empty editor and starts getting to work in a lot of these scenarios? Especially in an ops role where we're not building something from scratch.Amy: That's the interesting thing, right? In the majority of tech work today—maybe 20 years ago, we did it more because we were literally building the internet we have today. But today, most of the engineers out there working—most of us working stiffs—are working on stuff that already exists. We're making small incremental changes, which is great that's what we're doing. And we're dealing with old code.Corey: We're gluing APIs together, and that's fine. Ugh. I really want to thank you for taking so much time to talk to me about how you see all these things. If people want to learn more about what you're up to, where's the best place to find you?Amy: I'm on Twitter every once in a while as @MissAmyTobey, M-I-S-S-A-M-Y-T-O-B-E-Y. I have a blog I don't write on enough. And there's a couple things on the Equinix Metal blog that I've written, so if you're looking for that. Otherwise, mainly Twitter.Corey: And those links will of course be in the [show notes 00:41:08]. Thank you so much for your time. I appreciate it.Amy: I had fun. Thank you.Corey: As did I. Amy Tobey, Senior Principal Engineer at Equinix. 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, or on the YouTubes, smash the like and subscribe buttons, as the kids say. Whereas if you've hated this episode, same thing, five-star review all the platforms, smash the buttons, but also include an angry comment telling me that you're about to wind up subpoenaing a copy of my shell script because you're convinced that your intellectual property and secrets are buried within.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.
Rapid and ongoing advances in digital technologies have made agile adaptation the norm in industrial manufacturing. However, disruptions caused by the pandemic have forced leaders to look at infrastructure issues to plan for future disruptions. In this episode of “To the Edge and Beyond,” host James Kent talks with Irene Petrick, Senior Director of Industrial Innovation, and Faith McCreary, Senior Principal Engineer and Senior Researcher and Strategist for Industrial Innovation, both at Intel, about the challenges leaders face and what it will take to survive and thrive in the “new normal.”“COVID has been an amplifier for pre-existing issues such as access to digital data, worker safety, poor information quality, and unexpected data variances,” says McCreary. “Fortunately, industry leaders are starting to see that infrastructure is an important enabler that can help them deal with those issues.”Petrick agrees, adding “The lesson they've learned is that they need to be better prepared. There are no quick fixes. Disruptions can come from anywhere and will continue.”Petrick and McCreary expect remote work, resource fragility, worker safety, and global supply chain issues to make the need for changes to infrastructure very clear. “Our work suggests that the infrastructure piece is a critical problem,” says Petrick. “Machines give off an incredible amount of data. But not all of it is relevant. We have to figure out what data matters, how often to collect it, and how to process it at the edge so that we're only capturing the most important aspects.”Labor shortages further increase infrastructure problems. “Employers used to feel that automation would replace workers. But the concern now is they don't have enough workers so they must automate,” Petrick says. “Companies are having to scramble to attract, keep, and figure out how to equip workers with AI and automation solutions that augment their ability to do their jobs,”“There are just not enough digitally savvy workers to go around,” adds McCreary, “and that's not going to change anytime soon. What makes it more complicated is that it's not enough for a worker to have digital skills. They also need an understanding of manufacturing. Leaders need what we call ‘double-deep' workers with both manufacturing and technology skills.”According to Petrick and McCreary, the solution lies in creating an ecosystem of collaborators. “It's like making a patchwork quilt,” says McCreary, “and everyone is looking to Intel to bring the pieces together – to play the role of matchmaker. We're spending a lot of time developing standards to help the ecosystem partners play well together in the sandbox.”“It's a great time for technology companies,” says Petrick, “because it gives us problems that digital technologies can solve very well.”Connect with Irene Petrick and Faith McCreary on LinkedIn. To learn more about the latest in Industrial IoT and digital transformation visit: www.intel.com/industrial Subscribe to the “To the Edge and Beyond” Channel on Apple Podcasts, Spotify, or Google Podcasts from the Intel Internet of Things Group.
Throughout history, humans have seen new technologies through the lens of what came before – such as when the first cars were called “horseless carriages.” As the technology advances, of course, these terms seem absurd in hindsight. Autonomous vehicles face this challenge today, as many of the most common misperceptions of this technology, and its possible futures, trace back to thinking of them purely as cars that happen to drive themselves. In this PAVEcast episode, we'll start to recognize how our understanding of cars shapes our view of AVs. Our panelists will discuss the important lessons this influence filters out, why “driverless cars” are actually just one of many applications of autonomous technology, and how to start building a mental model for AVs that frees us from this subconscious constraint.PanelistsAdam Campbell – Senior Manager, Safety Innovation and Impact, GatikJohn Lenneman, Ph.D. – Senior Principal Engineer, Collaborative Safety Research Center, Toyota Motor North AmericaJoseph Putney – VP of Commercial Systems, RR.AIModeratorTabitha Colter - Director of Operations, PAVE
Moshe Wasserblat is a Senior Principal Engineer at Intel, where he serves as a Research Manager focused on NLP and Deep Learning. Download a FREE copy of our recent NLP Industry Survey Results: https://gradientflow.com/2021nlpsurvey/Subscribe: Apple • Android • Spotify • Stitcher • Google • AntennaPod • RSS.Detailed show notes can be found on The Data Exchange web site.Subscribe to The Gradient Flow Newsletter.
In this episode of Cyber Security Inside What That Means, Camille continues her conversation on non-fungible tokens (NFTs) with Mic Bowman, Senior Principal Engineer at Intel. This second part of the conversation covers: - Why NFTs exist and some thoughts on why we are creating scarcity in the digital world. - Where NFTs might be headed, such as in the direction of patents and software. - How NFTs could allow people who collect data to get that information to people who need the data. - How privacy and ethics play a role in NFTs and the passing of digital data. ...and more. Don't miss it! The views and opinions expressed are those of the guests and author and do not necessarily reflect the official policy or position of Intel Corporation. Here are some key takeaways: - One way an NFT could work is that you build a model that you can use as a plug in or something in your own software. And someone else can use it in their software, but they don't own the NFT so they can't see how the software is built. It gives us new ways to define what ownership is. - It could be possible to code an NFT such that you don't only own the art, but also the copyright. It becomes a licensed art piece. Some have discussed using NFTs in patents. - Right now there are copyright laws in simple media. But as we extend the idea of NFTs into patents and other industries, we don't know what ownership of the NFTs actually conveys. There will need to be some serious legal discussions, and it isn't well-defined yet. - We currently have sensors collecting all kinds of data that would be useful to people. But getting that data to an open market of people who might find it valuable is really difficult and not cost effective right now. If we can connect the data makers with those who want the data in an open market, we can collect and publish things we couldn't have before. An example of this is an existing vineyard who already collects soil data and climate data for optimizing growing now has a way to get that information to someone wanting to start a new field. - YouTube is a good analogy for NFTs. YouTube gives someone who knows something or can do something well an opportunity to monetize that skill through advertisements or subscriptions. Right now, when data is collected, there is no way to monetize that or get value on that information. If there were, like NFTs, we might see people collecting and sharing more information. Of course, one danger of this is ensuring that the data is being used appropriately, which is still very much an open question. - How do you protect the asset that goes along with NFTs? Let's say I have a model that I have trained using machine learning and confidential information. When I give you the right to use the model, I don't give you the right to see the data that went into training it. But how do I stop you from copying this asset and selling it independently? - We know how to trade NFTs, but what we aren't great at yet is updating the NFT as we trade physical things. Syncing those two things is difficult unless you build it that way from the beginning. - Partial ownership of NFTs is interesting. You can't own part of an image, like a slice of pixels, but if you are purchasing it for investment and resale, partial ownership makes a lot of sense. - Why create digital scarcity when anything digital can be reproduced? Why is scarcity valuable? It makes things collectible. The whole point is that we can own something that nobody else does, and defining the value of owning that thing. You can own a digital print of a Monet, but it isn't the original Monet. And for somebody, it is worth the money to own that collectible. Some interesting quotes from today's episode: “There was one company that was talking about taking all of their patents, creating NFTs for the patents, and ownership of the NFT would convey certain rights to use the intellectual property that was part of the patent.” - Mic Bowman on where NFTs might be headed “The asset is a separate thing out there, the picture. I may try to resell the picture, even though the NFT doesn't necessarily give me the rights to do that. And honestly that distinction between the two and sort of these open market may be the biggest barrier in extending NFTs out into new assets.” - Mic Bowman “In some sense this is the most exciting and most speculative kind of aspect and usage for NFTs is can we really start to monetize data?” - Mic Bowman “It's terrifying, actually. The biggest barrier for me on the technical side is how do we make it possible to do this monetization of data and preserve the appropriate use of that data?” - Mic Bowman on needing also pay attention to ethics and privacy when talking about NFTs “Are there ways that we can protect the intellectual property and those assets to create digital scarcity and to protect the assets more rigidly than we currently have?” - Mic Bowman “The digital print may look just as good on my wall, but it's not a Monet. It's not the original Monet. The print on my wall is worth $25 bucks. The Monet, the painting Waterfront just sold at Christie's for what, $60 million or some ridiculously high number. It's worth that much to somebody. Is it worth it because they are a collector? Is it worth it because they value seeing the paintbrush strokes on the Monet? I don't know.” - Mic Bowman
In this episode of Cyber Security Inside What That Means, Camille Morhardt jumps into the non-fungible token (NFT) conversation with Mic Bowman, Senior Principal Engineer at Intel. The conversation covers: - What an NFT is, with several examples - How an NFT is purchased and traded - How owning an NFT is different from owning the asset the NFT is connected to, and potential issues and opportunities that arise from that idea - What an NFT could become in the future, and where we might be headed ...and more. Don't miss it! The views and opinions expressed are those of the guests and author and do not necessarily reflect the official policy or position of Intel Corporation. Here are some key takeaways: - NFTs, or non-fungible tokens, are a tradable representation for digital assets. It's like the title for your car - it conveys a sense of the vehicle and ownership, but the vehicle itself is separate from the title. - NFTs are pretty much only bought with cryptocurrency. And the NFT itself, the asset, cannot be subdividable (even if we can have partial ownership). For example, multiple people can own a piece of art together, but you can't cut up the work of art. - Although digital art can be copied and downloaded, what NFTs really focus on is that we create value in ownership and where it came from. What makes it valuable is our belief that it has value because of who created it, where it came from, or what it is. - Digital marketplaces have existed in video games for quite a while. In World of Warcraft, you can buy certain characters or levels or things that will add value to your game. What the NFT does is allow the marketplace to be open. It becomes more about investment and market dynamics, and could create more opportunities for making these things happen. It moves the marketplace outside the game. - The music industry is using NFTs in creative ways as well. Beyond just purchasing a song or an album, an NFT can allow for different ways to get revenue from the artists' clientele. Perhaps you can get credits for purchasing better tickets, or being a part of a fan club. It's about the ownership more than the thing itself. - In terms of who makes the money, in some ways it is the companies and the businesses who are taking taxes or transaction fees or licensing fees. In others it is the creators. In others, it's investors and external people. It's an economy with every complexity that goes into any economy. - The majority of things being traded as NFTs right now are digital (images, videos, events, items, etc.). But once we have the NFTs and that abstract representation of a tradable interface, it can be bound to anything, even the non-digital. - For some NFTs, you can only see the asset if you are on that platform. The platform will manage who has access. However in an open market, there isn't a guarantee that you will be able to always access it from the platform that sold it to you. Some people are told to make a copy of the asset quickly, before it goes away. - In some cases, when you buy an NFT, it comes with a licensing agreement that tells you what you can and can't do with the asset. Are you able to collect fees or royalties on someone else using it? Can you trade it or resell it? It is very case-by-case, and is often not defined. You own the NFT, you don't necessarily own the asset. This could become future legal battles in the future. Some interesting quotes from today's episode: “Really what you're purchasing with an NFT is provenance. It's kind of like when you purchase an antique, you can buy an old dresser and it's kind of an old dresser. But if that old dresser once sat in George Washington's mansion, then it's a very different thing, right? You can come up with other dressers that might be the same, but the fact that it came from George Washington's mansion is what really adds value and creates value.” - Mic Bowman “It's not that the tweet itself is that interesting. It's that Jack Dorsey created the NFT for it. So anybody can go out and make a copy of the tweet. Who cares, right? We can all go back and look at it. But only one person can own Jack Dorsey's NFT that he created for it.” - Mic Bowman “It goes back in some sense to that notion of collectibles. It's what makes the Honus Wagner baseball card worth $2 million. It's a piece of cardboard, right? What makes it valuable is that people believe it has value.” - Mic Bowman “What makes an original Monet worth $50 million? Is it because the painting itself is worth $50 million? Maybe for some people. But it's the ownership of the Monet. That's really what it's about.” - Mic Bowman “It's a marketplace for connecting value and value chains. And once you have this NFT, what you can trade is almost universal.” - Mic Bowman “An NFT is nothing more than a unique identifier. Think of it as a serial number.” - Mic Bowman “In some cases, the artist can retain the copyright. An artist could potentially make revenue every time you trade, or show, or make available the asset. So, the asset is existing independent of your ownership of it.”- Camille Morhardt
Relicans host, Lauren Lee, talks to Senior Principal Engineer at Twilio, Scott Haines, about having a passion for distributed systems and event-based architectures, being a Databricks Beacon, and playing a critical role in establishing best practices for other emerging insights and analytics products in technology.Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.
The use of Artificial Intelligence and other new technologies is becoming essential for manufacturers working to build resilience and remain competitive in an ever-changing marketplace. According to a recent survey from The Manufacturer, 65 percent of leaders in the manufacturing sector are working to adopt AI. In this episode of To The Edge and Beyond, Host Tyler Kern talked with Tara Thimmanaik, Systems Architect and Dave Austin, Senior Principal Engineer for the Industrial Solutions Division at Intel about adopting industrial AI for smarter manufacturing. More and more manufacturers are seeing AI as the way of the future, so much so that its adoption is expected to grow at a rate of 57.2 percent CAGR over the next five years within warehouses. However, implementation can be challenging and there are barriers to entry. "The barriers are everywhere. “They usually start with the fact that there's never enough data,” says Austin. “You've also got to have enough of the right kinds of data. AI needs context, labels, and quality to create viable solutions.” Thimmanaik agrees adding, “It's not just about getting AI training right. It's about taking the environment in which the AI performs into consideration. That's what Industry 4.0 is all about – the digital transformation of manufacturing.”Thanks to the COVID pandemic, companies are realizing they need to innovate and shift their focus. “As a system architect, I like to understand what it takes to make those 4.0 transformations happen on factory floors,” Thimmanaik says. “There are LOTS of technologies which must come together and play well. We must realize that only those technologies that make business sense will be adopted.”"AI is very good at giving us insight into what it's trained to do,” said Austin, “but once we start getting into that space of asking it to give us an answer for something it isn't trained to do, or outside of that data space, it's actually not so great." Thimmanaik stresses that what is needed is an ecosystem of solutions. “Intel has a whole range of market-ready solutions, and we partner with some of the best players in this industry. It's about identifying business problems and developing end-to-end solutions that are easily scalable.”To learn more about Tara Thimmanaik and Dave Austin:• Connect with them on LinkedIn• Visit www.intel.com/manufacturingSubscribe to this channel on Apple Podcasts, Spotify and Google Podcasts to hear more from the Intel Internet of Things Group.
On this episode of the Futurum Tech Webcast – Interview Series, sponsored by Intel, I am joined by Rebecca Weekly, Vice President, General Manager, and Senior Principal Engineer of Hyperscale Strategy and Execution at Intel Corporation for conversation around system and software advances for cloud at scale. We also explored her keynote presentation from Intel InnovatiON 2021. Live from Intel InnovatiON: Elevate Your Cloud With Rebecca Weekly In our conversation we discussed the following: Challenges that developers face across the cloud ecosystem An exploration into the way hyperscalers need to evolve their thinking about the cloud Why security is more important than ever The key priorities as we seek to improve reliability and performance What Intel's ESG initiative looks like As always it was a great conversation and one you don't want to miss. If you want to learn more about Intel's cloud initiatives you can visit their website. Be sure to check out the complete episode below.
In this episode, the IoT Integrator Wire editors talk with Dave Austin, Senior Principal Engineer at Intel Corporation. Dave holds a patent for development of a method for manufacturing a semiconductor component, and he is also Intel's only Kaggle Grandmaster. Dave talks about how he earned that distinction and his winning ships vs. icebergs image classification project. He also talks about how the COVID-19 pandemic has accelerated the use of data automation and machine learning, and he offers insights into practical ways that solution integrators can put data to work.
In this episode, the IoT Integrator Wire editors talk with Dave Austin, Senior Principal Engineer at Intel Corporation. Dave holds a patent for development of a method for manufacturing a semiconductor component, and he is also Intel's only Kaggle Grandmaster. Dave talks about how he earned that distinction and his winning ships vs. icebergs image classification project. He also talks about how the COVID-19 pandemic has accelerated the use of data automation and machine learning, and he offers insights into practical ways that solution integrators can put data to work.
This week's episode of 'Advancing ALL Women,' with host Sarah Alter, President and CEO of Network of Executive Women, is 'Women in STEM.' Joining Sarah are guests Dr. Jayshree Seth, Corporate Scientist and Chief Science Advocate at 3M; Monique Picou, Global Executive: Product, Tech Strategy, & Server Operations, Google; and Tiffany Sargent, Chief Technologist for Cloud and Enterprise Sales and is a Senior Principal Engineer at Intel Corporation. Our panel will discuss the importance of bringing more women into STEM fields, the barriers women face to entering the industry, and best practices for opening the door wider to women.
This week's episode of 'Advancing ALL Women,' with host Sarah Alter, President and CEO of Network of Executive Women, is 'Women in STEM.' Joining Sarah are guests Dr. Jayshree Seth, Corporate Scientist and Chief Science Advocate at 3M; Monique Picou, Global Executive: Product, Tech Strategy, & Server Operations, Google; and Tiffany Sargent, Chief Technologist for Cloud and Enterprise Sales and is a Senior Principal Engineer at Intel Corporation. Our panel will discuss the importance of bringing more women into STEM fields, the barriers women face to entering the industry, and best practices for opening the door wider to women.
Even as some aspects of life return to “normal” in 2021, security modeling will never go back to a pre-pandemic state. In this episode of What That Means, Camille and guest Cathy Spence, Senior Principal Engineer at Intel, discuss the importance of zero trust adoption as more and more people work from home. The conversation covers: • The basic facets of the zero trust model, and how those can be compared those against older concepts like digital rights management and IDAM (Identity and Access Management) • How the pandemic accelerated the use of more modern provisioning models, and why zero trust is so important when so many people are working remotely • The kinds of vulnerabilities people face outside the firewall • What the workplace could look like post-pandemic, as well as predictions about the future of AI ... and more! Listen in on the fascinating discussion! The views and opinions expressed are those of the guests and author and do not necessarily reflect the official policy or position of Intel Corporation. Here are some key take-aways: • As more and more people work from home, and management tools become more cloud-based than on-premise based, zero trust securities become especially vital; if one device becomes infected, you don't want it to affect the entire network. • Currently, threat modeling is largely “cloud-first”, but in the future, it's likely to be “AI-first”. • As new solutions are implemented, it will be key to find the right balance between tracking and preserving people's privacy. • The general consensus is that adopting zero trust models is the way forward for data and asset protection as the world becomes less predictable. • Things will not go back to the way they were, and so it's crucial to fully adopt and embrace new models. Some interesting quotes from today's episode: “2021 is the year for zero trust, of people really fully embracing the zero trust kind of model, and it's because of these challenges that are beyond basic security hygiene.” “When the pandemic struck, it really accelerated a move to modern [management techniques], and some companies were better positioned than others to survive in this environment.” “Security is always an arms race, because as you address certain security problems, the attackers find a way to get around those, and you have to keep upping your game. This kind of approach really provides a great foundation for you to protect yourself.” “It's really about setting yourself up so that you can take better advantage of AI. What the pandemic has taught us is that the world's becoming less and less predictable.” “We're very sensitive about privacy at Intel. We have a process for that. We check ourselves, we go through a privacy review, and we make sure we're doing the right thing when it comes to people's privacy.” “We're not going to go back to working the way that we used to work, we're not going to look backward to the old security models. If you don't really implement the full model, and you let certain applications or certain things skirt the guidelines of zero trust, then it really does fall apart. You really want to embrace that.”
From spiderman to Loki to Rick and Morty, pop culture loves a good multiverse at the moment. In this episode we ask a quantum physicist what a multiverse is and whether the science behind it checks out. Expert guestJim Rantschler teaches physics at Texas A&M at Galveston. He has worked as an NRC postdoc at the National Institute of Standards and Technology, a research professor at the University of Houston, and a Senior Principal Engineer at Western Digital. He previously taught at Xavier University of Louisiana. Jim hosts the awesome Physics Frontiers podcast which you can check out here. Comedian guestEve is an effortlessly funny New Yorker formerly based in Melbourne, Australia. She hosts the Everyone is Doing Better Than Me podcast. When it's safe and legal I highly recommend you check her out live and on-stage, but until then, listen to her podcast :)
Did you know that your desk speaks volumes about you? Environmental psychology consultant Lily Bernheimer analyzes host Mel Green’s desk personality type. Lily says that knowing our type can help us design our own physical workspaces in a way that will help us work better - whether we’re setting up in a coffee shop, dining room, office, or all of the above. Then we move into the digital workspace with James Bulpin, Citrix’s Senior Principal Engineer with the Emerging Solutions Team. James offers tips and insight into how digital design can make our lives easier. It can remove distractions that stretch out the work day. It can reduce the number of passwords we have to remember. And it can allow us to work from many devices in many locations. Ultimately, good design can help us succeed in work and have time for play.Explore Fieldwork by Citrix for research and stories to transform the way we work. Visit us here for more on the Citrix Workspace James Bulpin has written about how the digital workspace can support well-being. Lily Bernheimer is the Director of Spaceworks Consulting and the author of The Shaping of Us: How Everyday Spaces Structure Our Lives, Behavior, and Well-Being. Read more about Lily Bernheimer’s personality desk types here.
Powering Urban Air Mobility (UAM) has challenges and solutions. Continuing the series on this vertical on Future of Air Transportation, host Tyler Kern sat down with Marcus Priest, Senior Principal Engineer at TE Connectivity.
The Cookware Manufacturers Association has the privilege of having incredible people as our members. In this What’s Cooking with the Cookware Manufacturing Association episode, we are kicking off our Women in Housewares series in celebration of women’s history month. Host Fran Groesbeck has a conversation with Senior Principal Engineer of Amway, Sue Hoff, and the Transitioning Managing Director of the CMA, Penny Rosema to discuss their journey in the cookware industry. They share insights on how they moved up the ranks in the housewares industry and give advice on what they had learned as they achieved their milestones. Do you know the story of Rosalind Franklin? In 1962, three men received the Nobel Prize for their work on DNA. Not so surprisingly, a fourth member of the team went unacknowledged: the woman whose data and photographs led to their discovery. Essentially erased from scientific history, Rosalind Franklin was a focused and bright young scientist who was determined to make her presence known. What about Brownie Wise? The original girl boss, Brownie Wise capitalized on postwar optimism to build an empire that has made its way into every home in America. Though she did not invent Tupperware, she elevated it from random accessory to a suburban must-have by hosting parties that demonstrated its use. As sales soared, she became the first woman to appear on the cover of Business Week. These stories are examples of the power of women in industry. In honor of women’s history month, and to kick off this new series, listen in as we shine the light on two incredible women in our industry and our association, Sue Hoff of Amway and Penny Rosema of the CMA.
In this episode of CableStakes, hear from Cisco's John Chapman, Cisco Fellow and CTO of broadband technologies, and two special guests from Riot Games, McDonald Richards, Senior Principal Engineer and Scott Adametz, Head of Technology, Global Esports, as we explore the world of online gaming and the impact its rising popularity is having on cable networks. To learn more check out our recent blog - https://newsroom.cisco.com/feature-content?type=webcontent&articleId=2109228
Who better to have a spicy discussion with about #OpenMP than Tim Mattson and Bronis de Supinski? These two have truly lived at the forefront of the amazing, decades-long OpenMP journey, from its inception to its preeminence as a foundational tool for HPC application programmers. Listen to what’s coming in 5.1 and beyond, how the C++ ecosystem is evolving, why Python in HPC, and have fun as these two razz each other. Guests: Bronis de Supinski, Chief Technology Officer, Livermore Computing, Lawrence Livermore National Lab; Chair, OpenMP Language Committee Tim Mattson, Senior Principal Engineer, and Manager, Programming Systems Research Group, Intel To learn more: OpenMP.org Intel oneAPI HPC Toolkit oneAPI
WiseUp talking with Panduit legend and Senior Principal Engineer, Bob Voss. In addition to his decades of service at Panduit, he finds time to sit on the Ethernet Alliance Single Pair Ethernet (SPE) subcommittee, amongst being active in several other industry groups. Tune in and WiseUp to what Panduit has going on. Whether you work in data centers, building automation or automotive and manufacturing you should check out this episode. Please note; the Automation Fair premier industrial automation event hosted by Rockwell Automation and their partners is coming soon. This is a virtual event & will feature a panel webinar about SPE with Peter Jones, Theo Brillhart and Bob Voss. The webinar will broadcasts live during the period of Nov 16th – Nov 20th and then will be available on demand.
Los ataques de falsa bandera se mueven no solo en el terreno físico sino que cada día están más presentes en el ciberespacio. Gobiernos, organizaciones, grupos de cibercriminales, juegan con el engaño y se envuelven bajo una bandera falsa al lanzar sus #ciberataques para intentar atribuir la autoría a otros y camuflar así sus verdaderas intenciones. Un ciberdebate para reflexionar sobre qué son estas operaciones de falsa bandera y el por qué y cómo surgen. Más información en: https://www.yolandacorral.com/ataques-de-falsa-bandera Los invitados que participan en el ciberdebate son: ◼️ David Barroso (https://twitter.com/lostinsecurity). Ingeniero informático con amplia experiencia en intenligencia, incidentes y seguridad en las redes. Fundador de CounterCraft (https://www.countercraft.eu), cuyo objetivo es ayudar a empresas y gobiernos de todo el mundo a definir y desplegar campañas de contrainteligencia digital. ◼️ José Manuel Díaz-Caneja (https://twitter.com/JDiaz_Caneja). Teniente Coronel del Ejército de Tierra. Diplomado Superior en Inteligencia. Ha ocupado diversos puestos de inteligencia, tanto en territorio nacional como en despliegues bajo mando de la OTAN y la UE. Es responsable de formación de I+L Inteligencia y Liderazgo (https://inteligenciayliderazgo.com). ◼️ Ismael Valenzuela (https://twitter.com/aboutsecurity). Senior Director y Senior Principal Engineer de Enterprise Products en McAfee (https://www.mcafee.com), instructor certificado y autor para los currículos de Ciber Defensa y Forense Digital del SANS Institute (https://www.sans.org). Ha liderado equipos de élite de respuesta a incidentes, forense, investigación de amenazas y análisis de malware en compañías como Intel y ha asesorado y formado a algunas de las organizaciones públicas y privadas más importantes del mundo. Blog personal: http://blog.ismaelvalenzuela.com ◼️ Josep Albors (https://twitter.com/JosepAlbors). Responsable de Investigación y Concienciación en ESET España (https://www.eset.com/es/). Editor del blog ESET España Protegerse (https://blogs.protegerse.com) y colaborador en el blog internacional de ESET en español. Especializado en el análisis de malware y la investigación de nuevas amenazas. Formador para las Fuerzas y Cuerpos de Seguridad del Estado y profesor en diversos cursos y másters en universidades españolas. Directora y presentadora: ◼️ Yolanda Corral (https://twitter.com/yocomu). Periodista. Formadora freelance especializada en ciberseguridad de tú a tú y competencias digitales (https://www.yolandacorral.com/servicios-formacion). Fundadora del canal Palabra de hacker. _________________________ Sigue Palabra de hacker tu canal de #ciberseguridad de tú a tú: 🔴 Canal de YouTube, suscríbete para no perderte ningún vídeo: https://www.youtube.com/c/Palabradehacker-ciberseguridad 🎙 Suscríbete y escucha todos los podcasts en: ✔️ Ivoox: http://www.ivoox.com/podcast-palabra-hacker_sq_f1266057_1.html ✔️ iTunes: https://itunes.apple.com/es/podcast/palabra-de-hacker/id1114292064 ✔️ Spotify: https://open.spotify.com/show/1xKmNk9Gk5egH6fJ9utG86 ✔️ Google Podcast: https://podcasts.google.com/?feed=aHR0cDovL3d3dy5pdm9veC5jb20vcGFsYWJyYS1oYWNrZXJfZmdfZjEyNjYwNTdfZmlsdHJvXzEueG1s - Toda la información en la web https://www.yolandacorral.com/palabra-de-hacker - Canal en Telegram: t.me/palabradehacker - Twitter: https://twitter.com/palabradehacker - Facebook: https://www.facebook.com/Palabradehacker
Tony McGarry, Senior Principal Engineer at Druva, joins W. Curtis Preston and Prasanna Malaiyandi to talk about backing up large, multi-node, sharded NoSQL databases like DynamoDB, Cassandra, and MongoDB.
Why is starting with identity essential when it comes to integrating a zero-trust strategy? To answer this question to share his insights, Bec Ney is joined by Leigh Doddy, Senior Principal Engineer at OKTA. OKTA is a global access management company focusing on how to best secure identity for cloud services. The Missing Link specialises in cybersecurity, IT infrastructure and automation. CREDITS: Host: Bec Ney Guest: Leigh Doddy, Senior Principal Engineer at OKTA Producer: Amelia NavascuesSee omnystudio.com/listener for privacy information.
In this Intel Chip Chat audio podcast with Allyson Klein: Andy Rudoff, Senior Principal Engineer at Intel, talks with host Allyson Klein about Intel Optane Persistent Memory (PMem) and the work done with software vendors to harness the power of the new technology, especially when it comes to database management and recovery. Rudoff goes into […] The post New Tools for Developers with Intel Optane PMem - Intel Chip Chat - Episode 709 first appeared on Connected Social Media.
In this Intel Chip Chat audio podcast with Allyson Klein: Andy Rudoff, Senior Principal Engineer at Intel, talks with host Allyson Klein about Intel Optane Persistent Memory (PMem) and the work done with software vendors to harness the power of the new technology, especially when it comes to database management and recovery. Rudoff goes into […] The post New Tools for Developers with Intel Optane PMem - Intel Chip Chat - Episode 709 first appeared on Connected Social Media.
Andy Rudoff, Senior Principal Engineer at Intel, talks with host Allyson Klein about Intel® Optane™ Persistent Memory (PMem) and the work done with software vendors to harness the power of the new technology, especially when it comes to database management and recovery. Rudoff goes into detail about how Optane PMem represents a new tier between memory and storage that allows giant databases to be hosted across fewer servers. He also discusses the Persistent Memory Development Kit (PMDK)—a growing collection of libraries and tools tuned and validated on both Linux and Windows, and the Persistent Memory Programming book—a complete guide for developers that delivers comprehensive information with detailed code examples. Both the development kit and the book can be found at: https://pmem.io/ Notices & Disclaimers Intel technologies may require enabled hardware, software or service activation. No product or component can be absolutely secure. Your costs and results may vary. © Intel Corporation. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. Other names and brands may be claimed as the property of others.
In this Intel Chip Chat audio podcast with Allyson Klein: Andy Rudoff, Senior Principal Engineer at Intel, talks with host Allyson Klein about Intel Optane Persistent Memory (PMem) and the work done with software vendors to harness the power of the new technology, especially when it comes to database management and recovery. Rudoff goes into […] The post New Tools for Developers with Intel Optane PMem - Intel Chip Chat - Episode 709 first appeared on Connected Social Media.
Monitoring is the topic for Day Two Cloud. Before you skip because you think it's boring, this conversation may change your mind. We dig into what's necessary to effectively monitor cloud-native and microservices applications to help you run infrastructure smoothly, improve troubleshooting, and anticipate issues before they affect performance or services. Our guest is Josh Barratt, Senior Principal Engineer at Twilio.
Monitoring is the topic for Day Two Cloud. Before you skip because you think it's boring, this conversation may change your mind. We dig into what's necessary to effectively monitor cloud-native and microservices applications to help you run infrastructure smoothly, improve troubleshooting, and anticipate issues before they affect performance or services. Our guest is Josh Barratt, Senior Principal Engineer at Twilio.
Monitoring is the topic for Day Two Cloud. Before you skip because you think it's boring, this conversation may change your mind. We dig into what's necessary to effectively monitor cloud-native and microservices applications to help you run infrastructure smoothly, improve troubleshooting, and anticipate issues before they affect performance or services. Our guest is Josh Barratt, Senior Principal Engineer at Twilio.
Monitoring is the topic for Day Two Cloud. Before you skip because you think it's boring, this conversation may change your mind. We dig into what's necessary to effectively monitor cloud-native and microservices applications to help you run infrastructure smoothly, improve troubleshooting, and anticipate issues before they affect performance or services. Our guest is Josh Barratt, Senior Principal Engineer at Twilio. The post Day Two Cloud 053: Effectively Monitoring Cloud-Native Applications appeared first on Packet Pushers.
Monitoring is the topic for Day Two Cloud. Before you skip because you think it's boring, this conversation may change your mind. We dig into what's necessary to effectively monitor cloud-native and microservices applications to help you run infrastructure smoothly, improve troubleshooting, and anticipate issues before they affect performance or services. Our guest is Josh Barratt, Senior Principal Engineer at Twilio. The post Day Two Cloud 053: Effectively Monitoring Cloud-Native Applications appeared first on Packet Pushers.
Monitoring is the topic for Day Two Cloud. Before you skip because you think it's boring, this conversation may change your mind. We dig into what's necessary to effectively monitor cloud-native and microservices applications to help you run infrastructure smoothly, improve troubleshooting, and anticipate issues before they affect performance or services. Our guest is Josh Barratt, Senior Principal Engineer at Twilio. The post Day Two Cloud 053: Effectively Monitoring Cloud-Native Applications appeared first on Packet Pushers.
Something special happened at Ampere when our interns took over the studio to interview their mentors! In this episode, Tony Faubert (UWashington) invites Jon Perry to chat about his origin story into engineering and CPU design. Jon is a Senior Principal Engineer at Ampere, and he speaks on the group dynamics of a small team, building technical culture, and how diversity of thought is beneficial when crafting a new core microarchitecture. Tony shares his experience as an intern in the performance team, and the mind-boggling freedom he was given to explore and contribute to our upcoming processor this past summer.
![Splunk [Foundations/Platform Track] 2019 .conf Videos w/ Slides](https://ivyfm.s3.amazonaws.com/i320/821522.jpg)
Splunk [Foundations/Platform Track] 2019 .conf Videos w/ Slides
Data Fabric Search (DFS) is the next generation of Splunk’s search platform. DFS executes the following vision: Splunk should be able to leverage compute assets from anywhere and access and execute on data regardless of type and origin. Inspired by the above mantra DFS scales Splunk searches both in terms of volume and cardinality. In this session you will learn how DFS searches scale to trillion scale event volume or billion scale cardinality - capabilities previously impossible. DFS is not limited to local but by supporting scaled federated executions also powers remote splunk deployments. The Search Pipeline of DFS has been build grounds up based on lambda architecture which provides massive scale, high throughput and performance gains. At the end some of the performance and scale numbers which has been achieved internally will be shared. Speaker(s) Ari Bhattacharjee, Distinguished Engineer, Splunk Sourav Pal, Senior Principal Engineer, Splunk Slides PDF link - https://conf.splunk.com/files/2019/slides/FN2124.pdf?podcast=1577146201 Product: Splunk Enterprise Track: Foundations/Platform Level: Good for all skill levels
![Splunk [All Products] 2019 .conf Videos w/ Slides](https://ivyfm.s3.amazonaws.com/i320/821514.jpg)
Data Fabric Search (DFS) is the next generation of Splunk’s search platform. DFS executes the following vision: Splunk should be able to leverage compute assets from anywhere and access and execute on data regardless of type and origin. Inspired by the above mantra DFS scales Splunk searches both in terms of volume and cardinality. In this session you will learn how DFS searches scale to trillion scale event volume or billion scale cardinality - capabilities previously impossible. DFS is not limited to local but by supporting scaled federated executions also powers remote splunk deployments. The Search Pipeline of DFS has been build grounds up based on lambda architecture which provides massive scale, high throughput and performance gains. At the end some of the performance and scale numbers which has been achieved internally will be shared. Speaker(s) Ari Bhattacharjee, Distinguished Engineer, Splunk Sourav Pal, Senior Principal Engineer, Splunk Slides PDF link - https://conf.splunk.com/files/2019/slides/FN2124.pdf?podcast=1577146224 Product: Splunk Enterprise Track: Foundations/Platform Level: Good for all skill levels
Rob and Jason are joined by Ken Museth the CEO of Voxel Tech. They first discuss a blog post about std::embed and the new version of Qt that was just released. Then they talk to Ken Museth about OpenVDB a C++ library for working with volumetric data used in Visual Effects, Scientific Simulations and more. Ken Museth is CEO and co-founder of Voxel Tech which contracts to tech companies primarily in the movie and aerospace industries. Ken currently does contract work for SpaceX and Weta Digital. Previously he was director of R&D and Senior Principal Engineer at Dreamworks Animation. He was also a professor in computer graphics at Linkoping University and a visiting faculty member and research scientist at Caltech. He worked on trajectory design for the Genesis space mission at NASA's JPL and in 2015 received an Academy Award for the development of OpenVDB. News Going Full Circle on Embed in C++ Qt 5.14 released C++Now 2020 Accepting Student/Volunteer Applications Links OpenVDB OpenVDB's GitHub Repository 2014 Sci-Tech Awards: Ken Museth, Peter Cucka and Mihai Aldén Sponsors Write the hashtag #cppcast when requesting the license here One Day from PVS-Studio User Support JetBrains
In this Intel on AI podcast episode: Phil Hummel, Senior Principal Engineer at Dell EMC, joins the Intel on AI Podcast to talk about the new Dell EMC Ready Solution for AI with Intel featuring Nauta. He illustrates how enterprises today want to take advantage of AI to leverage massive amounts of data to help […]
Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan Angular Bootcamp Triplebyte offers a $1000 signing bonus CacheFly Panel Aaron Frost Shai Reznik Brian Love Joined by Special Guest: Sander Elias Episode Summary In this episode of Adventures in Angular, the panel talks to Sander Elias, Senior Principal Engineer at HeroDevs from Netherlands. Sander is also an Angular Google GDE. Sander created Observable forms, an alternative way to do forms in Angular which takes advantage of what the platform has to offer. Aaron also talks about his speech at ng-conf 2019 and his follow up blog post about the speech and why he felt the need to write it. Links Sander’s GitHub Sander’s Twitter Sander’s LinkedIn Sander’s Medium ng-conf 2019 Sander Elias - ng-conf ObservableForm GitHub Aaron Frost Blog Piece Follow Adventures in Angular on tv, Facebook and Twitter. Picks Sander Elias: ng-conf 2019 https://github.com/tc39/proposal-decorators Suguru's Blog Angular 8 Release Aaron Frost: A is for Angular | Jo Hanna Pearce Melina Mejia Brian Love: ng-conf 2019 Reid Villeneuve Avengers: Endgame (2019) Shai Reznik: ng-conf 2019 A is for Angular | Jo Hanna Pearce Chrome Developers Channel Michio Kaku on The Future of Humanity https://www.16personalities.com/
Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan Angular Bootcamp Triplebyte offers a $1000 signing bonus CacheFly Panel Aaron Frost Shai Reznik Brian Love Joined by Special Guest: Sander Elias Episode Summary In this episode of Adventures in Angular, the panel talks to Sander Elias, Senior Principal Engineer at HeroDevs from Netherlands. Sander is also an Angular Google GDE. Sander created Observable forms, an alternative way to do forms in Angular which takes advantage of what the platform has to offer. Aaron also talks about his speech at ng-conf 2019 and his follow up blog post about the speech and why he felt the need to write it. Links Sander’s GitHub Sander’s Twitter Sander’s LinkedIn Sander’s Medium ng-conf 2019 Sander Elias - ng-conf ObservableForm GitHub Aaron Frost Blog Piece Follow Adventures in Angular on tv, Facebook and Twitter. Picks Sander Elias: ng-conf 2019 https://github.com/tc39/proposal-decorators Suguru's Blog Angular 8 Release Aaron Frost: A is for Angular | Jo Hanna Pearce Melina Mejia Brian Love: ng-conf 2019 Reid Villeneuve Avengers: Endgame (2019) Shai Reznik: ng-conf 2019 A is for Angular | Jo Hanna Pearce Chrome Developers Channel Michio Kaku on The Future of Humanity https://www.16personalities.com/
Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan Angular Bootcamp Triplebyte offers a $1000 signing bonus CacheFly Panel Aaron Frost Shai Reznik Brian Love Joined by Special Guest: Sander Elias Episode Summary In this episode of Adventures in Angular, the panel talks to Sander Elias, Senior Principal Engineer at HeroDevs from Netherlands. Sander is also an Angular Google GDE. Sander created Observable forms, an alternative way to do forms in Angular which takes advantage of what the platform has to offer. Aaron also talks about his speech at ng-conf 2019 and his follow up blog post about the speech and why he felt the need to write it. Links Sander’s GitHub Sander’s Twitter Sander’s LinkedIn Sander’s Medium ng-conf 2019 Sander Elias - ng-conf ObservableForm GitHub Aaron Frost Blog Piece Follow Adventures in Angular on tv, Facebook and Twitter. Picks Sander Elias: ng-conf 2019 https://github.com/tc39/proposal-decorators Suguru's Blog Angular 8 Release Aaron Frost: A is for Angular | Jo Hanna Pearce Melina Mejia Brian Love: ng-conf 2019 Reid Villeneuve Avengers: Endgame (2019) Shai Reznik: ng-conf 2019 A is for Angular | Jo Hanna Pearce Chrome Developers Channel Michio Kaku on The Future of Humanity https://www.16personalities.com/
Smart companies are modernizing enterprise infrastructure as the foundation for new digital services; extracting insights from their data to accelerate business decisions; and securing their customers' data to avoid becoming another statistic. In this episode, Bill Giard explains how Intel and its partners are helping customers future-proof their businesses with cloud technology innovations. Through the ecosystem of solutions, customers will find what they need to accelerate digital transformation and compete more effectively. Bill Giard is a Senior Principal Engineer in the Data Center Group at Intel. He has 20+ years’ experience designing enterprise architectures and developing software solutions across supply-chain, product development, and enterprise infrastructure segments. Before joining DCG he led software development in Intel IT to modernize the application and computing environment. For more information about the Intel data-centric portfolio for enterprise customers, visit https://intel.com/xeonscalable or https://intel.com/yourdata. Intel technologies' features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No product or component can be absolutely secure. Check with your system manufacturer or retailer or learn more at intel.com. Intel and the Intel logo are trademarks of Intel Corporation or its subsidiaries in the U.S. and/or other countries. *Other names and brands may be claimed as the property of others. © Intel Corporation
Our guest today is Dan Beeker, Senior Principal Engineer at NXP Semiconductors, who is well known for addressing EMC and signal integrity in a really fresh way. Dan has presented twice as a Keynote Speaker at AltiumLive, both in San Diego and Munich. The information shared in this talk is extremely practical and valuable. Listen in, this information will impact the designs you do every day! Remember, it’s “all about the space”. Trade In Your Outdated PCB Design Tool & Unlock 45% OFF Altium Designer today! Watch the video, click here. Show Highlights: Dan started out with Air Force electronics training followed by his role as Motorola’s microsystems Group Test Repair Technician, and now Dan is the Senior Principal Engineer with NXP. You’ve presented twice at AltiumLive events as a keynote speaker, called “It’s all about the space” What does it mean, it’s all about the space? The real key to successful engineering is the realisation that it is energy moving through space. It’s critical to design the spaces. The concept that the energy moves through wires, is what led us to where we are today. In the past where switching was very slow, it didn’t matter, however, as technology changed and switching sped up, we saw higher failure rates in EMC. We reduced the size of the antenna required by an order of magnitude, practicing circuit theory without realising that energy moves through the laminate (the space). Energy also moves through the board space from one dielectric layer, up to a higher one. Why do you think engineers and designers alike lose this perspective along the way? It’s somewhat confusing, because geometry cannot be imported. Many still believe that the energy transfer is instantaneous. If that were the case there would never be signal integrity problems because energy transfer is much slower. This is also happening because the physics side of electronics engineering is made out to be something that’s quite difficult. There is a lack of cohesion between the science of energy and its reality and what we’re teaching people. The fundamental concept is we design products that generate, manage and consume electromagnetic field energy, not electrons. This field has to be in a space. Physics trumps theory! Five minutes into that class I knew that everything I had ever designed, had worked by accident! Rick (Hartley) became a friend and a wonderful mentor. Ralph Morrison taught me the importance of physics and that the energy was in the spaces and not the traces. He said: ‘People travel through the halls and not the walls, signals and energy travel in the spaces not the traces,’ which inspired my song. The geometry of the spaces has proven to be extremely successful with the help of my mentors. Finding great mentors is crucial. If you’re still in school, pay attention, take the extra time to talk to your professors and connect the dots of the behaviors of the electromagnetic field. Electronics is a world of three’s: You can store energy, you can move it or you can convert it into kinetic energy - that’s it, the entire electronics world! This is not an extremely complicated world for managing electromagnetic fields. You have three components: a conductor, a dielectric, and a switch. This isn’t rocket science, this is plumbing! You have to have to start using ground as a pointer object within your board stack. The common conductor from the source of the energy to the place where that energy is consumed, next to a common dielectric, so that the ground and the dielectric next to it, is unbroken from the source of the energy to the destination. Technical conferences where you can see Dan Beeker speak: Embedded Systems, Boston in May PCB West in September Embedded Systems, Santa Clara this year NXP Connects in October, in Detroit Links and Resources: It's all about the space song Ralph Morrison website Trade In Your Outdated PCB Design Tool & Unlock 45% OFF Altium Designer today!
AWS offers a wide range of cloud computing services and technologies, but we rarely state opinions about which services and technologies customers should choose. When it comes to building our own services, our engineering groups have strong opinions, and they express them in the technologies they pick. Join Tim Bray, Senior Principal Engineer, to hear about the high-level choices that developers at AWS and our customers have to make. Here are a few: Are microservices always the way to go? Serverless, containers, or serverless containers? Is relational over? Is Java over? The talk is technical and based on our experience in building AWS services and working with customers on their cloud-native apps.
In this podcast you will hear from James L Jeffers, Sr. Director, Senior Principal Engineer, Visualization Solutions Intel Corporation. Jim will discuss Intel’s continued investments in its portfolio of Open Source Software Rendering libraries to enable the industry to deliver compelling visual effects for motion pictures and photorealistic renderings for scientists and engineers with optimum time to market and total cost of ownership benefits. Intel recently established Intel® Rendering Framework as the umbrella term for its family of rendering products which includes OpenImageDenoise, Embree, OSPray & OpenSWR. Learn more about each of the libraries along with how the Intel Rendering Framework continues to drive innovations across a broad spectrum of applications. Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No computer system can be absolutely secure. Check with your system manufacturer or retailer or learn more at intel.com. Intel and the Intel logo are trademarks of Intel Corporation or its subsidiaries in the U.S. and/or other countries. *Other names and brands may be claimed as the property of others. © Intel Corporation
Dr. Andres Rodriguez, a Senior Principal Engineer in the Data Center Group at Intel, stops by to talk about why it is so critical to optimize framework and software tools artificial intelligence applications. Intel has worked hard over the last two years to optimize popular frameworks like Caffe, TensorFlow, MXNet, and Pytorch for Intel® Xeon® processors. We’ve also developed the Intel® Math Kernel Library for Deep Neural Networks (Intel® MKL-DNN) to accelerate deep learning workloads on Intel® architecture. Customers are now seeing the benefits of using their existing Intel Xeon processors for artificial intelligence workloads with increasingly optimized performance. For more on this topic, visit: http://ai.intel.com. Intel technologies’ features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. No computer system can be absolutely secure. Check with your system manufacturer or retailer or learn more at intel.com. Intel and the Intel logo are trademarks of Intel Corporation or its subsidiaries in the U.S. and/or other countries. *Other names and brands may be claimed as the property of others. © Intel Corporation.
Visualizations serve the critical role of making complex data intelligible in a variety of industries. Jim Jeffers, Senior Director and Senior Principal Engineer, Visualization Solutions, at Intel, leads a team that develops three important open source libraries for data center rendering that deliver rasterization and ray tracing with high performance on Intel® Xeon® processors. Jim discusses the new Intel® Select Solutions for Professional Visualization that package up key software capabilities with the power of high performance computing (HPC) to provide stunning visualizations. For more information, visit https://software.intel.com/sdvis and intel.com/selectsolutions.
Dr. Paolo Narvaez, Senior Principal Engineer and Director of Engineering at Intel, joins Intel® Chip Chat to talk about Intel Select Solutions for Genomics Analytics. Dr. Narvaez works to harness the best Intel ingredients to create full-stack solutions for a number of different strategic verticals, including genomics analytics. In this interview, Dr. Narvaez discusses advances in genomics analytics technologies that are reducing the cost of whole genome sequencing, the ongoing explosion of genomics analytics data, and how Intel Select Solutions for Genomics Analytics will broaden access to personalized therapies. Intel Select Solutions for Genomics Analytics build upon Intel's ongoing collaboration with The Broad Institute of MIT and Harvard around BIGstack, and are a fast track to unlock the benefits of BIGstack 2.0 atop infrastructure purpose-built for genomics workloads. For more information on Intel Select Solutions for Genomics Analytics, please visit https://intel.com/selectsolutions.
Prof. Martin Curley is Professor of Technology and Business Innovation at NUI Maynooth and co-Director of IVI, helping lead a unique industry-academic open innovation consortium to advance IT management and innovation. Prof Curley is a fellow of the Institution of Engineers of Ireland and the British Computer Society. He is a frequent international keynote speaker on Innovation and Technology. Martin is also the recently appointed Director of Intel Labs Europe whose mission is to advance Intel research and innovation in Europe while partnering to enable European competitiveness. Prof Curley is also Senior Principal Engineer and Global Director of IT Innovation at Intel Corporation managing a network of IT Innovation centres catalyzing worldwide IT Innovation. Previously Prof Curley has held a number of senior IT Management positions for Intel and held management and research positions at General Electric and Philips. Prof Curley is author of “Managing Information Technology for Business Value” published by Intel Press, January 04, co-author of “Managing IT Innovation for Business Value” published in 2007 by Intel Press and co-author of “Knowledge Driven Entrepreneurship” published by Springer in Jan 2010.
Dr. Michael Voss, Software Architect at Intel, and Robert Geva, Senior Principal Engineer and Compiler Writer at Intel, join us to discuss parallel computing with Intel® Threading Building Blocks (Intel® TBB). Intel® TBB is a C++ library that enables developers to add parallelism to their applications without closely managing threading details. In this interview, Voss and Geva assess the software industry's current use of parallelism, highlight Intel® TBB's ability to optimize parallelized applications for current and future architectures, and report on benefits customers in industries like visual effects, financial services, and healthcare have already realized with Intel® TBB. For more information on Intel® TBB, please visit https://www.threadingbuildingblocks.org/.
In this Intel Chip Chat audio podcast with Allyson Klein: Dr. Brian Womack, Director of Distributed Analytics Solutions in Intel’s Data Center Solutions Group, and Das Kamhout, Senior Principal Engineer at Intel, join us live from Intel Developer Forum in San Francisco. Intel is collaborating with a number of industry partners to deliver SDI technologies […]
Dr. Brian Womack, Director of Distributed Analytics Solutions in Intel's Data Center Solutions Group, and Das Kamhout, Senior Principal Engineer at Intel, join us live from Intel Developer Forum in San Francisco. Intel is collaborating with a number of industry partners to deliver SDI technologies to data centers. Womack and Kamhout discuss the ways technologies like the Snap telemetry framework, Intel's Trusted Analytics Platform (TAP), and OpenStack are driving the industry towards a data center that thinks for itself. For more information on their work, follow them on Twitter at https://twitter.com/briandwomack and https://twitter.com/dkamhout.
Celebrating 25 years of IEEE 802.11 & monetizing Wi-Fi with intelligent consumer engagement. Guests: • Dr. Adrian Stephens, IEEE 802.11 Chair & Senior Principal Engineer at Intel • Zachary Britton, CEO of Frontporch, USA
Alan Ross, Senior Principal Engineer at Intel outlines how quickly the amount of data that enterprises deal with is scaling from millions to tens of billions and how gaining actionable insight from such unfathomable amounts of data is becoming increasingly challenging. He discusses how Intel is helping to develop analytics platform-as-a-service to better enable flexible adoption of new algorithms and applications that can expose data to end users allowing them to glean near real-time insights from such a constant flood of data. Alan also illustrates the incredible potential for advances in healthcare, disaster preparedness, and data security that can come from collecting and analyzing the growing expanse of big data.
IT Best Practices: Episode 69 – In previous podcasts we’ve examined Intel’s overhaul of its data center strategy, and how Intel IT looks to run its data center service like a factory. One key aspect of that strategy is the data center server refresh program. Shesha Krishnapura is a Senior Principal Engineer at Intel IT. […]
Software Engineering Radio - The Podcast for Professional Software Developers
In this Episode, we talk to Michael Stal, a Senior Principal Engineer at Siemens Corporate Technology, POSA 1 and 2 Co-Author and Editor of the german JavaSpetrum magazine. Since Michael's core focus is middlware, much of our discussion centered around that topic. Webservices and SOA, of course, have also been covered. Other topics include Java vs. .NET as well as Patterns.
Software Engineering Radio - The Podcast for Professional Software Developers
In this Episode, we talk to Michael Stal, a Senior Principal Engineer at Siemens Corporate Technology, POSA 1 and 2 Co-Author and Editor of the german JavaSpetrum magazine. Since Michael's core focus is middlware, much of our discussion centered around that topic. Webservices and SOA, of course, have also been covered. Other topics include Java vs. .NET as well as Patterns.
Software Engineering Radio - The Podcast for Professional Software Developers
In this Episode, we talk to Michael Stal, a Senior Principal Engineer at Siemens Corporate Technology, POSA 1 and 2 Co-Author and Editor of the german JavaSpetrum magazine. Since Michael's core focus is middlware, much of our discussion centered around that topic. Webservices and SOA, of course, have also been covered. Other topics include Java vs. .NET as well as Patterns.
© 2020-2025 Ivy Podcast Discovery LLC
