Podcasts about slis

Esbjerg slår igen dørene op for et af årets mest livsbekræftende sportsarrangementer, når Specialskolernes Landsidrætsstævne (SLIS) vender tilbage til Esbjerg d. 7-8. maj. Vi havde besøg af Jacob Drachmann Haag, Aktivitets- og værtsskabschef hos Sport & Event Park Esbjerg, som kort fortalte hvad SLIS står for.

In our eighth episode of the season, we talk to some of our classmates in the 2024-2025 first year cohort of the School of Library and Information Studies. What they wish they'd known, what they liked, what they found challenging - all manner of questions designed to give our listeners a sneak peek into what this program is all about! Thank you to Ken Price, Emily Simon, Alan Wobeser, Abigail Deck, Marissa Stelmack, Rowan Wiebe, Jerzy Beaumont, and Vincent Yu for their contributions to this episode.Theme SongMusic: Vlad Gluschenko – ForestLicense: Creative Commons Attribution 3.0 Unportedhttps://creativecommons.org/licenses/by/3.0/deed.enProduction CreditsNatasha D'Amours, Emily Jensen, Jennie McCurdy, Andy Zhang, Brett Sheehan, and Ethan Tonack.

Incident response is an increasingly difficult area for organizations. Many teams end up paying a lot of money for incident management solutions. However, issues remain because processes supporting the incident response are not robust.Incident response software alone isn't going to fix bad incident processes. It's gonna help for sure. You need these incident management tools to manage the data and communications within the incident. But you also need to have effective processes and human-technology integration. Dr Ukis wrote in his Establishing SRE Foundations book about complex incident coordination and priority setting. According to Vladislav, at the beginning of your SRE journey, it's not going to be focused on incident response in terms of setting up an incident response process, but more on core SRE artifacts like SLIs, availability measurement, SLOs, etc. And now we are safely investing more into the customer-facing features and things like this. So this is going to be the core SRE concepts. But then at some point, once you've got these things, more or less established in the organization. Understanding and Leveraging SLOsOnce your Service Level Objectives (SLOs) are well-defined and refined over time, they should accurately reflect user and customer experiences. Your SLOs are no longer just initial metrics; they've been validated through production. Product managers should now be able to use this data to make informed decisions about feature prioritization. This foundational work is crucial because it sets the stage for integrating a formal incident response process effectively.Implementing a Formal Incident ResponseBefore you overlay a formal incident response process, ensure that you have the cultural and technical groundwork in place. Without this, the process might not be as effective. When the foundational SLOs and organizational culture are strong, a well-structured incident response process can significantly enhance its effectiveness.Coordinating During Major IncidentsWhen a significant incident occurs, detecting it through SLO breaches is just the beginning. You need a system in place to coordinate responses across multiple teams. Consider appointing incident commanders and coordinators, as recommended in PagerDuty's documentation, to manage this coordination. Develop a lightweight process to guide how incidents are handled.Classifying IncidentsEstablish an incident classification scheme to differentiate between types of incidents. This scheme should include priorities such as Priority One, Priority Two, and Priority Three. Due to the inherently fuzzy nature of incidents, your classification system should also include guidelines for handling ambiguous cases. For instance, if uncertain whether an incident is Priority One or Two, default to Priority One.Deriving Actions from Incident ClassificationBased on the incident classification, outline specific actions. For example, Priority One incidents might require immediate involvement from an incident commander. They might take the following actions:* Create a communication channel, assemble relevant teams, and start coordination. * Simultaneously inform stakeholders according to their priority group. * Define stakeholder groups and establish protocols for notifying them as the situation evolves.Keep Incident Response Processes Simple and AccessibleEnsure that your incident response process is concise and easily understandable. Ideally, it should fit on a single sheet of paper. Complexity can lead to confusion and inefficiencies, so aim for simplicity and clarity in your process diagram. This approach ensures that the process is practical and can be followed effectively during an incident.Preparing Your OrganizationAn effective incident response process relies on an organization's readiness for such rigor. Attempting to implement this process in an organization not yet mature enough may result in poor adherence during critical times. Make sure your organization is prepared to follow the established procedures.For a deeper dive into these concepts, consider reading "Establishing SRE Foundations," available on Amazon and other book retailers. For further inquiries, you can also connect with the author, Vlad, on LinkedIn. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit read.srepath.com

In this first part of a 2-part coverage, Sebastian Vietz and I work out how to meet SLAs through SLOs and SLIs. This episode covers Chapter 4 of the Site Reliability Engineering book (2016). Here are 7 takeaways from the show:* Involve Technical Stakeholders Early: Ensure that technical stakeholders, such as SREs, are involved in discussions about SLAs and SLOs from the beginning. Their expertise can help ensure that objectives are feasible and aligned with the technical capabilities of the service.* Differentiate Between SLAs and SLOs: Understand the distinction between SLAs, which are legal contracts, and SLOs, which are based on customer expectations. Avoid using SLAs as a substitute for meaningful service level objectives.* Prioritize Meaningful Metrics: Focus on a select few service level indicators (SLIs) that truly reflect what users want from the system. Avoid the temptation to monitor everything and instead choose indicators that provide valuable insights into service performance.* Align with Customer Expectations: Start by understanding and prioritizing the expectations of your customers. Use their feedback to define service level objectives (SLOs) that align with their needs and preferences.* Avoid Alert Fatigue: Be mindful of the number of metrics being monitored and the associated alerts. Too many indicators can lead to alert fatigue and make it difficult to prioritize and respond to issues effectively. Focus on a few key indicators that matter most.* Start Top-Down with SLIs: Take a top-down approach to defining SLIs, starting with customer expectations and working downwards. This ensures that the selected metrics are meaningful and relevant to users' needs.* Prepare for Deep Dives: Anticipate the need for deeper exploration of specific topics, such as SLOs, and allocate time and resources to thoroughly understand and implement them in your work. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit read.srepath.com

SREs (Site Reliability Engineers) have varying roles across different organizations: From Codifying your Infrastructure, handling high priority incidents, automating resiliency, ensuring proper observability, defining SLOs or getting rid of alert fatigue. What an SRE team must not be is a SWAT team - or - as Dana Harrison, Staff SRE at Telus puts it: "You don't want to be the fire brigade along the DevOps Infinity Loop"In his years of experience as an SRE Dana also used to run 1 week boot camps for developers to educate them on making apps observable, proper logging, resiliency architecture patterns, defining good SLIs & SLOs. He talked about the 3 things that are the foundation of a good SRE: understand the app, understand the current state and make sure you know when your systems are down before your customers tell you so!If you are interested in seeing Dana and his colleagues from Telus talk about their observability and SRE journey then check out the On-Demand session from Dynatrace Perform 2024: https://www.dynatrace.com/perform/on-demand/perform-2024/?session=simplifying-observability-automations-and-insights-with-dynatrace#sessions

Embrace the Site Reliability Mindset with Alex Ewerlöf, Sr. Staff Engineer @ Volvo Cars

Recorded Live on 2/24/24 This Week's Blog: https://casaa.org/vaping-advocates-protest-in-utah-and-more-tobacco-harm-reduction-news/ YouTube Live Replay: https://www.youtube.com/live/mQmFHi9gbEU?si=hVJIKBVZ-Pn2QPcL Join CASAA: casaa.org/get-involved/join/​ CASAA State Pages: casaa.org/get-involved/state-...​ Donate: casaa.org/get-involved/donate/​ Shop: casaa.threadless.com/collections​ Music: Fight On Your Side by Crowander freemusicarchive.org/music/cr...

In this New Stack Makers podcast, Martin Parker, a solutions architect for UST, spoke with TNS editor-in-chief, Heather Joslyn and discussed the significance of internal developer platforms (IDPs), emphasizing benefits beyond frontend developers to backend engineers and site reliability engineers (SREs). Parker highlighted the role of IDPs in automating repetitive tasks, allowing SREs to focus on optimizing application performance. Standardization is key, ensuring observability and monitoring solutions align with best practices and cater to SRE needs. By providing standardized service level indicators (SLIs) and key performance indicators (KPIs), IDPs enable SREs to maintain reliability efficiently. Parker stresses the importance of avoiding siloed solutions by establishing standardized practices and tools for effective monitoring and incident response. Overall, the deployment of IDPs aims to streamline operations, reduce incidents, and enhance organizational value by empowering SREs to concentrate on system maintenance and improvements.Learn more from The New Stack about UST: Cloud Cost-Unit Economics- A Modern Profitability Model Cloud Native Users Struggle to Achieve Benefits, Report Says John our community of newsletter subscribers to stay on top of the news and at the top of your game. 

Join host Kaivalya Apte in this episode of The Geek Narrator Podcast as he discusses observability engineering with field CTO at Honeycomb, Liz Fong-Jones. They delve into the importance of observability for software engineers, the role of Honeycomb in popularizing this concept, and how observability has evolved over the years. Liz shares her experiences transitioning from being an SRE at Google to advocating for observability at Honeycomb and walking the journey from developer advocate to Field CTO. They discuss the definitions and misconceptions surrounding observability and elucidate on Service-Level Objectives (SLOs) & indicators (SLIs) and challenges they solve. Tune in for an informative and in-depth conversation on observability engineering. Chapters: 00:00 Introduction 00:08 Understanding Observability Engineering 00:37 Guest Introduction: Liz Fong Jones 00:53 Liz's Journey to Field CTO at Honeycomb 27:38 Understanding Site Reliability Workbook Materials 27:57 Identifying Critical User Journeys 29:49 Different Types of Services and Their SLOs 33:05 Setting Up SLOs: Granularity and Number 42:42 Understanding Service Level Indicators (SLIs) 50:26 Common Mistakes in Setting Up SLOs 52:09 Cultivating an Observability-Driven Development Culture References: Observability Engineering: https://www.oreilly.com/library/view/observability-engineering/9781492076438/  @Google  SRE book: https://sre.google/books/ =============================================================================== For discount on the below courses: Appsync: https://appsyncmasterclass.com/?affiliateId=41c07a65-24c8-4499-af3c-b853a3495003 Testing serverless: https://testserverlessapps.com/?affiliateId=41c07a65-24c8-4499-af3c-b853a3495003 Production-Ready Serverless: https://productionreadyserverless.com/?affiliateId=41c07a65-24c8-4499-af3c-b853a3495003 Use the button, Add Discount and enter "geeknarrator" discount code to get 20% discount. =============================================================================== Follow me on Linkedin and Twitter: https://www.linkedin.com/in/kaivalyaapte/ and https://twitter.com/thegeeknarrator If you like this episode, please hit the like button and share it with your network. Also please subscribe if you haven't yet. Database internals series: https://youtu.be/yV_Zp0Mi3xs Popular playlists: Realtime streaming systems: https://www.youtube.com/playlist?list=PLL7QpTxsA4se-mAKKoVOs3VcaP71X_LA- Software Engineering: https://www.youtube.com/playlist?list=PLL7QpTxsA4sf6By03bot5BhKoMgxDUU17 Distributed systems and databases: https://www.youtube.com/playlist?list=PLL7QpTxsA4sfLDUnjBJXJGFhhz94jDd_d Modern databases: https://www.youtube.com/playlist?list=PLL7QpTxsA4scSeZAsCUXijtnfW5ARlrsN Stay Curios! Keep Learning!

Academic Librarianship: Anchoring the Profession in Contribution, Scholarship, and Service (Rowman & Littlefield, 2023) by Marcy Simons is needed now as a response to how much has changed in academic librarianship as a profession (from the smallest academic libraries to large research libraries). Much has been written recently about the status of the profession of librarianship, i.e. whether or not it should still be considered a “profession,” are the same credentials still required/enough, should things change dramatically in SLIS programs in response to the new normal, and what is the impact of hiring PhD's in disciplines outside of librarianship. Dr. Michael LaMagna is the Information Literacy Program and Library Services Coordinator and Professor of Library Services at Delaware County Community College. Learn more about your ad choices. Visit megaphone.fm/adchoices Support our show by becoming a premium member! https://newbooksnetwork.supportingcast.fm/new-books-network

Academic Librarianship: Anchoring the Profession in Contribution, Scholarship, and Service (Rowman & Littlefield, 2023) by Marcy Simons is needed now as a response to how much has changed in academic librarianship as a profession (from the smallest academic libraries to large research libraries). Much has been written recently about the status of the profession of librarianship, i.e. whether or not it should still be considered a “profession,” are the same credentials still required/enough, should things change dramatically in SLIS programs in response to the new normal, and what is the impact of hiring PhD's in disciplines outside of librarianship. Dr. Michael LaMagna is the Information Literacy Program and Library Services Coordinator and Professor of Library Services at Delaware County Community College. Learn more about your ad choices. Visit megaphone.fm/adchoices Support our show by becoming a premium member! https://newbooksnetwork.supportingcast.fm/education

Academic Librarianship: Anchoring the Profession in Contribution, Scholarship, and Service (Rowman & Littlefield, 2023) by Marcy Simons is needed now as a response to how much has changed in academic librarianship as a profession (from the smallest academic libraries to large research libraries). Much has been written recently about the status of the profession of librarianship, i.e. whether or not it should still be considered a “profession,” are the same credentials still required/enough, should things change dramatically in SLIS programs in response to the new normal, and what is the impact of hiring PhD's in disciplines outside of librarianship. Dr. Michael LaMagna is the Information Literacy Program and Library Services Coordinator and Professor of Library Services at Delaware County Community College. Learn more about your ad choices. Visit megaphone.fm/adchoices

Academic Librarianship: Anchoring the Profession in Contribution, Scholarship, and Service (Rowman & Littlefield, 2023) by Marcy Simons is needed now as a response to how much has changed in academic librarianship as a profession (from the smallest academic libraries to large research libraries). Much has been written recently about the status of the profession of librarianship, i.e. whether or not it should still be considered a “profession,” are the same credentials still required/enough, should things change dramatically in SLIS programs in response to the new normal, and what is the impact of hiring PhD's in disciplines outside of librarianship. Dr. Michael LaMagna is the Information Literacy Program and Library Services Coordinator and Professor of Library Services at Delaware County Community College. Learn more about your ad choices. Visit megaphone.fm/adchoices

What happens when librarians go wild? Well, you'll know from this episode. We bring you spicy reviews of Madonna's aptly titled book, Sex, and other controversial titles from the stacks in the Bruce Peel Special Collection. Anne Elefante, a member of the Future Librarians for Intellectual Freedom shared banned library books with us, and you'd be surprised by what is banned. Finally, we have SLIS' own Dr. Danielle Allard talking about her work on a sex workers database.~~~~Music credits:intro: freesound.org/people/B_Sean/sounds/421888/

Episode 65 – Bob Friedman on the Birmingham Black Radio Museum's 2023 Digital History Award (Large Project Category). Air Date: August 3, 2023 Bob Friedman, founder and director of the Birmingham Black Radio Museum (BBRM) talks about receiving the Alabama Historical Association's 2023 Digital History Award, about the founding of the BBRM, and about his background in (and the history of) Black centered radio as a veteran talk show host and manager. He talks about singing with and interviewing many Black R&B and Gospel performers, and he tells us about Paul "Tall Paul" White, a legendary radio announcer of 1950s and 1960s Birmingham. Links to things mentioned in the episode: Birmingham Black Radio Museum (BBRM) https://www.thebbrm.org/ Alabama Historical Association Digital History Award https://www.alabamahistory.net/digital-history-award Alabama Historical Association https://www.alabamahistory.net/ Alabama Department of Archives and History https://archives.alabama.gov/ Department of Archival Studies, SLIS, University of Alabama https://cis.ua.edu/academic-departments/school-of-library-information-studies/ The Carver Theater https://www.bhamwiki.com/w/Carver_Theater Alabama Jazz Hall of Fame https://jazzhall.com/ Paul "Tall Paul" White http://www.bhamwiki.com/w/Tall_Paul Alabama Broadcasters Association Hall of Fame https://al-ba.com/wp2/aba-hall-of-fame-and-broadcasters-of-the-year/ "View a Radio Hero" https://www.blog.thebbrm.org/2020/04/22/a-radio-hero/ Radio Preservation Task Force of the Library of Congress [April 2023 Program] https://radiopreservation.org/wp-content/uploads/2023/04/23-LOC-Conference-Program-FINAL.pdf Dr. Robert Riter https://cis.ua.edu/cis-theme-staff/bob-riter/ Rather read? Here's a link to the transcript on Google Drive: https://tinyurl.com/7377xjb *Just a heads up – the provided transcript is likely to be less than 100% accurate. The Alabama History Podcast's producer is Marty Olliff and its associate producer is Laura Murray. Founded in 1947, the Alabama Historical Association is the oldest statewide historical society in Alabama. The AHA provides opportunities for meaningful engagement with the past through publications, meetings, historical markers, and other programs. See the website https://www.alabamahistory.net/

