Podcasts about aws community builder

AWS Community Builder and Software/Platform Engineer Ervin Szilágyi joins us today to talk about his project: creating a BlueSky Bot (for good, not evil

An airhacks.fm conversation with Vadym Kazulkin (@VKazulkin) about: journey as a Java developer from the late 1990s to present, early experiences with Java and J2EE development, transition to cloud and serverless technologies, particularly AWS Lambda, discussion of Java performance on lambda compared to node.js, detailed explanation of AWS SnapStart technology for improving Java cold starts, pros and cons of "fat" Lambda functions versus microservices, challenges of using GraalVM with Lambda, importance of optimizing Lambda package size and dependencies, comparison of quarkus and Spring Boot on Lambda, benefits of serverless architecture for business logic focus, involvement with Java User Group Bonn and AWS Community Builder program, brief mention of asynchronous patterns in serverless architectures, importance of staying technically hands-on as a manager in the rapidly evolving cloud world Vadym Kazulkin on twitter: @VKazulkin

Grant Fritchey has over thirty years of experience in IT, specializing in development and database administration. He works for Red Gate Software as a Product Advocate and writes articles for SQL Server Central and Simple-Talk. He is the author of “SQL Server Execution Plans” and “SQL Server Query Performance Tuning.” He also co-authored “Query Store for SQL Server 2019,” “Expert Performance Indexing,” “SQL Server MVP Deep Dives 2,” “Beginning SQL Server 2012 Administration,” and “Pro SQL Server 2012 Practices.”   He presents at conferences and user groups worldwide and is available for part-time, short-term consulting contracts.Since 2009, he has been recognized as a Microsoft SQL Server MVP. He has received the AWS Community Builder award for the past five years. In 2014, he was honored as a Dunn & Bradstreet MVP, and in 2011, he received the Tech10 Award in Rhode Island.   Topics of Discussion: [:35] Introduction of Grant Fritchey and his career in IT and database administration. [3:23] Grant's journey from software development to becoming a DBA. [5:13] The importance of database selection and how different types of databases serve different needs. [11:27] Grant's view on the addition of document support to major database platforms. [13:29] Database hygiene basics and the importance of regular backups and restore practices. [19:26] The business side of database recovery and balancing cost with recovery objectives (RPO/RTO). [25:03] Grant's recommendations for testing database restores. [28:08] Automation in DevOps and the importance of human training in recovery processes. [31:53] Managing data warehouses and recovery strategies for large databases. [35:12] Resources for developers without dedicated DBAs to ensure good database hygiene.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.net. Clear Measure, Inc. (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's Twitter — Follow to stay informed about future events! SimpleTalk by Redgate ScaryDBA.com Grant Fritchey on X   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Send us a Text Message.Alex Perkins is a Senior Network Engineer at Presidio Federal, Co-Host of the Cables2Cloud Podcast, and AWS Community Builder. Alex has a wealth of experience architecting, automating, and securing data center fabrics and hybrid multi-cloud networks at scale. In this conversation, we discuss the latest “happenings” in Cybersecurity, AI/ML, Infrastructure, and Cloud.Where to find AlexPodcast: https://www.cables2clouds.com/LinkedIn: https://www.linkedin.com/in/alex-perkins/Blog: https://bumpsinthewire.com/X: https://x.com/bumpsinthewireFollow, Like, and Subscribe!Podcast: https://www.thecloudgambit.com/YouTube: https://www.youtube.com/@TheCloudGambitLinkedIn: https://www.linkedin.com/company/thecloudgambitTwitter: https://twitter.com/TheCloudGambitTikTok: https://www.tiktok.com/@thecloudgambitEpisode LinksCyber Attacks: https://www.bbc.com/news/articles/c2vwz4exq4xoCyber Incident Reporting: https://www.cio.com/article/2108541/what-cios-need-to-know-about-the-newly-proposed-critical-infrastructure-cyber-incident-reporting-rule.html?amp=1H raises $200M: https://techcrunch.com/2024/05/21/french-ai-startup-h-raises-220-million-seed-round/OpenAI Drama: https://techcrunch.com/2024/05/24/startups-weekly-drama-at-techstars-drama-in-ai-drama-everywhere/Cisco Nexus HyperFabric: https://www.cisco.com/site/us/en/products/networking/networking-cloud/data-center/nexus-hyperfabric/index.htmlCisco CCDE AI: https://blogs.cisco.com/learning/introducing-the-ccde-ai-infrastructure-certificationMidwest Data Center Boom: https://www.datacenterknowledge.com/industry-perspectives/move-improve-why-midwest-housing-more-data-centers

Chatting With Cloud Specialist With Over 10 Years Of Hands-On Experience With AWS, AWS Community Builder, Self-Published "The Practical AWS IAM Guide" And Co-Authored "The AWS Administration Cookbook." - Rowan Udell From Brisbane, Australia- Rowan Odell said about his work and answered some of my questions. more info at https://smartcherrysthoughts.com

Tools, workflows and the Terraform ecosystem - Masterpoint's Matt Gowie dives deep into the IaC tooling landscape, covering tools like Terragrunt and Atmos, linting with TFLint, security scanning, CI/CD workflows and more. From Terraform 0.11 to OpenTofu, static code analysis to encryption, gain an inside look at pragmatic IaC practices.Matt Gowie is a seasoned entrepreneur, cloud architect, and platform engineer based in Boulder, Colorado. As CEO and CTO of Masterpoint, he leads a team dedicated to developing top-tier infrastructure-as-code solutions for a diverse clientele. With over twelve years of experience in software development, tech startups, and cloud infrastructure, Matt has a deep passion for Terraform and OpenTofu. He actively contributes to the community as a core maintainer of one of the largest open-source Terraform Module libraries and an AWS Community Builder. Outside of work, you can find him rock climbing across the American West, training for an ultramarathon, or exploring remote corners of the globe.

En este episodio del podcast, descubrimos los secretos del mundo de la consultoría en la nube con Guille Ojeda, Arquitecto de Soluciones y AWS Community Builder. Exploraremos la aventura de trabajar por tu cuenta y desentrañaremos todas las vicisitudes a las que see enfrentan.Este es el episodio 4 de la 5ta temporada del Podcast de Charlas Técnicas de AWS.Tabla de Contenidos00:33 Conociendo a nuestro invitado02:10 Usando IA para escribir un libro?03:52 Metodología para escribir 3000 palabras al día05:10 El mundo de AWS desde el lado del consultor08:00 Evita las penalizaciones09:00 Entendiendo los requerimientos de cliente11:43 Statement of Work (SOW), el santo grial del consultor13:43 Ejemplo práctico, nuestra app NodeJS16:16 Pipeline de despliegue continuo17:52 Sistemas de monitorización18:44 Contenedores19:38 El proceso de Discovery y Comunicación21:59 La documentación23:10 Cuando falla la comunicación y documentación, llega CodeWhisperer!24:12 Cuando todo lo demás falla25:26 Te ven como un intruso26:16 Movamos a contenerizar nuestra app32:48 Pasos para dockerizar nuestra app NodeJS36:00 Infraestructura como Código (IaC), CDK39:47 La IA, ¿una amenaza o una herramienta productiva?43:46 La formación es clave46:00 Consideraciones finales.Redes Sociales del Invitado LinkedIN: https://www.linkedin.com/in/guilleojeda/Twitter: https://twitter.com/itsguilleojedaNewsletter invitado: https://www.simpleaws.dev/

Craig Johnson is a Technical Solutions Architect for Forward Networks, Group Leader for USNUA (TX)NUG, and AWS Community Builder. In this conversation, we discuss the power of community, and then we dig into the growth and adoption of Digital Twins and where they fit in today's tech stack.Where to find CraigLinkedIn: https://www.linkedin.com/in/captainpacket/Twitter: https://twitter.com/captainpacketTikTok: https://www.tiktok.com/@captainpacketFollow, Like, and Subscribe!Podcast: https://www.thecloudgambit.com/YouTube: https://www.youtube.com/@TheCloudGambitLinkedIn: https://www.linkedin.com/company/thecloudgambitTwitter: https://twitter.com/TheCloudGambitTikTok: https://www.tiktok.com/@thecloudgambit

Witam w kolejnym odcinku podcastu „People Guy w IT”, w którym rozmawiamy o tym jak odnieść sukces jako lider, menadżer, konsultant pamiętając o najważniejszym składniku każdego sukcesu - ludziach. Nazywam się Marek Drob i od ponad 12 lat zajmuje się zarządzaniem, budową oraz skalowaniem zespołów. W tym odcinku wspólnie z moim gościem - Przemkiem Malakiem, rozmawiamy o tym jak zadbać o rozwój zespołu jako Tech Leader, jakich cech szuka Przemek u “Juniorów” w zespole oraz jak być na czasie z technologią. Przemek Malak, Software Architect z ponad 20 letnim doświadczeniem, aktywny programista, Cloud Native Guru, AWS Community Builder, bloger oraz fan dzielenia się wiedzą ze społecznością. Jak myślę serverless to myślę Przemek, nie ma lepszej osoby która odpowie na pytanie “co nowego w AWS”

This year at AWS re:Invent we are going to interview conference attendees, AWS Heroes, and AWS employees. We're asking them what they are excited about at re:Invent and what they are working on! Lilian is a Enterprise Solutions Architect at Sargento Foods Join us to hear the answer to these questions from some of the top minds in the industry!!! Resources: https://www.linkedin.com/in/lilian-shulika-tata-phd/ Link to her book: https://a.co/d/9zDeP7w Intro music attribution: Artist - MaxKoMusic

This year at AWS re:Invent we are going to interview conference attendees, AWS Heroes, and AWS employees. We're asking them what they are excited about at re:Invent and what they are working on! Join us to hear the answer to these questions from some of the top minds in the industry!!! Resources: https://www.linkedin.com/in/giftedlane/ https://twitter.com/GiftedLane https://www.youtube.com/channel/UC_qpgVCE35WQ1_ga9Gy1FSg Intro music attribution: Artist - MaxKoMusic

In this captivating episode, join us as we welcome Lays Rodrigues, a Sr. Software Engineer at Stone Co. and an esteemed AWS Community Builder in Containers. Lays, set to speak at the AWS Community track at re:Invent 2023, shares her inspiring journey from her roots in the open source community and KDE background to becoming a prominent figure in the open source and cloud development communities in Brazil. Discover Lays' path to becoming a sought-after speaker, starting from her involvement in organizing DevOps Days Rio to her participation in the AWS Community Builders New Voices program. We delve into her experiences in the vibrant developer cloud community in Brazil and how these experiences have shaped her career and speaking endeavors. Lays also gives us a sneak peek into her upcoming talk at AWS re:Invent 2023 – COM102 – "Automate Away the Toil," where she will share insights on leveraging automation to enhance productivity and reduce mundane tasks. Beyond her technical expertise, Lays' story is one of staying motivated and realizing one's potential. Her journey is not just about technical growth but also about personal development and becoming an inspirational figure for developers worldwide. Lays on Twitter: https://twitter.com/lays147 Lays on LinkedIn: https://www.linkedin.com/in/laysrodrigues147 Dave on Twitter: twitter.com/thedavedev Dave on LinkedIn: www.linkedin.com/in/davidisbitski Find an AWS User Group: https://aws.amazon.com/developer/community/usergroups AWS Heroes: https://aws.amazon.com/developer/community/heroes AWS Community Builders: https://aws.amazon.com/developer/community/community-builders/ Subscribe: Spotify: https://open.spotify.com/show/7rQjgnBvuyr18K03tnEHBI Apple Podcasts: https://podcasts.apple.com/us/podcast/aws-developers-podcast/id1574162669 Stitcher: https://www.stitcher.com/show/1065378 Pandora: https://www.pandora.com/podcast/aws-developers-podcast/PC:1001065378 TuneIn: https://tunein.com/podcasts/Technology-Podcasts/AWS-Developers-Podcast-p1461814/ Amazon Music: https://music.amazon.com/podcasts/f8bf7630-2521-4b40-be90-c46a9222c159/aws-developers-podcast Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zb3VuZGNsb3VkLmNvbS91c2Vycy9zb3VuZGNsb3VkOnVzZXJzOjk5NDM2MzU0OS9zb3VuZHMucnNz RSS Feed: https://feeds.soundcloud.com/users/soundcloud:users:994363549/sounds.rss

O EventosCast é um podcast para os Apaixonados por Eventos, com apresentação de Marcely Souza Fundadora da MS Eventos, uma Consultoria de Eventos presenciais e online! Os convidados de hoje são Marcelo Paiva, que é CTO na Softprime, Microsoft MVP, AWS Community Builder, Community Leader e Deivid Veras que é Coordenador de Tecnologia da informação, com mais de 18 anos de experiência em implantar soluções de infraestrutura e gerir equipes, provendo otimização de recursos as empresas. Atuante como agente de mudanças, liderando implantação de soluções definidas estrategicamente junto a área de negócios. Faça parte da Comunidade do EventosCast, por lá você encontrará diversos profissionais para dividir suas opiniões e aprender como tornar os eventos memoráveis, para entrar no link: bit.ly/eventoscast_comunidade Fale Conosco: Email: redacao@eventoscast.com.br | Instagram: https://www.instagram.com/eventoscast | Linkedin: https://www.linkedin.com/company/eventoscast EventosCast é uma produção da MS Eventos | Coordenação Geral: Marcely Souza | Apresentação: Marcely Souza | Edição: 2023

Early in her career, Nora Schöner fell in love with infrastructure as code.In this episode, Nora Schöner, Senior Cloud Consultant at superluminar, explains why she's so passionate about tools like Terraform, AWS CDK, and Pulumi, how they lower the threshold for developers entering the industry, and how they simplify the way developers define and make changes to infrastructure.You'll learn:1. How infrastructure as code helped Nora enter the programming industry2. What impact will the HashiCorp licensing change have on Terraform users?3. Why infrastructure from code could be the new wave of cloud infrastructure management4. Why infrastructure as code isn't as wasteful as some people think5. How to improve diversity in technical teams__________About Nora:Nora Schöner is a German-based Cloud Engineer who has been working in the tech industry for over 10 years. She is an AWS Community Builder and focuses on Cloud Computing and DevOps, but also on empowering other women developers. Nora founded She 'n IT Nuremberg, a meetup to connect other women devs in the industry, and co-organizes the AWS UG Nuremberg. She blogs at wolkencode.de and likes drawing Manga, dancing, and enjoying delicious food.Nora's blog and Social Media:Blog: https://wolkencode.de LinkedIn: https://www.linkedin.com/in/nora-schoener/ Instagram: https://www.instagram.com/wolkencode/ Mastodon: @wolkencode@awscommunity.social X/Twitter: https://twitter.com/wolkencode Nora's article recommendation:Gregor Hohpe's blog post: https://architectelevator.com/cloud/iac-architecture-as-code/ __________About superluminar:superluminar is an AWS Advanced Consulting Partner based in Hamburg, Germany. Established in 2017, the founding team started with over eight years of cloud experience and has grown to 19 cloud enthusiasts in 2023. By being committed to a hands-on approach, knowledge transfer that has impact, as well as quality and a performant outcome, at superluminar, we work with our clients, we don't just work for them.Website: https://www.superluminar.io Industry: Information Technology & ServicesCompany size: 11-50 employeesHeadquarters: HamburgFounded: 2017__________About the host Elias:Elias is the VP for North America at Checkmk. He comes from a strategy consulting background but has been an entrepreneur for the better part of the last 10 years. In his spare time, he likes to do triathlons.Get in touch with Elias via LinkedIn or email podcast@checkmk.com __________Podcast Music:Music by Ströme, used by permission‚Panta Rhei‘ written by Mario Schoenhofer(c)+p 2022, Compost Medien GmbH & Co KGhttps://stroeme.com/ https://compost-rec.com/ The All Things Ops Podcast has recently been named as one of the top DevOps Podcasts. Check it out here: https://blog.feedspot.com/devops_podcasts/ This podcast is produced by our friends at SAWOO. 

Welcome to another riveting episode of 'DevOps with Zack'! In this episode, I have a special guest, Suzana, who is making waves in the tech community of New Zealand with her remarkable contributions. Suzana joins me to share her incredible journey. Suzana is an AWS User Group Leader in New Zealand, an AWS Community Builder, a certified AWS Cloud Practitioner and the Auckland AWS Tools and Programming meetup group organiser. She is also a FullStack Dev Group Auckland NZ and Cloud Native Auckland co-organiser. Suzana graduated as a Full Stack developer in New Zealand after her 40s, having no previous tech background. She also has a bachelor's in Communications with over 20 years of experience from Brazil. Passionate for both areas, Software Development and Communications, she actively uses her skills to increase the number of women, minorities and under-represented groups in tech, help graduates and juniors excel in their careers and support projects focused on the tech community's growth. The article about the challenge of starting: https://www.linkedin.com/feed/update/urn:li:activity:7110487710972203008/ Suzana's Linkedin: https://www.linkedin.com/in/suzanamelomoraes/

Welcome to another riveting episode of 'DevOps with Zack'! In this episode, I have a special guest, Suzana, who is making waves in the tech community of New Zealand with her remarkable contributions. Suzana joins me to share her incredible journey. Suzana is an AWS User Group Leader in New Zealand, an AWS Community Builder, a certified AWS Cloud Practitioner and the Auckland AWS Tools and Programming meetup group organiser. She is also a FullStack Dev Group Auckland NZ and Cloud Native Auckland co-organiser. Suzana graduated as a Full Stack developer in New Zealand after her 40s, having no previous tech background. She also has a bachelor's in Communications with over 20 years of experience from Brazil. Passionate for both areas, Software Development and Communications, she actively uses her skills to increase the number of women, minorities and under-represented groups in tech, help graduates and juniors excel in their careers and support projects focused on the tech community's growth. The article about the challenge of starting: https://www.linkedin.com/feed/update/urn:li:activity:7110487710972203008/ Suzana's Linkedin: https://www.linkedin.com/in/suzanamelomoraes/

Java is notorious for slow cold starts in Lambda. But why? What can you do to make them faster? Is it time to ditch Python and make your way to the JVM? Join Vadym and Allen as they talk about Java's journey in serverless and explore some of the optimization techniques developers use to mitigate cold starts like Snap Start, priming, and using GraalVM. About Vadym Vadym Kazulkin is Head of Development at ip.labs GmbH, a 100% subsidiary of the FUJIFLM Group, based in Bonn. ip.labs is the world's leading white label e-commerce software imaging company. Vadym has been involved with the Java ecosystem for over twenty years. His focus and interests currently include the design and implementation of highly scalable and available applications, Serverless and AWS Cloud. Vadym is the co-organizer of the Java User Group Bonn meetup and AWS Community Builder in the Serverless category. He's also a frequent speaker at various Meetups and conferences. Links Twitter - https://twitter.com/VKazulkin LinkedIn - https://www.linkedin.com/in/vadymkazulkin Java User Group Bonn - https://www.meetup.com/jug-bonn GraalVM - https://www.graalvm.org --- Send in a voice message: https://podcasters.spotify.com/pod/show/readysetcloud/message Support this podcast: https://podcasters.spotify.com/pod/show/readysetcloud/support

Have you ever wondered how MidJourney or ChatGPT work? Generative AI has taken the world by storm with millions of adopters using it daily. But how does it work? How does it go from a question you type in a dialog box to a meaningful answer or perfectly drawn image on screen? Join Matt and Allen as they discuss how completion models work, explain the differences between Generative AI and "regular" AI, and dive into the possibilities of the not-too-distant future. About Matt Matt is a software developer at Aleios, creator of Orion Tools, maintainer at Quivr, and AWS Community Builder. He loves open-source, serverless, and Generative AI. He also publishes a newsletter, Building with GenAI, where he shares the learnings and news from his projects. Links Twitter - https://twitter.com/mattzcarey LinkedIn - https://www.linkedin.com/in/matt-carey-56b958181 Orion Tools - https://oriontools.ai Code Review GPT - https://github.com/mattzcarey/code-review-gpt Quivr - https://www.quivr.app --- Send in a voice message: https://podcasters.spotify.com/pod/show/readysetcloud/message Support this podcast: https://podcasters.spotify.com/pod/show/readysetcloud/support

Join Eveline Oehrlich and Grant Fritchey, Product Advocate at Redgate Software, to discuss product advocacy, collaboration, and leadership.  Grant has worked for more than 30 years in IT as a developer and a DBA. He has built systems from major enterprises to distributed systems to small boutique companies. Grant writes articles on various data-related topics for SQL Server Central and SimpleTalk. He is the author of multiple books including, SQL Server Execution Plans and SQL Server Query Performance Tuning.  He develops and presents complete structured learning plans to teach Azure, AWS, and other data-related topics to developers and other IS personnel. Grant is a Microsoft Data Platform MVP and an AWS Community Builder. The Humans of DevOps Podcast is incredibly grateful to be voted one of the Best 25 DevOps Podcasts by Feedspot. Learn more about getting DevOps certified at devopsinstitute.com

Many people say DevOps is dead with the introduction of serverless. Responsibilities change from infrastructure management to platform engineering. But what happens when you throw generative AI into the mix? How does this shake up what we now know as DevOps and what does it hold for the future? Is DevOps going to die? Omkar and Allen talk about the human aspect of DevOps and debate if this will still be something we're practicing in 5 years. About OmkarOmkar Kadam is a Lead DevOps Engineer at Cactus Communications, an AWS Community Builder, and a passionate problem solver with exceptional Solution Architecture skills. With a knack for simplifying complex concepts, Omkar's expertise in AWS/Cloud Computing allows him to deliver innovative and scalable solutions. In addition to his technical prowess, Omkar has a passion for mentoring others. He has been a mentor for the prestigious UNESCO India Africa Hackathon, an international event aimed at strengthening the bonds between India and African nations and solving real-life problems via technology. Through mentoring, Omkar has helped aspiring developers and technologists reach their full potential. He's also currently building something cool with Generative AI (checkout buildspace.so & Nights & weekends). And also won an AI Hackathon (organized by AWS Community Builders) for his project AWS Cost Advisor. Links   LinkedIn - https://www.linkedin.com/in/omkarokkadam Personal Blog - https://medium.com/@omkarokkadam --- Send in a voice message: https://podcasters.spotify.com/pod/show/readysetcloud/message Support this podcast: https://podcasters.spotify.com/pod/show/readysetcloud/support

Serverless services make it incredibly easy to start building. They reduce time to market, improve uptime (generally), and lower overall costs when starting up. But there's an entire world to consider before going serverless that most of us forget about - business operations. Aside from shifting ownership from hardware to software, you also have roles that need reassignment, an organizational culture to shift, and much more. Join Allen and Benjamen as the two dive into the subject and offer lessons learned from personal experiences in their careers. About BenjamenBenjamen Pyle is an energetic and resourceful architect in addition to an AWS Community Builder who has over 20 years of professional software development experience including the most recent 10 as a Cloud Architect. His expertise lies in solving complex business problems through the use of expert problem-solving skills, a deep understanding of the problem domain, and technical know-how to bring secure, reliable, and right-sized solutions to his customers. As a fan and advocate for Serverless and Event-Driven Architectures, he enjoys sharing what he's learned at his blog as well as engaging with the Serverless Community in a variety of ways. He's a strong believer in that no one gets where they'd like to go without the help of others and that software delivery is a team sport. On a personal side, Benjamen is a husband and a father and views those two titles as the most important in his life. He's also a proud Terrier Dad to 12 paws. When he's not writing, coding or engaging with the community, you can find him caddying for his kid's golf tournaments or enjoying a round with his family. Links https://twitter.com/benjamenpyle LinkedIn - https://www.linkedin.com/in/benjamenpyle Blog - https://binaryheap.com --- Send in a voice message: https://podcasters.spotify.com/pod/show/readysetcloud/message Support this podcast: https://podcasters.spotify.com/pod/show/readysetcloud/support

People throw around the phrase "app modernization" and "cloud migration" far too often. What do they mean? Are they the same thing? In this episode, Allen sits down with Alex Kearns to navigate the twists and turns of the cloud to find out the answer. The two talk about different strategies of modernization like the strangler pattern and learn how it's transforming the way businesses approach their cloud journeys. Learn how to dodge the dreaded 'modernization paralysis'. The conversation illuminates the nuances of feature-led modernization, the right way to adapt to the cloud, and how to maximize your cloud potential without affecting your end users. About Alex Alex is a Principal Solutions Architect at Ubertas Consulting, AWS Ambassador, and AWS Community Builder specializing in migration and modernization. With over 5 years of experience in architecting and implementing production workloads on AWS for both customers and internal teams, he has plenty of knowledge about core AWS services that enable easier migrations in addition to those that empower customers to make the most of the cloud. He is passionate about sharing his knowledge with the community through public speaking and blog posts as well as generally just playing about with new tech. Alex is a firm believer in making use of serverless or managed services wherever possible. Links LinkedIn - https://www.linkedin.com/in/alexjameskearns Alex's Site - https://www.alexkearns.co.uk/ Alex's Free AWS Workshops - http://cloud-workshops.com AWS 7 R's - https://docs.aws.amazon.com/prescriptive-guidance/latest/application-portfolio-assessment-guide/prioritization-and-migration-strategy.html#migration-r-type --- Send in a voice message: https://podcasters.spotify.com/pod/show/readysetcloud/message Support this podcast: https://podcasters.spotify.com/pod/show/readysetcloud/support

In this podcast, Pubudu will take a deep dive into the benefits of using Amazon EventBridge Pipes, how it works, and why it is a game changer for developers. About Pubudu: Pubudu is a senior backend developer at Starred (starred.com) and an AWS Community Builder in Serverless category. In free time, he likes to play around with Serverless services and share his experience about them in social media, tech talks and in blogs.LinkedIn: https://www.linkedin.com/in/pubudusj/Twitter: https://twitter.com/pubudusjMedium: https://medium.com/@pubudusjDev.to: https://dev.to/pubudusjEventBridge Pipes Articles:https://medium.com/@pubudusj/split-messages-from-single-sqs-queue-into-multiple-sqs-queues-using-eventbridge-728809342352https://medium.com/@pubudusj/self-healing-serverless-app-with-lambda-destinations-and-eventbridge-b548d4554df0

In this podcast, Pubudu will take a deep dive into the benefits of using Amazon EventBridge Pipes, how it works, and why it is a game changer for developers. About Pubudu: Pubudu is a senior backend developer at Starred (starred.com) and an AWS Community Builder in Serverless category. In free time, he likes to play around with Serverless services and share his experience about them in social media, tech talks and in blogs.LinkedIn: https://www.linkedin.com/in/pubudusj/Twitter: https://twitter.com/pubudusjMedium: https://medium.com/@pubudusjDev.to: https://dev.to/pubudusjEventBridge Pipes Articles:https://medium.com/@pubudusj/split-messages-from-single-sqs-queue-into-multiple-sqs-queues-using-eventbridge-728809342352https://medium.com/@pubudusj/self-healing-serverless-app-with-lambda-destinations-and-eventbridge-b548d4554df0

In this episode, Dave and Linda sit down with Johannes Koch, a Sr. DevOps Engineer, Developer Experience at FICO. As an AWS Community Builder, an AWS Usergroup Leader, and veteran speaker at AWS Community Days and AWS re:Invent, Johannes brings a wealth of experience to the table. Get ready to dive deep into Johannes' developer journey, as he recounts his first foray into the world of CI/CD and automation. He offers invaluable insights into the current state of CI/CD and covers popular developer approaches including pre-commit hooks, micro commits, and feature flagging. Johannes also reveals the must-have AWS Services that developers can use to supercharge their CI/CD productivity. Whether you're a seasoned developer or just starting out, this episode is packed with tips and tricks to help you level up your game. Johannes' YouTube Show - CICDONAWS: https://www.youtube.com/@CICDONAWS Johannes on LinkedIn: https://www.linkedin.com/in/johannes-koch-353b2158 Johannes's Blog: https://www.lockhead.info Johannes on Twitter: https://twitter.com/lockhead Linda on Twitter: https://twitter.com/lindavivah Linda's Website: https://lindavivah.com/ Linda on TikTok: https://www.tiktok.com/@lindavivah Linda on Instagram: https://www.instagram.com/lindavivah/ Linda's Medium: https://medium.com/@LindaVivah [GIT] CI/CD on AWS Example Project - https://github.com/Lock128/cicdonaws-example-projects [YOUTUBE] CICDONAWS Show - https://www.youtube.com/@CICDONAWS [YOUTUBE] CICDONAWS Show - CI/CD with Community Builders - https://www.youtube.com/watch?v=NR0pyPODfcM&list=PLSEiMZ6cyJvY4lB0VJk22eI4mP7wWoavE [YOUTUBE] CICDONAWS Show - Amazon CodeCatalyst - https://www.youtube.com/watch?v=elj3X4h96tc&list=PLSEiMZ6cyJva8Y9ZyUdGg6v5NNSfKTeSf [PORTAL] Amazon CodeCatalyst - https://codecatalyst.aws [PORTAL] AWS Community Builders Program - https://aws.amazon.com/developer/community/community-builders/ [PORTAL] AWS Builders Library - My CI/CD Pipeline is My Release Captain- https://aws.amazon.com/builders-library/cicd-pipeline/ DPRA - https://pipelines.devops.aws.dev/ AWS Community Day DACH - https://www.aws-community-day.de/ Planetarion – https://www.planetarion.com/ Subscribe: Spotify: https://open.spotify.com/show/7rQjgnBvuyr18K03tnEHBI Apple Podcasts: https://podcasts.apple.com/us/podcast/aws-developers-podcast/id1574162669 Stitcher: https://www.stitcher.com/show/1065378 Pandora: https://www.pandora.com/podcast/aws-developers-podcast/PC:1001065378 TuneIn: https://tunein.com/podcasts/Technology-Podcasts/AWS-Developers-Podcast-p1461814/ Amazon Music: https://music.amazon.com/podcasts/f8bf7630-2521-4b40-be90-c46a9222c159/aws-developers-podcast Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zb3VuZGNsb3VkLmNvbS91c2Vycy9zb3VuZGNsb3VkOnVzZXJzOjk5NDM2MzU0OS9zb3VuZHMucnNz RSS Feed: https://feeds.soundcloud.com/users/soundcloud:users:994363549/sounds.rss

Ifeanyi Otuonye is also NACAC U23 Long Jump Champion, He is from Turks and Caicos Islands, he said about his work and answered some of my questions. more info- https://www.smartcherrysthoughts.com

John Mille, Principal Cloud Engineer at Sainsbury's UK joins Corey on Screaming in the Cloud to discuss how retail companies are using cloud services. John describes the lessons he's learned since joining the Sainsbury's UK team, including why it's important to share knowledge across your team if you don't want to be on call 24/7,  as well as why he doesn't subscribe to the idea that every developer needs access to production. Corey and John also discuss an open-source project John created called ECS Compose-X.About JohnJohn is an AWS Community Builder (devtools), Open Source enthusiast, SysAdmin born in the cloud, and has worked with AWS since his very first job. He enjoys writing code and creating projects. John likes to focus on automation & architecture that delivers business value, and has been dabbling with data & the wonderful world of Kafka for the past 3 years.Links Referenced: AWS Open-Source Roundup newsletter blog post about ECS Compose-X: https://aws.amazon.com/blogs/opensource/automating-your-ecs-container-architecture-deployments-with-ecs-composex/ ECS Compose-X: https://docs.compose-x.io/ LinkedIn: https://www.linkedin.com/in/john-mille/ Twitter: https://twitter.com/JohnPre32286850 TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: It's easy to **BEEP** up on AWS. Especially when you're managing your cloud environment on your own!Mission Cloud un **BEEP**s your apps and servers. Whatever you need in AWS, we can do it. Head to missioncloud.com for the AWS expertise you need. Corey: Do you wish your developers had less permanent access to AWS? Has the complexity of Amazon's reference architecture for temporary elevated access caused you to sob uncontrollably? With Sym, you can protect your cloud infrastructure with customizable, just-in-time access workflows that can be setup in minutes. By automating the access request lifecycle, Sym helps you reduce the scope of default access while keeping your developers moving quickly. Say goodbye to your cloud access woes with Sym. Go to symops.com/corey to learn more. That's S-Y-M-O-P-S.com/coreyCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Today my guest is a long-time listener, first-time caller. John Mille is a Principal Cloud Engineer at Sainsbury's, which is UK-speak for ‘grocery store.' John, thank you for joining me.John: Hi, Corey. Thanks for having me.Corey: So, I have to begin with, I guess, the big question that I used to run into people in San Francisco with all the time. They would work at Walmart Labs and they would mention in conversation that they work at Walmart, and people who weren't aware that there was a labs out here figured they were a greeter at the grocery store. Do you ever wind up with people making that sort of fundamental assumption around the fact, oh, you work at Sainsbury's as a checker or whatnot?John: No. But it actually is one of the—if you look at one of the job descriptions from Sainsbury's, the first thing is, why would you join a retail company to do tech? And as it turns out, tech—I mean, I think retail companies, as any other companies in the world, rely on Cloud more and more and more. And I think that one of the things that is interesting today is, if you look at the landscape of retailers, I've heard many times people saying, “We don't want to go for AWS because we're giving money to the competition.” And actually, I think AWS does a fantastic job overall giving you all the tools to actually beat them as your competition. And as it turns out, we've had really, really great success running a lot of our workloads on AWS for many, many years now.Corey: On some level, if you can't come to terms with the idea of Amazon as competition, you shouldn't be using AWS, regardless of what industry you're in, because their entire company strategy is yes. It's very hard to start to even come up with industries that they don't have some form of presence within. On some level, that's a problem. In fact a lot of levels, that's something of a problem.Everyone tends to wind up viewing the world in a bunch of different ways. I like to divide companies into two groups. More or less it's, is the AWS bill one of the top three line items at the company? And if the answer's no, on some level, you know, that usually is an indicator that there's a sustainable business there that, you know, both our grandparents and our grandchildren will be able to recognize, in the fullness of time. You absolutely have a business that winds up falling into that category, whereas, “Oh yeah, I fix the AWS bill,” yeah, my parents would have no idea what I do and my kids don't have much of a better one. It feels like it's very point-in-time type of problem. At least I hope.Technology is not the core of what grocery stores tend to do, but I also don't get the sense that what you're doing is sitting there doing the back office corporate IT style of work, either. How do you use technology in the overall context of the business?John: Well, so we use it in a very wide variety of sense. So, you obviously have everything that has to do with online shopping, orders and all of those sort of things, which obviously, especially with the drive of Covid and being everybody from home, has been a huge driver to improve our ability to deliver to customers. But certainly, I think that Sainsbury's sees AWS as a key partner to be able to go and say we want to deliver more value. And so, there's been a number of transformation over the years to—and one of the reasons I was hired is actually to be part of one of those transformation, where we're going to take existing infrastructure servers that literally—I usually say to people, “Oh, are we doing an upgrade this month? Has somebody gotten their little brush to go and brush onto the hard drives to make sure that nothing is going to die?” And actually do that transformation and move over to the cloud in order to never have to really worry about whether or not they have to manage hardware and infrastructure.Corey: It's strange in that I never got very deep into containers until I was no longer hands-on hardware, managing things. I was more or less doing advisory work and then messing around with them. And you'd think given my proclivities historically, of being very unlucky when it comes to data, you would think that this would be great because, oh yeah, you blow away an ephemeral container? Well, that's kind of the point. We'll all laugh and it'll re-instantiate itself and life goes on.But no. Making fun of them was more or less how I tended to do approach them for the longest time until I started to see them a little bit… well I guess less as a culture, less as a religion, and more as an incredibly versatile packaging format, which is probably going to annoy the people I know who are the packaging [unintelligible 00:04:58] for Linux distributions. How do you tend to view them? And how did you start using them?John: Right. So, that's a great question. So historically, I was a student at, I think the school were one of the original creators of Docker were. And one of the things that you learn when you do development at the school is that, you know, containers [unintelligible 00:05:18] new invention. Docker, I think, came on the platform as the way to, you know, give everybody a great framework, a great API, to drive the deployment of containers in the world and bundle them and ship them around the world, on your laptop and somebody else's, and help a little bit with, you know, solving the problem of it works on my laptop, but not just on the laptop properly. Maybe.It's obviously gone viral over the years and I really enjoy containers; I quite like containers. What I find interesting is what people are going to do with. And I think that over the last few years, we've seen a number of technologies such as Kubernetes and others come into the scene and say—and trying to solve people's problem, but everybody seems to be doing, sort of, things on their own way. And historically, I started off using ECS, when it was terrible and you didn't have security groups per containers and all of this. But over the years, you know, you learn, and AWS has improved the service quite significantly with more and more features.And I think we are today in the place where there's this landscape, I think, where a lot of workloads are going to be extremely ephemeral and you can go [unintelligible 00:06:28], you know, wherever you want and you have a bit—if you have a platform or workflow that you need to have working in different places, maybe Kubernetes could be an easy way to have a different sort of sets of features that allows you to move around in maybe an easier way. But that also comes with a set of drawbacks. Again, I look at using EKS, for example, and I see okay, I have to manage IAM in our back now, whereas if I used something like ECS, for the whatever the [unintelligible 00:06:56] cloud vendor of choice, I don't have to deal with any of this. So, I think it's finding the fine balance between how you do orchestration of containers now and what works for you and is any sustainable over the time, more than about are you going to use containers? Because the chances are, somebody is using containers.Corey: My experiences and workflows and constraints are radically different than that of other folks because for a lot of the things I'm building, these are accounts that are I'm the only person that has access to them. It is me. So, the idea of fine-grained permissions for users from an ARBAC perspective doesn't really factor into it. Yes, yes, in theory, I should have a lot of the systems themselves with incidents roles being managed in safe and secure ways, but in many cases, the AWS account boundary is sufficient for that, depending on what it is we're talking about. But that changes when you start having a small team of people working with you and having to collaborate on these things.And we do a little bit of that with some of our consulting stuff that isn't just the shitpost stuff I build for fun. But there's multiple levels beyond that. You are clearly in a full-blown enterprise at this point where there are a bunch of different teams working on different things, all ideally going in the same direction. And it's easy to get stuck in the weeds of having to either go through central IT for these things, which gives rise to shadow IT every time you find a corporate credit card in the wild, or it winds up being everyone can do what they want, but then there's no consensus, there's no control, there's no architectural similarity. And I'm not sure which path is worse in some respects. How do you land on it?John: Right. So, what I've seen done in companies that works very well—and again, to the credit of my current company—is one of the things they've done really well is build a hub of people who are going to manage solely everything that has to do with accounts access, right? So, the control, IAM, Security Hub, all of those sorts of things, for you. There's things that are mandatory that you can't deal without, you have permissions boundary, that's it, you have to use those things, end of story. But beyond that point, once you have access to your accounts, you've been given all of the access that is necessary for you to deliver application and deploy them all the way up to production without asking permission for anybody else apart from your delivery managers, potentially.And I think from there, because there is the room to do all of this, one of the things that we've done within my business unit is that we've put in place a framework that enables developers—and when I say that it really is a question of allowing them to do everything they have to do, focus on the code, and I know it's a little catchy [unintelligible 00:09:33] a phrase that you hear these days, but the developers really are the customers that we have. And all that we do is to try to make sure that they have a framework in place that allows them to do what they need and deploy the applications in a secure fashion. And the only way to do that for us was to build the tools for them that allows them to do all of that. And I honestly haven't checked a single service IAM policies in a very are longtime because I know that by providing the tools to developers, they don't have this [will 00:10:05] to go and mess with the permissions because their application suddenly doesn't have the permissions. They just know that with the automation we've providing them, the application gets the access it needs and no more.Corey: On some level, it feels like there's a story around graduated development approach where in a dev environment you can do basically whatever you want with a big asterisk next to it. That's the same asterisk, by the way, next to the AWS free tier. But as you start elevating things into higher environments, you start to see gating around things like who has access to what, security reviews, et cetera, et cetera, and ideally, by the time you wind up getting into production, almost no one should have access and that access that people do have winds up being heavily gated. That is, of course, the vision that folks have. In practice, reality is what happens instead of what we plan on. The idea of it works in theory, but not in production is of course, why I call my staging environment ‘theory.' Does that tend to resonate as far as what you've seen in the wild?John: Yeah. Very much so. And when I joined the company, and we put together our [standard 00:11:11] pipelines for developers to be able to do everything, the rule that I would give to my team—so I manage a small team of cloud engineers—the one rule I would say is, “We have access to prod because we need to provision resources, but when we're going to build the pipelines for the developers, you have to build everything in such a way that the developers will only have read-only access to the production environment, and that is only to go and see their logs.” And at least try to foster this notion that developers do not need access to production, as much as possible because that avoids people going and do something they shouldn't be doing in those production environments.Now, as the pipeline progresses and applications get deployed to production, there are some operational capabilities that people need to have, and so in that case, what we do is we try to fine-tune what do people need to do and grant those people access to the accounts so that they can perform the jobs and I don't have to be woken up at two in the morning. The developers are.Corey: One thing that I think is going to be a cause of some consternation for folks—because I didn't really think about this in any meaningful sense until I started acting as a consultant, which means you're getting three years of experience for every year that you're in the wild, just by virtue of the variety of environments you encounter—on some level, there's a reasonable expectation you can have when you're at a small, scrappy startup, that everyone involved knows where all the moving parts live. That tends to break down with scale. So, the idea of a Cloud Center of Excellence has been bandied around a lot. And personally, I hate the term because it implies the ‘Data Center of Mediocrity,' which is a little on the nose for some people at times. So, the idea of having a sort of as a centralized tiger team that has the expertise and has the ability to go on deep dives and sort of loan themselves out to different teams seems to be a compromise between nobody knows what they're doing and, every person involved should have an in-depth knowledge of the following list of disciplines.For example, most folks do not need an in-depth primer on AWS billing constructs. They need about as much information fits on an index card. Do you find that having the centralized concentration of cloud knowledge on a particular team works out or do you find that effectively doing a rotating embedding story is the better answer?John: It varies a lot, I think, because it depends on the level of curiosity of the developers quite a lot. So, I have a huge developer background. People in my team are probably more coming from ex-IT environments or this sort of operation and then it just naturally went into the cloud. And in my opinion, is fairly rare to find somebody that is actually good at doing both AWS and coding. I am by no means really, really great at coding. I code pretty much every day but I wouldn't call myself a professional developer.However, it does bring to my knowledge the fact that there are some good patterns and good practices that you can bring into building your applications in the cloud and some really bad ones. However, I think it's really down to making sure that the knowledge is here within the team. If there's a specialized team, those really need to be specialists. And I think the important thing then is to make sure that the developers and the people around you that are curious and want to ask questions know that you're available to them to share that knowledge. Because at the end of the day, if I'm the only one with the knowledge, I'm going to be the one who is always going to be on call for this or doing that and this is no responsibility that I want. I am happy with a number of responsibilities, but not to be the only person to ever do this. I want to go on holidays from time to time.So, at the end of the day, I suppose it really is up to what people want or expect out of their careers. I do a job that it was a passion for me since I was about 14 years old. And I've always been extremely curious to understand how things work, but I do draw the line that I don't write anything else than Python these days. And if you ask me to write Java, I'll probably change job in the flip of a second. But that's the end of it. But I enjoy understanding how Java things work so that I can help my developers make better choices with what services in AWS to use.Corey: On some level, it feels like there's a, I guess, lack of the same kind of socialization that startups have sort of been somewhat guided by as far as core ethos goes, where, oh whatever I'm working on, I want to reach out to other people, and, “Hey, I'm trying to solve this problem. What is it that you have been working on that's germane to this and how can we collaborate together?” It has nothing to do, incidentally, with the idea that, oh, big company people aren't friendly or are dedicated or aren't good or aren't well-connected; none of that. But there are so many people internally that you're spending your time focusing on and there's so much more internal context that doesn't necessarily map to anything outside of the company that the idea of someone off the street who just solved a particular problem in a weird way could apply to what a larger company with, you know, regulatory burdens, starts to have in mind, it becomes a little bit further afield. Do you think that that's accurate? Do you think that there's still a strong sense of enterprise community that I'm just potentially not seeing in various ways because I don't work at big companies?John: It's a very fine line to walk. So, when I joined the company, I was made aware that there's a lot of Terraform and Kubernetes, which I went [unintelligible 00:16:28] all the way with CloudFormation is yes. So, that was one of the changes I knew I would have. But I can move an open mind and when I looked around at, okay, what are the Terraform modules—because I used Terraform with anger for an entire year of suffering—and I thought, “Okay, well, maybe people have actually got to a point where they've built great modules that I can just pick up off the shelf and reuse or customize only a tiny little bit, add maybe a couple of features and that's, it move on; it's good enough for me.” But as it turns out, there is I think, a lot of the time a case where the need for standardization goes against the need for business to move on.So, I think this is where you start to see silos start to being built within the company and people do their own thing and the other ones do their own. And I think it's always a really big challenge for a large company with extremely opinionated individuals to say, “All right, we're going to standardize on this way.” And it definitely was one of the biggest challenge that I had when I joined the company because again, big communities and Terraform place, we're going to need to do something else. So, then it was the case of saying, “Hey, I don't think we need Kubernetes and I definitely don't think we need Terraform for any the things—for any of those reasons, so how about we do something a little different?”Corey: Speaking of doing things a little bit different, you were recently featured in an AWS Open-Source Roundup newsletter that was just where you, I think, came across my desk one of the first times, has specifically around an open-source project that you built: ECS Compose-X.So, I assume it's like, oh, it's like Docker Compose for ECS and also the ‘X' implies that it is extreme, just, like, you know, snack foods at the convenience store. What does it do and where'd it come from?John: Right. So, you said most of it, right? It literally is a question where you take a Docker Compose file and you want to deploy your services that you worked on and all of that together, and you want to deploy it to AWS. So, ECS Compose-X is a CLI tool very much like the Copilot. I think it was released about four months just before Copilots came out—so, sorry, I beat you to the ball there—but with the Docker Compose specification supported.And again, it was really out of I needed to find a neat way to take my services and deploy them in AWS. So, Compose-X is just a CLI tool that is going to parse your Docker Compose file and create CloudFormation templates out of it. Now, the X is not very extreme or anything like that, but it's actually coming from the [finite 00:18:59] extension fields, which is something supported in Docker Compose. And so, you can do things like x-RDS, or x-DynamoDB, which Docker Compose on your laptop will totally ignore, but ECS Compose-X however will take that into account.And what it will do is if you need a database or a DynamoDB table, for example, in your Docker Compose file, you do [x-RDS, my database, some properties, 00:19:22]—exactly the same properties as CloudFormation, actually—and then you say, “I want this service to have access to it in read-only fashion.” And what ECS Compose-X is going to do is just understand what it has to do when—meaning creating IAM policies, opening security groups, all of that stuff, and make all of that available to the containers in one way or another.Corey: It feels like it's a bit of a miss for Copilot not to do this. It feels like they wanted to go off in their own direction with the way that they viewed the world—which I get; I'm not saying there's anything inherently wrong with that. There's a reason that I point kubernetestheeasyway.com to the ECS marketing site—but there's so much stuff out there that is shipped or made available in other ways with a Docker Compose file, and the question of okay, how do I take this and run it in Fargate or something because I don't want to run it locally for whatever reason, and the answer is, “That's the neat part. You don't.”And it just becomes such a clear miss. There have been questions about this Since Copilot launched. There's a GitHub issue tracking getting support for this that was last updated in September—we are currently recording this at the end of March—it just doesn't seem to be something that's a priority. I mean, I will say the couple of times that I've used Copilot myself, it was always for greenfield experiments, never for adopting something else that already existed. And that was… it just felt like a bit of a heavy lift to me of oh, you need to know from the beginning that this is the tool you're going to use for the thing. Docker Compose is what the ecosystem has settled on a long time ago and I really am disheartened by the fact that there's no direct ECS support for it today.John: Yeah, and it was definitely a motivation for me because I knew that ECS CLI version 1 was going into the sunset, and there wasn't going to be anything supporting it. And so, I just wanted to have Docker Compose because it's familiar to developers and again, if you want to have adoption and have people use your thing, it has to be easy. And when I looked at Copilot the first time around, I was extremely excited because I thought, “Yes, thank you, Amazon for making my life easy. I don't have to maintain this project anymore and I'm going to be able to just lift and shift, move over, and be happy about it.” But when the specification for Copilot was out and I could go for the documentation, I was equally disheartened because I was like, “Okay, not for me.”And something very similar happened when they announced Proton. I was extremely excited by Proton. I opened a GitHub issue on the roadmap immediately to say, “Hey, are you going to support to have some of those things together or not?” And the fact that the Proton templates—I mean, again, it was, what, two, three years ago now—and I haven't looked at Proton since, so it was a very long time now.Corey: The beta splasher was announced in 2020 and I really haven't seen much from it since.John: Well, and I haven't done anything [unintelligible 00:22:07] with it. And literally, one of the first thing did when the project came out. Because obviously, this is an open-source project that we use in Sainsbury's, right because we deploy everything in [ECS 00:22:17] so why would I reinvent the wheel the third time? It's been done, I might as well leverage it. But every time something on it came out, I was seeing it as the way out of nobody's going to need me anymore—which is great—and that doesn't create a huge potential dependency on the company for me, oh, well, we need this to, you know, keep working.Now, it's open-source, it's on the license you can fork it and do whatever you want with it, so from that point of view, nobody's going to ask me anything in the future, but from the point of view where I need to, as much as possible, use AWS native tools, or AWS-built tools, I differently wanted every time to move over to something different. But every time I tried and tiptoed with those alternative offerings, I just went back and said, “No, this [laugh] either is too new and not mature enough yet, or my tool is just better.” Right? And one of the things I've been doing for the past three years is look at the Docker ECS plugin, all of the issues, and I see all of the feature requests that people are asking for and just do that in my project. And some with Copilots. The only thing that Copilot does that I don't do is tell people how to do CI/CD pipelines.Corey: One thing you said a second ago just sort of, I guess, sent me spiraling for a second because I distinctly remember this particular painful part. You're right, there was an ECS CLI for a long time that has since been deprecated. But we had internal tooling built around that. When there was an issue with a particular task that failed, getting logs out of it was non-trivial, so great. Here's the magic incantation that does it.I still haven't found a great way to do that with the AWS v2 CLI and that feels like it's a gap where yes, I understand, old tools go away and new ones show up, but, “Hey, I [unintelligible 00:24:05] task. Can you tell me what the logs are?” “No. Well, Copilot's the new answer.” “Okay. Can I use this to get logs from something that isn't Copilot?” “Oh, absolutely not.” And the future is inherently terrible as a direct result.John: Yeah. Well, I mean, again, the [unintelligible 00:24:20]—the only thing that ECS Compose-X does is create all the templates for you so you can, you know, then just query it and know where everything has been created. And one of the things it definitely does create is all of the log groups. Because again, least-privileged permissions being something that is very dear to me, I create the log groups and just allow the services to only write in those log groups and that's it.Now, typically this is not a thing that I've thought Compose-X was going to do because that's not its purpose. It's not going to be an operational tool to troubleshoot all the things and this is where I think that other projects are much better suited and I would rather use them as an extension or library of the project as opposed to reinvent them. So, if you're trying to find a tool for yourself to look at logs, I highly recommend something called ‘AWS logs,' which is fantastic. You just say, “Hey, can you list the groups?” “Okay.” “Can you get me the groups and can I tell them on a terminal?”And that's it. Job done. So, as much as I enjoy building new features into the project, for example, I think that there's a clear definition between what the project is for and what it's not. And what it's for is giving people CloudFormation templates they can reuse in any region and deploy their services and not necessarily deal with their operations; that's up to them. At the end of the day, it's really up to the user to know what they want to do with it. I'm not trying to force anybody into doing something specific.Corey: I would agree. I think that there's value to there's more than one way to do it. The problem is, at some point, there's a tipping point where you have this proliferation of different options to the point where you end up in this analysis paralysis model where you're too busy trying to figure out what is the next clear step. And yes, that flexibility is incredibly valuable, especially when you get into, you know, large, sophisticated enterprises—ahem, ahem—but when you're just trying to kick the tires on something new, I feel like there's a certain lack of golden path where in the event of not having an opinion on any of these things, this is what you should do just to keep things moving forward, as opposed to here are two equal options that you can check with radio boxes and it's not at all clear what you which does what or what the longer-term implications are. We've all gotten caught with the one-way doors we didn't realize we were passing through at the time and then had to do significant technical debt repayment efforts to wind up making it right again.I just wish that those questions would be called out, but everything else just, it doesn't matter. If you don't like the name of the service that you're creating, you can change it later. Or if you can't, maybe you should know now, so you don't have—in my case—a DynamoDB table that is named ‘test' running in production forever.John: Yeah. You're absolutely right. And again, I think it goes back to one of the biggest challenges that I had when I joined the company, which was when I said, “I think we should be using CloudFormation, I think we should be using ECS and Terraforming Kubernetes for those reasons.” And one of the reasons was, the people. Meaning we were a very small team, only five cloud engineers at the time.And as I joined the company, they were already was three different teams using four different CI/CD tools. And they all wanted to use Kubernetes, for example, and they were all using different CI/CD—like I said, just now—different CI/CD tools. And so, the real big challenge for me was how do I pitch that simplicity is what's going to allow us to deliver value for the business? Because at the end of the day, like you said many, many times before, the AWS bill is a question of architecture, right? And there's a link and intricacy between the two things.So, the only thing that really mattered for me and the team was to find a way, find the service that was going to allow to do a number of things, A, delivering value quickly, being supported over time. Because one of the things that I think people forget these days—well, one of the things I'm allergic to and one of the things that makes me spiral is what I call CV-driven tech choices where people say, “Hey, I love this great thing I read about and I think that we should use that in production. How great idea.” But really, I don't know anything about it and is then up to somebody else to maintain it long-term.And that goes to the other point, which is, turnover-proof is what I call it. So, making tech choices that are going to be something that people will be able to use for many, many years, there is going to be a company behind the scenes that he's going to be able to support you as well as you go and use the service for the many, many years to go.Corey: I really want to thank you for taking the time to speak with me today. If people want to learn more, where's the best place for them to find you?John: So, people can find me on LinkedIn. I'm also around on Twitter these days, although I probably about have nine followers. Well, probably shouldn't say that [laugh] and that doesn't matter.Corey: It's fine. We'll put a link into it—we'll put a link to that in the [show notes 00:29:02] and maybe we'll come up with number ten. You never know. Thanks again for your time. I really appreciate it.John: Thanks so much, Corey, for having me.Corey: John Mille, Principal Cloud Engineer at Sainsbury's. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment that you go to great pains to type out but then fails to post because the version of the tool you use to submit it has been deprecated without a viable replacement.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.

We have plenty of tools that build Infrastructure as Code (IaC) in the cloud. But today, we're zeroing in on two powerhouses: SAM and CDK. Allen, a passionate SAM supporter, goes head-to-head with Matt Martz, a CDK enthusiast, as they share their preferred IaC methods. Dive into the world of CDK constructs versus SAM macros, explore the portability of templates in YAML versus code, and uncover the hidden gems of missing features. Can we finally settle the great SAM vs. CDK debate? Tune in and join the excitement to find out! About Matt Meet Matt, a Principal Engineer at PowerSchool who is passionate about enabling teams to adopt a serverless-first, event-driven architecture philosophy. He is an AWS Community Builder since 2020 and has extensive expertise in CDK, Serverless, and EDA, which he shares through his blog's advanced technical content.Matt manages an inner-source CDK Construct Library, driving innovation and fostering a collaborative environment at PowerSchool. His innovative approach to serverless architectures has helped several teams streamline their processes, reduce costs, and improve their overall efficiency.In his free time, Matt enjoys cold brew coffee, camping with his daughter, and spending time with his family. Links Twitter - https://twitter.com/martzcodes Mastodon - https://awscommunity.social/@martzcodes LinkedIn - https://linkedin.com/in/martzcodes Matt's blog - https://matt.martz.codes --- Send in a voice message: https://podcasters.spotify.com/pod/show/readysetcloud/message Support this podcast: https://podcasters.spotify.com/pod/show/readysetcloud/support

Lahiru Hewawasam is Security Engineer for ExpressVPN and an AWS Community Builder. In this episode he talks about architectural best practices when building a data lake dedicated to security concerns. Resources: https://www.linkedin.com/in/richardfan1126/ https://twitter.com/richardfan1126

Serverless is taking the world by storm. Despite there being countless blogs, tutorials, and recommended best practices around serverless, there's shockingly little material on observability. Why? It's hard! Join AJ and Allen as they talk about the difficulties of observing a serverless application, dive into the differences between KPIs and infrastructure metrics, what the future holds for observability, and more. About AJAJ Stuyvenberg is the Engineering Lead for Serverless APM at Datadog, and has been a member of the Serverless community for 6+ years. He's an AWS Community Builder, serverless meetup organizer, open source author, and frequently blogs about Serverless topics.Before Datadog, he was a Principal Engineer at Serverless Inc, the company behind the Serverless Framework.In his spare time, AJ is an avid BASE jumper and enjoys flying his wingsuit in the Alps. Links Twitter - https://twitter.com/astuyve LinkedIn - https://www.linkedin.com/in/aaron-stuyvenberg Blog - https://aaronstuyvenberg.com Email: aj@datadoghq.com --- Send in a voice message: https://podcasters.spotify.com/pod/show/readysetcloud/message Support this podcast: https://podcasters.spotify.com/pod/show/readysetcloud/support

There are about as many "first" approaches to software as there are colors in the rainbow. Front-end first, serverless-first, API-first, test-first, the list goes on and on. Andres Moreno and I cover what it means to be API-first, clarify the definition of serverless-first, and discuss how he managed to build a development process that follows both patterns. Learn about the tooling that helps this highly-optimized team push out high-quality code faster than ever without getting lost in the weeds. About Andres Andres is a lead software engineer at Tyler Technologies with over a decade of experience. He's a skilled AWS serverless engineer and has spent time as an AWS Community Builder. Andres writes in-depth technical content on his blog where he shares his insights on CI/CD, cloud security, and JavaScript. Links Twitter - https://twitter.com/andmoredev LinkedIn -https://www.linkedin.com/in/andmoredev Personal blog - https://www.andmore.dev Postman - https://postman.com Open API Specification - https://www.openapis.org --- Send in a voice message: https://podcasters.spotify.com/pod/show/readysetcloud/message Support this podcast: https://podcasters.spotify.com/pod/show/readysetcloud/support

Renaldi Gondosubroto is a developer advocate for cloud security as well as an AWS Community Builder and joins us today with his talk Once More Into the Breach, establishing a secure coding culture in an era of continuous threats. Renaldi is a software development, enjoys ethical hacking, and enjoys sharing his knowledge and insights at conferences and events. Today's discussion will look at setting security goals, understanding the need for Zero Trust, how to establish secure coding as a culture, and looking into example case studies on how to achieve this. Resources: https://www.linkedin.com/in/renaldigondosubroto/?originalSubdomain=au https://twitter.com/Renaldig

Episode Summary Developer experience is often an afterthought when building APIs. But when you build for developers, DevEx is critical to your success. How fast can you make that time to first call? If you have a high barrier of entry, nobody is going to use it. The easier it is to move quickly, the easier it is to spread the word and drive usage. Lars and Allen talk about what makes for good and bad developer experiences. They cover real-world examples and what makes them particularly easy (or bad!) to use. Lars dives into the AWS Step Functions DevEx and what he did to finally get rid of that "swivel chair experience." About Lars Lars is the Head of Infrastructure at Mathem.se and AWS Community Builder. He regularly takes it upon himself to make developer experience better for everyone with his open source tools like the Step Functions SDK Autocomplete VSCode extension and EventBridge pattern generator CLI. He's also the creator of the Step Functions Workflow Studio sync, which aims to address the big gap in usability with the popular AWS service. Links Twitter - https://twitter.com/lajacobsson LinkedIn - https://www.linkedin.com/in/lars-jacobsson-a9518b23/ GitHub - https://github.com/ljacobsson Step Functions Workflow Studio Sync -https://github.com/ljacobsson/sfn-workflow-studio-sync Mathem's GitHub - https://github.com/mhlabs --- Send in a voice message: https://podcasters.spotify.com/pod/show/readysetcloud/message Support this podcast: https://podcasters.spotify.com/pod/show/readysetcloud/support

Ryan Jones is joined by Vadym Kazulkin! Vadym Kazulkin is Head of Development at ip.labs GmbH, a 100% subsidiary of the FUJIFILM Group, based in Bonn, Germany. ip.labs is the world's leading white-label e-commerce software imaging company. Vadym has been involved with the Java ecosystem for over twenty years. His focus and interests currently include the design and implementation of highly scalable and available applications, Serverless and AWS Cloud. Vadym is the co-organizer of the Java User Group Bonn meetup and AWS Community Builder in the Serverless category and a frequent speaker at various Meetups and conferences. More about Vadym: Twitter: https://twitter.com/VKazulkin GitHub: https://github.com/Vadym79/ Last article of his series about AWS SnapStart: https://dev.to/aws-builders/measuring-java-11-lambda-cold-starts-with-snapstart-part-6-priming-the-request-invocation-30od --- Send in a voice message: https://podcasters.spotify.com/pod/show/talking-serverless/message

Episode Summary Platform engineering is a trending topic in cloud communities these days. Does it replace DevOps? Is it really "the next new thing?" Before we can answer that, we need to understand what platform engineering is and how it is different from DevOps. Allen talks with Ran Isenberg about the responsibilities his team undertakes at CyberArk, some challenges they went through when starting up, and some of the benefits they gained as a company by going serverless. About Ran Ran is a Principal Software Architect at CyberArk and AWS Community Builder based out of Israel. He runs a high-quality serverless blog, Ran The Builder, where he goes into detail on serverless best practices and design. Ran is also a prominent public speaker, regularly talking about serverless and open source contributions. Links Twitter - https://twitter.com/IsenbergRan LinkedIn - https://www.linkedin.com/in/ranisenberg Ran The Builder Blog - https://ranthebuilder.cloud --- Send in a voice message: https://podcasters.spotify.com/pod/show/readysetcloud/message Support this podcast: https://podcasters.spotify.com/pod/show/readysetcloud/support

Ryan Jones is joined by Vadym Kazulkin! Vadym Kazulkin is Head of Development at ip.labs GmbH, a 100% subsidiary of the FUJIFILM Group, based in Bonn, Germany. ip.labs is the world's leading white-label e-commerce software imaging company. Vadym has been involved with the Java ecosystem for over twenty years. His focus and interests currently include the design and implementation of highly scalable and available applications, Serverless and AWS Cloud. Vadym is the co-organizer of the Java User Group Bonn meetup and AWS Community Builder in the Serverless category and a frequent speaker at various Meetups and conferences. More about Vadym: Twitter: https://twitter.com/VKazulkin GitHub: https://github.com/Vadym79/ Last article of his series about AWS SnapStart: https://dev.to/aws-builders/measuring-java-11-lambda-cold-starts-with-snapstart-part-6-priming-the-request-invocation-30od --- Send in a voice message: https://podcasters.spotify.com/pod/show/talking-serverless/message

In this episode, I caught up with Sarah Hamilton, who is an AWS Community Builder and a software engineer at LEGO.We talked about her journey into serverless and LEGO's serverless adoption has changed since I spoke with Sheen and Nicole on this podcast. In the two years since they have grown from 6 features teams to over 25, all focused on serverless technologies. We also talked about some of Sarah's previous work, especially a project where she used Step Functions, and her approach towards testing Step Functions.Links from the episode:Sarah's talk on advanced event-driven architectures at LEGO groupEpisode 12: Serverless at LEGO with Nicole Yip and Sheen BrisalsFor more stories about real-world use of serverless technologies, please follow us on Twitter as @RealWorldSls and subscribe to this podcast.Want to step up your AWS game and learn how to build production-ready serverless applications? Check out my upcoming workshops and I will teach you everything I know.Opening theme song:Cheery Monday by Kevin MacLeodLink: https://incompetech.filmmusic.io/song/3495-cheery-mondayLicense: http://creativecommons.org/licenses/by/4.0

Chi Che is a Network and a Cloud Engineer who is also an AWS Community Builder. Chi Che is based in Yaounde, Cameroon. In this episode, we talk about the importance of building hands-on projects on AWS in order to position one for a career in the cloud. Find Chi Che here: Linkedin: https://www.linkedin.com/in/chi-che/ Twitter: https://twitter.com/chiche_ds

Marcos Ortiz is also content creator of Interesting Data Gigs & AWS Graviton Weekly Newsletters and Common Sense Investing Youtube Channel. Follow me on- www.SmartCherrysThoughts.com www.SmartCherrysTech.com, www.SaiCharanPaloju.com --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app

Avinash Dalvi said about his present work and his work experience and answered some of my questions.my websites- www.SmartCherrysThoughts.com, www.SmartCherrysTech.com, www.SaiCharanPaloju.com. Avinash Dalvi blog- www.internetkatta.com his twitter, LinkedIn- AvinashDalvi_ his website- www.avinashdalvi.com --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app

About AllenAllen is a cloud architect at Tyler Technologies. He helps modernize government software by creating secure, highly scalable, and fault-tolerant serverless applications.Allen publishes content regularly about serverless concepts and design on his blog - Ready, Set Cloud!Links Referenced: Ready, Set, Cloud blog: https://readysetcloud.io Tyler Technologies: https://www.tylertech.com/ Twitter: https://twitter.com/allenheltondev Linked: https://www.linkedin.com/in/allenheltondev/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at AWS AppConfig. Engineers love to solve, and occasionally create, problems. But not when it's an on-call fire-drill at 4 in the morning. Software problems should drive innovation and collaboration, NOT stress, and sleeplessness, and threats of violence. That's why so many developers are realizing the value of AWS AppConfig Feature Flags. Feature Flags let developers push code to production, but hide that that feature from customers so that the developers can release their feature when it's ready. This practice allows for safe, fast, and convenient software development. You can seamlessly incorporate AppConfig Feature Flags into your AWS or cloud environment and ship your Features with excitement, not trepidation and fear. To get started, go to snark.cloud/appconfig. That's snark.cloud/appconfig.Corey: I come bearing ill tidings. Developers are responsible for more than ever these days. Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on. Because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud. And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are - Finding and fixing vulnerabilities right from the CLI, IDEs, Repos, and Pipelines. Snyk integrates seamlessly with AWS offerings like code pipeline, EKS, ECR, and more! As well as things you're actually likely to be using. Deploy on AWS, secure with Snyk. Learn more at Snyk.co/scream That's S-N-Y-K.co/screamCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Every once in a while I wind up stumbling into corners of the internet that I previously had not traveled. Somewhat recently, I wound up having that delightful experience again by discovering readysetcloud.io, which has a whole series of, I guess some people might call it thought leadership, I'm going to call it instead how I view it, which is just amazing opinion pieces on the context of serverless, mixed with APIs, mixed with some prognostications about the future.Allen Helton by day is a cloud architect at Tyler Technologies, but that's not how I encountered you. First off, Allen, thank you for joining me.Allen: Thank you, Corey. Happy to be here.Corey: I was originally pointed towards your work by folks in the AWS Community Builder program, of which we both participate from time to time, and it's one of those, “Oh, wow, this is amazing. I really wish I'd discovered some of this sooner.” And every time I look through your back catalog, and I click on a new post, I see things that are either I've really agree with this or I can't stand this opinion, I want to fight about it, but more often than not, it's one of those recurring moments that I love: “Damn, I wish I had written something like this.” So first, you're absolutely killing it on the content front.Allen: Thank you, Corey, I appreciate that. The content that I make is really about the stuff that I'm doing at work. It's stuff that I'm passionate about, stuff that I'd spend a decent amount of time on, and really the most important thing about it for me, is it's stuff that I'm learning and forming opinions on and wants to share with others.Corey: I have to say, when I saw that you were—oh, your Tyler Technologies, which sounds for all the world like, oh, it's a relatively small consultancy run by some guy presumably named Tyler, and you know, it's a petite team of maybe 20, 30 people on the outside. Yeah, then I realized, wait a minute, that's not entirely true. For example, for starters, you're publicly traded. And okay, that does change things a little bit. First off, who are you people? Secondly, what do you do? And third, why have I never heard of you folks, until now?Allen: Tyler is the largest company that focuses completely on the public sector. We have divisions and products for pretty much everything that you can imagine that's in the public sector. We have software for schools, software for tax and appraisal, we have software for police officers, for courts, everything you can think of that runs the government can and a lot of times is run on Tyler software. We've been around for decades building our expertise in the domain, and the reason you probably haven't heard about us is because you might not have ever been in trouble with the law before. If you [laugh] if you have been—Corey: No, no, I learned very early on in the course of my life—which will come as a surprise to absolutely no one who spent more than 30 seconds with me—that I have remarkably little filter and if ten kids were the ones doing something wrong, I'm the one that gets caught. So, I spent a lot of time in the principal's office, so this taught me to keep my nose clean. I'm one of those squeaky-clean types, just because I was always terrified of getting punished because I knew I would get caught. I'm not saying this is the right way to go through life necessarily, but it did have the side benefit of, no, I don't really engage with law enforcement going throughout the course of my life.Allen: That's good. That's good. But one exposure that a lot of people get to Tyler is if you look at the bottom of your next traffic ticket, it'll probably say Tyler Technologies on the bottom there.Corey: Oh, so you're really popular in certain circles, I'd imagine?Allen: Super popular. Yes, yes. And of course, you get all the benefits of writing that code that says ‘if defendant equals Allen Helton then return.'Corey: I like that. You get to have the exception cases built in that no one's ever going to wind up looking into.Allen: That's right. Yes.Corey: The idea of what you're doing makes an awful lot of sense. There's a tremendous need for a wide variety of technical assistance in the public sector. What surprises me, although I guess it probably shouldn't, is how much of your content is aimed at serverless technologies and API design, which to my way of thinking, isn't really something that public sector has done a lot with. Clearly I'm wrong.Allen: Historically, you're not wrong. There's an old saying that government tends to run about ten years behind on technology. Not just technology, but all over the board and runs about ten years behind. And until recently, that's really been true. There was a case last year, a situation last year where one of the state governments—I don't remember which one it was—but they were having a crisis because they couldn't find any COBOL developers to come in and maintain their software that runs the state.And it's COBOL; you're not going to find a whole lot of people that have that skill. A lot of those people are retiring out. And what's happening is that we're getting new people sitting in positions of power and government that want innovation. They know about the cloud and they want to be able to integrate with systems quickly and easily, have little to no onboarding time. You know, there are people in power that have grown up with technology and understand that, well, with everything else, I can be up and running in five or ten minutes. I cannot do this with the software I'm consuming now.Corey: My opinion on it is admittedly conflicted because on the one hand, yeah, I don't think that governments should be running on COBOL software that runs on mainframes that haven't been supported in 25 years. Conversely, I also don't necessarily want them being run like a seed series startup, where, “Well, I wrote this code last night, and it's awesome, so off I go to production with it.” Because I can decide not to do business anymore with Twitter for Pets, and I could go on to something else, like PetFlicks, or whatever it is I choose to use. I can't easily opt out of my government. The decisions that they make stick and that is going to have a meaningful impact on my life and everyone else's life who is subject to their jurisdiction. So, I guess I don't really know where I believe the proper, I guess, pace of technological adoption should be for governments. Curious to get your thoughts on this.Allen: Well, you certainly don't want anything that's bleeding edge. That's one of the things that we kind of draw fine lines around. Because when we're dealing with government software, we're dealing with, usually, critically sensitive information. It's not medical records, but it's your criminal record, and it's things like your social security number, it's things that you can't have leaking out under any circumstances. So, the things that we're building on are things that have proven out to be secure and have best practices around security, uptime, reliability, and in a lot of cases as well, and maintainability. You know, if there are issues, then let's try to get those turned around as quickly as we can because we don't want to have any sort of downtime from the software side versus the software vendor side.Corey: I want to pivot a little bit to some of the content you've put out because an awful lot of it seems to be, I think I'll call it variations on a theme. For example, I just read some recent titles, and to illustrate my point, “Going API First: Your First 30 Days,” “Solutions Architect Tips how to Design Applications for Growth,” “3 Things to Know Before Building A Multi-Tenant Serverless App.” And the common thread that I see running through all of these things are these are things that you tend to have extraordinarily strong and vocal opinions about only after dismissing all of them the first time and slapping something together, and then sort of being forced to live with the consequences of the choices that you've made, in some cases you didn't realize you were making at the time. Are you one of those folks that has the wisdom to see what's coming down the road, or did you do what the rest of us do and basically learn all this stuff by getting it hilariously wrong and having to careen into rebound situations as a result?Allen: [laugh]. I love that question. I would like to say now, I feel like I have the vision to see something like that coming. Historically, no, not at all. Let me talk a little bit about how I got to where I am because that will shed a lot of context on that question.A few years ago, I was put into a position at Tyler that said, “Hey, go figure out this cloud thing.” Let's figure out what we need to do to move into the cloud safely, securely, quickly, all that rigmarole. And so, I did. I got to hand-select team of engineers from people that I worked with at Tyler over the past few years, and we were basically given free rein to learn. We were an R&D team, a hundred percent R&D, for about a year's worth of time, where we were learning about cloud concepts and theory and building little proof of concepts.CI/CD, serverless, APIs, multi-tenancy, a whole bunch of different stuff. NoSQL was another one of the things that we had to learn. And after that year of R&D, we were told, “Okay, now go do something with that. Go build this application.” And we did, building on our theory our cursory theory knowledge. And we get pretty close to go live, and then the business says, “What do you do in this scenario? What do you do in that scenario? What do you do here?”Corey: “I update my resume and go work somewhere else. Where's the hard part here?”Allen: [laugh].Corey: Turns out, that's not a convincing answer.Allen: Right. So, we moved quickly. And then I wouldn't say we backpedaled, but we hardened for a long time before the—prior to the go-live, with the lessons that we've learned with the eyes of Tyler, the mature enterprise company, saying, “These are the things that you have to make sure that you take into consideration in an actual production application.” One of the things that I always pushed—I was a manager for a few years of all these cloud teams—I always push do it; do it right; do it better. Right?It's kind of like crawl, walk, run. And if you follow my writing from the beginning, just looking at the titles and reading them, kind of like what you were doing, Corey, you'll see that very much. You'll see how I talk about CI/CD, you'll see me how I talk about authorization, you'll see me how I talk about multi-tenancy. And I kind of go in waves where maybe a year passes and you see my content revisit some of the topics that I've done in the past. And they're like, “No, no, no, don't do what I said before. It's not right.”Corey: The problem when I'm writing all of these things that I do, for example, my entire newsletter publication pipeline is built on a giant morass of Lambda functions and API Gateways. It's microservices-driven—kind of—and each microservice is built, almost always, with a different framework. Lately, all the new stuff is CDK. I started off with the serverless framework. There are a few other things here and there.And it's like going architecting, back in time as I have to make updates to these things from time to time. And it's the problem with having done all that myself is that I already know the answer to, “What fool designed this?” It's, well, you're basically watching me learn what I was, doing bit by bit. I'm starting to believe that the right answer on some level, is to build an inherent shelf-life into some of these things. Great, in five years, you're going to come back and re-architect it now that you know how this stuff actually works rather than patching together 15 blog posts by different authors, not all of whom are talking about the same thing and hoping for the best.Allen: Yep. That's one of the things that I really like about serverless, I view that as a giant pro of doing Serverless is that when we revisit with the lessons learned, we don't have to refactor everything at once like if it was just a big, you know, MVC controller out there in the sky. We can refactor one Lambda function at a time if now we're using a new version of the AWS SDK, or we've learned about a new best practice that needs to go in place. It's a, “While you're in there, tidy up, please,” kind of deal.Corey: I know that the DynamoDB fanatics will absolutely murder me over this one, but one of the reasons that I have multiple Dynamo tables that contain, effectively, variations on the exact same data, is because I want to have the dependency between the two different microservices be the API, not, “Oh, and under the hood, it's expecting this exact same data structure all the time.” But it just felt like that was the wrong direction to go in. That is the justification I use for myself why I run multiple DynamoDB tables that [laugh] have the same content. Where do you fall on the idea of data store separation?Allen: I'm a big single table design person myself, I really like the idea of being able to store everything in the same table and being able to create queries that can return me multiple different types of entity with one lookup. Now, that being said, one of the issues that we ran into, or one of the ambiguous areas when we were getting started with serverless was, what does single table design mean when you're talking about microservices? We were wondering does single table mean one DynamoDB table for an entire application that's composed of 15 microservices? Or is it one table per microservice? And that was ultimately what we ended up going with is a table per microservice. Even if multiple microservices are pushed into the same AWS account, we're still building that logical construct of a microservice and one table that houses similar entities in the same domain.Corey: So, something I wish that every service team at AWS would do as a part of their design is draw the architecture of an application that you're planning to build. Great, now assume that every single resource on that architecture diagram lives in its own distinct AWS account because somewhere in some customer, there's going to be an account boundary at every interconnection point along the way. And so, many services don't do that where it's, “Oh, that thing and the other thing has to be in the same account.” So, people have to write their own integration shims, and it makes doing the right thing of putting different services into distinct bounded AWS accounts for security or compliance reasons way harder than I feel like it needs to be.Allen: [laugh]. Totally agree with you on that one. That's one of the things that I feel like I'm still learning about is the account-level isolation. I'm still kind of early on, personally, with my opinions in how we're structuring things right now, but I'm very much of a like opinion that deploying multiple things into the same account is going to make it too easy to do something that you shouldn't. And I just try not to inherently trust people, in the sense that, “Oh, this is easy. I'm just going to cross that boundary real quick.”Corey: For me, it's also come down to security risk exposure. Like my lasttweetinaws.com Twitter shitposting thread client lives in a distinct AWS account that is separate from the AWS account that has all of our client billing data that lives within it. The idea being that if you find a way to compromise my public-facing Twitter client, great, the blast radius should be constrained to, “Yay, now you can, I don't know, spin up some cryptocurrency mining in my AWS account and I get to look like a fool when I beg AWS for forgiveness.”But that should be the end of it. It shouldn't be a security incident because I should not have the credit card numbers living right next to the funny internet web thing. That sort of flies in the face of the original guidance that AWS gave at launch. And right around 2008-era, best practices were one customer, one AWS account. And then by 2012, they had changed their perspective, but once you've made a decision to build multiple services in a single account, unwinding and unpacking that becomes an incredibly burdensome thing. It's about the equivalent of doing a cloud migration, in some ways.Allen: We went through that. We started off building one application with the intent that it was going to be a siloed application, a one-off, essentially. And about a year into it, it's one of those moments of, “Oh, no. What we're building is not actually a one-off. It's a piece to a much larger puzzle.”And we had a whole bunch of—unfortunately—tightly coupled things that were in there that we're assuming that resources were going to be in the same AWS account. So, we ended up—how long—I think we took probably two months, which in the grand scheme of things isn't that long, but two months, kind of unwinding the pieces and decoupling what was possible at the time into multiple AWS accounts, kind of, segmented by domain, essentially. But that's hard. AWS puts it, you know, it's those one-way door decisions. I think this one was a two-way door, but it locked and you could kind of jimmy the lock on the way back out.Corey: And you could buzz someone from the lobby to let you back in. Yeah, the biggest problem is not necessarily the one-way door decisions. It's the one-way door decisions that you don't realize you're passing through at the time that you do them. Which, of course, brings us to a topic near and dear to your heart—and I only recently started have opinions on this myself—and that is the proper design of APIs, which I'm sure will incense absolutely no one who's listening to this. Like, my opinions on APIs start with well, probably REST is the right answer in this day and age. I had people, like, “Well, I don't know, GraphQL is pretty awesome.” Like, “Oh, I'm thinking SOAP,” and people look at me like I'm a monster from the Black Lagoon of centuries past in XML-land. So, my particular brand of strangeness side, what do you see that people are doing in the world of API design that is the, I guess, most common or easy to make mistakes that you really wish they would stop doing?Allen: If I could boil it down to one word, fundamentalism. Let me unpack that for you.Corey: Oh, please, absolutely want to get a definition on that one.Allen: [laugh]. I approach API design from a developer experience point of view: how easy is it for both internal and external integrators to consume and satisfy the business processes that they want to accomplish? And a lot of times, REST guidelines, you know, it's all about entity basis, you know, drill into the appropriate entities and name your endpoints with nouns, not verbs. I'm actually very much onto that one.But something that you could easily do, let's say you have a business process that given a fundamentally correct RESTful API design takes ten API calls to satisfy. You could, in theory, boil that down to maybe three well-designed endpoints that aren't, quote-unquote, “RESTful,” that make that developer experience significantly easier. And if you were a fundamentalist, that option is not even on the table, but thinking about it pragmatically from a developer experience point of view, that might be the better call. So, that's one of the things that, I know feels like a hot take. Every time I say it, I get a little bit of flack for it, but don't be a fundamentalist when it comes to your API designs. Do something that makes it easier while staying in the guidelines to do what you want.Corey: For me the problem that I've kept smacking into with API design, and it honestly—let me be very clear on this—my first real exposure to API design rather than API consumer—which of course, I complain about constantly, especially in the context of the AWS inconsistent APIs between services—was when I'm building something out, and I'm reading the documentation for API Gateway, and oh, this is how you wind up having this stage linked to this thing, and here's the endpoint. And okay, great, so I would just populate—build out a structure or a schema that has the positional parameters I want to use as variables in my function. And that's awesome. And then I realized, “Oh, I might want to call this a different way. Aw, crap.” And sometimes it's easy; you just add a different endpoint. Other times, I have to significantly rethink things. And I can't shake the feeling that this is an entire discipline that exists that I just haven't had a whole lot of exposure to previously.Allen: Yeah, I believe that. One of the things that you could tie a metaphor to for what I'm saying and kind of what you're saying, is AWS SAM, the Serverless Application Model, all it does is basically macros CloudFormation resources. It's just a transform from a template into CloudFormation. CDK does same thing. But what the developers of SAM have done is they've recognized these business processes that people do regularly, and they've made these incredibly easy ways to satisfy those business processes and tie them all together, right?If I want to have a Lambda function that is backed behind a endpoint, an API endpoint, I just have to add four or five lines of YAML or JSON that says, “This is the event trigger, here's the route, here's the API.” And then it goes and does four, five, six different things. Now, there's some engineers that don't like that because sometimes that feels like magic. Sometimes a little bit magic is okay.Corey: This episode is sponsored in part by our friends at Sysdig. Sysdig secures your cloud from source to run. They believe, as do I, that DevOps and security are inextricably linked. If you wanna learn more about how they view this, check out their blog, it's definitely worth the read. To learn more about how they are absolutely getting it right from where I sit, visit Sysdig.com and tell them that I sent you. That's S Y S D I G.com. And my thanks to them for their continued support of this ridiculous nonsense.Corey: I feel like one of the benefits I've had with the vast majority of APIs that I've built is that because this is all relatively small-scale stuff for what amounts to basically shitposting for the sake of entertainment, I'm really the only consumer of an awful lot of these things. So, I get frustrated when I have to backtrack and make changes and teach other microservices to talk to this thing that has now changed. And it's frustrating, but I have the capacity to do that. It's just work for a period of time. I feel like that equation completely shifts when you have published this and it is now out in the world, and it's not just users, but in many cases paying customers where you can't really make those changes without significant notice, and every time you do you're creating work for those customers, so you have to be a lot more judicious about it.Allen: Oh, yeah. There is a whole lot of governance and practice that goes into production-level APIs that people integrate with. You know, they say once you push something out the door into production that you're going to support it forever. I don't disagree with that. That seems like something that a lot of people don't understand.And that's one of the reasons why I push API-first development so hard in all the content that I write is because you need to be intentional about what you're letting out the door. You need to go in and work, not just with the developers, but your product people and your analysts to say, what does this absolutely need to do, and what does it need to do in the future? And you take those things, and you work with analysts who want specifics, you work with the engineers to actually build it out. And you're very intentional about what goes out the door that first time because once it goes out with a mistake, you're either going to version it immediately or you're going to make some people very unhappy when you make a breaking change to something that they immediately started consuming.Corey: It absolutely feels like that's one of those things that AWS gets astonishingly right. I mean, I had the privilege of interviewing, at the time, Jeff Barr and then Ariel Kelman, who was their head of marketing, to basically debunk a bunch of old myths. And one thing that they started talking about extensively was the idea that an API is fundamentally a promise to your customers. And when you make a promise, you'd better damn well intend on keeping it. It's why API deprecations from AWS are effectively unique whenever something happens.It's the, this is a singular moment in time when they turn off a service or degrade old functionality in favor of new. They can add to it, they can launch a V2 of something and then start to wean people off by calling the old one classic or whatnot, but if I built something on AWS in 2008 and I wound up sleeping until today, and go and try and do the exact same thing and deploy it now, it will almost certainly work exactly as it did back then. Sure, reliability is going to be a lot better and there's a crap ton of features and whatnot that I'm not taking advantage of, but that fundamental ability to do that is awesome. Conversely, it feels like Google Cloud likes to change around a lot of their API stories almost constantly. And it's unplanned work that frustrates the heck out of me when I'm trying to build something stable and lasting on top of it.Allen: I think it goes to show the maturity of these companies as API companies versus just vendors. It's one of the things that I think AWS does [laugh]—Corey: You see the similar dichotomy with Microsoft and Apple. Microsoft's new versions of Windows generally still have functionalities in them to support stuff that was written in the '90s for a few use cases, whereas Apple's like, “Oh, your computer's more than 18-months old? Have you tried throwing it away and buying a new one? And oh, it's a new version of Mac OS, so yeah, maybe the last one would get security updates for a year and then get with the times.” And I can't shake the feeling that the correct answer is in some way, both of those, depending upon who your customer is and what it is you're trying to achieve.If Microsoft adopted the Apple approach, their customers would mutiny, and rightfully so; the expectation has been set for decades that isn't what happens. Conversely, if Apple decided now we're going to support this version of Mac OS in perpetuity, I don't think a lot of their application developers wouldn't quite know what to make of that.Allen: Yeah. I think it also comes from a standpoint of you better make it worth their while if you're going to move their cheese. I'm not a Mac user myself, but from what I hear for Mac users—and this could be rose-colored glasses—but is that their stuff works phenomenally well. You know, when a new thing comes out—Corey: Until it doesn't, absolutely. It's—whenever I say things like that on this show, I get letters. And it's, “Oh, yeah, really? They'll come up with something that is a colossal pain in the ass on Mac.” Like, yeah, “Try building a system-wide mute key.”It's yeah, that's just a hotkey away on windows and here in Mac land. It's, “But it makes such beautiful sounds. Why would you want them to be quiet?” And it's, yeah, it becomes this back-and-forth dichotomy there. And you can even explain it to iPhones as well and the Android ecosystem where it's, oh, you're going to support the last couple of versions of iOS.Well, as a developer, I don't want to do that. And Apple's position is, “Okay, great.” Almost half of the mobile users on the planet will be upgrading because they're in the ecosystem. Do you want us to be able to sell things those people are not? And they're at a point of scale where they get to dictate those terms.On some level, there are benefits to it and others, it is intensely frustrating. I don't know what the right answer is on the level of permanence on that level of platform. I only have slightly better ideas around the position of APIs. I will say that when AWS deprecates something, they reach out individually to affected customers, on some level, and invariably, when they say, “This is going to be deprecated as of August 31,” or whenever it is, yeah, it is going to slip at least twice in almost every case, just because they're not going to turn off a service that is revenue-bearing or critical-load-bearing for customers without massive amounts of notice and outreach, and in some cases according to rumor, having engineers reach out to help restructure things so it's not as big of a burden on customers. That's a level of customer focus that I don't think most other companies are capable of matching.Allen: I think that comes with the size and the history of Amazon. And one of the things that they're doing right now, we've used Amazon Cloud Cams for years, in my house. We use them as baby monitors. And they—Corey: Yea, I saw this I did something very similar with Nest. They didn't have the Cloud Cam at the right time that I was looking at it. And they just announced that they're going to be deprecating. They're withdrawing them for sale. They're not going to support them anymore. Which, oh at Amazon—we're not offering this anymore. But you tell the story; what are they offering existing customers?Allen: Yeah, so slightly upset about it because I like my Cloud Cams and I don't want to have to take them off the wall or wherever they are to replace them with something else. But what they're doing is, you know, they gave me—or they gave all the customers about eight months head start. I think they're going to be taking them offline around Thanksgiving this year, just mid-November. And what they said is as compensation for you, we're going to send you a Blink Cam—a Blink Mini—for every Cloud Cam that you have in use, and then we are going to gift you a year subscription to the Pro for Blink.Corey: That's very reasonable for things that were bought years ago. Meanwhile, I feel like not to be unkind or uncharitable here, but I use Nest Cams. And that's a Google product. I half expected if they ever get deprecated, I'll find out because Google just turns it off in the middle of the night—Allen: [laugh].Corey: —and I wake up and have to read a blog post somewhere that they put an update on Nest Cams, the same way they killed Google Reader once upon a time. That's slightly unfair, but the fact that joke even lands does say a lot about Google's reputation in this space.Allen: For sure.Corey: One last topic I want to talk with you about before we call it a show is that at the time of this recording, you recently had a blog post titled, “What does the Future Hold for Serverless?” Summarize that for me. Where do you see this serverless movement—if you'll forgive the term—going?Allen: So, I'm going to start at the end. I'm going to work back a little bit on what needs to happen for us to get there. I have a feeling that in the future—I'm going to be vague about how far in the future this is—that we'll finally have a satisfied promise of all you're going to write in the future is business logic. And what does that mean? I think what can end up happening, given the right focus, the right companies, the right feedback, at the right time, is we can write code as developers and have that get pushed up into the cloud.And a phrase that I know Jeremy Daly likes to say ‘infrastructure from code,' where it provisions resources in the cloud for you based on your use case. I've developed an application and it gets pushed up in the cloud at the time of deploying it, optimized resource allocation. Over time, what will happen—with my future vision—is when you get production traffic going through, maybe it's spiky, maybe it's consistently at a scale that outperforms the resources that it originally provisioned. We can have monitoring tools that analyze that and pick that out, find the anomalies, find the standard patterns, and adjust that infrastructure that it deployed for you automatically, where it's based on your production traffic for what it created, optimizes it for you. Which is something that you can't do on an initial deployment right now. You can put what looks best on paper, but once you actually get traffic through your application, you realize that, you know, what was on paper might not be correct.Corey: You ever noticed that whiteboard diagrams never show the reality, and they're always aspirational, and they miss certain parts? And I used to think that this was the symptom I had from working at small, scrappy companies because you know what, those big tech companies, everything they build is amazing and awesome. I know it because I've seen their conference talks. But I've been a consultant long enough now, and for a number of those companies, to realize that nope, everyone's infrastructure is basically a trash fire at any given point in time. And it works almost in spite of itself, rather than because of it.There is no golden path where everything is shiny, new and beautiful. And that, honestly, I got to say, it was really [laugh] depressing when I first discovered it. Like, oh, God, even these really smart people who are so intelligent they have to have extra brain packs bolted to their chests don't have the magic answer to all of this. The rest of us are just screwed, then. But we find ways to make it work.Allen: Yep. There's a quote, I wish I remembered who said it, but it was a military quote where, “No battle plan survives impact with the enemy—first contact with the enemy.” It's kind of that way with infrastructure diagrams. We can draw it out however we want and then you turn it on in production. It's like, “Oh, no. That's not right.”Corey: I want to mix the metaphors there and say, yeah, no architecture survives your first fight with a customer. Like, “Great, I don't think that's quite what they're trying to say.” It's like, “What, you don't attack your customers? Pfft, what's your customer service line look like?” Yeah, it's… I think you're onto something.I think that inherently everything beyond the V1 design of almost anything is an emergent property where this is what we learned about it by running it and putting traffic through it and finding these problems, and here's how it wound up evolving to account for that.Allen: I agree. I don't have anything to add on that.Corey: [laugh]. Fair enough. I really want to thank you for taking so much time out of your day to talk about how you view these things. If people want to learn more, where is the best place to find you?Allen: Twitter is probably the best place to find me: @AllenHeltonDev. I have that username on all the major social platforms, so if you want to find me on LinkedIn, same thing: AllenHeltonDev. My blog is always open as well, if you have any feedback you'd like to give there: readysetcloud.io.Corey: And we will, of course, put links to that in the show notes. Thanks again for spending so much time talking to me. I really appreciate it.Allen: Yeah, this was fun. This was a lot of fun. I love talking shop.Corey: It shows. And it's nice to talk about things I don't spend enough time thinking about. Allen Helton, cloud architect at Tyler Technologies. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment that I will reject because it was not written in valid XML.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

On this episode of the Humans of DevOps, Jason Baum is joined by Grant Fritchey(@GFritchey) DevOps Advocate at Redgate. They discuss automation, configuration and planning, and how DevOps can help with the shift to hybrid work environments. Grant Fritchey has worked for more than 30 years in IT as a developer and a DBA. He has built systems from the major enterprise to distributed systems to small boutique companies. He is the author of multiple books including SQL Server Execution Plans and SQL Server Query Performance Tuning. He develops and presents complete structured learning plans to teach Azure, AWS, and other data-related topics to developers and other IS personnel. Grant is a Microsoft Data Platform MVP and an AWS Community Builder. Voted Best 25 DevOps Podcasts by Feedspot Thank you to our sponsor Range Want access to more content like this? Gain the tools, resources and knowledge to help your organization adapt and respond to challenges by becoming a member of DevOps Institute. Engage in one of the fastest-growing DevOps communities today! Get started for free: https://www.devopsinstitute.com/membership/ Have questions, feedback or just want to chat? Send us an email at podcast@devopsinstitute.com

They say seeing is believing, and in this case, it's literal. On this episode of the Talking Serverless podcast host, Ryan Jones is joined by the incredible Michael Liendo. Michael is a self-driven developer with a passion for knowledge; he is an AWS Community Builder, Frontend & Serverless instructor, consultant, and recently became a Senior Developer Advocate at AWS! In this episode hear Michael's wild story of how he got into tech, his experience as an AWS Community Builder, and much more. If you like this podcast and want, visit our website where it is all there and always free: talkingserverless.io And if you want to follow this guest on social media you can find him here on Twitter @mtliendo and visit his Github: https://github.com/mtliendo --- Send in a voice message: https://anchor.fm/talking-serverless/message

About Sarah HamiltonSarah Hamilton is a Software Engineer at LEGO Group and an AWS Community Builder. Prior to her current role, she was a Cloud Engineer at aleios. Twitter: @serverlesssarah LinkedIn: https://www.linkedin.com/in/hamilton-sarah/ Medium: https://medium.com/@08hamiltons GitHub: https://github.com/hamilton-s

Maheswarakumar said about AWS Community Builder, Data, AWS Glue.he is from india. --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app

On this episode of the Talking Serverless Podcast Ryan Jones is joined by the always lovely Igor Soroka. Igor is a highly motivated, self-driven, and confident IT professional who actively participates in hackathons, meetups, and conferences—which has earned him the title of AWS Community Builder. For work, Igor does Software Consulting at Soroka Tech, focusing on Digital Transformations, where he gives hands-on technical consulting on AWS migrations, the building of DevOps practices, and the adoption of serverless technologies. For more content with both Igor and Ryan, check out this episode of the Serverless Panel HERE Find Igor on Twitter: @Grenguar Follow his Blog: https://tap.link/grenguar --- Send in a voice message: https://anchor.fm/talking-serverless/message

In this episode of the Tiaras and Tech podcast, Shelley Benhoff talks to Nikema Prophet on the topic of being your authentic self. Shelley is a Business Owner, Author, and Professional Speaker. She is also a Sitecore Technology MVP with experience as a Lead Developer for many years. Intro Hello Gems! Welcome to another episode of Tiaras and Tech. I'm your host, Shelley Benhoff, and today I'm talking to Nikema Prophet about Being Your Authentic Self. She's passionate about developer relations and is an AWS Community Builder. We talked about her journey into tech from a dance background, how ADHD has impacted her career, and learning how to speak up and live your truth. Without further ado, on to the episode! Connect with Nikema! https://twitter.com/dev_nikema https://instagram.com/nikema https://www.linkedin.com/in/nikemaprophet/ Connect with Shelley! https://twitter.com/sbenhoff https://pluralsight.pxf.io/mgGLbO Tiaras and Tech is dedicated to providing inspiration for women & marginalized groups in tech. We aim to provide support, celebrate successes, & discuss how we're treated. Follow us! YouTube, Twitter, TikTok, Instagram @tiarasandtech tiarasandtech.com Tiaras and Tech is a HoffsTech production. Thank you to Jerome Heaven for producing this episode! Theme music by Nobuo Uematsu and Juan Medrano https://ocremix.org/remix/OCR03610 --- Support this podcast: https://anchor.fm/tiaras-and-tech/support

Tonight will be talking with Kristi Perreault (@kperreault95) covering Serverless DevOps, and how to scale a Serverless First initiative inside of your organization. Kristi is a Senior Software Engineer in Serverless Enablement and Development at Liberty Mutual Insurance, and the conversation we will be having tonight dives into what she and her team have been working on. In addition, we will explore guidance, lessons learned, and advice for your organization as it relates to scaling and enabling teams adopting and innovating with serverless. Kristi holds a Masters Degree in Electrical and Computer engineering, is a member and advocate for Women Who Code, as well as an AWS Community Builder member! So sit back, relax, and get ready to dive into how to scale a Serverless First Initiative with vBrownBag and Kristi. Resources: https://www.womenwhocode.com/ https://twitter.com/kperreault95 https://www.linkedin.com/in/kristi-perreault/ https://kristiperreault.medium.com/

Wiele osób planuje zmianę kariery I wejście w świat IT. Jak praktycznie może to wyglądać? W tym odcinku rozmawiam z Karoliną Boboli o tym, jak od księgowej doszła do pozycji architekta chmury pracującego z AWS. Karolina nie zajmuje się chmurą tylko profesjonalnie ale też tworzy swoją społeczność dookoła technologii I jest AWS Community Builder.Ta rozmowa nie tylko pokaże Ci, jak może wyglądać kariera architekta, ale jak “chcieć” znaczy “móc” I jak zmiana kariery o 360 stopni wygląda w praktyce.>>> ====  TY MOŻESZ BYĆ CZĘŚCIĄ TEGO PODCASTU ====

In this episode, Dave chats with Jason Dunn, Sr. Developer Community Manager at AWS, and owner of the AWS Community Builders program. The program offers technical resources, mentorship, and networking opportunities to AWS technical enthusiasts and emerging thought leaders who are passionate about sharing knowledge and connecting with the technical community. Jason covers what it's like to run a program with over 1,700 members across 90 countries, what community builders are creating today, and how you can apply to be a member this month! Jason on Twitter: https://twitter.com/jasondunn Dave on Twitter: https://twitter.com/thedavedev Jason on LinkedIn: https://www.linkedin.com/in/jasonrobertdunn/ Jason's Blog: http://www.jasondunn.com/ AWS Community Builders Program: https://go.aws/33wR7se Community Builders Content on Dev.to: https://bit.ly/3KeG7Aw How to Become an AWS Community Builder by Stephen Sennett https://bit.ly/3GtNiCQ Telnet BBS Guide: https://www.telnetbbsguide.com/ Hayes Modem AT Commands: https://en.wikipedia.org/wiki/Hayes_command_set Apply Here for the Community Builders Program – applications are open January 10th – January 24th, 2022! https://bit.ly/3K8w0gR ------------------- Subscribe: Amazon Music: https://music.amazon.com/podcasts/f8bf7630-2521-4b40-be90-c46a9222c159/aws-developers-podcast Apple Podcasts: https://podcasts.apple.com/us/podcast/aws-developers-podcast/id1574162669 Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5zb3VuZGNsb3VkLmNvbS91c2Vycy9zb3VuZGNsb3VkOnVzZXJzOjk5NDM2MzU0OS9zb3VuZHMucnNz Spotify: https://open.spotify.com/show/7rQjgnBvuyr18K03tnEHBI TuneIn: https://tunein.com/podcasts/Technology-Podcasts/AWS-Developers-Podcast-p1461814/ RSS Feed: https://feeds.soundcloud.com/users/soundcloud:users:994363549/sounds.rss

About AaronI am a Cloud Focused Product Management and Technical Product Ownership Consultant. I have worked on several Cloud Products & Services including resale, management & governance, cost optimisation, platform management, SaaS, PaaS. I am also recognised as a AWS Community Builder due to my work building cloud communities cross-government in the UK over the last 3 years. I have extensive commercial experience dealing with Cloud Service Providers including AWS, Azure, GCP & UKCloud. I was the Single Point of Contact for Cloud at the UK Home Office and was the business representative for the Home Office's £120m contract with AWS. I have been involved in contract negotiation, supplier relationship management & financial planning such as business cases & cost management.I run a IT Consultancy called Embue, specialising in Agile, Cloud & DevOps consulting, coaching and training. Links: Twitter: https://twitter.com/AaronBoothUK LinkedIn: https://www.linkedin.com/in/aaronboothuk/ Embue: https://embue.co.uk Publicgood.cloud: https://publicgood.cloud TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: It seems like there is a new security breach every day. Are you confident that an old SSH key, or a shared admin account, isn't going to come back and bite you? If not, check out Teleport. Teleport is the easiest, most secure way to access all of your infrastructure. The open-source Teleport Access Plane consolidates everything you need for secure access to your Linux and Windows servers, and I assure you there is no third option there. Kubernetes clusters, databases, and internal applications like AWS Management Console, Yankins, GitLab, Grafana, Jupyter Notebooks, and more. Teleport's unique approach is not only more secure, it also improves developer productivity. To learn more visit: goteleport.com. And not, that is not me telling you to go away, it is: goteleport.com.Corey: This episode is sponsored in part by our friends at Rising Cloud, which I hadn't heard of before, but they're doing something vaguely interesting here. They are using AI, which is usually where my eyes glaze over and I lose attention, but they're using it to help developers be more efficient by reducing repetitive tasks. So, the idea being that you can run stateless things without having to worry about scaling, placement, et cetera, and the rest. They claim significant cost savings, and they're able to wind up taking what you're running as it is in AWS with no changes, and run it inside of their data centers that span multiple regions. I'm somewhat skeptical, but their customers seem to really like them, so that's one of those areas where I really have a hard time being too snarky about it because when you solve a customer's problem and they get out there in public and say, “We're solving a problem,” it's very hard to snark about that. Multus Medical, Construx.ai and Stax have seen significant results by using them. And it's worth exploring. So, if you're looking for a smarter, faster, cheaper alternative to EC2, Lambda, or batch, consider checking them out. Visit risingcloud.com/benefits. That's risingcloud.com/benefits, and be sure to tell them that I said you because watching people wince when you mention my name is one of the guilty pleasures of listening to this podcast.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. So, when I went to re:Invent last year, I discovered a whole bunch of things I honestly was a little surprised to discover. One of those things is my guest today, Aaron Booth, who's a cloud consultant with an emphasis on sustainability. Now, you see a number of consultants at things like re:Invent, but what made Aaron interesting was that this was apparently his first time visiting the United States, and he started with not just Las Vegas, but Las Vegas to attend re:Invent. Aaron, thank you for joining me, and honestly, I'm a little surprised you survived.Aaron: Yeah, I think one of the things about going to Las Vegas or Nevada is no one really prepared me for how dry it was. I ended up walking out of re:Invent with my fingers, like, bleeding, and everything else. And there was so much about America that I didn't expect, but that was one thing I wish somebody had warned me about. But yeah, it was my first time in the US, first time at re:Invent, and I really enjoyed it. It was probably the best investment in myself and my business that I think I've done so far.Corey: It's always strange to look at a place that you live and realize, oh, yeah, this is far away for someone else. What would their experience be of coming and learning about the culture we have here? And then you go to Las Vegas, and it's easy to forget there are people who live there. And even the people who live there do not live on the strip, in the casinos, at loud, obnoxious cloud conferences. So, it feels like it's one of those ideas of oh, I'm going to go to a movie for the first time and then watching something surreal, like Memento or whatnot, that leaves everyone very confused. Like, “Is this what movies are like?” “Well, this one, but no others are quite like that.” And I feel that way about Las Vegas and re:Invent, simultaneously.Aaron: I mean, talking about movies, before it came to the US and before I came to Vegas, I was like, “Oh, how can I prepare myself for this trip?” I ended up watching Fear and Loathing in Las Vegas. And I don't know if you ever seen it, with Johnny Depp, but it's probably not the best representation, or the most modern representation what Vegas would be like. And I think halfway through the conference, went down to Fremont Street in the old downtown. And they have this massive, kind of, free block screen in the sky that is lit up and doing all these animations. And you're just thinking, “What world am I on?” And it kind of is interesting as well, from a point of view of, we're at this tech conference; it's in Vegas; what is the reason for that? And there's obviously lots of different things. We want people to have fun, but you know, it is an interesting place to put 30,000 people, especially during a pandemic.Corey: It really is. I imagine it's going to have to stay there because in a couple more years, you're going to need a three block long screen just to list all of the various services that AWS offers because they don't believe in turning anything off. Now, it would be remiss for me not to ask you, what was announced at re:Invent that got you the most, let's call it excited, I guess? What got you enthusiastic? What are you happy to start working with more?Aaron: I think from my perspective, there's a few different announcements. The first one that comes to mind is the stuff of AWS Amplify Studio, and that's taken this, kind of, no-code Figma designs and turn into a working front end. And it's really interesting for me to think about, okay, what is the point of cloud? Why are we moving forward in the world, especially in technology? And, you know, abstracting a lot of stuff we worry about today to simple drag-and-drop tools is probably going to be the next big thing for most of the world.You know, we've come from a privileged position in the West where we follow technology along the whole of the journey, where now we have an opportunity to open this out to many more regions, and many more AWS customers, for example. But for me, as a small business owner—I've run multiple businesses—there's a lot of effort you put into, okay, I need to set up a business, and a website, and newsletter, or whatever else. But the more you can just turn that into, “I've got an idea, and I can give it to people with one click,” you'll enable a lot more business and a lot more future customers as well.Corey: I was very excited about that one, too, just from a perspective of I want to drag and drop something together to make a fairly crappy web app, that sounds like the thing that I could use to do that. No, that feels a lot more like what Honeycode is trying to be, as opposed to the Amplify side of the world, which is still very focused on React. Which, okay, that makes sense. There's a lot of front end developers out there, and if you're trying to get into tech today and are asking what language should I learn, I would be very hard-pressed to advise you pick anything that isn't JavaScript because it is front end, it is back end, it runs slash eats the world. And I've just never understood it. It does not work the way that I think about computers because I'm old and grumpy. I have high hopes of where it might go, but so far I'm looking at it's [sigh] it's not what I want it to be, yet. And maybe that's just because I'm weird.Aaron: Well, I mean, you know, you mentioned part of the problem really is two different competing AWS services themselves, which with a business like AWS and their product strategy being the word, “Yes,” you know, you're never really going to get a lot of focus or forward direction with certain products. And hopefully, there'll be the next, no-code tool announced in re:Invent in a few years' time, which is exactly what we're looking for, and gives startup founders or small businesses drag-and-drop tools. But for now, there's going to be a lot of competing services.Corey: There's so much out there that it's almost impossible to wind up contextualizing re:Invent as a single event. It feels like it's too easy to step back and say, “Oh, okay. I'm here to build websites”—is what we're talking about now in the context of Amplify—and then they start talking about mainframes. And then they start talking about RoboRunner to control 10,000 robots at once. And I'm looking around going, “I don't have problems that feel a lot like that. What's the deal?”Aaron: I think even just, like you said in perspective of re:Invent is like, when you go to an event like this, that you can't experience everything and you probably have a very specific focus of, you know, what am I here to do. And I was really surprised—again, my first time at a big tech conference, as well as Vegas and the US is, how important it was just to meet people and how valuable that was. First time I met you, and you know, going from somebody who's probably very likely interacted with you on Twitter before the event to being on this podcast and having a great conversation now is kind of crazy to think that the value you can get out of it. I mean, in terms of over services, and areas of re:Invent that I found interesting was the announcement of the new sustainability pillar, as part of the well-architected framework. You know, I've tried to use that before in previous workplaces, and it has been useful. You know, I'm hoping it is more useful in the future, and the cynical part of me worries about whether the whole point of putting this as part of a well-architected framework review where the customer is supposed to do it is Amazon passing the buck for sustainability. But it's an interesting way forward for what we care about.Corey: An interesting quirk of re:Invent—to me—has always been that despite there being tens of thousands of people there are always a few folks that you wind up running into again and again and again throughout the week. One year for me it was Ben Kehoe; this trip it was you where we kept finding ourselves at the same events, we kept finding ourselves at the same restaurants, and we had three or four meals together as a result, and it was a blast talking to you. And I was definitely noticing that sustainability was a topic that you kept going back to a bunch of different ways. I mean previously, before starting your current consulting company, you did a lot of work in the government—specifically the UK Government, for those who are having trouble connecting the fact this is the first time in America to the other thing. Like, “Wow, you can be far away and work for the government?” It's like, we have more than one on this planet, as it turns out.Yes, it was a fun series of conversations, and I am honestly a little less cynical about the idea of the sustainability pillar, in no small part due to the conversations that we had together. I initially had the cynical perspective of here's how to make your cloud infrastructure more sustainable. It's, isn't that really a “you” problem? You're the cloud provider. I can't control how you get energy on the markets, how you wind up handling heat issues, how you address water issues from your data center outflows, et cetera. It seems to me that the only thing I can really do is use the services you give me, and then it becomes a “you” problem. You have a more nuanced take on it.Aaron: I think there's a log of different things to think about when it comes to sustainability. One of the main ones is, from my perspective, you know, I worked at the UK Home Office in the UK, and we'd been using cloud for about six or seven years. And just looking at how we use clouds as an enterprise organization, one of the things I really started to see was these different generations of cloud and you've got aspects of legacy infrastructure, almost, that we lifted-and-shifted in the early days, versus maybe stuff would run on serverless now. And you know, that's one element, from a customer is how you control your energy usage is actually the use of servers, how efficient your code is, and there's definitely a difference between stringing together EC2 and S3 buckets compared to using serverless or Lambda functions.Corey: There's also a question of scale. When I'm trying to build something out of Lambda functions, and okay, which region is the most cost effective way to run this thing? The Google search for that will have a larger climate impact than any decision I can make at the scale that I operate at. Whereas if you're a company running tens of thousands of instances at any given point in time and your massive scale, then yeah, the choices you make are going to have significant impact. I think that a problem AWS has always struggled with has been articulating who needs to care about what, when.If you go down the best practices for security and governance and follow the white papers, they put out as a one-person startup trying to build an idea this evening, just to see if it's viable, you're never going to get anywhere. If you ignore all those things, and now you're about to go public as a bank, you're going to have a bad time, but at what point do you have to start caring about these different things in different ways? And I don't think we know the answer yet, from a sustainability perspective.Aaron: I think it's interesting in some senses, that sustainability is only just enter the conversation when it comes to stuff we care about in businesses and enterprises. You know, we all know about risk registers, and security reviews, and all those things, but sustainability, while we've, kind of, maybe said nice public statements, and put things on our website, it's not really been a thing that's, okay, this is how we're going to run our business, and the thing we care about as number one. You know, Amazon always says security is job zero, but maybe one day someone will be saying sustainability is our job zero. And especially when it comes down to, sort of, you know, the ethics of running a business and how you want that to be run, whether it is going to be a capitalistic VC-funded venture to extract wealth from citizens and become a billionaire versus creating something that's a bit more circular, and gives back as sustainability might be a key element of what you care about when you make decisions.Corey: The challenge that I find as well is, I don't know how you can talk about the relative sustainability impact of various cloud services within the AWS umbrella without, effectively, AWS explaining to you what their margins are on different services, in many respects. Power usage is the primary driver of this and that determines the cost of running things. It is very clear that it is less expensive and more efficient to run more modern hardware than older hardware, so we start seeing, okay, wow, if I start seeing those breakdowns, what does that say about the margin on some of these products and services? And I don't think they want to give that level of transparency into their business, just because as soon as someone finds out just how profitable Managed NAT gateways are, my God, everything explodes.Aaron: I think it's interesting from a cloud provider or hyperscaler perspective, as well, is, you know, what is your USP? And I think Amazon is definitely not saying sustainability is their USP right now, and I think you know, there are other cloud providers, like Azure for example, who basically can provide you a Power BI plugin; if you just log in with your Cloud account details, it will show you a sustainability dashboard and give you more of this information that you might be looking for, whereas Amazon currently doesn't offer anything like that automated. And even having conversations with your account team or trying to get hold of the right person, Amazon isn't going to go anywhere at the moment, just because maybe that's the reason why we don't want to talk about it: It's too sensitive. I'm sure that'll change because of the public statements they've made at re:Invent now and previously of, you know, where they're going in terms of energy usage. They want to be carbon neutral by 2025, so maybe it'll change to next re:Invent, we'll get the AWS Sustainability Explorer add-on for [unintelligible 00:15:23] or 12—Corey: Oh no.Aaron: —tools to do the same thing [laugh].Corey: In the Google Cloud Console, you click around, and there are green leafs next to some services and some regions, and it's, on the one hand, okay, I appreciate the attention that is coming from. On the other hand, it feels like you're shaming me for putting things in a region that I've already built things out in when there weren't these green leafs here, and I don't know that I necessarily want to have that conversation with my entire team because we can't necessarily migrate at this point. And let's also be clear, here, I cannot fathom a scenario in which running your own data centers is ever going to be more climate-friendly than picking a hyperscaler.Aaron: And I think that's sort of, you know, we all might think about is, at the end of the day, if your sustainability strategy for your business is to go all-in-on cloud, and bet horse on AWS or another cloud provider, then, at the end of the day, that's going to be viable. I know, from the, sort of, hands-on stuff I've done with our own data centers, you can never get it as efficient as what some of these cloud providers are doing. And I mean, look at Microsoft. The fact that they're putting some of their data centers under the sea to use that as a cooling mechanism, and kind of all the interesting things that they're able to do because they can invest at scale, you're never going to be able to do that with the cupboard beyond the desks in your local office to make it more efficient or sustainable.Corey: There are definite parallels between Cloud economics and sustainability because as mentioned, I worship at the altar of Our Lady of Turn that Shit Off because that's important. If you don't have a workload running and it doesn't exist, it has no climate impact. Mostly. I'm sure there are corner cases. But that does lead to the question then of okay, what is the climate sustainability impact, for example, of storing a petabyte of data and EBS versus in S3?And that has architectural impact as well, and there's also questions of how often does it move because when you move it, Lord knows there is nothing more dear than the price of data transfer for data movement. And in order to answer those questions, they're going to start talking a lot more about their architecture. I believe that is why Peter DeSantis's keynote talked so much about—finally—the admission of what we sort of known for ages now that they use erasure coding to make S3 as durable yet inexpensive, as it is. That was super interesting. Without that disclosure, it would have been pretty clear as soon as they start publishing sustainability numbers around things like that.Aaron: And I think is really interesting, you know, when you look at your business and make decisions like that. I think the first thing to start with is do you need that data at all? What's a petabyte of data are going to do? Unless it's for serious compliance reasons for, you know, the sector or the business that you're doing, the rest of it is, you know, you've got to wonder how long is that relevant for. And you know, even as individuals, we could delete junk mail and take things off our internal emails, it's the same thing of businesses, what you're doing with this data.But it is interesting, when you look at some of the specific services, even just the tiering of S3, for example, put that into Glacier instead of keeping it on S3 general. And I think you've talked about this before, I think cost the same to transfer something in and out of Glacier as just to hold it for a month. So, at the end of the day, you've got to make these decisions in the right way, and you know, with the right goals in mind, and if you're not able to make these decisions or you need help, then that's where, you know, people like us come in to help you do this.Corey: There's also the idea of—when I was growing up, the thing they always told us about being responsible was, “Oh, turn out the lights when you're not in the room.” Great. Well, cloud economics starts to get in that direction, too. If you have a job that fires off once a day at two in the morning and it stops at four in the morning, you should not be running those instances the other 22 hours of the day. What's the deal here?And that becomes an interesting expiratory area just as far as starting to wonder, okay, so you're telling me that if I'm environmentally friendly, I'm also going to save money? Let's be clear people, in many cases—in a corporate sense—care about sustainability only insofar as that don't get yelled out about it. But when it comes to saving money, well, now you've got the power of self-interest working for you. And if you can dress them both up and do the exact same things and have two reasons to do it. That feels like it could in some respects, be an accelerator towards achieving both outcomes.Aaron: Definitely. I think, you know, at the end of the day, we all want to work on things that are going to hopefully make the world a better place. And if you use that as a way of motivating, not just yourself as a business, but the workforce and the people that you want to work for you, then that is a really great goal as well. And I think you just got to look at companies that are in this world and not doing very great things that maybe they end up paying more for engineers. I think I read an interesting article the other day about Facebook is basically offering almost double or 150 percent of over salaries because it feels like a black mark on the soul to work for that company. And if there is anything—maybe it's not greenwashing per se, but if you can just make your business a better place, then that could be something that you can hopefully attract other like-minded people with.Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of, “Hello World” demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And let me be clear here, it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself all while gaining the networking, load balancing, and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications, or do proof-of-concept testing without spending a dime. You know that I always like to put asterisks next to the word free. This is actually free, no asterisk. Start now. Visit snark.cloud/oci-free that's snark.cloud/oci-free.Corey: One would really like to hope that the challenge, of course, is getting there in such a way that it, well, I guess makes sense, is probably the best way to frame it. These are still early days, and we don't know how things are going to wind up… I guess, it playing out. I have hopes, I have theories, but I just don't know.Aaron: I mean, even looking at Cloud as a concept, how long we've all worked with this now ranges probably from fifteen to five, and for me the last six years, but you got to think looking at the outages at the end of last year at Amazon, that [unintelligible 00:21:57], very close to re:Invent, that impacted a lot of different workloads, not just if you were hosted in us-west or east-1, but actually for a lot of the regional services that actually were [laugh]… discovered to be kind of integral to these regions. You know, one AZ going down can impact single-sign-on logins around the world. And let's see what Amazon looks like in ten years' time as well because it could be very different.Corey: Do you find that as you talk to folks, both in government and in private sector, that there is a legitimate interest in the sustainability story? Or is it the self-serving cynical perspective that I've painted?Aaron: I mean, a lot of my experience is biased towards the public sector, so I'll start with that. In terms of the public sector, over the last few years, especially in the UK, there's been a lot more focus on sustainability as part of your business cases and your project plans for when you're making new services or building new things. And one of the things they've recently asked every government department in the UK to do is come up with a sustainability strategy for their technology. And that's been something that a lot of people have been working on as part of something called the One Gov Cloud Strategy Working Groups—which in the UK, we do love an abbreviation, so [laugh] a bit of a long name—but I think there's definitely more of an interest in it.In terms of the private sector, I'm not too sure if that's something that people are prioritizing. A lot of the focus I kind of come across as either, we want to focus on enterprise customers, so we're going to offer migration professional services, or you're a new business and you're starting to go up and already spending a couple a hundred pounds, or thousands of pounds a month. And at that scale, it's probably not going to be something you need to worry about right now.Corey: I want to talk a little bit about how you got into tech in the first place because you told me elements of this story, and I generally find them to be—how do I put this?—they strain the bounds of credulity. So, how did you wind up in this ridiculous industry?Aaron: I mean, hoping as I explain them, you don't just think I'm a liar. I have got a Scouse accent, so you're probably predisposed towards it. But my journey into tech was quite weird, I guess, in the sense that when I was 16—I was, again, like I said, born in Liverpool and didn't really know what I wanted to do in the world, and had no idea what the hell to do. So, I was at college, and kind of what happened to me there is I joined, like, an entrepreneurship club and was like, “Okay, I'll start my own business and do something interesting.” And I went to a conference at college, and there was a panel with Richard Branson and other few of business leaders, and I stood up and asked the question said, you know, “I'm 16. I want to start a business. Where can I get money to start a business?”And the panel answered with kind of a couple of different things, but one of them was, “Get a job.” The other one was, “Get money off your parents.” And I was kind of like, “Oh, a bit weird. I've got a job already. You know, I would ask my parents put their own benefits.”And asked the woman with the microphone, “Can I say something back?” And she said, “No.” So, being… a young person, I guess, and just I stood back up and said, you know, “You're in Liverpool. You've kind of come to one of the poorest cities in some sense in the UK, and you kind of—I've already got a job. What can I really do?”And that's when Richard Branson turned round and said, “Well, what is it you want to do?” And I said, “I make really good cheesecakes and I want to sell them to people.” And after that sort of exchange, he said he'd give me the money. So, he gave me 200 pounds to start my own business. And that was just, kind of like, this whirlwind of what the hell's going on here?But for me, it's one of those moments in my life, which I think back on, and honestly, it's like one of these ten [left 00:25:15] moments of, you know, I didn't stand back up and say something, if I didn't join the entrepreneurship club, like, I just wouldn't be in the position I am right now. And it was also weird in the sense that I said at the start of the story, I didn't know what I wanted to do in my life. This was the first time that anyone had ever said to me, “I trust you to do something, and here's 200 pounds to do it.” And it was such a small thing, and a small moment that basically got me to where I am today. And kind of a condensed version of that is, you know, after that event, I started volunteering for a charity who—a, sort of, magazine launch, and then applied for the civil service and progressed through six to eight years of the civil service.And it was because of that moment, and that experience, and that confidence boost, where I was like, “Oh, I actually can do something with my life.” And I think tech, and I think a lot of people talk about this is, it can be a bit of a crazy whirlwind, and to go from that background into, you know, working with great people and earning great money is a bit of a crazy thing sometimes.Corey: Is there another path that you might have gone down instead and completely missed out on, for lack of a better term—and not missed out. You probably would have been far happier not working in tech; I know I would have been—but as far as trying to figure out, like, what does the road not taken look like for you?Aaron: I'm not too sure, really. And at the time, I was working in a club. I was like 16, 17 years old, working in a nightclub in Liverpool for five pounds an hour, and was doing that while I was studying, and that was almost like, what was in my mind at the time. When it came to the end of college, I was applying for universities, I got in on, like, a second backup course, and that was the only thing to do was food science. And it was like, I can't imagine coming out of university three years after that, studying something that's not really that relevant to a lot of industries, and trying to find a good job. It could have just been that I was working in a supermarket for minimum wage after I came out for uni trying to find what I wanted to do in the world. And, yeah, I'm really glad that I kind of ended up where I am now.Corey: As you take a look at what you want your career to be about in the broad sweep of things, what is it that drives you? What is it that makes you, for example, decide to spend the previous portion of career working in public service? That is a very, shall we say, atypical path—I say, as someone who lives in San Francisco and is surrounded by people who want to make the world a better place, but all those paths just coincidentally would result in them also becoming billionaires along the way.Aaron: I mean, it is interesting. You know, one of the things that worked for the civil service for so long, is the fact that I did want to do more than just make somebody else more money. And you know, there are not really a lot of ways you can do that and make a good wage for yourself. And I think early on in your career, working for somewhere like the civil service or federal government can be a little bit of that opportunity. And especially with some of the government's focus on tech these days, and investments—you know, I joined through an apprenticeship scheme and then progressed on to a digital leadership scheme, you know, they were guided schemes to help me become a better leader and improve my skills.And I think I would have probably not gone to the same position if I just got the tech job or my first engineering job somewhere else. I think, if I was to look at the future and where do I want to go, what do I care about? And, you know, you ask me, sort of, this question at re:Invent, and it took me a few days to really figure out, but one of the things when I talk about making the world a better place is thinking about how you can start businesses that give back to people in local areas, or kind of solve problems and kind of keep itself running a bit like a trust does, [laugh], if only that keeping rich people running. And a lot of the time, like, you've highlighted is coincidentally these things that we try and solve whether it's, like, a new app or a new thing that does something seems to either be making money for VCs, reinventing things that we already have, or just trying to make people billionaires rather than trying to make everyone rise up and—high tide rise all ships, is the saying. And there are a few people that do this, a few CEOs who take salaries the same as everyone else in the business. And I think that's hopefully you know, as I grow my own business and work on different things in the future, is how can I just help people live better lives?Corey: It's a big question, and it's odd in that I don't find that most people asking it tend to find themselves going toward government work so much as they do NGOs, and nonprofits, and things that are very focused on specific things.Aaron: And it can be frustrating in some sense is that, you know, you look at the landscape of NGOs, and charities, and go, “Why are they involved in solving this problem?” You know, one of the big problems we have in the UK is the use of food banks where people who don't have enough money, whether they receive benefits or not, have to go and get food which is donated just by people of the UK and people who donate to these charities. You know, at the end of the day, I'm really interested in government, and public sector work, and potentially one day, being a bit more involved in policy elements of that, is how can we solve these problems with broad brushstrokes, whether it's technology advancements, or kind of policy decisions? And one of the interesting things that I got close to a few times, but I don't think we've ever really solved is stuff like how can we use Agile to build policy?How can we iterate on what that policy might look like, get customers or citizens of countries involved in those conversations, and measure outcomes, and see whether it's successful afterwards. And a lot of the time, policies and decisions are just things that come out of politicians minds, and it'd be interesting to see how we can solve some of these problems in the world with stuff like Agile methodologies or tech practices.Corey: So, it's easy to sit and talk about these things in the grand sweep of how the world could be or how it should look, but for those of us who think in more, I guess, tactical terms, what's a good first step?Aaron: I think from my point of view, and you know, meeting so many people at re:Invent, and just have my eyes opened of these great conversations we can have a great people and get things changed, one of the things that I'm looking at starting next year is a podcast and a newsletter, around the use of public cloud for public good. And when I say that, it does cover elements of sustainability, but it is other stuff like how do we use Cloud to deliver things in the public sector and NGOs and charities? And I think having more conversations like that would be really interesting. Obviously, that's just the start of a conversation, and I'm sure when I speak to more people in the future, more opportunities and more things might come out of it. But I'd just love to speak to more people about stuff like this.Corey: I want to thank you for spending so much time to speak with me today about… well, the wide variety of things, and of course, spending as much time as you did chatting with me at re:Invent in person. If people want to learn more, where can they find you?Aaron: So yep, got a few social media handles on Twitter, I'm @AaronBoothUK. On LinkedIn is the same, forward slash aaronboothuk, and I've also got the website for my consultancy, which is embue.co.uk—E-M-B-U-E dot co dot uk. And for the newsletter, it's publicgood.cloud.Corey: And we will, of course, include links to that in the [show notes 00:32:11]. Thank you so much for taking the time to speak with me. I really do appreciate it.Aaron: Thank you so much for having me.Corey: Aaron Booth, cloud consultant with an emphasis on sustainability. I'm Cloud Economist Corey Quinn with an emphasis on optimizing bills. And this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment that you will then kickstart the coal-burning generator under your desk to wind up posting.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.

Do you currently feel stuck in your career? Do you want to make a career transition but don't know how to start? This is the perfect episode for you! Today on the show, Grace chats with Linda Vivah a Software Engineer, an AWS Community Builder, a mom of 2, a part-time wedding singer &  founder of Coding Crystals about how to get unstuck in your career and develop the mindset needed to make successful career transitions.    Linda Vivah is a Software Engineer at a major media organization in NYC, an AWS Community Builder, a mom of 2, a part-time wedding singer & the founder of a shop called Coding Crystals: a jewelry & accessories company taking inspiration from STEM. She creates content around tech including coding, cloud computing, career tips with a sprinkle of lifestyle. Linda had an untraditional journey into tech and broke into tech post-college via self-studying and attending a coding bootcamp. She currently works as an SRE (Site Reliability Engineer). She was previously working as a Web Application Developer (mainly JavaScript) for 5 years and transitioned from Web Development to an SRE role last year to be more hands-on in the cloud computing space.  Key takeaways: How to shift your mindset when you feel stuck in your career Practical tips for getting unstuck in your career How to learn a new skill while balancing your day job Why most people in tech experience imposter syndrome  The truth about coding bootcamps Top 3 things you should look for in your first tech job Resources: AWS Certified Cloud Practitioner (CLF-C01) The Cloud Resume Challenge AWS Certified Solutions Architect – Associate Flatiron Bootcamp Follow Tech Unlocked for career tips: Website Substack Twitter Instagram   Connect with Grace: Instagram Twitter LinkedIn   Connect with Linda: Instagram TikTok YouTube Twitter Medium Coding Crystals Shop   Enjoyed listening to this episode? Please leave a review on iTunes and Spotify. Questions about sponsorship? Email us techunlockedpod@gmail.com    

Adam is an independent cloud consultant helping startups build products on AWS. He's also the host of AWS FM, a weekly podcast and live audio show where he shares stories from around the AWS community. Adam holds all twelve AWS certifications and is an AWS Community Builder. He's the creator of ness.sh, a CLI tool for deploying web sites and apps into your own AWS account. He's also the co-founder of StatMuse, a Disney and Google backed startup building search technology for sports and financial information. Adam lives in Nixa, Missouri, with his wife and two young boys. Twitter: https://twitter.com/aeduhm  LinkedIn: https://www.linkedin.com/in/adamelmore/ Consulting Site: https://adam.dev/ AWS.FM Podcast: https://aws.fm/

In dieser Episode spricht Dennis mit Linda Mohamed über das AWS Community-Builder-Programm, die AWS Usergroup in Wien und eine Idee, um Jongliershows mit Hilfe von Künstlicher Intelligenz und Maschinellem Lernen auch über den Sehsinn hinaus erlebbar zu machen. Linda ist Co-Organisatorin des AWS Meetup in Wien, Teilnehmerin im AWS-Community-Builder-Programm und AI/ML-Enthusiastin bei creative-it, einem Wiener Software- und Consulting-Unternehmen. Ihr findet sie auf: LinkedIn: https://www.linkedin.com/in/linda-mohamed Twitter: https://twitter.com/linda_mhmd Instagram: https://www.instagram.com/mrs_lee_g und bei creative-it: https://www.creative-it.com Weitere Links zur Sendung: AWS Meetup Wien: https://www.meetup.com/Amazon-Web-Services-AWS-Vienna Deutschsprachige AWS Community: https://www.aws-community.de Das AWS Community Builders-Programm: https://aws.amazon.com/developer/community/community-builders Sonic Pi – The Live Coding Music Synth for Everyone: https://sonic-pi.net Der offizielle deutschsprachige Podcast rund um Amazon Web Services (AWS), für Neugierige, Cloud-Einsteiger und AWS-Experten, produziert von Dennis Traub, Developer Advocate bei AWS. Bei Fragen, Anregungen und Feedback wendet euch gerne direkt an Dennis auf Twitter (@dtraub) oder per Mail an traubd@amazon.com. Für mehr Infos, Tipps und Tricks rund um AWS und die Cloud folgt Dennis auf: Twitter - https://twitter.com/dtraub LinkedIn - https://www.linkedin.com/in/dennis-traub YouTube - https://www.youtube.com/dennistraub

On this episode of the Talking Serverless podcast host, Ryan Jones is joined by the incredible Michael Liendo. Michael is a self-driven developer with a passion for knowledge; he is an AWS Community Builder, Frontend & Serverless instructor, consultant, and recently became a Senior Developer Advocate at AWS! In this episode hear Michael's wild story of how he got into tech, his experience as an AWS Community Builder, and much more. If you like this podcast and want, visit our website where it is all there and always free: talkingserverless.io And if you want to follow this guest on social media you can find him here on Twitter @mtliendo and visit his Github: https://github.com/mtliendo --- Send in a voice message: https://anchor.fm/talking-serverless/message

W siódmym odcinku podcastu rozmawiamy z moim gościem Wojciechem Gawrońskim o Kubernetes i kontenerach w Amazon Web Services. Elastic Container Registry – zwykłe container registry, czy może coś więcej? ECR i skanowanie obrazów pod kątem bezpieczeństwa Czym jest i jak działa Elastic Container Service (ECS)? Jaka jest różnica między Elastic Container Service, a Elastic Kubernetes Service? EKS we własnej infrastrukturze - dlaczego i jak to możliwe? Co daje nam AWS Fargate? App2Container – dla kogo i jakie problemy rozwiązuje? AWS App Runner – czy to może być alternatywa dla ECS i EKS Wojtek to współzałożyciel firmy Pattern Match, gdzie pracuje jako architekt systemów IT opartych o rozwiązania chmurowe. Specjalista od chmury Amazon Web Services (8 certyfikatów, pracuje z nią od 2015 roku), uhonorowany tytułem AWS Community Builder. Na co dzień pracuje z klientami z Polski, Europy Zachodniej (Niemcy, Wielka Brytania, Francja i Holandia) i Stanów Zjednoczonych przy wdrożeniach rozwiązań opartych o rozwiązania chmury publicznej, prywatnej i hybrydowej. Programista i architekt systemów rozproszonych z 12-letnim doświadczeniem (Erlang, Java, Python). Firma: https://pattern-match.comBlog: https://awsmaniac.com YT: https://youtube.com/c/AWSManiac Twitter: https://twitter.com/afronski LinkedIn: https://www.linkedin.com/in/afronski Instagram: https://www.instagram.com/afronsky -- Szukasz materiałów do nauki Dockera i Kubernetesa?

OPIS W tym odcinku, razem z Wojtkiem Szczepuchą rozmawiamy o pracy z chmurą publiczną. O tym czy warto zdobywać certyfikaty chmurowe i jaka za tym może iść wartość. Rozmawiamy również o tym czy warto dzielić się wiedzą w społecznościach i jako daję to wartość twórcom jak i odbiorcom. O tym i wielu innych ciekawych tematach możesz posłuchać już teraz. ZAPRASZAM! O CZYM ROZMAWIAMY Kim jest Wojtek Szczepucha, Wojtek i jego początki pracy z chmurą publiczną, Co takiego daje chmura gdy patrzysz z perspektywy swojej pracy "wczoraj i dzisiaj"? Wojtek zdawał ostatnio egzamin AWS Certified Solutions Architect - Professional i dzieli się swoimi doświadczeniami, Jaką wartość daje dzielenie się wiedzą? Kto czerpie z tego najwięcej korzyści? AWS Community Builders - co to takiego? Jak można zostać AWS Community Builder? Wróżmy trochę z fusów - w jakim kierunku pójdzie chmura? LINKI Wojtek LinkedIN - https://www.linkedin.com/in/wojciechszczepucha/ Wojtek Twitter - https://twitter.com/DonKoyote Poznaj AWS - https://poznajaws.pl

In this episode, Anahit Pogosova answers 10 questions about cloud.Anahit works as a Lead Cloud Software Engineer at Solita. She is a software and data engineer working with cloud solutions and passionate about all things serverless. She is also an AWS Community Builder.MEET ANAHIT POGOSOVA➡️  Twitter: https://twitter.com/anahit_fi/​➡️  LinkedIn: https://www.linkedin.com/in/anahit-pogosova/MEET PABLO PUIG➡️ LinkedIn: https://www.linkedin.com/in/pablo-puig-433295171/PODCAST "10 QUESTIONS ABOUT CLOUD"➡️ Web: https://roopu.cloud/podcast➡️ Spotify: https://open.spotify.com/show/4kH3z7x0Eydh1lBlvncLyQ➡️ Apple Podcasts: https://podcasts.apple.com/us/podcast/roopu-clouds-podcast/id1539635929MEET ROOPU CLOUD➡️ https://roopu.cloud#cloud #cloudcomputing #aws #podcast #roopucloud

Welcome back to the Tech Stack Playbook — your guide to apps, software, and tech (but in a fun way I promise!) This week, I had an amazing conversation on Instagram LIVE with Linda Vivah (https://instagram.com/lindavivah​ and https://vm.tiktok.com/ZMJpRQjpe​), a software engineer from NYC, the founder of Coding Crystals (https://www.instagram.com/codingcrystals​), and a fellow AWS Community Builder. I thought the conversation was too good to just stay on Instagram, so that's why I made a whole podcast episode out of it. Here's a glance at what you'll learn in this episode: What role creativity has in tech. The path to AWS — why should you get certified? Why is understanding the fundamentals so important? Why we joined the #AWSCommunityBuilders​ Program. Why having a community of mentors and friends helps us battle imposter syndrome in tech. And more! ALSO, the AWS Community Builders Applications is open until March 31, so make sure to apply and join an incredible community of passionate builders, innovators, and developers along with exclusive trainings hosted by AWS' leading experts. Link to apply is here: http://amzn.to/38LFg9x​

Der offizielle deutschsprachige Podcast rund um Amazon Web Services (AWS), für Neugierige, Cloud-Einsteiger und AWS-Experten, produziert von Dennis Traub, Developer Advocate bei AWS. Bei Fragen, Anregungen und Feedback wendet euch gerne direkt an Dennis auf Twitter (@dtraub) oder per Mail an traubd@amazon.com. In dieser Episode haben wir Gernot Glawe zu Gast. Gernot ist Consultant und Trainer bei tecRacer, leitet die AWS Usergroup Hannover und ist Mitglied im AWS Community Builder Programm. Ihr findet Gernot auf Twitter (@megaproaktiv) und bei LinkedIn. Für mehr Infos, Tipps und Tricks rund um AWS und die Cloud folgt Dennis auf: - Twitter - https://twitter.com/dtraub   - Twitch - https://www.twitch.tv/dennis_at_work  - YouTube - https://www.youtube.com/dennistraub