This week Adam talks with Marcin Kurc about chasing the 9s. Marcin is the Co-founder and CEO of Nobl9 where they build tools for managing service level objectives, aka SLOs. We also talk about service level agreements (SLAs), service level indicators (SLIs), error budgets, and monitoring, and how it all comes together to help teams align on goals, improve customer satisfaction, manage risks, increase transparency, and of course, a favorite around here…continuous improvement. Kaizen! This is an awesome deep dive into the world of chasing those 9s, and how teams are levering SLOs to earn the trust of their customers as well showcase transparency.

This week Adam talks with Marcin Kurc about chasing the 9s. Marcin is the Co-founder and CEO of Nobl9 where they build tools for managing service level objectives, aka SLOs. We also talk about service level agreements (SLAs), service level indicators (SLIs), error budgets, and monitoring, and how it all comes together to help teams align on goals, improve customer satisfaction, manage risks, increase transparency, and of course, a favorite around here…continuous improvement. Kaizen! This is an awesome deep dive into the world of chasing those 9s, and how teams are levering SLOs to earn the trust of their customers as well showcase transparency.

Guest:  Ana Oprea, Staff Security Engineer, European Lead of Vulnerability Coordination Center @ Google Topics: What is the scope for the vulnerability management program at Google? Does it cover  OS, off-the-shelf applications, custom code we wrote … or all of the above? Our vulnerability prioritization includes a process called “impact assessment.” What does our impact assessment for a vulnerability look like? How do we prioritize what to remediate? How do we decide on the speed of remediation needed? How do we know if we've done a good job? When we look backwards, what are our critical metrics (SLIs and SLOs) and how high up the security stack is the reporting on our progress? What of the “Google Approach” should other companies not try to emulate? Surely some things work because of Google being Google, so what are the weird or surprising things that only work for us? Resources: SRS Book, Chapter 20: Understanding Roles and Responsibilities and Chapter 21: Building a Culture of Security and Reliability  Why Google Stores Billions of Lines of Code in a Single Repository  SRE book and SRE Workbook “How Google Secures It's Google Cloud Usage at Massive Scale” (ep107) “Is This Binary Legit? How Google Uses Binary Authorization and Code Provenance” (ep66) “How We Scale Detection and Response at Google: Automation, Metrics, Toil” (ep75)

⏰Taйминг⏰ 00:00:00 - Start  00:11:12 - Path-to-production mapping (new)  00:14:06 - 2 Team cognitive load  00:22:33 - 6 Design tokens (new)  00:23:09 - 7 Fake SMTP server to test mail sending (new)  00:25:59 - 9 Incremental developer platform (new)  00:35:11 - 11 Observability for CI/CD pipelines (new)  00:39:53 - 12 Supply chain Levels for Software Artifacts, or SLSA (updated)  00:40:16 - 14 Carbon efficiency as an architectural characteristic (new)  00:42:48 - 16 GitHub push protection (new)  00:45:25 - 17 Local-first application (new)  00:51:22 - 20 SLIs and SLOs as code (new)  00:53:56 - Demo sloth  00:54:46 - 21 Synthetic data for testing models (new)  00:55:32 - 24 Satellite workers without "remote native" (new) - hold  00:56:05 - Вернемся ли мы офисы? А вы хотите вернуться?  01:01:47 - 26 Superficial cloud native 01:04:17 - 52 - k6 (up)  01:08:21 - 51 Great Expectations (up)  01:08:38 - 54 AWS Backup Vault Lock (new)  01:11:32 - 55 AWS Control Tower (new)  01:13:46 - 56 Clumio Protect  01:17:01 - 60. Kaniko  01:18:27 - 59. Hadolint (new)  01:22:38 - 64. xbar for build monitoring  01:27:13 - 65. Clasp  01:28:15 - 66 Databricks Overwatch (new)  01:35:34 - 68 git-together (new)  01:39:20 - Проблема code-review  01:43:16 - 69 Harness Cloud Cost Management  01:44:49 - 71. Karpenter 01:46:59 - 72. Mizu (new)  01:48:12 - 74. Teller (new)  01:49:03 - 75. Xcode Cloud  01:49:34 - 76. Online services for formatting or parsing code  01:51:13 - 27 Backstage (up)  01:52:57 - 29. AWS Database Migration Service (new)  01:55:17 - 37. Retool  01:55:55 - 39 Teleport (up)  02:00:31 - 40 VictoriaMetrics (new)  02:01:08 - 47. IAM Roles Anywhere (new)  02:02:33 - Languages & Frameworks  02:03:01 - 101. Stable Diffusion

I love interviewing other authors because every time I get to speak to one on Unstoppable Mindset I learn new concepts I hope I can use. I hope you feel the same way.   Our guest on this episode is Natasha Deen. She is an author of over 40 books written for youth, adults and everyone else in between. She made an interesting observation I love and which led to this episode's title. She observed that there are no great writers. There are only great rewriters. Listen to this episode to hear why she thinks this is so. I won't give it away.   About the Guest:   Guyanese-Canadian author, Natasha Deen has published over forty works for kids, teens, and adults, in a variety of genres, and for a variety of readerships. Her works include the JLG Standard Selection Thicker than Water, Guardian which was a Sunburst Award nominee, _and the Alberta Readers Choice nominated _Gatekeeper. Her YA novel, In the Key of Nira Ghani, won the 2020 Amy Mathers Teen Book Award and her upcoming novel, The Signs and Wonders of Tuna Rashad, is a CBC Top 14 Canadian YA books to watch for in spring 2022 and a JLG Gold Standard Selection. When she's not writing, she teaches Introduction to Children's Writing with the University of Toronto SCS and spends an inordinate amount of time trying to convince her pets that she's the boss of the house.   Social media links:   Visit Natasha at www.natashadeen.com and on Twitter/Instagram, @natasha_deen.   About the Host: Michael Hingson is a New York Times best-selling author, international lecturer, and Chief Vision Officer for accessiBe. Michael, blind since birth, survived the 9/11 attacks with the help of his guide dog Roselle. This story is the subject of his best-selling book, Thunder Dog.   Michael gives over 100 presentations around the world each year speaking to influential groups such as Exxon Mobile, AT&T, Federal Express, Scripps College, Rutgers University, Children's Hospital, and the American Red Cross just to name a few. He is an Ambassador for the National Braille Literacy Campaign for the National Federation of the Blind and also serves as Ambassador for the American Humane Association's 2012 Hero Dog Awards.   https://michaelhingson.com https://www.facebook.com/michael.hingson.author.speaker/ https://twitter.com/mhingson https://www.youtube.com/user/mhingson https://www.linkedin.com/in/michaelhingson/   accessiBe Links https://accessibe.com/ https://www.youtube.com/c/accessiBe https://www.linkedin.com/company/accessibe/mycompany/ https://www.facebook.com/accessibe/       Thanks for listening! Thanks so much for listening to our podcast! If you enjoyed this episode and think that others could benefit from listening, please share it using the social media buttons on this page. Do you have some feedback or questions about this episode? Leave a comment in the section below!   Subscribe to the podcast If you would like to get automatic updates of new podcast episodes, you can subscribe to the podcast on Apple Podcasts or Stitcher. You can also subscribe in your favorite podcast app.   Leave us an Apple Podcasts review Ratings and reviews from our listeners are extremely valuable to us and greatly appreciated. They help our podcast rank higher on Apple Podcasts, which exposes our show to more awesome listeners like you. If you have a minute, please leave an honest review on Apple Podcasts.     Transcription Notes Michael Hingson  00:00 Access Cast and accessiBe Initiative presents Unstoppable Mindset. The podcast where inclusion, diversity and the unexpected meet. Hi, I'm Michael Hingson, Chief Vision Officer for accessiBe and the author of the number one New York Times bestselling book, Thunder dog, the story of a blind man, his guide dog and the triumph of trust. Thanks for joining me on my podcast as we explore our own blinding fears of inclusion unacceptance and our resistance to change. We will discover the idea that no matter the situation, or the people we encounter, our own fears, and prejudices often are our strongest barriers to moving forward. The unstoppable mindset podcast is sponsored by accessiBe, that's a c c e s s i  capital B e. Visit www.accessibe.com to learn how you can make your website accessible for persons with disabilities. And to help make the internet fully inclusive by the year 2025. Glad you dropped by we're happy to meet you and to have you here with us.   Michael Hingson  01:20 Well, hi, and I am glad that you're with us again on an unstoppable mindset podcast episode. Today, our guest is Natasha Deen, except that she said to introduce her as she who would follow you home for cupcakes I buy into that. So true. Hey, listen, there's nothing wrong with a good cupcake. Or good muffins. Well, Natasha is an author, she's written over 40 books of various genres, and so on, we're going to talk about that. And she has all sorts of adventures and stories to tell. And so I think we will have a lot of fun on this podcast. So thanks for joining us. And Natasha, thank you for joining us today.   Natasha Deen  02:05 Thank you. And yes, thank you for joining my clan, I'm very excited to be here.   Michael Hingson  02:10 Well, tell me a little bit about you, you sort of the the early Natasha years and so on, and what you did how you got to the point of writing and anything else that you want to say,   Natasha Deen  02:20 Oh, well, I have an interesting, you know, that's gonna say like, I have a kind of an interesting origin story because I was born in Canada. But when I was three weeks old, my family moved back home to Guyana, South America, lived there, and then came back to Canada. So I'm a born Canadian, but my experience with Canada is an immigrant experience. Because the first country I knew was, you know, a country of, of coconuts and vampire bats. And you know, peacocks. And it was it was amazing, we lived No, we were just talking about previous residences. And the house we lived at, there was a stream in front of the house. And then there was a bridge that would connect you like you know, into the town. And I have, I can remember that we would get these huge rainstorms. And it would wash out the bridge. And then you'd either be well basically, as a kid, you were you were stuck, because you have to wait for the men to go find the bridge and bring it back and reattach because it just like a wooden bridge, or they'd have to rebuild it. And it was the same thing at school, like when the rains would hit, the teachers would just show off all the lights, and then we'd make paper boats, and we'd sail them down these like little these little rivers. And when I moved to Canada, the first time it rained, you know, I'm in school, and it starts pouring. And I'm so excited because I think for sure the teachers are going to turn off the lights and we're all gonna go sail paper boats. But it was like a loop was not to be as close the window and told me to pay attention. I'm like, but but but but no, I you know? And to answer your question about any desires to be a writer I did when I was a kid, I thought it would have been very cool to have a book on a shelf. But when I went to the teacher's library and the elders, parents, nobody knew nobody knew how to how to do it. And so I figured it was sort of like, you know, winning a lottery, or perhaps I don't know, some sort of happy, happy meeting, you have to sit down next to some editor on a train. And you mentioned that you really liked writing and they handed the contract right there. So I moved on to other other things. And it was after I graduated with my BA in psychology that I thought I'm just gonna give this writing thing at shot. And luckily for me, and you know, sort of all the writers who are up and coming like, we have the internet so we can, we can talk to the Google and the Google will tell us how how we navigate getting published and Contact, it's an editor's. So first sort of a snapshot.   Michael Hingson  05:04 So did you do anything with psychology? Or did you go straight into writing?   Natasha Deen  05:09 I so like dark secret, I was doing a couple of classes over the summer and preparation I had applied for my masters. And I was sitting there, and it was this really odd textbook that was telling you about, you know, counseling. And one of the techniques they had, they would repeat back to you what, you you know what the patient would say you repeat it back them, because the thinking of the time was, you know, hearing it, hearing it echo back would open up places. And I just, you know, what I remember, we had to do like a whole thing where we were practicing, you know, and it was the most, I realized I did not have the personality for it. Because if I was on the other side of the chair, and I'm saying to someone, I've had a really bad day, and they say back to me. So it sounds like you've had a really bad day. Yeah, yeah, my boss, my boss yelled at me. The boss yelled at you, I would have been like, No, I'm out. I'm gonna go find someone else to talk to you. Cool, actually, you know, talk back to me, instead of giving me a repeat of what I've like, I know what I just said, man. I just said it, you know? So. So that was about that. And I was also you know, so I thought, oh, I'll just, I'll just do a little bit of writing. And then, you know, I'll come back maybe what it is, I'm just tired, because I did school for, you know, 100 billionaires. And there's a danger, there's a danger of taking a break from from school, because then for people like me, we realize now we don't ever want to go back. Thank you very much. Well, we go do something else that someone else can have our desk. Okay, bye.   Michael Hingson  06:47 I remember when I was at UC Irvine, and working in physics and doing a lot with the computers, and there was a mainframe computer on campus. They had a psychology program, and it called Elijah. And it sort of worked like that. It would, if you type something in it would sort of repeat it back. But it was smart enough to deviate. And it could actually get you off in all sorts of unusual twists and turns. It was all about also psychoanalyzing you or, or creating conversations with you to try to figure you out, it was kind of fun. You could you could get absorbed with it for hours.   Natasha Deen  07:29 Well, that's amazing. They have I know that they have a digital version of rat training, mice mouse training. So you would you would train a mouse to like do a maze, but it was a digital mouse, which I appreciate it. I feel like mice have other things to do with their time than to run a maze forming.   Michael Hingson  07:48 Hey, I've read The Hitchhiker's Guide to the Galaxy. I know about mice. They're they're in. They're in control of the universe. Go read the book.   Natasha Deen  07:56 I wouldn't, you know, I wouldn't doubt that. That sounds that sounds feasible to me.   Michael Hingson  08:00 So something to work on. Well, so how did you end up getting to the point where your first book was published?   Natasha Deen  08:08 Oh, yeah, that's a great, like, I so I, you know, I was I was writing and I was sending out and I think for a lot of writers, you know, we know this feeling, right? You're sending out to editors, you're sending out to agents, and nobody wants you. Right? And sometimes, as soon as you get the really nice rejection letters, like, dear Natasha, thank you so much. I really enjoyed the work, but it just didn't reach me in the way it should. And I'm just not as passionate. You know, I wish you luck. And those ones I didn't mind the ones that that used to irritate me were the ones that would say, Dear author, yeah. Yeah, no, thank you. And it was, like, they didn't capitalize their sentences. And it would just irritate me so much. But I think it was a day and I just spent like, two hours researching you, making sure I spelled your name, making sure I was professional in my letter, the least you could do is capitalized, you know, I, I don't want this, you know, give it to them or whatever. But it was just so I happened upon a small e publisher. And I'd heard really, really good things about them. I'm not sure if they're around anymore. But I've heard really great things about them. And a few friends who had published them said, they're really great because they don't send generic rejection letters. If they don't want your work. They will tell you, and I thought okay, I this is this is perfect for me, because then I can send it out and really someone will tell me if I'm doing something wrong, like what what is it that I'm doing so wrong with with, you know, my books? So I sent it out. And about a month later, I got an email saying, Hey, we really liked this. We'd love to publish it. Can we send you a contract? Yes. Yeah. Yeah, well, you know, I think I think that's kind of the thing with the industry sometimes, like, you know, we get enough kicks in the hand at art, we start wondering if we're in the right industry, we start wondering, do we have any kind of talent? Do we have any kind of skill? Are we just kidding ourselves? And so, you know, when I sent it out, I really, I was still thinking, Okay, I just don't think I'm a great writer, I don't think I have what it takes. And so it was a really good lesson about how subjective the industry can be, you know, and that that frustrating, heartbreaking thing, which is persevering. And you just have to keep going, because what else are you gonna do? You know, if you're built to be a writer, you're built to be a writer.   Michael Hingson  10:42 So you got a contract? And you published your first book? Did they do any editing or work with you on making any improvements before it was actually published?   Natasha Deen  10:53 Oh, yeah, yeah, I had to do a quitter, I think three, three rounds of edits. And then they were really great. I mean, they were, they were teeny tiny, small, small budget. But I really love that they did the very best they could for like, publicity and marketing, for their authors. And they, they would bring, like different opportunities, if you wanted to do it yourself. You could also like, expand out. And I think it's something for authors to think about, you know, that quite often we dream of, you know, the big, I don't know how many publishers, I think it's a big five now maybe even just sort of a big for publishers. But sometimes there's something to be said for for the small and plucky publisher, you know, you may not have necessarily the bragging rights, where everyone knows that publisher, they know who you're talking about. But in terms of that sort of one on one interaction with your editor, the responsiveness of your editor, and just the care they'll take with your work. And I really enjoyed my time with them.   Michael Hingson  12:01 So when was the first book published? Or when did you start working with this first publisher?   Natasha Deen  12:06 Oh, so 2007 It was actually it. So the first thing I'd sent them was a short story. And that was 2007. And then my first novel would then came out in 2009. And then in 2012, and those were all adult romances. And then, in 2012, I went into writing for ya. And I was, that's that was in The Guardian series. And the first book in that series is conveniently titled with enough guardian, which is, which is all about Maggie who sees the dead, and is currently being haunted by the ghost of the kid who bullied her. So that was that was in 2012. Ah,   Michael Hingson  12:49 so the bullies haunting her, and what does she do about that?   Natasha Deen  12:53 Well, that's, that's kind of the whole thing, right? Because it's like, do you? Do you stay quiet? Because he's, you know, he doesn't know she could see him? So does she stay quiet? And just sort of leave him in this limbo? You know, sort of till the end of time as justice for what he's done to her? Or does she actually just say to him, Look, I can see you and here we go. And so the story, the story explores, you know, that side of it, but also it's sort of exploring the idea of, you know, the way that our painful memories can can haunt us. And what do we do? Do we do we face them? Do we acknowledge them? Or do we just sort of push them down and pretend like they don't exist?   Michael Hingson  13:39 So how many books have you written in that series? Which is I guess about Maggie?   Natasha Deen  13:43 Yes. So there's, it's a trilogy. So there's three books in that series?   Michael Hingson  13:47 Okay. Are they all with the same ghosts are different ghosts,   Natasha Deen  13:51 the ghosts, there are one to two supernatural creatures who are there throughout the whole trilogy. But each each book it was it's it's it's kind of an interesting, it's it's fantasy mixed with horror mixed with supernatural mixed with a mystery. So in each book, she's dealing with a ghost who is dead. A ghost story? I guess it goes, who doesn't know that they're dead? And is trying to sort you know, why? What has happened to them? And usually someone has murdered them. And so it's all about trying to figure out who who, who done them in like, well, who did it and then they can move on?   Michael Hingson  14:36 Sounds like a fun series. Have any of the books been converted to audio at all?   Natasha Deen  14:41 Oh, I don't know. Like I know, in the key of near Ghani, I know she's, she's audio. And I think one or two books in the large series is but I'm not sure about the Guardian series. I don't think so. I don't think I don't not yet. I don't think   Michael Hingson  14:58 well If we can find electronic copies, and then we can, can do them in Braille, which is also fine.   Natasha Deen  15:07 Oh, that's wild. That's interesting.   Michael Hingson  15:10 It's not magically overly hard to do. So, you started with this one publisher? I gather you didn't continue with them. Because you said you're not sure if they're around anymore, did you go elsewhere? Or what happened?   Natasha Deen  15:25 I get? Well, they were they were strictly for adults. And I realized with Guardian that it was, it wasn't aimed for adults, it was aimed for teens. And then once I started writing for kids and teens, it just, it's a very different kind of experience writing for for people who are under 18. Because when you think about it, like an adult reader, it's a very sort of, I feel like it's a very direct connection, right? I'm going to write the story. And here you go. And you as an adult reader, you the only thing you're going to think about is, is this the genre that I love to read. And with kids, there's no such like, with with Kid readers, what you're looking at is you're going to write the book, but then there's going to be an adult in that child's life, who buys that book or boards a book for the child. And it's more than just a question of, oh, this is these are the kinds of stories I like, it's questions of how old is this kid because how old that child is determines the kind of story you're going to tell? And how you tell that story? You know, are they? Are they someone who is an add grade reader? Or are they someone who is striving or what we call a reluctant reader? So they're in grade five, reading at a grade three level? And so you don't there's there's all of these things? So things like, how big is the sentence? Like how long is the sentence? What is the vocabulary? Are the words, am I using words that are easy to pronounce, and easy to sound out? And, and it's just a very like, from a writer's perspective, it's a very, very fun exercise. Because how I'm gonna write a story for someone who is seven, is going to be wildly different than how I write a story for someone who is 17. And, you know, I love it. Because, you know, we talked about the idea that simple doesn't always mean easy. And certainly when you're writing for kids, you're, you're really getting down and asking those questions about where are they, in terms of their literacy rates? Where are they in terms of how passionate they are about reading, you know, and I think about that now, in a really different light. And I'm really grateful to all of the kid authors who around when I was growing up, because their care and attention and love of like, kids everywhere, really ignited a passion for for reading that I now because of them. I am not just an adult reader. I'm an out writer. And so yeah, I'm very thankful to them for for all that they did when I was a little kid and making sure that those stories were accessible to me and made me feel lifted up because I could read it myself.   Michael Hingson  18:16 What do you come up with some of the ideas like for The Guardian series, and that's pretty, pretty creative, and a lot of twists and whatnot, twists and turns, but just a lot of parts to it? How do you come up with an idea like writing about a creature who is dead who may not know they're dead, and certainly don't know that someone can see them? Someone who can see them? And going through all the different gyrations of that,   Natasha Deen  18:41 you know, it was really, it actually started off as an adult story. And I was aiming for a mystery like it just a straight, cozy mystery with a librarian who finds who finds a body in the trunk of her car. And it turns out that it is, in fact, her ex husband her near her, you know, what do you call that it and near do well? Well, ex husband. And of course, obviously suspicion starts to her. And I was really struggling with it. And it was just a thought one day that I had about wouldn't it be interesting if it was a girl like a teenager? And instead of an ex husband? What if she found the body of her bully in the back of the car? And then where would we go? And I and then I started thinking though, then wonder where we go and how can I make this more interesting? And then I thought, well, what if she could actually see the dad and at first it's like, you know, are people gonna think I did it. And then of course now it gets super complicated because oh, he's he's there. I have not heard of this terrible person. So sometimes it's just a story where you're thinking about how can I make it more interesting for the reader? And then sometimes it's so Well, I, you know, I was talking to, to a relative, and we were sort of joking around because they had a younger relative in their life, who loved them a lot and worried about them. But the the love and the worry meant that this younger relative could be quite overbearing with this person I was speaking to, you know, and they were like, I'm not that old, I could take care of myself. And I thought, you know, like, it was such an interesting idea for a story about what do you what do you do? What do you do when someone loves you, but they're just, they, you know, they just they're so caught up and knowing in their mind what is right for you, that your your own wants and needs are getting tossed to the side. And that was the start of the signs and wonders of Tish odd because I have tuna, and then there's her brother, Robbie and Robbie is he's loving, and he's a great brother, and he's a great son. But he's just convinced he knows what's good for everyone. And, you know, and adding to that complicate, like, complicating it is the idea is that his his husband has just died. And so He's grieving. And now this is how, you know, one part of his grief is manifesting is that tuna can't breathe. And she just really needs Robbie to like, get a life or at least get out of her life and give her give her some room. And when I was writing it, I knew I wanted her to be an aspiring screenwriter, I thought there would be lots of room for for funny if I could do it like that. And I was struggling with it. And then I went back and I was thinking about the beats of a screen a screenplay. Right? And so how does it like when do you when does the a story break into the B story and, you know, what are the fun and games and, and, and then I got the idea that every chapter heading would mirror a story beat. And that's that's how to knows. That's how to news personality would would show itself. And so So yeah, sometimes it's, it's you're trying to solve a some writer's block, and then you realize that you're the wrong genre, the wrong age group. And other time too. You've got your genre, and you've got your age group. But now you're just trying to sort through, how do you make it? How do you make it funnier, and, and, and I love I really love the chapter headings because it meant that for any kid who relatable anyone who reads the story, who also has to write, not only do you have the story, but now you have a very with the chapter headings now you know exactly where your story needs to go, because they're all your story beats right there for you.   Michael Hingson  22:39 When you're writing a book, and this is something I've always been curious about, especially if in dealing with fiction, some but when you're writing a book, is each chapter somewhat like a story and then you you transition and do things to make them all combined together? Or how do you deal with deciding what's a chapter and what's not a chapter?   Natasha Deen  23:02 Oh, yeah, that's a great question. Um, I think for me, you know, what we think about or what I think about is, what's the story problem. So with tuna, the story problem is that Robbie is just overbearing, and and she needs to, you know, get some space from him. And so that's, you know, that's one plot of the story. And then, you know, from there I go, Okay, well, how do I, how do I make this problem? More complicated, right? Or how do I make this problem? Like, how do I start giving this problem texture? And I thought, well, it would be really funny if two has a crush on a guy trusted, and like, what, what sibling wouldn't interfere? So and I thought, yep, that's perfect. So once I had those, then it's just like, here's my big problem. How do I make them? Little tiny problems? Right? And so what is the what's the saying about? How do you how do you eat an elephant like one one bite at a time? And that's sort of it like, here's my big problem. Now, how do I make it smaller? So, you know, the opening chapter tonight is gonna go and estrus now it's summer, she's got, you know, 60 days to finally tell this guy students, she really cares for him. So she's going to tell him and she just, she gets shy, you know, and then she she trips up over herself over it. And so the problem in that chapter, which is I really want to tell this person I care for them does not get solved. And the her now having to resort, okay, that didn't work. How do I ask him about it now? Like, what's my next step? Now that jumps me to my next chapter that jumps and hopefully that jumps the reader because there's there's a chapter question, okay, what is she going to do now? And we we go on. And so one of the things to think about with bigger stories that are like the, you know, 5060 80,000 word count is, there's probably going to be more than one problem that your character is trying to solve. And you're gonna have like that big external prominent character needs a job, your character needs to rob a bank, and then you're gonna have another story that will probably tie into that bigger one, right? So my character needs to draw a bank, but really, the robbing the bank, because they have a sick child, and if they robbed the bank, they can get the money, and they're gonna be able to, you know, pay for some private operation and save the life of their child, then that's how that's how we twine it together.   Michael Hingson  25:50 So you, you do kind of have different things in in different chapters. But by the same token, things can get away from you, or things can go off in different directions, which is what makes writing fun. And part of the adventure for you.   Natasha Deen  26:08 Yeah, yeah. And you're right, because you know, you're asking about the containment of the chapters, and every chapter is going to have a beginning middle end to it, it's just that in those chapters, there is no like Final the end, there's just an end to that particular scene, or an end to that particular moment, that's going to bump you into the next moment. And the next seat. Well,   Michael Hingson  26:31 so you going back to your story, you decided to write full time I gather, and that's what you do now.   Natasha Deen  26:40 I do, I did I write full time, and I also teach with the University of Toronto School of Continuing Studies, I teach their introduction to children's writing, and I visit schools, and I tell kids funny stories about growing up and being the weird kid in class. And, and I also, you know, teach at libraries and, you know, attend festivals and that kind of thing. And, and I still, you know, and I think as writers, we know this, right, that sometimes this job can be such a grind, because you're, you're alone in a room with just your thoughts, and the voices in your head, and you're trying to sort it. And sometimes it can feel like why, why did I choose this job, but he was just refreshing, there's got to be some better way to make money, but the roof over my head, but you know, like, I just, it's so much fun that more More times than not, I'm kind of waking up, as I'm thinking to myself like that, that eight year old nine year old 10 year old me would be so jazzed to know that we grew up to be an actual writer with books on the shelves, and, you know, award stickers on on the covers of our books. Like, how cool is that? You know? So?   Michael Hingson  27:58 Yeah, that's, that's pretty cool. By any standard? Well, tell me, do you, you must have support and help? Do you have someone who represents you? Do you have people that you work with in that regard? Or how does all that work that you now get to publishers? Or you get help doing the other things that you do? Yeah, that's   Natasha Deen  28:19 a great question. And I'm, I'm really lucky because in Canada, our publishers don't, you don't need to have an agent to be published in Canada. And America, it's a little bit different, right? Like you have some publishers where I can contact a publisher directly and saying, Hey, I've got this, this story. And I think, I really think it will fit your catalog. But a lot of the pressures are going to be, hey, my agent has my story. And they think it's, it's, you know, just jazzy. So go ahead and take a look. And then, you know, see your agent is going to work on on your behalf. So early on in my career, I it was just me, right, it was just me all by myself submitting to publishers, and I'm saying I really hope you like my story. And then in 2016, I signed with Amy Tompkins from the transatlantic literary agency. And so now she represents me. So instead of me sending out my work directly to the publishers, I send them to Amy and then Amy sends out on on my behalf. So for those upcoming writers who are listening to our podcast, there's there's many ways there's many ways to get your, your book on the shelf. You can you can absolutely talk to the publishers yourself. You can go through an agent or you know, you can you can self publish, right, you can be an independent author, as well. And there's pros and cons to both sides of that, oh, it's what fits you.   Michael Hingson  29:51 How important is then having someone to represent you're having representation in what you do.   Natasha Deen  29:59 Well and Mike Ace, I would like I love my agent. I think she's, she's the bee's knees. I just think she's amazing. So I really enjoy writing, like, like I enjoy, because like, I love being able to send her work and talk to her about the industry and all these kinds of things. And I do think and I, and again, I think it's going to come down to what is your goal as a writer, what is your you know, do you want to make a career out of it, like a full time career, in which case, an agent is going to be really helpful to that, because they can get you into it and get you into the bigger markets, so they can get you into the bigger publishers, right. If you want to be part time writer, then you know, it all depends. But I will say for for anyone who is looking for an agent, you know, do be aware that your agent is is going to be doing lots of work on your behalf, but they're not, they're not magic genie is you're not going to rub a lamp and all of a sudden, here's all the things that are going to happen. What your agent gives you the opportunity to do is knock on more doors, but there's still no guarantee about being contracted or any of those things. So it's really good to have a realistic idea of, of what you're what the job of an agent is. So it's good to go and make sure you do your research about what they do. They're very, you know, they're they're like, they're vital when it comes to things like reading over your contracts, making sure that your artistic well being is being protected. But having said that, you know, you can also hire an entertainment lawyer who will do the same thing for you. So, again, you know, the frustrating, and yet the very amazing thing about this industry is that it always comes down to you as the individual, what is it that you want? How do you see this journey. And once you know those things, then you can build your plan for creating, sort of creating the career of your dreams.   Michael Hingson  32:09 What are some of the mistakes up and coming or new writers tend to make in your experience,   Natasha Deen  32:17 in my experience, they set or their work far too soon. It's great if you've written your story, but it's not ready yet, as and that can be a hard thing to hear if you've been working on this story for like three or four years, but it's not ready yet, you finish your story. And you start working on something else. Like you've got to give yourself a month, six weeks, two months, where you're not looking at that story that you finished at all, Project eight, don't look at Project day. And then after that, four to eight weeks, go back and take a look at it. Because now what you've done is you've decoupled you're not as close to that story anymore. And you're going to be a lot more objective. So you know, it's important to like, edit, and revise your work. You know, I don't know, I was saying to a class at one of my school visits, there are no great writers, there are just really, really great rewriters and the professional writers, this is what we know that you're going to do it. And then you're going to do it again. And again. And again. And again, until it's finally in a place where it's readable for more than just yourself. So it's really important to edit, it's to have beta readers. And there are people who are going to read your work and offer you feedback on your work, what's working, what's not working. And they're, they're also really important because, you know, when we're working on our projects in in the quiet, we're telling the stories to ourselves. And that's great. But to be an author is to be able to tell a story to a wide variety of people who you will probably never meet in your whole entire life. So you need to get other brains and other you know, viewpoints on on your work. And so, you know, it's all those things. And then once you're ready, you know, do your research, look and buy do your research. I mean, go look up these publishers, and find out if they're reputable, and look at their submission guidelines. Agents are the same thing. Look at the submission guidelines. How do they want you to submit the work? What kind of work are they taking? If you can do that, you're probably about 95% ahead of a lot of the writers out there who will just gonna do you know, they're just gonna throw in that and they're just gonna submit to everybody. And, you know, it can be a really frustrating thing for editors and agents because they're only representing nonfiction. And here's this manuscript they've got to deal with or this email they've got to deal with with someone who's who wants to, you know them to represent their picture book or their, you know, suspense thriller for adults, and it's like, no, you need to, you need to have enough respect for your work and for your emerging career, to take the time and do the research. And it is going to take time, and it is going to be frustrating, because you're looking at their, you know, Twitter feeds, and their social media and the blogs and all these kinds of things. But in the long term, and in the long run, it will, it will only do good.   Michael Hingson  35:33 One of the things that seems to me when you're talking about great writers is either they have a real sense of what it is, that would make someone want to read their book or their story, or they know how to get that information and then will will put it to use, which may not mean that that makes them a great writer, but it certainly makes them a much better marketer. Yeah.   Natasha Deen  36:03 No, it's well, and you know, this is? Yeah, you know, like, the, the great thing is that there's lots of different readers out there. And there's lots of different writers out there. And I think it's really important for us as readers to understand that just because we don't like a book, doesn't mean the book is bad. It can just mean that we're not the reader for that book. And I like, you know, I'm the person, like, if you're gonna give me a book, and there's, there's animal characters in that book, those animal characters better survived through the book, because if not surviving through the book, I am not reading it, you know, and it is like, and I will give you full credit that it's an amazing book, it's probably beautifully written. But no, if there's dog on page one, that dog still needs to be there on page, the end and happy. I want I want my dogs if they've gone through what they've gone through, but it's all okay. So so things like that, you know, and I'm very careful about women in peril kind of books, right? I'm I, some of them, I can read some of them. I can't. And again, it doesn't mean that they're not great writers. And those aren't great stories. It just means that I'm not the reader for them.   Michael Hingson  37:19 Yeah, Old Yeller is is a fine book. Except,   Natasha Deen  37:23 right. Hey, I tell you what, Michael, I mean, I get teased a lot because I'm the person who reads the ending before I read the rest of the book. But I blame that on Where the Red Fern Grows, because that book took out my heart. And I'm still not over it. I was when I read it. I'm still not over that book. And yeah, you know, and, and for me, it's like, Listen, if you're gonna ask me to spend however many hours, I need to know, it's gonna be worth my time, I need to know that these characters are gonna like, there's gonna be some kind of like, hopeful sort of note. The only time they don't do that as if it's a murder mystery. Because I want to I want to play along and see if I can find who the bad guy is before the detective does.   Michael Hingson  38:08 So dealing with animal books, of course, I mean, maybe it's the exception to a degree but then you have a book like Cujo, you know, from Stephen King, and, you know, do you really want I'm gonna I would love to have the dog not to have gotten rabies in the first place. But you know, that's the whole story.   Natasha Deen  38:25 I never I never rented the idea of a bad dog was just like no, no, I can't   Michael Hingson  38:31 start out a bad dog. That was the thing of course.   Natasha Deen  38:34 Oh, I know. I know what it is. No cuz you know there's only one ending for this poor dog. Yeah, right. Yeah. So so there is a dog in in tuna story and I want to sure all three out there that don't worry Everything Everything will be fine with magic.   Michael Hingson  38:57 Well, I appreciate that. I like books where were the animals survive? Of course I wrote thunder dog and Roselle survived in Thunder dog but they all they all do pass and but that's another that's another story.   Natasha Deen  39:12 Yes. That's it. And that's that's different. That's different. That's a   Michael Hingson  39:17 whole different you know? Yeah. And Roselle is somewhere waiting and watching and and monitoring and and occasionally probably yelling at us but you know, that's her.   Natasha Deen  39:29 That is yelling just just can't the ducks the doughnuts, man. Nothing.   Michael Hingson  39:36 What do you mean? Yeah, no, no, no, no, no. Roselle was also out there saying don't give them the donut. I want the donut. What do you do to those dumb ducks?   Natasha Deen  39:49 I feel like she would know that her bread will come later. Right?   Michael Hingson  39:54 Oh, well, maybe now but not then. Oh, yeah. Oh, no, no, thank you. is a lab What can I say?   Natasha Deen  40:02 No, I listened. We've got a husky mix. And I was joking around about how you definitely don't have to share DNA to the family because the look on her face when there's food. And just just the way she'll just look at you like, you're gonna share that right. And the long conversations I have with her room, like, I cannot share this. This is not appropriate. This is gonna make you really sick. You know, but I was thinking my husband one day I was like, as like, you know, I am pretty sure I get that same look on my face whenever I see through to just like, Oh, dang, is that? Oh, is that? Is that bread? Oh, man. Is that cheesecake? Hey, how you doing? Are you? Do you need some help on that? I can I   Michael Hingson  40:41 can totally help me. Make sure that that's really safe for you to eat.   Natasha Deen  40:45 Let me let me just make sure I Is that is that good. Let me let me tell you that bullet. Right. Let me take this for you.   Michael Hingson  40:52 You have you have children?   Natasha Deen  40:54 Yes. Yes, they're full grown boat. So they have kids of their own now.   Michael Hingson  40:58 So okay, so you have grandchildren? And and do we? Do we have any of them in your beta reader groups?   Natasha Deen  41:06 No, no. Because they Well, because they're they're still little adults, adult's? Oh, you know, I actually they'll read it afterwards. Because their schedules are pretty, their schedules are pretty intense. So   Michael Hingson  41:24 part of the evaluation process? Well, I   Natasha Deen  41:27 just feel bad, you know, looking them being Hey, hey, I know you're juggling, like 10 Different things now. But can I throw one more ball at you. And then also, like, I appreciate, like I use I use writer BETA readers, as opposed to just the quote unquote, regular folk, just because I usually by the time I'm done, I've got very specific questions about story structure, how the acts are transitioning? Can you can you see the a story B story? Where can you see the external? And so there needs to be a certain level of, I guess, like literary mechanical engineering? Do you know what I mean? Where I think to that? I think I think I think my family would be like, I love you. But stop asking me about the grammar. There's only so many times you can be like, okay, within what about, you know, when I when we're doing this metaphor, and it's, you know, like, just let me read it. Okay, so read it. So   Michael Hingson  42:29 how about today? Reading, I don't know, I'm trying to figure out what's happening to reading we've, we've changed a lot. Reading is now not just getting something on paper, we have electronic books, and so on. And I hear a lot of people say, Yeah, I read the books, it's not quite the same as reading a book. That's a full paper book, but I enjoy reading them as well. And of course, then there are a lot of people who just don't get into reading at all. But reading is so valuable, because it seems to me that one of the great advantages of reading is it gets you to sit and relax and take time away from everything else that probably we really don't need to be doing anyway. But we do it. But the reading gives you the opportunity to just sit down and let your mind wander. And it develops a lot of imagination. How do we get more people to do that?   Natasha Deen  43:30 That's a great question. And I'm not sure that I have a feasible? I'm not sure I have the answer. You know, but I think one of the things you said in the beginning was I think very well said that there is more than one way to access stories now. And I think that's really important. Right? If you are if you are someone who loves paper books, that's wonderful. But you know, for some of us, we're going to come to story differently. We want the story told to us, you know, or we want the story in some kind of a different, you know, when you're thinking about sometimes, like, finger dexterity and coordinate, you know, a screen is much easier to navigate. Than, then sometimes a book can be, and depending on the device you're using, it's going to be lighter. So if you have issues holding books, paper books, I mean, you know, this, these are like, these are the kindnesses that I think technology affords us, and that, you know, and if you're if you're busy, you can pop in that audiobook when you're sitting in the middle of rush hour and you can get to story that way. But I think a lot of it is is getting to folks when they're young and understanding that, again, not everybody comes to story the same way. And the thing that I think is magical about being a writer is that I can write I can write this Signs of wonders of tuna or Shawn, and I can give 30 people a copy of that book. And everyone will have the same book, not everyone is going to read the same story. Because at the moment time we start reading, we're going to bring our hopes, our dreams, our past experiences, our, you know, future or future hopes for us. Like we bring all of these things in how you know, do we have great relationships with our parents? Do we not, you know, how do we view the world? All of these things, like infuse the stories that we read, and they changed right there, they become another creature. So someone reads the book, and they say, Oh, yes, I read this. And this book is a cat. And someone say, no, no, no, it's not a cat. It was a chameleon. And someone else will say, No, it's a phoenix. And each of those people are correct, because that is how they interpret the story. And that's how they interpreted the book. And so you know, when we're talking about getting people, folks to love reading, it's getting them I think, a lot of times getting them young, understanding what are their what are the things that they love to read? What are the things that they love about the world? Let's, let's start there, and give them those kinds of stories. Like, you know, the idea that oh, I love this book, therefore, you must love this book is a really unkind to do to people. Because it says because I think of this like this, you must also think of this, like this, and and people are individuals, right? My mom's favorite book is To Kill a Mockingbird. I think I think it's a well written book. I can't stand the book. It sets my hair on fire every single time. You know, I have friends who really love the Great Gatsby, I'm not that person. Right? It doesn't mean that those people are wrong. I love the fact that my mom loves To Kill a Mockingbird, you know, and I love that my mom understands that's never going to be my favorite book. And she respects that. And so when, you know, when we were growing up, it was like, go to the library, even if she was like, Oh, that's okay. You know, she would give us space, if that's what you love. That's what you love. And I think we need to stop. Also, what's the word I'm thinking of? You know, I hear people a lot of times, especially with young readers, where they say things like, oh, but it's a graphic novel. There's not a lot of text in there. And, you know, how are they are they going to become readers? And it's like, be okay, granted, but when you look at a graphic novel, there's, there's images and who's looking at this book and reading through it has to be able to make intuitive leaps about you know, what's happening in this box versus what's happening in this box. And, you know, so it's still teaching, it's teaching life skills is teaching like human skills. And I think if we can leave, we can go from the point of taking the spotlight and putting like taking the spotlight and putting it on to the person who we want to get reading and having an open conversation where we respect where they're coming from. I think that can be really helpful.   Michael Hingson  48:11 Yeah, book like To Kill a Mockingbird is is an interesting book, I'm, I'd be curious to know what it is that the you've read, really find a problem with the book, but I can see that different people would certainly read that and deal with it in different ways. Oh, for me,   Natasha Deen  48:29 it was it was just this as you know, I'm a person of color in my everyday life, I've got to deal with micro aggressions and, and so in my, in my relaxed life, in in my fictional world, I don't want to have to I want space from that. I just want to be able to read something fun and something, you know, enjoyable. I don't want to have to read about the things that I'm trying to deal with in the real world, but at the same time, people really love it.   Michael Hingson  49:00 One of my favorite books is one that I'm sure today is not a favorite book for a lot of people. It's a Connecticut Yankee in King Arthur's court by Mark Twain. And I love the plot. I love all the things that happened in it. It's just one of those books that has really stuck with me, and that I absolutely thoroughly enjoy. I guess also, I do have to say that I originally read it as a recording. It was a talking book produced by the Library of Congress. And the guy who read it was perfect. But it has always been one of my favorite books. I think it's just an incredibly creative book. And I admire that.   Natasha Deen  49:43 Yes, yeah. Well, I you know, it's easy because I really liked calm Sawyer and Hawk you know, I thought I mean different books. But yeah, they were fun characters, and I thought Twain had a very excellent storytelling style. I guess that's it. You're right. Yeah.   Michael Hingson  50:01 Well and, and different kinds of stories. I'm an okay Yankee Yankee in King Arthur's Court is hard. I like Tom Sawyer.   Natasha Deen  50:08 Well, did you did you know that he when he died, and like fact check me on this because I remember reading this years ago, but that his diary, he made sure as well that the diary could never be published for something like 100 years, because of the he was talking smack about so many people. He was like, they cannot be alive. But like,   Michael Hingson  50:33 yeah, I remember that. And it wasn't. So, of course, he knew we knew what he was going to die. He was born in 1835. And he said, I came in with Halley's comet, and I'll go out with it. And he did.   Natasha Deen  50:45 That's amazing. Hey,   Michael Hingson  50:48 it's just one of those things. Well, you know, before we wrap all this up, what's next for you? Where are you headed? What? What kind of projects do you have coming up?   Natasha Deen  50:58 Well, so yes, the tuna releases on June 7. I'm very, very excited about that. And then I'm just finalizing the book in the spooky SLIS series. And that's for early. That's for ages like 79 That's with Penguin Random House. And I'm very excited about that. That's, that's awesome. And Rockstar who live on in Lions Gate, and spooky creepy things happen. And awesome is convinced that there are supernatural creatures roaming the town. And rock star is convinced that because there is a science lab, it's probably just science running wild. And so the books, the book one opens up with a tree. That seems to be housing, a very evil spirit. But what will happen next?   Michael Hingson  51:48 Oh, you have to read the book to find out.   Natasha Deen  51:51 That's right.   Michael Hingson  51:54 Have you ever read books by David Baldacci?   Natasha Deen  51:56 Yes. Yeah, I just started reading him. Memory Man, I just I just started.   Michael Hingson  52:01 So and that's a that's a good one. But he also wrote, I think it's more for youth if I recall, but he wrote a series of four books. It's the Vega chain series. And if you ever get a chance to read those, it's a totally different Baldacci, then all of his mysteries, their fantasies, and it's a fantasy world, sort of, I don't want to give it away. But they're, they're well worth reading. I accidentally discovered them. I was looking to see if there was anything new by Baldacci out on Audible. And I found one of these and I read it on a on a plane flight and got hooked and so then could hardly wait for the next one to come out. So it's Vega, Jain V, GA and then chain.   Natasha Deen  52:48 Okay, yeah, thank you.   Michael Hingson  52:51 I think they fit into a lot of the things that you have been writing about. So they're, they're they're definitely worth reading. But there's nothing like reading conversations are great with people. But you get to meet so many more people in a book. And as I said, it seems to me that the most important thing about reading is sitting down and reading to let your imagination go. And you're right. The way you imagine is different than the way that I imagined. And we're all different. And that's the way it should be.   Natasha Deen  53:23 Yeah, absolutely. Absolutely. Thank you, Michael. This was a lot of fun.   Michael Hingson  53:28 This was fun. I very much enjoyed it. And we need to do it again in the future. Yes, sir. So no tuna books are out yet. No, not yet. Next. So tunas tuna is new. It's coming out next Tuesday.   Natasha Deen  53:45 The signs and wonders of tuna are shot.   53:47 Wow. So that'll be fun. Well, we'll have to kind of watch for   53:51 it. Okay, sounds good.   53:55 If people want to learn more about you, and maybe reach out to you and talk to you about writing or any of those things, how can they do that?   54:04 Oh, on my website, www dot Natashadeen.com. And Natasha Deen is spelt D E E N. And Natasha is N A T A S H A.   54:18 So N A T A S H A D E E N.com. And they can contact they can contact you there and so on. And I assume you have links so that they can go buy books.   Natasha Deen  54:32 Yes, yes. Yes. It wouldn't be a website without it.   Michael Hingson  54:35 No, not an author's website. It would not be Well, this has been great. I really appreciate you coming on we will have to stay in touch. And we'll have to catch up to see how all the book sales go and how the the awards go once the new series are out. Thank you.   Natasha Deen  54:54 Yeah, sounds well make it a date, sir. They'll be perfect.   54:58 Absolutely. Well, Natasha, thanks for being here. And I want to thank all of you for listening and being with us today. This has been absolutely enjoyable. I hope you found it. So reach out to Natasha at her website, Natasha deen.com. And of course, I want to hear from you. So if you would like to reach out, please email me at Michaelhi at accessibe.com M I C H A E L H I at A C C E S S I B E.com. Or go to our podcast page, Michael hingson.com. hingson is h i n g s o n.com/podcast. And of course, we sure would appreciate it if you'd give us a five star rating after listening and, and come back and subscribe and listen to more unstoppable mindsets. We have all sorts of adventures coming up. And we would love you to be part of it. So if you'd like to be a guest, let us know if you know of someone who you think would make a good guest. Let us know that too. So again, thanks for being here. And Natasha, thank you once more for coming on unstoppable mindset.   Natasha Deen  56:03 Thank you, Michael. And thank you to all the listeners. I loved it. Thank you for spending time with us.   Michael Hingson  56:12 You have been listening to the Unstoppable Mindset podcast. Thanks for dropping by. I hope that you'll join us again next week, and in future weeks for upcoming episodes. To subscribe to our podcast and to learn about upcoming episodes, please visit www dot Michael hingson.com slash podcast. Michael Hingson is spelled m i c h a e l h i n g s o n. While you're on the site., please use the form there to recommend people who we ought to interview in upcoming editions of the show. And also, we ask you and urge you to invite your friends to join us in the future. If you know of any one or any organization needing a speaker for an event, please email me at speaker at Michael hingson.com. I appreciate it very much. To learn more about the concept of blinded by fear, please visit www dot Michael hingson.com forward slash blinded by fear and while you're there, feel free to pick up a copy of my free eBook entitled blinded by fear. The unstoppable mindset podcast is provided by access cast an initiative of accessiBe and is sponsored by accessiBe. Please visit www.accessibe.com. accessiBe is spelled a c c e s s i b e. There you can learn all about how you can make your website inclusive for all persons with disabilities and how you can help make the internet fully inclusive by 2025. Thanks again for listening. Please come back and visit us again next week.

This week, our host Sean is sitting down with Chris Schroeder of App47 to talk about Service Level Indicators (SLIs), Service Level Objectives (SLOs) and discuss their potential impact on your organization's ability to invest in innovation. How do you structure an SLO? What are the standard conventions? And how do you build a dashboard that helps you find the capacity to prioritize innovation and transformation by reducing the volume of issues and incidents?

Guest: Tim Nguyen, Director of Detection and Response @ Google Topics: I know we don't like to say “SOC” here, so why don't we talk about the role of automation in detection and response (D&R) at Google? One SRE concept we found useful in security operations is “toil” - How do we squeeze toil out of D&R practice at Google? A combined analyst and engineer role (just like an SRE) was critical for both increasing automation and reducing toil, how hard was it to put this into practice? Tell us about that journey? How do we automate security signal analysis, can you give us a few examples? D&R metrics have been a big pain point for many organizations, how does SRE thinking of SLOs and SLIs (and less about SLAs) helps us in our “not SOC”? How do we avoid falling into the “time to respond” trap that rewards fast response, sometimes at the cost of good? Resource: SRE book, Chapter 5 - Eliminating Toil SRE book, Chapter 4 - Service Level Objectives “Building Secure and Reliable Systems” book “Achieving Autonomic Security Operations: Automation as a Force Multiplier” “Achieving Autonomic Security Operations: Reducing toil” “Taking an autonomic approach to security operations” video “Modern Threat Detection at Google” (ep17)

DhDanfar an leabhar Gael linn I gCúige Uladh; Slis den saol 1953-1970 a fhoilsiú tráthnóna amárach in Aonach Mhacha in Ard Mhacha.

“The most significant body of my SRE work is architectural reviews, disaster and failover planning and help with SLIs and SLOs of applications that would like to become SRE supported.”This statement comes from Hilliary Lipsig, Principal SRE at Red Hat, as her introduction to what the role of an SRE should be. Hilliary and her teams are helping organizations getting their applications cloud native ready so that the operational aspect of keeping a system up & running and within Error Budgets can be handled by an SRE Team.Listen in to this episode and learn about the key advices she has for every organization that wants to build and operate resilient systems. And understand why every suggestion she makes has to be and will always be evidence-based!In the talk we mentioned a couple of tools and practices. Here are the links:Hilliary on Linkedin: https://www.linkedin.com/in/hilliary-lipsig-a5935245/KubeLinter: https://docs.kubelinter.ioListen to talk Helm and Back again: an SRE Guide to choosing from DevConf.cz: https://www.youtube.com/watch?v=HQuK6txYS3g

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.

Cilvēku uzmanību spēcīgi ietekmē draudi dzīvībai, veselībai un drošībai - gan fiziskai, gan emocionālai, gan finansiālai. Karš Ukrainā ir iemesls, kāpēc šajā laikā daudziem ir grūti ilgstoši koncentrēties un noturēt uzmanību uz mērķiem, kuru sasniegšanai vajadzīgs laiks. Šajā sarunā Intelekta attīstības centra vadītājs un uzmanības treneris Oskars Grīslis stāsta, ko cilvēkam ir ieteicams darīt un nedarīt, lai atgūtu kontroli pār savu uzmanību un spēju koncentrēties darbam un sev būtiskajam.Vairāk informācijas un Oskara ieteiktās grāmatas un citus avotus atradīsi sarunas lapā šeit. Šeit pieejama informācija par Intelekta attīstības centru un Latvijas Miega projektu.SARUNAS PIETURPUNKTI:03:02 Kāda ir saistība negatīvām ziņām un uzmanības problēmām07:21 Kāpēc šobrīd īpaši svarīgi ir uzmanīt savu ikdienas struktūru; kā to veidot16:47 Kas ir ikdienas dienasgrāmata un kāpēc ir vērtīgi ro rakstīt; praktisks piemērs33:31 Mērķis, kādēļ tika radīta “Vīru grupa”, kāda ir tās struktūra44:54 Kādus datus var iegūt ar miega gredzena palīdzību, un kādos brīžos tas ir svarīgi51:01 Kā spēt vienoties, noturot savas robežas55:28 Kāds hormons ietekmē to, ka mēs prokrastinējam lietas, kuras vajadzētu darīt1:03:05 Kas var palīdzēt cīņā ar digitālā formāta atkarību1:08:30 Kā uzlabot savu spēju fokusēties uz vienu lietu1:13:52 Ar ko īpašs ir jaunais projekts “Jauniešu skola”1:16:57 Latvijas miega projekts1:21:16 Galvenie trīs pieturpunkti, kas palīdzēs atgūt kontroli par savu uzmanību

In our previous two episodes, we learned more about patron-perpetrated sexual harrasment through research conducted by Dr. Danielle Allard, Dr. Tami Oliphant and Angela Lieu. This epsiode, we sat down with Sam Pearson, Director of the University of Alberta Sexual Assault Centre so see  what libraries can do and what resources are available.**Content Warning** This episode delves into topics of sexual harrasment and workplace trauma, which may be triggering for some listeners. Please take care of yourself and, if you need to, don't be afraid to reach out and ask for help. Resources can be found below. Resources:General Info: 211University of Alberta Sexual Assault Centre: 780-492-9771 Sexual Assault Centre of Edmonton: 780-423-4121 Alberta One Line for Sexual Violence: 1-866-403-8000 Music Credits:Beanbag Fight by Scanglobe

This episode is part 2 of our interview with Dr. Danielle Allard and Dr. Tami Oliphant on their research on patron-perpetrated sexual harrasment, done in collaboration Angela Lieu. **Content Warning** This episode delves into topics of sexual harrasment and workplace trauma, which may be triggering for some listeners. Please take care of yourself and, if you need to, don't be afraid to reach out and ask for help. Resources can be found below. Resources:General Info: 211University of Alberta Sexual Assault Centre: 780-492-9771 Sexual Assault Centre of Edmonton: 780-423-4121 Alberta One Line for Sexual Violence: 1-866-403-8000 Music Credits:Beanbag Fight by ScanglobeAlgorithms by Chad Crouch

Our first You Conferences Speaker Spotlight of 2022 is Kellee Forkenbrock. Kellee is a proven marketing executive with 20+ years of experience, an outreach librarian enrolled in the University of Iowa's SLIS graduate program, a local indie writer with 12 self-published novels under the pseudonym Eliza David, former Board member for both the Iowa City Public Library and Girls on the Run of Eastern Iowa, current Ambassador for the Iowa City Area Business Partnership, and City of North Liberty's 2019 Rookie of the Year! You can learn more about her here: https://linktr.ee/elizadwrites ------------------------------------- Connect with Kendra Facebook: https://www.facebook.com/kendraaarhus/ Website: https://www.kendraaarhus.com Instagram: https://www.instagram.com/kendraarhus/ TikTok: https://www.tiktok.com/@kendraaarhus It's Funny You Ask Podcast https://anchor.fm/kendraaarhus --------------------------------- Follow You Conferences Website: https://www.youconferences.com Instagram: https://www.instagram.com/youconferences/ Facebook: https://www.facebook.com/youconferences/ --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app --- Send in a voice message: https://anchor.fm/kendraaarhus/message

4 years ago, the S4Ls team interviewed Dr. Danielle Allard, Dr. Tami Oliphant and Angela Lieu to learn more about sexual harrasment in the library. This episode, we had the opportunity to chat with them again to see where their research is today and learn more about patron-perpetrated sexual harrasment. Tune in next month to hear part 2!**Content Warning** This episode delves into topics of sexual harrasment and workplace trauma, which may be triggering for some listeners. Please take care of yourself and, if you need to, don't be afraid to reach out and ask for help. Resources can be found below.Resources:General Info: 211University of Alberta Sexual Assault Centre: 780-492-9771 Sexual Assault Centre of Edmonton: 780-423-4121 Alberta One Line for Sexual Violence: 1-866-403-8000Music Credits:Beanbag Fight by Scanglobe

Saham SLIS emiten produsen sepeda listrik dan motor listrik

No Cilvēkjaudas auditorijas saņēmām lūgumus pievērsties spējai fokusēties, it īpaši - ilgstošākā periodā, jo cilvēki ir pamanījuši, ka noturēt savu uzmanību uz konkrētu uzdevumu ir palicis grūtāk, sevišķi pēdējo gadu laikā. Par šo tēmu uz sarunu aicināju Oskaru Grīsli, kurš ir uzmanības treneris un Intelekta attīstības centra vadītājs. Trenēt cilvēku spēju noturēt savu uzmanību uz veicamo uzdevumu un sev aktuālo ir Oskara specialitāte. Pie reizes pievērsāmies arī tēmai par nebeidzamās sevis optimizēšanas saprātīgām robežām un atpūtu.Mana pirmā saruna ar Oskaru bija par emocionālo izlādi un to, kā uzlabot savas spējas mentālam darbam.Oskars ir tēvs 4 bērniem. Intelekta attīstības centrā viņš konsultē bērnus, jauniešus un pieaugušos, tai skaitā, izmantojot biofeedback un neurofeedback. Oskars studē RSU maģistratūrā, ir arī vīru grupas vadītājs ar 25 biedriem un Daudzbērnu ģimeņu biedrības priekšsēdētājs savā novadā.Vairāk informācijas sarunas lapā šeit.SARUNAS PIETURPUNKTI:3:19 Kas ir tie trīs galvenie faktori, kas traucē saglabāt fokusu7:53 Nepārtraukti sevi optimizējošie cilvēki – cik ir veselīgi, un kā saprast, kad ir jau par daudz15:27 Kādu savas veselības uzraudzības “gadžetu” ir gudri iegādāties22:35 Kas ir sirds ritma variabilitāte un ko tā parāda30:32 Iemesli, kuru dēļ ir grūti koncentrēties pat uz patīkamām nodarbēm40:30 Metode, kā samazināt sociālo tīklu lietošanu sev, bērniem un pusaudžiem57:20 Ko nozīmē uzņemties simtprocentīgu atbildību par savu dzīvi1:02:21 Kā pareizi sastādīt dienas plānu, lai tas būtu efektīvs un kā veicināt fokusēšanos uz konkrētu lietu1:16:00 Kas ir meditācija un kādi ir meditāciju tipi1:22:47 Miega higiēna un kā pielāgot miega stundas konkrētā cilvēka hronotipam1:26:38 Iemācīties pareizi atpūsties1:35:00 Kāda ir emocionālās izlādes saikne ar fokusēšanos1:41:11 Pastāvošās izglītības sistēmas galvenās nepilnības

This episode, join us for our first ever virtual workplace holiday party. Our hosts gathered to share some of their favourite media from the past year, from books and music to TV shows and podcasts. The best part, you can find all their recommendations for free at your local public library!Music Credits:Beanbag Fight by ScanglobeCan't Let Go by Robert Plant and Alison KraussUnsmart Lady by Dry CleaningSound Effects: Zapsplat 

This episode brings back the familiar voice of S4Ls alum Joel Blechinger. We sat down to discuss his investigations into the information literacy habits of conspiracy theorists in the QAnon movement.Music Credits:Beanbag Fight by Scanglobe

Welcome to the first episode of the new season of The Podcast Studies Podcast (formerly New Aural Cultures). We are absolutely delighted to have Dr. Reginold Royston on the show, whose article Podcasts and New Orality in the African Mediascape is the focus of the discussion. A transcript of this episode is available. Dr. Royston is a media anthropologist and digital humanities researcher, jointly appointed in the School of Information (formerly SLIS) and the Department of African Cultural Studies at the University of Wisconsin-Madison. He teaches courses on the political economy of information, race/class/gender/identity in tech, Africa, and internet practices in developing world contexts. He also coordinates the Black Arts + Data Futures group through the Borghesi-Mellon Interdisciplinary Workshop in the Humanities at the UW-Madison Center for Humanities. The conversation covers the context of African podcasting, researching from a diaspora identity, tech entrepreneurialism as a genre, the concepts of secondary and new orality, the influence of African oral traditions, and the dialogic formulas that structure podcasts discussion. For this season Dario is joined by a new regular (I mean deluxe) co-host Lori Beckstead. Lori is a professor of audio and digital media at the RTA School of Media at “X” University (undergoing a name change), where she teaches courses in radio production, sound design, and digital media production. Also, as a sound artist, she has a particular interest in soundscape recording and interactive installation art. Dario and Lori give an overview of their interests for the coming season. We are also delighted to have a new recommendation segment (or a podcast neighbourhood walk) featuring podcast producer and all-around guru Jess Schmidt. Jess is a podcast producer and consultant based in Calgary, Alberta. She recently completed a Master of Media Production at "X" University, and listens to more podcasts than anyone Lori has ever known. Shownotes Podcasts Dr. Royston mentions: Building the Future African Tech Roundup Afroqueer history Accra We Dey Gorga podcast Shanti tree Pod-Africa Platform Africa Past and Present Podcast Africa Pod festival Jess' recommendations: Dan Misener's Podcast Neighbourhoods You're Wrong About We Need to Talk about Britney --- Send in a voice message: https://anchor.fm/podcaststudiespodcast/message

In this episode, Henrik and Leandro will talk about all the new SLs that are around now. The evolution from simple SLAs, into the more complex triad of SLIs, SLOs, and SLAs.

A Mesa Redonda da Quality Engineering Unit reuniu-se para partilhar sobre o tema do QAOps https://qeunit.com Subscreva ao podcast para seguir os próximos episódios

A Mesa Redonda da Quality Engineering Unit reuniu-se para partilhar sobre o tema do QAOps https://qeunit.com Subscreva ao podcast para seguir os próximos episódios

A Mesa Redonda da Quality Engineering Unit reuniu-se para partilhar sobre o tema do QAOps https://qeunit.com Subscreva ao podcast para seguir os próximos episódios

A Mesa Redonda da Quality Engineering Unit reuniu-se para partilhar sobre o tema do QAOps https://qeunit.com Subscreva ao podcast para seguir os próximos episódios

A Mesa Redonda da Quality Engineering Unit reuniu-se para partilhar sobre o tema do QAOps https://qeunit.com Subscreva ao podcast para seguir os próximos episódios

A Mesa Redonda da Quality Engineering Unit reuniu-se para partilhar sobre o tema do QAOps https://qeunit.com Subscreva ao podcast para seguir os próximos episódios

A Mesa Redonda da Quality Engineering Unit reuniu-se para partilhar sobre o tema do QAOps https://qeunit.com Subscreva ao podcast para seguir os próximos episódios

A Mesa Redonda da Quality Engineering Unit reuniu-se para partilhar sobre o tema do QAOps https://qeunit.com Subscreva ao podcast para seguir os próximos episódios

Alex Bramley continuous his conversation with Sven Johann. They begin with how granular you should monitor your user journeys and then discuss error budget policies in depth. They continue on how to iterate on SLIs, SLOs and error budget policies. They close the conversation with SLO alerting.

Alex Bramley talks to Sven Johann about the basics of service level objectives. They begin with terminologies (SLI, SLO, SLA, Error Budget), look at costs of outages and discuss what reliability has to do with customer happiness. They continue with having 100% reliability is the wrong target and what’s possibly the right target. Alex then explains how to get started with collecting data about your system’s behaviour. They close the first part of this series by looking into latency SLIs.

Hello librarians.  Thank you for joining me. Today's episode is short but essential.  It hits at the heart of what you do. Today, I'm going to talk about the why of what you do and why that why matters. You can find today's show notes at masterfullibrarian.com/ep3.When I ask why you become a librarian, I don't mean how did you come to this profession.  That may not be that relevant at all to why you are inspired to do the work you. For instance, I got my MLS only because I couldn't find a good job with my Public Relations degree and the chance for a graduate stipend from the University of Alabama Graduate School of Library and Information Service (now SLIS) dropped in my lap. My mother was a college library director and a graduate of the school.  The Dean happened to call her looking for graduate assistants while I was sitting in her office making a nuisance of myself.  I applied and the rest is history. That's how I got into the profession, but it certainly wasn't why I stayed.  When I talk about your why, I'm referring to the concept so beautifully articulated by Simon Sinek in his 2009 book “Start With Why: How Great Leaders Inspire Everyone To Take Action” and his subsequent TED talks with the same title. If you've never read the book or listened to the talk, I highly recommend doing both.  You can check out his work and his message on his website at simonsinek.com.  The link is in the show notes.One of the most powerful things Sinek says in this book is “People don't buy what you do; they buy why you do it. And what you do simply proves what you believe”. He uses the example of Steve Job's masterful marketing for Apple. Apple's marketing strategy didn't focus on their products, which of course were good; it focused on the company's own why. Sinek describes a Golden Circle needed to be successful in engaging others.  This circle has Why a business does things at it's core, How it does things as the next circle out from the core, and what it does or produces as the outer circle.In his TEDx talk he describes Apple's Golden Circle this way: “The inner core, the Why- In everything we do, we believe in challenging the status quo, we believe in thinking differently; the next circle, the How – We make products that are beautifully designed and user friendly; and the outer circle, the What – We just happen to make great computers.  Wanna buy one? "So when I ask about your why, I mean that thing that serves as the bedrock of your motivation and inspiration for your library work.  It's the deep belief or beliefs that drive your ideas, decisions, programs and professional relationships. And it's an absolutely critical component to achieving greater relevance, meaning, and library impact.  Your patrons, your users, will be drawn to your why much more so than your what. In fact, I would say that librarians who struggle the most to gain support and be effective are the ones with the least compelling and service-oriented why's.  For complete show notes, go to  masterfullibrarian.com/ep3.        

Learn more:VMware TanzuVMware Pivotal LabsReliability Engineering for HumansA Quick Guide For Getting Up to Speed on SRESRE in 15 MinutesHow RBC adopted SRE culture to help it embrace cloud-native applicationsA Service-Level What?Getting good at messing up, negotiating SRE error budgets, and small talk topicsSLIs and Error Budgets: What These Terms Mean and How They Apply to Your Platform Monitoring StrategyFollow everyone on Twitter:VMware TanzuVMware Pivotal LabsHannah FoxwellDanielle BurrowDerrick Harris

The conversation covers:  An overview of Ravi's role as an evangelist — an often misunderstood, but important technology enabler.  Balancing organizational versus individual needs when making decisions. Some of the core motivations that are driving cloud native migrations today.  Why Ravi believes it in empowering engineers to make business decisions.  Some of the top misconceptions about cloud native. Ravi also provides his own definition of cloud native. How cloud native architectures are forcing developers to “shift left.” Links https://harness.io/ Twitter: https://twitter.com/ravilach Harness community: https://community.harness.io/ Harness Slack: https://harnesscommunity.slack.com/ TranscriptEmily: Hi everyone. I'm Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product's value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn't talk about them. Instead, we talk a lot about technical reasons. I'm hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you'll join me.Welcome to The Business of Cloud Native, I am your host Emily Omier. And today I'm chatting with Ravi Lachhman. Ravi, I want to always start out with, first of all, saying thank you—Ravi: Sure, excited to be here.Emily: —and second of all, I like to have you introduce yourself, in your own words. What do you do? Where do you work?Ravi: Yes, sure. I'm an evangelist for Harness. So, what an evangelist does, I focus on the ecosystem, and I always like the joke, I marry people with software because when people think of evangelists, they think of a televangelist. Or at least that's what I told my mother and she believes me still. I focus on the ecosystem Harness plays in. And so, Harness is a continuous delivery as a service company. So, what that means, all of the confidence-building steps that you need to get software into production, such as approvals, test orchestration, Harness, how to do that with lots of convention, and as a service.Emily: So, when you start your day, walk me through what you're actually doing on a typical day?Ravi: a typical day—dude, I wish there was a typical day because we wear so many hats as a start-up here, but kind of a typical day for me and a typical day for my team, I ended up reading a lot. I probably read about two hours a day, at least during the business day. Now, for some people that might not be a lot, but for me, that's a lot. So, I'll usually catch up with a lot of technology news and news in general. They kind of see how certain things are playing out. So, a big fan of The New Stack big fan of InfoQ. I also like reading Hacker News for more emotional reading. The big orange angry site, I call Hacker News. And then really just interacting with the community and teams at large. So, I'm the person I used to make fun of, you know, quote-unquote, “thought leader.” I used to not understand what they do, then I became one that was like, “Oh, boy.” [laughs]. And so just providing guidance for some of our field teams, some of the marketing teams around the cloud-native ecosystem, what I'm seeing, what I'm hearing, my opinion on it. And that's pretty much it. And I get to do fun stuff like this, talking on podcasts, always excited to talk to folks and talk to the public. And then kind of just a mix of, say, making some sort of demos, or writing scaffolding code, just exploring new technologies. I'm pretty fortunate in my day to day activities.Emily: And tell me a little bit more about marrying people with software. Are you the matchmaker? Are you the priest, what role?Ravi: I can play all parts of the marrying lifecycle. Sometimes I'm the groom, sometimes I'm the priest. But I'm really helping folks make technical decisions. So, it's go a joke because I get the opportunity to take a look at a wide swath of technology. And so just helping folks make technical decisions. Oh, is this new technology hot? Does this technology make sense? Does this project fatality? What do you think? I just play, kind of, masters of ceremony on folks who are making technology decisions.Emily: What are some common decisions that you help people with, and common questions that they have?Ravi: Lot of times it comes around common questions about technology. It's always finding rationale. Why are you leveraging a certain piece of technology? The ‘why' question is always important. Let's say that you're a forward-thinking engineer or a forward-thinking technology leader. They also read a lot, and so if they come across, let's say a new hot technology, or if they're on Twitter, seeing, yeah, this particular project's getting a lot of retweets, or they go in GitHub and see oh, this project has little stars, or forks. What does that mean? So, part of my role when talking to people is actually to kind of help slow that roll down, saying, “Hey, what's the business rationale behind you making a change? Why do you actually want to go about leveraging a certain, let's say, technology?” I'm just taking more of a generic approach, saying, “Hey, what's the shiny penny today might not be the shiny penny tomorrow.” And also just providing some sort of guidance like, “Hey, let's take a look at project vitality. Let's take a look at some other metrics that projects have, like defect close ratio—you know, how often it's updates happening, what's your security posture?” And so just walking through a more, I would say the non-fun tasks or non-functional tasks, and also looking about how to operationalize something like, “Hey, given you want to make sure you're maintaining innovation, and making sure that you're maintaining business controls, what are some best operational practices?” You know, want to go for gold, or don't boil the ocean, it's helping people make decisive decisions.Emily: What do you see as sort of the common threads that connect to the conversations that you have?Ravi: Yeah, so I think a lot of the common threads are usually like people say, “Oh, we have to have it. We're going to fall behind if you don't use XYZ technology.” And when you really start getting to talking to them, it's like, let's try to line up some sort of technical debt or business problem that you have, and how about are you going to solve these particular technical challenges? It's something that, of the space I play into, which is ironic, it's the double-edged sword, I call it ‘chasing conference tech.' So, sometimes people see a really hot project, if my team implements this, I can go speak at a conference about a certain piece of technology. And it's like, eh, is that a really rational reason? Maybe. It kind of goes into taking the conversation slightly somewhere else. One of the biggest challenges I think, let's say if you're kind of climbing the engineering ranks—and this is something that I had to do as I went from a junior to a staff to a principal engineer in my roles—with that it's always having some sort of portfolio. So, if you speak at a conference, you have a portfolio, people can Google your name, funny pictures of you are not the only things that come up, but some sort of technical knowledge, and sometimes that's what people are chasing. So, it's really trying to have to balance that emotional decision with what's best for the firm, what's best for you, and just what's best for the team.Emily: That's actually a really interesting question is sometimes what's best for the individual engineer is not what's best for the organization. And when I say individual engineer, maybe it's not one individual, but five, or the team. How do you sort of help piece together and help people understand here's the business reason, that's organization-wide, but here's my personal motivation, and how do I reconcile these, and is there a way even to get both?Ravi: There actually is a way to get both. I call it the 75/25 percent rule. And let's take all the experience away from the engineers, to start with a blank slate. It has to do with the organization. An organization needs to set up engineers to be successful in being innovative. And so if we take the timeline or the scale all the way back to hiring, so when I like to hire folks, I always like to look at—my ratio is a little bit different than 75/25. I'm more of a 50/50. You bring 50 percent of the skills, and you'll learn 50 percent of the skills, versus more conservative organizations would say, “You know what? You have 75 percent of the skills, if you can learn 25 percent of the skills, this job would be interesting to you.” Versus if you have to learn 80 percent, it's going to be frustrating for the individual. And so having that kind of leeway to make decisions, and also knowing that technical change can take a lot of time, I think, as an engineer, as an engineer—as talking software engineering professions as a whole, how do you build your value? So, your value is usually calculated in two parts. It's calculated in your business domain experience and your technical skills. And so when you go project to project—and this is what might be more of, hey, if you're facing too big of a climb, you'll usually change roles. Nobody is in their position for a decade. Gone are the days that you're a lifetime engineer on one project or one product. It's kind of a given that you'll change around that because you're building your repertoire in two places: you're building domain experience, and you're building technical experience. And so knowing when to pick your battles, as cliche as that sounds, oh, you know what, this particular technology, this shiny penny came out. I seen a lot of it when Kubernetes came out, like, “Oh, we have to have it.” But—or even a lot of the cloud-native and container-based and all the ‘et cetera accessories' as I call it, as those projects get steam surrounding it. It's, “We have to have it.” It's like, eh. It's good for resume building, but there's your things to do on your own also to learn it. I think we live in a day of open source. And so as an engineer, if I want to learn a new skill, I don't necessarily have to wait for my organization to implement it. I could go and play, something like Katacoda, I can go do things on my own, I can learn and then say, “You know what, this is a good fit. I can make a bigger play to help implement it in the organization than just me wanting to learn it.” Because a lot of the learning is free these days, which I think it's amazing. I know that was a long-winded answer. But I think you can kind of quench the thirst of knowledge with playing it on your own, and that if it makes sense, you can make a much better case to the business or to technology leadership to make change.Emily: And what do you think the core business motivations are for most of the organizations that you end up talking to?Ravi: Yeah, [unintelligible] core motivation to leveraging cloud-native technology, it really depends on organization to organization. I'm pretty fortunate that I get to span, I think, a wide swath of organization—so from startups to pretty established enterprises—I kind of talk about the pretty established enterprises. A lot of the business justification, it might not be a technical justification, but there's a pseudo technical business reason, a lot of times, though, I when I talk to folks, they're big concern is portability. And so, like, hey, if you take a look at the dollar and cents rationale behind certain things, the big play there is portability. So, if you're leveraging—we can get into the definition of what cloud-native resources are, but a big draw to that is being portable—and so, hopefully, you're not tied down to a single provider, or single purveyor, and you have the ability to move. Now, that also ties into agility. Supposedly, if you're able to use ubiquitous hardware or semi-ubiquitous software, you were able to move a little bit faster. But again, what I usually see is folk's main concern is portability. And then also with that is [unintelligible] up against scale. And so as—looking at ways of reducing resources, if you could use generics, you're able to shop around a little bit better, either internally or externally, and help provide scale for a softer or lesser cost.Emily: And how frequently do you think the engineers that you talked to are aware of those core business motivations?Ravi: Hmm, it really depends on—I'm always giving you the ‘depends' answer because talking to a wide swath of folks—where I see there's more emotion involved in a good way if there's closer alignment to the business—which is something hard to do. I think it is slowly eroding and chipping away. I've definitely seen this during my career. It's the old stodgy business first technology argument, right. Like, modern teams, they're very well [unintelligible] together. So, it's not a us versus them or cat versus dog argument, “Oh, why do these engineers want to take their sweet time?” versus, “Why does the business want us to act so fast?” So, having the engineers empowered to make decisions, and have them looked at instead of being a cost center, as the center of innovation is fairly key. And so having that type of rationale, like, hey, allowing the engineers to give input into feature development, even requirement development is something I've seen changed throughout my career. It used to be a very special thing to do requirements building, versus most of the projects that I've worked on now—as an engineer, we're very, very well attuned to the requirements with the business.Emily: Do you think there's anything that gets lost in translation?Ravi: Oh, absolutely. As people, we're emotional. And so if we're all sum total of our experiences—so let's say if someone asked, Emily, you and I a question, we would probably have four different answers for that person, just because maybe we have differences in opinions, differences of sum totals of experience. And I might say, “Hey, try this or this,” and then you might say, “Try that or that.” So, it really depends. Being lost in translation is always—it's been a fundamental problem in requirements gathering and it's continued to be a fundamental problem. I think just taking that question a step further, is how you go about combating that? I think having very shortened feedback cycles are very important. So, if you have to make any sort of adjustments, gone are the days I think when I started my career, waterfall was becoming unpopular, but the first project or two I was on was very waterfall-ish just because of the size of the project we worked on, we had to agree on lots of things; we were building something for six months. Versus, if you look at today, modern development methodologies like Agile, or Scaled Agile, a lot of the feedback happens pretty regularly, which can be exhausting, but decisions are made all the time.Emily: Do you think in addition to mistranslations, do you think there are any misconceptions? And I'm talking about sort of on both sides of this equation, you know, business leaders or business motivations, and then also technologists, and let's refocus back to talk about cloud-native in particular. What sort of misconceptions do you think are sort of floating out there about cloud-native and what it means?Ravi: Yeah, so what cloud-native means—it means something different to everybody. So, you listen to your podcasts for a couple episodes, if you asked any one of the guests the question, we all would give you a different answer. So, in my definition of cloud-native—and then I'll get back to what some of the misconceptions are—I have a very basic definition: cloud-native means two pillars. It means your architecture, or your platform needs to be ephemeral, and it needs to be [indibited]. So, it needs to be able to be short-lived, and be consistent, which are two things that are at odds with each other. But if you kind of talk to folks that, hey, they might be a little more slighted towards the business, they have this idea that cloud-native will solve all your problems. So, it reminds me a lot of big data back in the day. “Oh, if you have a Hadoop cluster, it will solve all of our logistics and shipping problems.” No. That's the technology. If you have Kubernetes, it will solve all of our problems. No. That's the technology. It's just a conduit of helping you make changes. And so just making sure that understand that hey, cloud-native doesn't mean that you get the checkmark that, “Oh, you know what? We're stable. We're robust. We can scale by using all cloud-native technologies,” because cloud-native technologies are actually quite complicated. If you're introducing a lot of complexity to your architecture, does it make sense? Does that make sense? Does it give you the value you're looking for? Because at the end of the day, and this is kind of something, the older I get, the more I believe it, is that your customers don't care how you did something; they care what the result is. So, if your web application's up, they don't care if you're running a simple LAMP stack, they just care that the application is up, versus using the latest Kubernetes stack, but using some sort of cloud-native NoSQL database, and we're using [Istio], and we're using, pick your flavor du jour of cloud-native technology, your end customer actually doesn't care how you did it. They care what happened.Emily: We can talk about misconceptions that other people have, but is there anything that continues to surprise you?Ravi: Yeah, I think the biggest misconception is that there's very limited choice. And so I'll play devil's advocate, I think the CNCF, the Cloud Native Computing Foundation, there's lots of projects, I've seen the CNCF, they have something called the CNCF Landscape, and I seen it grow from 200 cards, it was 1200 cards at KubeCon, I guess, end of last year in San Diego, and it's hovering around 1500 cards. So, these cards means there's projects or vendors that play in this space. Having that much choice—this is usually surprising to people because they—if you're thinking of cloud-native, it's like saying Kleenex today, and you think of Kubernetes or other auxiliary product or project that surrounds that. And a lot of misconception would be it's helping solve for complexity. It's the quintessential computer science argument. All you do in computer science is move complexity around like an abacus. We move it left to right. We're just shifting it around, and so by leveraging certain technologies there's a lot of complication, a lot of burden that's brought in. For example, if you want to leverage, let's say, a service Istio, Istio will not solve all your networking problems. In fact, it's going to introduce a whole set of problems. And I could talk about my biggest outage, and one of the things I see with cloud-native is a lot of skills are getting shifted left because you're codifying areas that were not codified before. But that's something I would love to talk about.Emily: Tell me about your biggest outage that sounds interesting.Ravi: Yeah, I didn't know how it would manifest itself. It's ways, I think, until, like, years later that I didn't have the aha moment. I used to think it was me, it probably still is me, but—so the year was 2013, and I was working for a client, and we were—it's actually a large news site—and so we were in the midst of modernizing their application, or their streaming application. And so I was one of the first applications to actually go to AWS. And so my background is in Java, so I have a Java software engineer or J2ED or JEE engineer, and having to start working more in infrastructure was kind of a new thing, so I was very fortunate up until 2013-ish up until this point that I didn't really touch the infrastructure. I was immune to that. And now being more, kind of becoming a more senior engineer was in charge of the infrastructure for the application—which is kind of odd—but what ended up happening that—this is going to be kind of funny—since I was one of the first teams to go to AWS, the networking team wouldn't touch the configurations. So, when we were testing things, and [unintelligible] environments, we had our VPC CIDR rules—so the traffic rules—wide open. And then as we were going into production, there were rules that we had to limit traffic due to a CIDR so up until 2013, I thought a C-I-D-R like a CIDR was something you drink. I was like, “What? Like apple cider?” So, this shows you how much I know. So, basically, I had to configure the VPC or Virtual Private Cloud networking rules. Finally, when we deployed the application, unknowing to myself, CIDR calculation is a significant digit calculation. So, the larger the number you divide by, the more IPs you let in. And so instead of dividing by 16, I divided by 8. I was like, “Oh, you'll have a bigger number if you divide by a smaller number.” I end up cutting off half the traffic of the internet when we deployed to production. So, that was a very not smooth way of doing something. But how did this manifest itself? So, the experts, who would have been the networking team, refused to look at my configuration because it was a public cloud. “Nope, you don't have a slot in our data center, we look at it.” And poor me, as a JEE or J2EE engineer, I had very little experience networking. Now, if you fast forward to what this means today, a lot of the cloud-native stack, are again, slicing and dicing these CNCF cards, a lot of this, you're exposing different, let's say verticals or dimensions to engineers that they haven't really seen before. A lot of its networking related a lot of it can be storage related. And so, as a software engineer, these are verticals that I'd never had to deal with before. Now, it's kind of ironic that in 2020, hey, yes, you will be dealing with certain configurations because, hey, it's code. So, it's shifting the burden left towards the developer that, “Oh, you know what, you know networking—” or, “You do need to know your app, so here's some Istio rules that you need to include in your packaging of your application.” Which folks might scratch your head. So, yeah, again, it's like shifting complexity away from folks that have traditional expertise towards the developer. Now, times are changing. I seen a lot of this in years gone by, “Oh, no. These are pieces of code. We don't want to touch it.” Being more traditional or legacy operations team, versus today, everybody—it's kind of the merging of the two worlds. The going joke is all developers are becoming infrastructure engineers, and infrastructure engineers are becoming software engineers. So, it's the perfect blend of two worlds coming together.Emily: That's interesting. And I now think I understand what you mean by skills shifting left. Developers have to know more, and more, and more. But I'm also curious, there's also people who talk about how Kubernetes, one of its failures is that it forces this shift left of skills and that the ideal world is that developers don't need to interact with it at all. That's just a platform team. What do you think about that?Ravi: These are awesome questions. These are things I'm very passionate about. I definitely seen the evolution. So, I've been pretty fortunate that I was jumping on the application infrastructure shift around 2014, 2015, so right when Kubernetes was coming of age. So, most of my background was in distributed systems. So, I'm making very large distributed Java applications. And so when Kubernetes came out, the teams that I worked on, the applications that were deployed to Kubernetes were actually owned by the app dev team. The infrastructure team wouldn't even touch the Kubernetes cluster. It was like, “Oh, this is a development tool. This is not a platform tool.” The platform teams that I were interacting with 2015, 2016, as Kubernetes became more popular than ever, they were the legacy—well, hate to say legacy because it's kind of my background too—they were the remaining middleware engineers. We maintained a web server cluster, we maintained the message broker cluster, we maintained XYZ distributed Java infrastructure cluster. And so when looking at a tool like Kubernetes, or even there were different platforming services, so the paths I've leveraged early, or mid-2010s was Red Hat OpenShift, before and after the Kubernetes migration inside of OpenShift. And so looking at a different—how teams are set up, it used to be, “Oh, this is an app dev item. This is what houses your application.” Versus today, because the workloads are so critical that are going on to say platforms such as Kubernetes, it was that you really need that system engineering bubble of expertise. You really need those platform engineers to understand how to best scale, how to best purvey, and maintain a platform like Kubernetes. Also, one of the odd things are—going back to your point, Emily, like, hey, why things were tossed over either to the development team or going back to a developing software engineer myself, do we care what the end system is?So, it used to be, I'll talk about Java-land here for a minute, give you kind of long-winded answer of back in Java land, we really used to care about the target system, not necessarily for an application that have one node, but if we had to develop a clustered application. So, we have more than one node talking to each other, or a stateful application, we really had start developing to a specific target system. Okay, I know how JBoss WildFly clusters or I know how IBM WebSphere or WebLogic clusters. And so when we're designing our applications, we had to make sure that we play well into those clustering mechanisms. With Kubernetes, since it's generic, you don't necessarily have to play into those clustering mechanisms because there's a basic understanding. But that's been the biggest Achilles heel in Kubernetes. It wasn't designed for those type of workloads, stateful workloads that don't like dying very often. That's kind of been the push or pull. It's just a tool, there's a lot of generic, so you can assume that the target platform will handle a certain way. And you're slowly start backing off the case that you're building to a specific target platform. But as Kubernetes has evolved, especially with the operator framework, you actually are starting to build to Kubernetes in 2018, 2019, 2020.Emily: It actually brought up a question for me that, at risk of sounding naive myself, I feel like I never meet anybody who introduces themselves as a platform engineer. I meet all these developers, everyone's a developer evangelist, for example, or their background is as a developer, I feel like maybe once or twice, someone has introduced themselves as, “I'm a platform engineer,” or, “I'm an operations specialist.” I mean, is that just me? Is that a real thing?Ravi: They're very real jobs. I think… it's like saying DevOps engineer, it means something else to who you talk to you. So, I'll harp on, like ‘platform engineer.' so kind of like, the evolution of the platform engineer, if you would have talked to me in 2013, 2014, “Hey, I'm a platform engineer,” I would think that you're a software engineer focused on platform tools. Like, “Hey, I focus on authentication, authorization.” You're building—let's say we had a dozen people on this call and we're working for Acme Incorporated, there's modules that transcend every one of our teams. Let's say logging, or let's say login, or let's say, some sort of look and feel. So, the platform engineer or the platform engineering development focused platform engineering team would make common reusable modules throughout. Now, with the great rise of platforms as a service, like PCF, and OpenShift, and DCOS, they became kind of like a shift. The middleware engineers that were maintaining the message broker clusters, maintaining your web application server clusters, they're kind of shifting towards one of those platforms. Even today, Kubernetes, pick your provider du jour of Kubernetes. And so those are where the platform engineers are today. “Hey, I'm a platform engineer. I focus on OpenShift and Kubernetes.” Usually, they're very vertically focused on one or more specific platforms. And operations folks can ride very big gamut. Usually, if you put, “operations” in quotes, usually they're systems or infrastructure engineers that are very focused on the infrastructure where the platform's run.Emily: I'm obviously a words person, and it just seems like there's this vocabulary issue where everybody knows what a developer is, and so it's easy to say, “Oh, I'm a developer.” But then everything else that's related to engineering, there's not quite as much specificity, precisely because you said everybody has a slightly different understanding. It's kind of interesting.Ravi: Yeah, it's like, I think as a engineer, we're not one for titles. So, I think a engineer is a engineer. I think if you asked most engineers, it's like, “Yeah, I'm a engineer.” It's so funny, a good example of that is Tim Berners-Lee, the person who created WWW, the World Wide Web. If you looked at his LinkedIn, he just says he's a web developer. And he invented WWW. So, usually engineering-level folks, you're not—at least for myself—is not one for title.Emily: The example that you gave regarding the biggest outage of your career was basically a skills problem. Do you think that there's still a skills or knowledge issue in the cloud-native world?Ravi: Oh, absolutely. We work for incentivization. You know, my mortgage is with PNC, and they require a payment every month, unfortunately. So, I do work for an employer. Incentivization is key. So, kind of resume chasing, conference chasing there's been some of that in the cloud-native world, but what ends up happening more often than not is that we're continuously shifting left. A talk I like to give is called, “The Engineering Burden is on the Rise.” And taking a look at what, let's say, a software engineer was required to do in 2010 versus what a software engineer is required to do today in 2020. And there's a lot more burden in infrastructure that, as a software engineer you didn't have to deal with. Now, this has to do with two things, or actually one particular movement. There's a movie company, or a video company in Los Gatos, California, and there's a book company in South Lake Union in Seattle. And so these two particular companies given the rise of what's called a full lifecycle developer. Basically, if you run it, or if you operate—you operate what you run, or if you write it, you run it. So, that means that if you write a piece of code, you're in charge of the operations. You have support, you're in charge of the SLAs, SLOs, SLIs. You're ultimately responsible if a customer has a problem. And can you imagine the number of people, the amount of skill set that requires? There's this concept of a T-shaped skill that you have to have experience in so many different platforms, that it becomes a very big burden. As an engineer, I don't envy anybody entering a team that's leveraging a lot of cloud-native technology because most likely a lot of that onus will fall on the software engineer to create the deployable, to create how you build it, to fly [unintelligible] in your CI stack, write the configuration that builds it, write the configuration deploys it, write the networking rules, write how you test it, write the login interceptors. So, there's a lot going on.Emily: Is there anything else that you want to add about your experience with cloud-native that I haven't really thought to ask, yet?Ravi: It's not all doom and gloom. I'm very positive on cloud-native technologies. I think it's a great equalizer. You're kind of going back—this might be a more intrinsic, like a 30-second answer here. If you taking back that I wanted to learn certain skills in 2010, I basically had to be working for a firm. So, 2010, I was working for IBM. So, there's certain distributed Java problems I wanted to solve. I basically had to be working for a firm because the software licensing costs were so expensive, and that technology wasn't very democratized. Looking at cloud-native technology today, there's a big, big push for open source, which open source is R&D methodology. That's what open source is, it helps alleviate some sort of acquisition—but not necessarily adoption—problems. And you can learn a lot. Hey, you could pick up any project and just try to learn, try to run it. Pick up these particular distributed system skills that were very guarded, I would say, a decade ago, it's being opened up to the masses. And so there's a lot to drink from, but you can drink as much as you want from the CNCF or the cloud-native garden hose.Emily: Do you have a software engineering tool that you cannot live without?Ravi: Recently, because I deal in a lot of YAML, I need a YAML linter. So, YAML is a space-separated language. As a human, I can't tell you what spaces are. Like, you know, if you have three spaces, and the next line you have four spaces. So, I use a YAML linter. It puts periods for me, so I can count them because it's been multiple times that my demo is not syntactically correct because I missed a space and I can't see it on my screen.Emily: And how can listeners connect with you?Ravi: Oh, yeah. You can hit me up on Twitter @ravilach, R-A-V-I-L-A-C-H. Or come visit us at Harness at www.harness.io. I run the Harness community, so community.harness.io. We have a Slack channel and a Discourse, and always excited to interact with people.Emily: Thanks for listening. I hope you've learned just a little bit more about the business of cloud-native. If you'd like to connect with me or learn more about my positioning services, look me up on LinkedIn: I'm Emily Omier, that's O-M-I-E-R, or visit my website which is emilyomier.com. Thank you, and until next time.Announcer: This has been a HumblePod production. Stay humble.

This conversation covers: How Frame.io was faced with the decision to be cloud native or cloud-enabled — and the business and technical reasons why Frame.io chose to be cloud native.  How Abhinav successfully built a world class cloud-native security program from the ground up to protect Frame.io users' sensitive video content. Abhinav also talks about the special security considerations for truly cloud native applications.  Cloud native as a “journey without a destination.” In other words, there is no end point with cloud native transitions, because new technologies are always being developed. Why Abhinav is a firm believer in both ISEs and GitOps, and why he thinks the industry should embrace both of these strategies. The challenge of not only maintaining security in this type of environment, but also communicating security issues to various stakeholders with different priorities. Abinhav also talks about the role that specialists like AWS and machine learning experts can play in furthering security agendas. Common misconceptions about cloud native security. Frame.io's decision to roll out Kubernetes, and why they are also considering adding chaos engineering to fortify against unexpected issues. Tool and vendor overload, and the importance of trying to find the right tools that fit your infrastructure.  Links: Frame.io: https://frame.io/ Connect with Abhinav on LinkedIn: https://www.linkedin.com/in/absri/ The Business of Cloud Native: http://thebusinessofcloudnative.com  TranscriptAnnouncer: Welcome to The Business of Cloud Native podcast where we explore how end users talk and think about the transition to Kubernetes and cloud-native architectures.Emily: Welcome to The Business of Cloud Native. I'm Emily Omier, your host, and today I am chatting with Abhinav Srivastava. Abhinav, can you go ahead and introduce yourself and tell us about where you work, and what you do.Abhinav: Thanks for having me, Emily. Hello, everyone. My name is Avinash Srivastava. I'm a VP and the head of information security and infrastructure at Frame.io. At Frame, I am building the security and infrastructure programs from ground up, making sure that we are secured and compliant, and our services are available and reliable. Before joining Frame.io, I spent a number of years in AT&T Research. There I worked on various cloud and security technologies, wrote numerous research papers, and filed patents. And before joining AT&T, I spent five great years in Georgia Tech on a Ph.D. in computer science. My dissertation was on cloud and virtualization security.Emily: And what do you do? What does an average day look like?Abhinav: Right. So, just to tell you where I answer the question where I work: so I work at Frame.io, and Frame.io is a cloud-based video review and collaboration startup that allows users to securely upload their video contents to our platform, and then invite teams and clients to collaborate on those uploaded assets. We are essentially building the video cloud, so you can think of us as a GitHub for videos. What I do when I get to office—apart from getting my morning coffee—as soon as I arrive at my desk, I check my calendar to see how's my day looking; I check my emails and slack messages. We use slack primarily within the company doing for communication. And then I do my daily standup with my teams. We follow a two-week sprint across all departments that I oversee. So, a standup gives me a good picture on the current priorities and any blockers.Emily: Tell me a little bit about the cloud-native journey at Frame.io? How did the company get started with containers, and what are you using to orchestrate now? How have you moved along in the cloud-native journey?Abhinav: We are born in the cloud, kind of, company. So, we are hosted in Amazon AWS since day one. So, we are in the cloud from the get-go. And once you are in the cloud, it is hard not to use tools and technologies that are offered, because our goal has always been to build secure, reliable, and available infrastructure. So, we were very, very mindful from the get-go that while we are in the cloud, we can choose to be cloud-native or just cloud-enabled. Means use tools, just virtual machines, or heavyweight virtual machines, and not to use container and just host our entire workload within that. But we chose to be cloud-native because, again, they wanted to boot up or spin up new containers very fast. As a platform we, as I mentioned, we allow users to upload videos, and once the videos are uploaded, we have to transcode those videos to generate different low-resolution videos. And that use case fits with the lightweight container model. So, from the get-go, we started using containerized microservices; orchestration layer; From AWS, their auto-scaling; automation infrastructure as a code; monitoring. so all those things were, kind of, no brainer for us to use because given our use case and given the way we wanted to be a very fast uploader and transcoder for all of our customers.Emily: This actually leads me to another question: have you guys seen a lot of scaling recently as a result of stay-at-home orders and work from home?Abhinav: Right. So, we are seeing a lot more people moving towards remote collaboration tools who are actually working in the production house since they have to work from home now. So, they are now moving to these kind of tools such as Frame.io. And we do see a lot more customers joining our platform because of that. From the traffic perspective, we did not see much increase in the web traffic or load our infrastructure, because we have always set up the auto-scaling and our infrastructure can always meet these peak demands. So, we didn't see any adverse effect on our infrastructure from these remote situations.Emily: What were some of the other advantages? Like you were talking about that you had the choice to be either cloud-enabled or truly cloud-native? What were the biggest, you know—and I'm interested, obviously in business rationale to the extent you can talk about it—for being truly cloud-native?Abhinav: So, from business perspective, again, a goal was to [basic] secure available and reliable production infrastructure to offer Frame.io services. But cloud-native actually helped us to faster time to market because our developers are just focusing on the business logic, deploying code. They were not worried about the infrastructure aspect, which is good. Then we're rolling out bug fixes very quickly through CI/CD platform, so that, again, we offer the better [good] services to our customer. Cloud-native helped us to meet our SLA and uptime so that our customer can access their content whenever they would like to. It also helped us securing our infrastructure and services, and our cost also went down because we were scaling up and down based on the peak demand, and we don't have to provide dedicated resources, so that's good there. And it also allowed us to faster onboard developers to our platform because we are using a lot of open source technologies, and so the developers can learn quickly—there are a lot more resources out there for them to learn. And it also helped us avoid vendor lock-in. We are relying on more and more open-source projects, CNCF [unintelligible] projects, so that has helped us. And more importantly, it is helping us stay competitive because in this industry—in this time—we would like to be available, we would like to be secure. So, for our customers to stay doing their job that they used to do in an office setting or in a non-remote setting, and we can continue providing help that they need.Emily: How has this changed the security story?Abhinav: So, obviously, security story is same what we have before because, I mean, we allow people to have upload their media content to our platform. So, that's very sensitive content. So, we always wanted to make sure that they stay secure. And for that, we have built a world-class security program from ground up, with emphasis on product security, cloud security, security data science, and also compliance and privacy program. So, we are doing what we used to do: making sure that content is still secure, our infrastructure follows the AWS security best practices, we can identify vulnerability within our application and fix it. So, again, as I said, that it hasn't changed much from security perspective, as far as Frame.io's daily operations are concerned.Emily: How does having a truly cloud-native application, how is that different from a security perspective from something that isn't cloud-native?Abhinav: So, security is very important whether you are cloud-enabled or cloud-native. So, security is very important for all the services. Being in the world of microservices and in the container, actually, it helped us to model the application behavior. For example, if you have one very big monolithic application, it does so many things, so it's really hard for you to know to find out what's the normal execution pattern. And when this application is going to—if it attacked, how it's going to behave, how is abnormal execution look like? But in the microservices world, since each application, each microservices is getting one job. So, you can create a good model of behavior of that container. Or even if you are monitoring their runtime behavior, you know that what kind of processes are going to be invoked from that container? What kind of network connections are going to be made? What are the files are going to be accessed by the services within the host, or within S3, or other resources? So, you know their interaction pattern—execution pattern, and that, you can qualify, both in terms of your security rules that you want to create on the infrastructure for those services, or you can create a better anomaly detection or machine learning models for those behavior. And we did both in our infrastructure to keep them secure.Emily: And how do conversations about security go when you talk with different stakeholders. I'm curious to know if there's any sort of miscommunications, or things that are lost in translation when you're talking about security with, say, the development team; with the business stakeholders; with platform engineers. What are some of the things—anything that gets lost in translation?Abhinav: So, there are two parts of this question. In general, having a discussion around cloud-native services and the security of cloud-native services. Because there are various ways you can deploy a service in the cloud, you can have a service deployed in the cloud just by running a bunch of VMs, or you can deploy it using cloud-native architecture where you have doing all those things. But the cloud-native architecture requires you to think of all the stages of the services. For example, how will SLAs, SLOs, SLIs look like for this service? Or, how do you monitor the service when it execute? How will you protect these services when you deploy them? What kind of resources are going to be accessed by this service? How will create their identity and management rules there? How would you deploy it and how would you create network rules for that so that you can do it in a principle of least privileged fashion, you can execute these services?So, you need to do proper planning that how would a new service going to interact with other services in the infrastructure. And these non-functional requirements are, many times, described poorly or not written at all because as a developer, you would like to create service and deploy service, and so that customer can use it. And these are the things behind the scenes we have to think about it. And we, as a team are working very actively to bridge this knowledge and semantic gap so that these things don't get lost in the translation when you're thinking about the service.Emily: What about when you talk to say, business stakeholders? Is there anything that gets lost in the translation?Abhinav: So, I mean, in the business sense, we always have to keep the discussion at a very high level. That, what's a use of service? Or, where we should deploy? Who are going to be the users? So, at that time, we don't want to talk about those underlying infrastructure-related issues because at the business level, we would like to know that how the service is going to function, and mostly functional requirements. But at the low level, we would like to think about that when we are about design these services, what are the things we have to worry about in order for that service to deploy securely and reliably?Emily: How important is security to Frame.io? Not every company thinks the same about security, I should say.Abhinav: And that's a great question. I think for us, security is very important. I know every company says that, but I think we truly mean that. So, we are close to 150 employees, but I was hired around when I was a [00:12:31 unintelligible] employee as a head of security. So, that shows that we care about security. And I have been building security from ground up. We got our SOC 2 Type II compliance when we was around 70 employees. And there are companies out there who are doing SOC 2, and they are thousand employees. So, we are GDPR compliant; we are working towards our CCPA compliance, and we are TPN compliant as well. TPN stand for Trusted Partner Network, which is the [same world] media, and entertainment companies, and industry users. And we were the first few companies who got that certification, also. So, we care about security very much because we allow users to upload their contents in our cloud and we make sure that those contents remain secure.Emily: And so, is there any tension that you feel between talking about security or making things as secure as possible, and either business stakeholders or other parts of the IT team?Abhinav: So, there is definitely attention. [laughs]. If I say no, then I would be lying because our goal—engineers or developers or service creators, they want to deploy the service. They will get satisfaction once the customer start using those services. And our job is to make sure to—we put some guardrails in place—or barriers in place so that we can vet the application, we can vet the service, we can do the proper testing, we can make sure that by deploying the service, we don't increase our exploitable surface. So, that kind of tension will always be there because, by nature, security's job is to make sure that whatever is deployed is secure. Our infrastructure is secure and the service owner's job is to deploy the service. But I think what we are trying to do in the organization, we are trying to take a risk-based approach because security is just another business function. The way sales is important, the way engineering is important, the same way that security is important. And there's a risk in this environment of not meeting sales targets, same way there's a risk of getting breached. So, how do we provide a risk-based methodology so that when we talk about security, we talk in terms of risk; we talk in terms of probabilities versus possibilities? Because there is always possibility of something going wrong, but what's the probability of something happening? And that basically gives us some way of talking to other business-holders saying that, “Okay, if you deploy the service the risk is high. But the risk is high because the likelihood of getting breached is high, but impact would be very low. So, since risk is the product of impact and likelihood, overall the risk is low.” But sometimes the risk is that chance of getting attacked is very low, but the impact could be very high. Again, you will have risk low because probability of actually happening that event is low. So, that basically gives us some common language we can use to talk to other business-holders because risk is being used as a language across other departments. We try to use the same language to convey cybersecurity risk as well.Emily: Since starting with Frame.io and building this security program from the ground up, what surprises have you encountered?Abhinav: I would say there were many surprises. First of all, I had those surprises because I come from a background from research and development. There, goal was to develop services, goal was to think about new security product, and goal was to think of attack and coming up with defenses for them. Having the responsibility of building the security program from ground up, or having to adjust this risk-based mentality was a big surprise because it's not that just because there is a bug, engineering is going to fix it. You have to show the impact of that bug. You should have a proper [unintelligible] associated with that. You have to show that what are the ways that bug can be launched. So, it means, just because you care about security, doesn't mean that everybody else cares about security. So, you have to keep the communication on. You have to always talking, you have to always adjusting, and you have to use the right language to the right person that you are talking to.Emily: What tips do you have about adjusting your language for different audiences and getting them to understand what you're talking about?Abhinav: So, one thing is to use risk-based methodology. That is saying that, “Oh, we have a bug, or we have a high priority bug.” I think saying that, “What is the impact of that bug? How would that bug be exploited in a real setting?” I think those things are important because people care about security, but then they have hundred other things to do, as well. So, how do you talk to their language? And also building the right team, as well. So, if you want to target product security, you have to have a product security specialist, who can understand these nuances; who can understand what are the different attacks. Some companies build a security team with many generalists. I took an approach where I'm building team with the specialists. So, for product security, I have two core product security engineers who have done this thing many times before. For cloud security, I have a specialist who knows about AWS Cloud and everything. For security data science, I have a machine learning expert. So, for each of those roles that you have mined, you try to fill the position with the right set of people. And coming back to this cloud-native security. I think one thing is very important in the cloud-native world, as I have realized lately, that infrastructure as a goal is very important piece for securing your cloud. It's not that I or the team don't know about it, but the temptation to do things quickly sometimes resorting to manual work instead of writing your Terraform or CloudFormation. So, you can do things quickly, but then the chances of you making error are also high. Because if you go to Terraform, you can follow the regular CI/CD process, you can have your pull request approved by somebody, and chances of finding a error quickly is high. And for security purposes, infrastructure code is a blessing. Because you can put proper guard rails in place to make sure that nobody does manual operation in the infrastructure, and everything goes through proper approval process, and that will—as a head of security if you know that if somebody wants to do anything or open any port in the infrastructure, two people are going to look at it and then they're going to have a dialogue with each other, and they're going to find out the real need for opening that port. Your life will be a lot simpler. Emily: What do you think are some misconceptions about cloud-native security, both inside the engineering department—so developers, for example—and then outside in the rest of the company?Abhinav: I think misconception that I view—and it's my opinion—is that the only thing that is important is deploying fast, or moving to production very fast. I think there are so many things has to be done behind the scene in order for you to move fast. And if you don't do those things, then it means that either you're going to break your application, or you're going to make your infrastructure insecure. So, for example, if you have a CI/CD set up and you want to deploy a business logic, and you think that, “Oh, I can code that thing in AWS Lambda functions.” AWS Lambda function is completely managed service. You went ahead and coded in Python, and your service is up and running. But now in doing so, what you did quickly that you forgot to follow the best practices that Lambda function has to be within the VPC; you need to generate an IAM role that has restricted permission; you have to make sure that proper security groups has to be attached to Lambda functions so that it is not open to www. And those things are part of misconception that, “Oh, if I have to do something, AWS allows that we can do it quickly.” That's what we are trying to do. We are trying to come up with a set of best practices for each of those resources as a team, writing documents, sharing with engineering that, “Okay, you want to do it? Sure, go ahead, do it, but just follow these best practices.” So, that even if you SAM or Terraform, whatever you want to use to deploy your application, make sure that best practices are always followed.Emily: Can you think of any misconceptions about cloud-native security that, say, somebody might have if they're coming from a legacy environment: managing security but in a very different type of environment.Abhinav: So, I mean, cloud-native security is all about making sure that your microservices are secure, the kind of access pattern they have, kind of network pattern they have. So, I think one misconception is that—you can think of misconception is, if you are coming from a monolithic world, where you have logged on your services, but just by assuming that you have a parameter between outside world and inside world, so your firewall rules are just like that between in and out. But that parameter is blurred now. There is no such thing as a “them versus us.” It's all blurred now. So, in the microservices world, instead of North/South traffic going up and down. You have to think about East/West traffic as well. So, making sure that your service communication are secure as well: you make sure you use proper cryptography, make sure your endpoints are authenticated so that your services are not compromised. Because if one service compromised, if you don't use proper control among those services, then your other services can be compromised very quickly. And that's the problem when we go from monolithic application to microservices.Emily: Do you think that people outside of the security team understand that distinction?Abhinav: I would say they do, to the extent that they know about it, but then when we have to actually implement it, there are always some concerns that it is going to slow down our application, it is going to introduce latency in the application. So, people do understand that okay parameter is going away, but to the extent that they know about it, but when you—again, when we start implementing it, there is always concern that how it's going to play out.Emily: Do you think Frame.io is fully cloud-native? Do you think there's anything that you could do to be more quote-unquote, “cloud native.”Abhinav: So, in my opinion, it is a journey without any destination. Just like security, you can never say, “I'm secure.” You will have to adjust your control based on the threats or attacks going on. In the same way, there is no end to transition to cloud-native because new technologies are coming, and we will have to evaluate new tools that can help us realize our business goals effectively. So, we are cloud-native, but still, we can do a lot more things, given time and resources. So, in some concrete world that we are doing right now, that we are creating more tools for developers to perform tasks themselves. So, creating more self-serve culture. As I said that moving towards more [IFC] model, and so on. And for that, we are setting up guardrails so that they can perform those operations within those boundaries without impacting security and reliability. We are also looking into ways to extend Kubernetes. Because Kubernetes is in itself a full cloud platform with a lot of possibilities. So, we are interested in making it more programmable for our environment. But these are ongoing things that we'll have to continue doing it.Emily: Do you have any other next steps that you could share? What's next in your journey?Abhinav: So, we rolled out Kubernetes in our infrastructure last December, and that move paid us off. So, we are building more tools on Kubernetes. As I said, that we are going towards more self-service style of architecture where developers can do a lot more things within those guardrails and we are also looking into ways to introduce chaos engineering in our environment because we do things fast, but we break things fast as well. [laughs]. So, one small configuration error can create severity zero alert. So, what we need is a good chaos engineering practices to simulate these areas, so that everybody can train on these events and know how to prevent and respond to such problems. That will reduce our incident resolution time as well.Emily: When—sort of last question: anything else that you would like to add?Abhinav: Two things, I think. One thing is we all should be going towards IFC and GitOps; infrastructure code and GitOps. If this is the one takeaway from this podcast, is that that's the way to go. I know manually doing work is tempting, but that creates problem down the road. So, life will be a lot simpler if we go with the IFC and GitOps. Second thing is that I feel this pain, and many other people are facing the same way, that there are too many tools and vendors out there. So, it's really hard to choose from what is going to work in your environment. CNCF is helping us by highlighting some of these projects by assigning proper maturity levels, like sandbox incubation, and graduated project, so on, but it still is very challenging to find the right tooling that fits your infrastructure. So, always make sure that when you choose a new technology, see how it's going to be working with your existing technologies because it's not that easy to throw away an existing thing because all these things that the tool that you try, it also complicates your security as well because you just do not know how it's going to play out when you deploy this new technology in your environment where the other tools and services are running. So, I think we have to evaluate all tools carefully to make sure that we understand its a security and reliability impact on our existing infrastructure.Emily: What is your can't live without engineering tool or security tool?Abhinav: Huh, that's a good question. Right now, one tool that I cannot live without is Falco. That is a runtime container monitoring solution. We invested a lot on it, and it is paying off in terms of the kind of alert it is generating, kind of visibility it is providing in our infrastructure. And one tool I can't leave off from both from security infrastructure perspective is Slack because we have done a lot of automation to bring all these alerts through Slack. So, all of our ops happen via Slack. So, I think these are the two tools I'm relying a lot in terms of visibility and in terms of response.Emily: Well, thank you so much for joining me.Announcer: Thank you for listening to The Business of Cloud Native podcast. Keep up with the latest on the podcast at thebusinessofcloudnative.com and subscribe on iTunes, Spotify, Google Podcasts, or wherever fine podcasts are distributed. We'll see you next time.This has been HumblePod production. Stay humble.