Podcasts about azure devops

In this episode, Sujit D'Mello and Cynthia Kreng are joined by special guest Mike Becker, an Azure Architect at Microsoft, to discuss how various Azure services can be combined to create a complex solution. Sujit covers the latest enhancements in AKS, including Azure CNI, load balancer support, network isolated clusters, cost recommendations, and GPU driver options. Mike shares insights into a comprehensive Azure cloud solution for collecting and analyzing economic data and media feedback about companies, highlighting the use of Azure Data Factory, Databricks, Power BI, and OpenAI for sentiment analysis. The discussion delves into the architectural decisions, technical challenges, and practical applications of these technologies in delivering robust and secure solutions.   Media file: https://azpodcast.blob.core.windows.net/episodes/Episode516.mp3 YouTube: https://youtu.be/wG12eJymh54 Resources: ADF how it workshttps://learn.microsoft.com/en-us/azure/data-factory/introduction#how-does-it-work Azure Data Factory- Best Practiceshttps://learn.microsoft.com/en-us/answers/questions/1283307/azure-data-factory-best-practices Azure Data Bricks Medallion architecturehttps://learn.microsoft.com/en-us/azure/databricks/lakehouse/medallion Azure Data Bricks Best Practiceshttps://dzone.com/articles/azure-databricks-best-practices-for-a-developer Sentiment Analysis with Azure AI serviceshttps://learn.microsoft.com/en-us/azure/synapse-analytics/machine-learning/tutorial-cognitive-services-sentiment Power BI recommendationshttps://community.fabric.microsoft.com/t5/Desktop/Power-BI-Development-and-Best-Practices/m-p/4632985/highlight/true#M1386307 Improve Power BI model's performancehttps://powerbi.microsoft.com/en-us/blog/best-practice-rules-to-improve-your-models-performance/ GitLab best practices - if you cannot use Azure DevOpshttps://about.gitlab.com/topics/version-control/what-are-gitlab-flow-best-practices/

In this news episode, the trio discuss the Spark connector for Fabric warehouse, a better alternative to the Azure Update page, Windows Recall (again), and the conundrum of Azure DevOps and GitHub Enterprise!Show Notes Hosted on Acast. See acast.com/privacy for more information.

How do you manage your CI/CD pipeline resources? Richard chats with Eliza Tarasila about Managed DevOps Pools in Azure DevOps. Eliza tells the story of discovering that teams were using Azure DevOps internally at Microsoft but would need to build their tooling to stand up the resources for testing and deployment. Managed DevOps Pools became the standard way to specify resources like virtual machines and assign them to projects so that they would start up automatically. The resources in the pool can be custom resources in Azure or even on-premises servers! And, more importantly, you don't need to care and feed for the infrastructure used in the pipelines, Azure DevOps will do it for you.LinksAzure DevOpsCreate and Manage PoolsManaged DevOps Pool Origin StoryAzure DevOps PricingAzure Spot Virtual MachinesManaged DevOps Pools DocumentationRecorded January 6, 2025

Send me a Text Message hereFULL SHOW NOTES https://www.microsoftinnovationpodcast.com/652   Join Parvez Ghumra as he explores his journey as a Microsoft MVP from Leicester, UK. His passion for the Power Platform and Dynamics 365 CE development is shaped by strong family values, a love for travel—especially his mini pilgrimage to Mecca—and a spicy hobby of chili growing. Parvez reflects on the evolution of CRM deployment tools, from manual XML to modern no-code solutions like Azure DevOps and GitHub Actions, while acknowledging challenges with tools like Package Deployer. Alongside his insights, Mark also shares his own path to MVP recognition, emphasizing the power of community support in driving personal and professional growth. TAKEAWAYS• The role of family in professional development • Travel experiences influencing personal and professional growth • Transition from bespoke development to Dynamics 365 • Importance of Application Lifecycle Management in software delivery • Shift from SDK to low-code solutions in modern development • The value of community support in achieving the MVP statusThis year we're adding a new show to our line up - The AI Advantage. We'll discuss the skills you need to thrive in an AI-enabled world. DynamicsMinds is a world-class event in Slovenia that brings together Microsoft product managers, industry leaders, and dedicated users to explore the latest in Microsoft Dynamics 365, the Power Platform, and Copilot.Early bird tickets are on sale now and listeners of the Microsoft Innovation Podcast get 10% off with the code MIPVIP144bff https://www.dynamicsminds.com/register/?voucher=MIPVIP144bff Accelerate your Microsoft career with the 90 Day Mentoring Challenge We've helped 1,300+ people across 70+ countries establish successful careers in the Microsoft Power Platform and Dynamics 365 ecosystem.Benefit from expert guidance, a supportive community, and a clear career roadmap. A lot can change in 90 days, get started today!Support the showIf you want to get in touch with me, you can message me here on Linkedin.Thanks for listening

In this episode, we talk about downloading and analyzing partial ZIP files, how legitimate remote access tools are used in recent compromises and how a research found an SSRF vulnerability in Azure DevOps Partial ZIP File Downloads A closer look at how attackers are leveraging partial ZIP file downloads to bypass file verification systems and plant malicious content. https://isc.sans.edu/diary/Partial%20ZIP%20File%20Downloads/31608 Ukrainian CERT Advisory on AnyDesk Threat The Ukrainian CERT provides detailed guidance on identifying and mitigating recent cyber threats exploiting AnyDesk for unauthorized access. https://cert.gov.ua/article/6282069 Finding SSRFs in Azure DevOps An in-depth analysis of how server-side request forgery (SSRF) vulnerabilities are discovered and exploited in Azure DevOps pipelines. https://binarysecurity.no/posts/2025/01/finding-ssrfs-in-devops

James Montemagno is a Principal Lead Program Manager for the Developer Community at Microsoft. He has been a .NET developer since 2005, working in a wide range of industries including game development, printer software, and web services. Prior to becoming a Principal Program Manager, James was a professional mobile developer and has been crafting apps since 2011 with Xamarin. In his spare time, he is most likely cycling around Seattle or guzzling gallons of coffee at a local coffee shop. He co-hosts the weekly development podcast Merge Conflict mergeconflict.fm.   Topics of Discussion: [:36] Jeffrey introduces the concept of .NET Aspire and highlights its integration with Azure DevOps and .NET ecosystem tools. [2:51] The evolution of .NET mobile and desktop development since 2005. [4:45] An overview of .NET Aspire and its focus on simplifying app development and infrastructure orchestration. [11:45] How .NET Aspire supports both local development and cloud deployment. [16:24] Integrating DevOps automation for Azure deployments using bicep templates and Azure Developer CLI (azd). [25:30] Generating infrastructure manifests and deploying them with Azure Developer CLI. [32:51] Configuring Azure resources like Redis Cache for development and deployment scenarios. [35:11] Simplifying cloud deployment for developers using Azure Container Apps. [39:37] Polyglot support in .NET Aspire projects, allowing integration with Python, JavaScript, and more. [44:50] Plans to integrate development tunnels to streamline mobile app testing.   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! Ep 62 with James Montemagno James Montemagno James on YouTube James Montemagno GitHub James on DevOps James on X .NET Aspire Manifest plus + azd + Bicep == Mind Blown Aspire Dashboard   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Dicas para Facilitar o Processo de Refinamento do Backlog O refinamento do backlog é uma prática fundamental no Scrum para garantir que o trabalho a ser realizado em um sprint esteja claro, bem definido e priorizado. Para otimizar esse processo, considere as seguintes dicas: Frequência: Estabeleça reuniões regulares e curtas para o refinamento do backlog, idealmente antes de cada sprint planning. Foco: Concentre-se em um número limitado de itens a cada reunião para evitar sobrecarga e garantir que todos os detalhes sejam discutidos. DEEP: Garanta que os itens do backlog sejam detalhados (Detailed), estimados (Estimated), emergentes (Emergent) e prontos (Ready). INVEST: Verifique se os itens atendem aos critérios de INVEST (Independent, Negotiable, Valuable, Estimatable, Small, Testable). Envolvimento: Incentive a participação de toda a equipe de desenvolvimento, incluindo o Product Owner e o Scrum Master. Diversidade de Perspectivas: A colaboração promove a diversidade de perspectivas e ajuda a identificar possíveis problemas ou lacunas nos requisitos. Kanban: Utilize um quadro Kanban para visualizar o fluxo dos itens do backlog e identificar gargalos. Mapas Mentais: Crie mapas mentais para visualizar as relações entre os diferentes itens e requisitos. Software de Gestão de Projetos: Utilize ferramentas como Jira, Trello ou Azure DevOps para gerenciar o backlog e facilitar a colaboração. Documentação Compartilhada: Utilize ferramentas de colaboração como o Google Docs ou o Confluence para criar e compartilhar documentos sobre os itens do backlog. Valor de Negócio: Priorize os itens com maior valor de negócio para o cliente. Estimativas: Utilize técnicas de estimativa como o Planning Poker para auxiliar na priorização. Critérios: Defina claramente os critérios de aceite para cada item do backlog, garantindo que a equipe entenda o que significa "feito". Consenso: Obtenha o consenso da equipe sobre a definição de pronto. Adaptação: Revise o backlog regularmente para garantir que ele esteja alinhado com as necessidades do negócio e com as mudanças no projeto. Eliminação: Remova itens do backlog que não sejam mais relevantes ou que tenham sido completados. Transparência: Mantenha todos os membros da equipe informados sobre as mudanças no backlog. Feedback: Incentive o feedback constante para melhorar o processo de refinamento. Habilidades: Invista no desenvolvimento das habilidades da equipe em relação ao refinamento do backlog e às técnicas ágeis. Mentoria: Ofereça mentoria para os membros da equipe que necessitem de suporte. Ao seguir essas dicas, você poderá otimizar o processo de refinamento do backlog, garantir que a equipe esteja alinhada e aumentar a eficiência do seu projeto. 1. Reuniões Regulares e Curtas:2. Investimento em Detalhes:3. Colaboração da Equipe:4. Uso de Técnicas Visuais:5. Ferramentas Digitais:6. Priorização Constante:7. Definição de Pronto Clara:8. Revisão Contínua:9. Comunicação Eficaz:10. Treinamento e Desenvolvimento:

Refinamento do Backlog: Alicerce da Agilidade O refinamento do backlog é uma prática fundamental no Scrum que garante que o trabalho a ser realizado em um sprint esteja claro, bem definido e priorizado. É nesse momento que a equipe se reúne para detalhar, estimar e priorizar os itens do backlog do produto, preparando-os para serem trabalhados em sprints futuros. Clareza e Entendimento: Assegura que todos os membros da equipe compreendam os requisitos e o escopo do trabalho. Priorização: Permite que a equipe priorize os itens de acordo com o valor de negócio e a urgência. Estimativas Realistas: Auxilia na criação de estimativas mais precisas para o tempo de desenvolvimento. Redução de Riscos: Identifica e mitiga potenciais riscos antes que eles se tornem problemas maiores. Melhora da Colaboração: Fortalece a colaboração entre os membros da equipe, o Product Owner e outros stakeholders. Reuniões Regulares: Estabeleça reuniões curtas e frequentes para o refinamento, garantindo que o backlog esteja sempre atualizado. Foco em Detalhes: Detalhe os itens do backlog, definindo critérios de aceite claros e concisos. Estimativas: Utilize técnicas como o Planning Poker para estimar o esforço necessário para cada item. Priorização: Priorize os itens com base no valor de negócio e na urgência. Divisão de Tarefas: Divida itens grandes em tarefas menores e mais gerenciáveis. Visualização: Utilize ferramentas visuais como quadros Kanban ou mapas mentais para facilitar a compreensão. Colaboração: Incentive a participação de todos os membros da equipe, incluindo o Product Owner. Invista em uma Definição de Pronto clara: Todos devem saber o que significa um item estar "feito". Utilize ferramentas adequadas: Softwares de gestão de projetos como Jira, Trello ou Azure DevOps podem auxiliar no processo. Adapte-se às mudanças: O backlog é dinâmico e deve ser ajustado conforme as necessidades do projeto evoluem. Revise o backlog regularmente: Certifique-se de que os itens ainda são relevantes e estão alinhados com os objetivos do projeto. Reuniões longas e improdutivas: Mantenha as reuniões focadas e com tempo limitado. Falta de detalhes: Itens mal definidos podem levar a mal entendidos e retrabalho. Estimativas imprecisas: Estimativas imprecisas podem comprometer o planejamento do sprint. Falta de priorização: Sem uma priorização clara, a equipe pode se perder em tarefas menos importantes. Em resumo, o refinamento do backlog é um processo contínuo e fundamental para o sucesso de um projeto ágil. Ao investir tempo e esforço nesse processo, as equipes podem garantir que o trabalho seja entregue com qualidade, dentro do prazo e atendendo às expectativas do cliente. Por que o Refinamento do Backlog é Importante?Como Realizar um Refinamento de Backlog Eficaz?Dicas para um Refinamento de Backlog de Sucesso:Erros Comuns a Evitar:

In deze aflevering van De Nederlandse Kubernetes Podcast spreken hosts Ronald Kers en Jan Stomphorst met René Schoonrok (IT Engineering Manager) en Jeroen van Bijnen (Product Owner) van Nationale Nederlanden. Het gesprek duikt diep in de strategie en toekomst van het containerplatform binnen Nationale Nederlanden, waarbij onderwerpen als multicloud-omgevingen, DevSecOps, en nieuwe technologieën als GitOps aan bod komen.Hoofdpunten van de aflevering:Het Container Platform en Multicloud-aanpak: René en Jeroen leggen de uit hoe Nationale Nederlanden werkt met een containerplatform dat flexibel inzetbaar is in een multicloud-omgeving, en welke voordelen en uitdagingen dit met zich meebrengt vergeleken met cloud-provider-specifieke oplossingen.Extra Diensten en DevSecOps: Naast het containerplatform biedt hun team cruciale aanvullende services, zoals DevSecOps, algemene IT-taken en integratie met Azure DevOps. Deze services ondersteunen de ontwikkelteams en zorgen voor beveiliging en efficiëntie in de processen.Innovaties en de Toekomst van het Platform: Ze bespreken spannende plannen, waaronder de lancering van een Machine Learning-platform op Kubernetes met GitOps en ArgoCD, ondersteund door tools zoals Knative en Istio. Ook wordt er gekeken naar serverless opties op Kubernetes om flexibiliteit verder te vergroten.Toekomstvisie van Nationale Nederlanden: Het Future Ready-programma van Nationale Nederlanden krijgt aandacht.Aflevering 52: Autoscaling Magic with KEDA | De Nederlandse Kubernetes PodcastStuur ons een bericht.Like and subscribe! It helps out a lot.You can also find us on:De Nederlandse Kubernetes Podcast - YouTubeNederlandse Kubernetes Podcast (@k8spodcast.nl) | TikTokDe Nederlandse Kubernetes PodcastWhere can you meet us:EventsThis Podcast is powered by:ACC ICT - IT-Continuïteit voor Bedrijfskritische Applicaties | ACC ICT

We had an amazing time at the Nordic Summit 2024 at the Hub in Oslo. Ulrikke has been part of the planning committee and was a part of the opening keynote. Nick and Ulrikke were some of the hosts for the Nordic Summit podcast during the event but also made sure to attend some of the many amazing sessions.  The sessions we talked aboutHow to destroy your Power Pages site in 5 easy steps by Morten Krosby-SætherStreamlining environment lifecycles with Power Platform CLI & Azure DevOps by Yannick ReekmansMy Red Cross on Power Pages with Ulrikke Akerbæk, Ida Holdhus, Magnus JacobsenPlug-In to the Future: Low-Code vs. Pro-Code Showdown in Dataverse, with Wilmer Alcivar and Ben den BlankenIt's Power Automate not Power Integrate

De deadline om verplicht MFA af te dwingen voor alle Entra ID-gebruikers komt steeds dichterbij. Hier zitten nog wel wat belangrijke punten in die je moet weten. Verder bespreken we de nieuwe Azure Policy Community Repository en geven we updates over Azure DevOps en Logic Apps. Multi-factor authentication: Announcing Mandatory Multi-Factor Authentication for Azure Sign-In: Microsoft heeft aangekondigd dat MFA verplicht wordt voor alle Azure gebruikers. Dit gaat impact hebben op jouw beveiligingsinstellingen. Concept Mandatory Multi-Factor Authentication: Lees meer over hoe je je kunt voorbereiden op de verplichte MFA en wat het inhoudt voor jouw organisatie. Azure Policy Community Repo: Introducing the Azure Policy Community Repo: Een nieuwe community-gedreven repository voor het delen van Azure Policy definities, nu beschikbaar voor iedereen. Exchange recall updates: Exchange Online Message Recall Updates: Microsoft heeft verbeteringen aangekondigd voor de functionaliteit van het terugroepen van e-mails in Exchange Online. Azure DevOps: Introducing Object Limit Tracker in Azure DevOps: Een nieuwe tool om te helpen bij het beheren van objectlimieten binnen Azure DevOps. New Boards Hub Rollout Update: Updates over de uitrol van de nieuwe Boards Hub in Azure DevOps. Azure Logic Apps: Unlock Inline PowerShell Capabilities to Streamline Logic Apps: Mogelijkheid om PowerShell direct in Logic Apps te gebruiken voor meer geavanceerde workflows. Announcement: Templates for Azure Logic Apps Standard Now in Public Preview: Nieuwe sjablonen voor Logic Apps Standard zijn nu beschikbaar in public preview. Logic Apps Standard Monitoring Dashboards: Microsoft heeft nieuwe monitoring dashboards geïntroduceerd voor Logic Apps Standard. Copilot - default enterprise data protection: Updates to Microsoft Copilot to Bring Enterprise Data Protection: Copilot krijgt verbeterde enterprise data protection features om de veiligheid van bedrijfsgegevens te waarborgen. Instance Mix on Virtual Machine Scale Sets: Announcing Public Preview of Instance Mix on Virtual Machine Scale Sets: Een nieuwe functie waarmee verschillende VM-instanties binnen een enkele schaalset kunnen worden gecombineerd, nu beschikbaar in public preview.

Brian A. Randell is a Staff Developer Advocate at GitHub where he works to help tell the good word about GitHub and how it can help you deliver solutions faster and more securely. For more than 30 years, he has been building software solutions. As a Partner at MCW Technologies, he educated teams on Microsoft technologies via writing and training — both in-person and on-demand. He's been a consultant for companies small and large, worldwide, including Fortune 100 companies like Microsoft. Brian is a passionate software craftsman who still enjoys coding as he helps teams to improve their processes from idea to release. He was a Microsoft MVP for 18 years and has co-authored books, written magazine articles, and more. When not working, Brian enjoys spending time with his wife, two children, dog, and extended family.   Topics of Discussion: [3:01] Brian's career journey from software development to education and consulting. [8:20] Brian's role as a developer advocate at GitHub. [11:57] GitHub's CoPilot feature and its benefits for developers. [12:04] The impact of GitHub on software delivery and security. [18:22] How CoPilot can save you time and energy to spend more on innovation. [20:36] CoPilot Workspace. [24:11] Best setup for .NET development teams between Azure DevOps and GitHub. [32:21] Prioritizing developer experience and value delivery in software development. [40:09] Leading with a developer-first mindset. [41:15] Using GitHub for code storage and collaboration. [43:32] More info on the upcoming Essential DevOps book and San Francisco event. [46:31] What is platform engineering?   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! Brian Randell Brian Randell on LinkedIn Professional Application Lifecycle Management Brian Randell Github GitHub and .NET Conf Deployment Protection Rules octobrian What is DevOps?   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Jason Haley is a Full Stack Solution Architect at Jason Haley Consulting, LLC, where he provides custom Azure and .NET application development solutions for a variety of clients. With over 20 years of experience using Microsoft technologies, he has earned the title of Microsoft Azure MVP and holds numerous certifications.   His expertise lies in developing Web Applications and Single Page Applications (SPA) using Blazor, Angular, jQuery, ASP.Net Core, Entity Framework Core, Redis, SQL Server, and Windows Azure Active Directory. In addition, he customizes build processes for Azure DevOps pipelines and creates courseware for .NET and Azure topics. He is deeply passionate about learning and sharing his knowledge with the local Azure and .NET community, and he leads two user groups in the Boston area.   Topics of Discussion: [3:40] The two things that have stuck out in Jason's career. [5:36] When Jason started paying attention to GenAI. [9:12] Looking at GenAI from a solution perspective. [10:52] Where to start as a .NET developer. [16:49] Why aren't there more examples in C#? [18:02] What is Graph RAG? [19:11] Using language models for natural language processing tasks, including prompt engineering and token limits. [20:56] The importance of prompt engineering, and how to optimize prompts. [25:04] Cost and mechanics of using OpenAI's language model in Azure. [32:12] Using Azure AI services for business problems and thinking about AI as an intern. [34:48] Recommendations for .NET developers to get started with Azure Open AI and semantic search.   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! Jason Haley website Generative AI for Beginners Azure OpenAI RAG Pattern using a SQL Vector Database   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Join Brian and Ken Rickard as they delve into why agile transformations get stuck and uncover strategies for creating adaptive, resilient organizations and people. Overview In this episode, Brian sits down with coach, author, and Lean Change agent, Ken Rickard to explore the common pitfalls of agile transformations and the commodification of agile practices. Ken emphasizes the need to focus on people rather than processes and introduces the art of change, which includes self-awareness and adaptability. And shares the six big ideas of adaptive organizations, such as sense-making strategies and leadership agility. Tune in to learn how to navigate transformation challenges and create an environment that fosters resilience and adaptability. References and resources mentioned in the show: Ken Rickard Insight The Six Big Ideas of Adaptive Organizations: From Frameworks to Sensemaking by Ken Rickard and Jason Little Agile Manifesto For Software Development Lean Change Mountain Goat Software’s Agile for Leaders Training Join the Agile Mentors Community Mountain Goat Software Certified Scrum and Agile Training Schedule Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Ken Rickard is a spark for transformative good — a change alchemist, deep thinker, and a catalyst for personal growth and organizational evolution. With over 15 years in the agile community, he's honed the art of navigating change and embracing adaptation as the true essence of agility. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors Podcast. I'm with you as always, Brian Milner. And today I have a really special guest with us. I have Mr. Ken Ricard with us. Welcome in, Ken. Ken Rickard (00:12) Thank you. Nice to be here. Brian (00:14) Glad to have Ken here with us. Ken recently spoke at the the global Scrum Gathering, in New Orleans that I was at as well and had a really interesting, actually had a workshop slot there for a workshop titled Humans Agile and Change, How to Get Your Transformation Unstuck. And wanted to have Ken on to kind of talk through that a little bit. But before we do, for those people who aren't familiar with Ken, let me give you a little bit of an introduction here. Ken is an enterprise coach and change alchemist. I love that. At a company called Insight, he co -authored a book called The Six Big Ideas of Adaptive Organizations, which I know we're going to get into here in this conversation. He's a licensed facilitator of Lean Change. He's an IC Agile authorized instructor. So he's got just a load of credentials and a load of experience to bring to the table here with this. So Ken, let's get into this. Let's talk about humans agile and change and how to get transformations unstuck. What do you think is the main cause of transformations getting stuck? Ken Rickard (01:31) Yeah. So I think, you know, we're all feeling the effects of the high of agile. And I think now we're, we're starting to come down a little bit in the industry. I think everyone's feeling that effect. I mean, I see so many agile coaches on LinkedIn that are still looking for roles and whatnot, scrum masters, you know, a good bit of that, though, I think it's a blowback from the industry and just companies in general who, when they need to tighten the belt, they're actually beginning to look at the roles they've got and figure out which ones that they can do without for now. Or maybe they can do with roles they've already got. And so the effect of that, I think is coming from this idea that, you know, the agile industry, let's even narrow that a little bit more and talk about scrum specifically, has really kind of in the industry has become commodified around this idea that it's a process. And that we just like, we used to do this thing over here and we can just go to the shelf and purchase like scrum in a way. And then like. take that and just drop it into the spot and the practices we used to do. And so when it was only viewed as a process replacement for what they're doing now, it's very easy when, things get rough or tough in the industry as they've been over the past year, year and a half, two years, that our natural, you know, kind of inclination is to kind of hunker down and that hunkering down is to go back to what's comfortable to us, which is typically non -agile, non edge. things because that edge is actually kind of uncomfortable. And so we want to kind of go back and go back into our hole and actually like do the things that we're most comfortable with as an organization or as leaders. And so, yeah, I think that's been kind of what's been happening. And it's just, you know, the follow up from that, I think it's just now hitting the industry, I think in the current times now. Brian (03:10) Yeah. Yeah, I agree. I mean, you talk about it being a commodity and I can definitely see that across the different organizations that do certifications with this, and we're both trainers, we both do trainings. The hard part for me as a trainer is that I don't wanna... discourage people from getting training because I think the training is an important step, right? I think it's you know, you got to know the basics before you can play a sport and You know, if this is the team sport, but it's it's so much easier for me to tell someone all right Well, there's these roles these events and these artifacts Ken Rickard (03:49) Mm -hmm. Brian (04:05) and they can just go, you know, start putting it into their schedule. Here's the events we're going to do, and we have these meetings at this time. It's easy to do that, but it's hard to say, all right, what is openness? And how do we operate in an open environment, you know, or how do we treat each other with respect as we go through this kind of thing? That's hard to train, you know? Ken Rickard (04:10) Right. Right. Yeah. Yeah. Yeah. And coming from the, you know, I've spent a three and a half, almost four years now, I think with lean change and Jason little, and, and obviously we co -wrote co -wrote the, the book together, but the, I think the thing that I've learned from all that is, I mean, I want to say that at the beginning, the intention of the folks that created the agile manifesto for software development, their intention was really to help the industry change, but from a software development and probably an adjacent request would have been that the project management kind of behavioral patterns that were there and existing already. They could have actually kind of caused that trajectory to start to shift. And they obviously did over time. I think the one thing, if I had a time machine and I could go back and I could just plant a little seed with those 17 folks, it would be to not look so narrowly at the organization, like just the software development part. Because I think that's what's caused agile and scrum to become that thing that those IT developers do. And it's actually in a way done a disservice, I believe, to the industry at large and then just kind of the trajectory over time and where we kind of landed over these past few years. And it's why with lean change, what I'm trying to do, and I'm not the only one trying to do this. There's a number of folks out there trying to do this as well. But I think Jason and I, what we're trying to do and all the lean change facilitators is to get people to realize. that at the end of the day, everything is really about change. So scrum is just a process. It has all these, like behavioral patterns that come along with it. You're going to need to change, but those things aren't laid out necessarily exactly explicitly in the scrum guide. So you can read through that with your current understanding and your current lens of the world. And you can go, okay, I got this. And okay, all I need to do is go and create a scrum master position and I need a product owner and we need to do these events and then we need to set up these artifacts. And, and that can very easily lead to that kind of mechanical approach to scrum because that's kind of the world they've come from, right? If they've come from kind of project management world where everything is very laid out, very kind of straightforward and linear and then sequentially executed. And I think what we would all probably agree is that what's really missing is that mentality shift and. and the perspective shift. And to get there, we got to really focus on people change. Like, and I don't mean just like, Hey, we're doing a new process. So what do I need to do differently? Or, Hey, we put, we installed this new piece of governance software. So what buttons do I need to push differently? I'm talking about like actual evolution of the individual, their beliefs, their behavioral patterns, and the rituals that match up to those behaviors and beliefs that set underneath them as a person. Brian (06:52) Yeah. Yeah. Ken Rickard (07:14) And so that's what we're really trying to focus on from Lean Change is we're really trying to help people understand that, that to do those things well, to do things like Scrum well, you really have to focus not just on the process change or the technology change, but actually on the people change. You may even have to focus on structures and strategies as well. Brian (07:31) So I'm trying to channel my inner listener and try to think of what they might be asking or thinking about in hearing this. And I mean, what I think about is, all right, well, let's say I'm an organization and I buy an end to all this stuff. And I'm like, yeah, yeah, yeah, we've tried that. We've tried to implement this stuff and it's all about process and we'd rather not do that. We want to do it the right way. Where do you start? How do you start to... Ken Rickard (07:38) Yeah. That's it. Yeah. Brian (08:00) you come in and just say, hey everybody, we're gonna change how you think and how you, how do you start to get the organization to shift like that? Ken Rickard (08:06) Yeah, that's tough. Yeah. Yeah. And I would actually, I would point the finger right back at ourselves first. I mean, this is the journey I've been on for the past five years. You know, I mean, I, I actually talked about this in the session at the global scrum, scrum gathering. I told the crowd there. I was like, like five years ago, Ken, like if anybody challenged anything or didn't understand how scrum worked, I would essentially kind of like, Brian (08:14) Ha ha ha. Ken Rickard (08:34) just picture this idea of Ken taking them by the arm and leading them over to the Scrum Guide and being like, look, here's what the Scrum Guide says. And that was kind of my go -to thing in a way, variations on that, obviously. But at that time, it was mentality -wise, I was just like, okay, well, we just need to do Scrum. If we just do it well and we do it like it says we're supposed to do it, then it'll fix all the things. And that didn't really get the best response out of it. everyone. You know, it wasn't until I started to shift myself and my own perspective and start to really understand that, okay, I'm not the snake oil salesperson that they probably think I am. I'm actually somebody who's trying to help them change. And so if I look at it from that perspective, now it becomes less about the process or the framework and all the specifics of the framework. And it becomes more about, okay, where are they now? Brian (09:18) Yeah. Ken Rickard (09:29) What mentality do they have now? What are the attitudes that they have about the things that I would hope to put in front of them? Like, are they, are they like, yeah, this is great. Let's do it. Or are they like, no, I don't know. Not so sure. Or are they like, no, that's a stupidest thing I've ever heard of. Like we would never do that here. so better understanding them as an individual and then being able to better show up in a way that is going to be conducive for them to see the need to change is actually the very first. Brian (09:42) Yeah. Ken Rickard (09:55) best thing that I ever did in the way that I shifted my own perspective and how I showed up. And then that started to actually unlock them and their ability to actually pay attention and realize how they needed to change. And then therefore the change started to go. It's a much slower route because you can just go take stuff off the shelf and be like, Hey, we need to do it like this. And you probably will get some traction with some folks, but you're probably going to miss a good bit of them too. So. Brian (10:20) Well, let me, let me ask you this because this is something I've kind of been wrestling with with some other guests on the podcast as well. It's just this, this concept that, you know, partly, I think what's behind some of the problems with this is, is also the short kind of nature of, of how we view change in organizations. And, you know, we want quick results. We, you know, we have a change initiative to do something and we want to see that, that, that benefit of that change in the next three months. Ken Rickard (10:42) Sure. Brian (10:49) And all of a sudden things are going to be completely turned around and we're going to do things differently. But that's driven a lot from this short -sighted nature of, you know, we got to increase our profits quarter by quarter. We got to, you know, please our shareholders and they don't have the long vision that we used to have in companies of, you know, 10 years or something. Ken Rickard (10:54) Yeah. Yeah. Yeah, I'm going to, I'm going to say something and I'm going to meet it in a completely different way. Planning. Let me explain what I mean by this. all right. And I don't want to make this into the lean change show either, but I'm going to talk about a concept, from lean change real quick. so bear with me, but, so there's this idea that has been created in lean change. It's called, we, we, we refer to it as a big next now. Really what it is is it's like. Brian (11:17) Okay? Hahaha. Ken Rickard (11:42) Think of like an overarching rainbow at the top of like, Hey, what's the largest, biggest thing we're trying to accomplish? And what's the strategy around that? And if we can define a high level strategy around that, it will help us be, get like an orientation towards what outcomes are trying to seek it at the grandiose level. Let's say it's an agile transformation. All right. Underneath there are like a series of smaller humps that are like, okay, what are the goals we might want to actually achieve? Let's make sure those are really loose. except for the ones that are in the very beginning. Does this sound familiar? I'm basically describing breaking down and iterating incrementally changing the organization, right? So, underneath that you'd have like what's referred to as like the lean change cycle. This idea that we go out and actually look at the organization and get data back on what might need to change instead of actually telling people what needs to change. Like, Hey, we're becoming a scrum team, or this is what scrum is, and this is how it works. Brian (12:21) Yeah, yeah. Ken Rickard (12:41) well, what if they just start where they are and maybe the first thing I add is like a daily, you know, maybe they don't have any kind of coordination events at all right now. And then their tolerance level to change is just minimal. So, okay. So as a coach or as a less even a scrum master, the first thing I might help them do is to actually just put in some frequency of a regular sink. That could wind up turning into something that we would recognize as a daily scrum or a daily standup, but. In the beginning, maybe they don't have the tolerance to go right directly to the thing. Maybe they'll reject that or resist that. So as, as a coach or as a scrum master who's focused on change and not the process of the framework, I would go in and actually help them figure out what the best changes for them right now. And that's the approach I've been using and it just works. It works pretty well. versus coming in and being like, Hey, here's what scrum is. Here's how it works. Let's go through this training. You know, we got to get all these things set up. We need, here's what perfect looks like. Brian (13:14) Yeah. Ken Rickard (13:39) guess what we can't get there. So yeah. Brian (13:43) Yeah, I mean, as I'm listening to you, I'm thinking, you know, it's a difference of listening versus telling, you know, like there's a, there's kind of a telling mindset of going in for a lot of coaching of, you know, what we would typically frame more as a consulting approach. You know, I have answers. Here's the answers for you. Just do the way that I've always done it and everything will be fine versus let's actually hear what your situation is. And. Ken Rickard (13:59) Yeah. Brian (14:10) what your needs are and what you're seeing going wrong and how can we address those issues? I love that. Yeah, yeah, exactly. Ken Rickard (14:14) Yeah, and experimenting through it and honestly showing up, showing up as, or knowing when to show up in a coaching stance, who is going to be more empathetic and more understanding and not going to give them all the answers and it's going to let them explore and figure it out. And it's going to shine the light in the dark corners of the room versus the consultant stance, which is going to show up in more of an advisory. Hey, If I see you all struggling, I'm going to kind of tell you what to do or show you what to do. And they may not be ready for that. So it's about knowing when to actually do one stance or the other and be able to be very fluid in those things. Brian (14:47) Yeah. Yeah, there's a, there's a phrase I'll use often in class when I talk about the coaching kind of mindset to say, you know, what we're trying to do is not build knowledge, but build capability. And if you build the capability, then people can then adapt and change when, when something similar comes along or something in the same realm, they can say, yeah, I remember last time when we had something like this, here's how I responded. So that, that ability, I think to. deal with change like you're saying. And if we have it ingrained in our mindset that, hey, we identify problems, we inspect them and we adapt as we go along, to me, that's so much more important to build into how we do things than it is to know, we got these four meetings or five meetings that we're gonna make sure we hold at a certain time. Awesome. Well, you know, I'd like to hear a little bit because I know, you know, your talk is somewhat loosely based on your book as well. And, you know, with a title like the six big ideas, help us understand. We may not have time for all six, but give us some of these big ideas. Ken Rickard (16:00) Yeah. Yeah. Sure. Yeah. Yeah. I'm also still, I think Jason and I are still trying to figure out if, how the word or the phrase big ideas is resonating with folks too, because in the agile community, you know, big, big is not a word that I think people will gravitate to very quickly, but, we're also trying to straddle the fence on the change community and the agile community. Honestly, what we're trying to do is I was joking around and I think we, I'm. Brian (16:21) Yeah. Yeah. Ken Rickard (16:31) might've wrote this either in the book that's out now or the bigger book that we're working on for later this fall. But I wrote somewhere that really the change community and the agile community should really go on a blind date because they never should have really been two separate communities in my opinion. And I think Jason would hold the same opinions and a lot of our lean change facilitators, I think would hold the same opinions. So yeah, so the book is really about trying to get Agilist to understand that their role is really about change. Brian (16:47) Yeah. Ken Rickard (17:02) They already know the agile bits and the iterative incremental and all that kind of stuff. And that the change community really needs to better understand the agility community and take some of those practices and apply it to the change. And if both sides do those things, we're going to wind up in the middle and everybody's going to be the same type of person or the same type of thing. Because at the end of the day, getting to agility, like this idea of the characteristics of being nimble and being able to adapt to what's going on with a certain grace and resilience. Brian (17:25) Yeah. Ken Rickard (17:31) that set of characteristics is really, I think what the agile industry is hoping to go for. And yet a lot of the folks that find these things come to it with their current understanding and they don't really, aren't really looking to change themselves and how they see things, their perspective. And so that's how we get into this commodified kind of off the shelf version of it. And so I think we're just trying to get people to realize that. Look, if you look at these big, these six big ideas, which are really just sense making strategies. At the end of the day, that's what they are. You should be able to sense your way through what your context, your organization, given the changes that are going on. you know, what are those circumstances? How well do you know those circumstances? If you can understand those things in a sense making way, you'll be able to show up in a way that it actually be conducive to help that organization change, no matter what the scope of the changes. Let's say you're a store master. It could be your scope of your change is essentially your team or teams. Brian (18:25) Yeah. Ken Rickard (18:29) And the product that they're building, let's say you're an agile coach. Okay. Maybe it's somewhat wider than that. I don't know. I'm still on the fence about what the difference between agile coaching and scrum master is. That's another podcast though. I think, or let's say you're somewhere higher up in the organization. So whatever your purview is, whatever your scope is, that context is really what we're trying to do. We're trying to help you and the others around you understand what it is that you're not paying attention to, what it is that you don't understand. Brian (18:39) Yeah. Ken Rickard (18:58) or that you might think you understand about your organization. So it's really six ideas to help people kind of unravel that about their organization and themselves. Because like, for instance, one of the six big ideas is something that Jason had created quite a long time ago called the four dimensions of change. And what it says is that there's four things that you really probably need to focus on as, as a agent of change. And that is yourself. So like, Brian (19:07) Yeah. Ken Rickard (19:26) Your set of beliefs about things, you know, how you show up because how you show up actually affects how others receive or perceive you. And then that impacts your ability to influence others and actually help them change. And then it goes on to say there's, the big ideas or strategies that you can deploy from, from a change perspective, typically minimally viable practices, or strategies. And then the last bucket in that four dimensions is, tools and practices. You know, the things that we have the most affinity for and tend to go to first, and kind of ignore the other three things. So it's, so that particular big idea is trying to get people to recognize that, no, there's like a bigger kind of art and science here to helping people change. It's not just about the science, like the strategy and the tools and practices to be good at those things. Most likely you got to focus on the art of change, which is yourself and your stance or how you show up. Brian (19:59) Right. Right. Yeah, I'm gonna share one of my geeky subdivisions here in making this quote, but it reminds me of in the musical Hamilton, there's a line in there that George Washington says to Hamilton where he's talking about, you know, Hamilton has these visions of going off and dying like a martyr and George Washington says, dying is easy young man, living is harder. And. Ken Rickard (20:30) Yeah. Yeah. Brian (20:51) That's kind of how I see this. I'm not saying we're dying or making a choice between dying or not, but I am saying that the practices side of thing, practice is easy young man, culture is harder. It's just harder to try to implement those things. And I think a lot of times, I don't know if it's, I think individually sometimes as coaches we can get lazy. Ken Rickard (20:55) Yeah. Brian (21:18) and go to the things that's easier to tell people about. But I also think that it's an institutional thing because it's much easier for me to certify somebody or give them a credential saying that, hey, this person knows their stuff when I can test them on facts and figures and how long is that meeting and that sort of stuff versus. Ken Rickard (21:20) Mm -hmm. somebody. Yeah. Please. Brian (21:41) you know, how do you change the mindset of the culture of the organization when they're really into quick solutions and they're into trying to get things out the door as fast as possible and not focus on quality. It's harder, right? It's just, it's more difficult. Ken Rickard (21:55) Yeah. Yeah. Yeah. Yeah. Yeah. You're hitting on one of the other six big ideas right now. Actually two of them, but we can start out with the explain the one. So there's another one that we made called the, the two change strategies of effective organizations. And so what this one says is that there's two ways that you can probably improve or change your organization. And that's a fractal statement in an organization because again, we're only talking about whatever context you have. Brian (22:06) Hahaha. Ken Rickard (22:27) Cause if you're a SCAR master, we're talking about the context you have of the teams you're working with. Agile coach or something higher up than that, whatever context you have. So, okay. So within your context, you probably have two ways to think about and try to help your organization change. And those two ways are either optimizing what they already do to make it better, faster, cheaper, or evolving the way they think about what they do so that they can actually succeed in ways that they never have before. And I'd be, I'll go out on a limb and say that every, at the very least, every single company I've come across that's doing agile and whatever way they call it, is really trying to do it from the purpose of the optimization, better, faster, cheaper. I think there are very few companies around the world that are actually taking it seriously enough to do the evolution part to actually change the way they think about how they do things in such ways that they're actually elevating. their set of beliefs and behavioral patterns, not just as individuals, sorry, as individuals, but as a collective and then ultimately as an organization. And so it's really trying to get you to, to focus on what is it that we actually are trying to improve? Is it just that we're trying to optimize what we're doing now? Cause that's a take scram off the shelf and just drop it in, you know, or that's send people to training and like come back and be like, cool, you're certified. Brian (23:33) Chief. Ken Rickard (23:49) But if we don't ask the hard questions around, okay, well, what are you gonna change about your behaviors? Then they're likely not focusing on evolution. And if we're not coaching them through that, yeah, not really going anywhere. Brian (24:01) Yeah, do you think organizations just don't know what they don't know? I mean, because I know you're right, they do want better, faster, cheaper. And that's sort of the end goal that they're coming at a lot of this stuff with. They just not recognize that it's really the change capability that they should prioritize. Ken Rickard (24:05) It's like. Well, I think it's because they focus. So what's really easy for a lot of organizations to change. There's a, we're going to keep tying these five, sorry, these six big ideas together, I guess, because there's another one called the five levers of change. And what that one is, is a, it's a circle of five things with people being the biggest circle in the center. And then on the four corners of it, it's basically process and technology strategies and structures. Brian (24:32) No, that's great. Ken Rickard (24:48) And so if we look at that as a systems approach to changing an organization, the reason why it's called the five levers is because they can pull any levers in any combination they want in order to try to change their organization. But the easiest levers to pull are process and technology. So, Hey, let's do scrum and we need to install Jira or Azure DevOps. Right. And that's generally where these kinds of things start because it's within the control of the teams oftentimes to make those changes. It doesn't impact a larger organization to, well, it can, but probably to a lesser extent initially. So the teams have some level of autonomy or local control to start making those changes. They don't run into problems or impediments or just kind of organizational dysfunction until a little bit down the road so they can kick that can down the road. And so I think it's, I think it's that that causes us to gravitate towards a process and then just pull that lever pretty easily. And, and that's an optimization lever. So if you tie those two ideas together, it takes the other side of those five levers, the structure and the strategies, which are all built on beliefs. You know, like if I'm a leader in a hierarchy who's worked 20 years to get to my lofty management position, I'm going to be a lot less likely to take a empathetic kind of delegated approach to my management style because I put in a lot of hard work to get to where I am now. And there's no way you're going to tell me now. Brian (25:48) Yeah. Ken Rickard (26:18) 20 years that I now have to change the way I operate? Like, no, I'm in control here. So I think we're also battling that a little bit too. Brian (26:20) Right. Yeah, what I've done got me here. So why would I do something different now? Right? Ken Rickard (26:32) Right. Exactly. Brian (26:34) Yeah, I've battled that in multiple occasions, for sure. One of the places I worked was a newspaper. And if you want to talk about people not wanting to change their mindsets of, hey, what do you mean that people don't want to have delivery of their newspaper on their front doorstep every day like they've done their whole life? Yeah, it's crazy. Well, this is great stuff. I'm really enjoying this. Ken Rickard (26:49) Yeah. Yeah. Brian (27:03) Do you have one last big thought, big idea to leave us with here? Because we're almost out of time, but what have we missed in these big ideas? Ken Rickard (27:13) Yeah, probably the other big one that comes up a lot. one of the other six that I haven't talked about yet is the, what I call the three agilities. And we'll tend to focus on the delivery agility, which is like, Hey, we, we can help you team better and people better at the team level where you're delivering. And we can help you become more product led. And we can also help you with your technical excellence, you know, like DevOps types things, right? Brian (27:21) Okay? Ken Rickard (27:38) And I think we could probably draw a circle around those three things and go, you know what, for the vast majority of the agile industry, this is what they think agile is. But in my opinion, that's only one of the agilities an organization needs in order to actually possess the characteristics of agility. And the other two would be change agility. The idea that we are adaptable to the change that we cannot control and that we actually can adapt well in a resilient way to the change we can control within our organization. And that we're constantly evolving to get better at that so that we can sustain change in a graceful way over time. So that's change agility. And then the third one is probably possibly the most important one. And that is leadership agility. This idea that if we don't create the environment for change to take place in a conducive way that is productive and adaptable. then we won't change and we'll stay stagnant and we'll stick to our standardized approaches in a stagnant way. And then delivery will suffer even though we can put new things on top of it and we can call things new words, it won't actually change. And the leadership agility is really about not just trying to teach leaders to be more competent. That's generally what management consulting and a lot of other folks are focused on. It's really about trying to help leaders address their ability. to actually have a consciousness about themselves, that they can show up in ways that are actually enabling and empowering the organization to be adaptable and flexible and to be able to deliver and change in ways that are graceful and resilient. And so in my opinion, it kind of starts there even though a lot of them don't start. Brian (29:14) I love that. No, I love that. I think that's great because, you know, a lot of times you hear the complaints of people who come through classes that are kind of more team level in the organization. And it's, there's a lot of complaints about how management just doesn't understand, or we're bumping up against the glass ceiling, you know, kind of in our organization, we can't really Institute change or make the change permanent because, you know, leadership still wants things exactly in the old way. They haven't actually shifted. how they think about things. So I love that, I love that concept. I would agree there. Well, this is great stuff. And obviously, like I said, the workshop that Ken did at the Scrum Gathering was an hour and a half. And this is just a short little taste in half an hour. So there's no way we're gonna be able to cover it all here. I strongly encourage people, if they're really interested in this topic, if they're really interested in what Ken is saying, Ken Rickard (29:53) Thank you. Yeah. Brian (30:15) Check out the book the six big ideas of adaptive organizations. It's a great book And it'll go into detail on all of these these six big ideas that we talked about here And what we're gonna put lots of the links in our show notes here so if you want to just head on over our show notes you'll find links over not only that but to to Ken's organization the six big ideas network and you can find the website there and find the the Ken Rickard (30:24) Mm -hmm. Brian (30:44) classes and trainings that Ken is doing in this area. So we'll make sure that everybody can get to that. Ken, I can't thank you enough. Thanks for coming on and sharing your knowledge with us today. Yeah. Ken Rickard (30:54) Yeah, thanks for having me. It was fun.

Massdriver's innovative platform and DevOps-as-a-Service offerings transform cloud infrastructure management, Podcast, Cory O'Daniel, CEO of Massdriver, discusses how Massdriver's innovative platform and DevOps-as-a-Service offering are transforming cloud infrastructure management “If you have 150 software developers, 1,000 software developers, but then you have three, four, five, 10 people working in operations, you can actually start to get really good yields out of their time because they're not spending most of their day's kind of drowning in technical debt,” says  Cory O'Daniel, Co-Founder & CEO. In this episode Cory O'Daniel, CEO of Massdriver, discusses how Massdriver's innovative platform and DevOps-as-a-Service offering are transforming cloud infrastructure management. Cory discusses the platform's robust features, the unique value it provides, and how it simplifies complex deployment processes. We delve into broader trends and challenges in the cloud and DevOps industry, providing valuable insights for resellers looking to stay ahead in the market. “The way MassDriver works for your operation teams is nothing changes except for the maintenance burden goes away. So you write your code the same way you do today. You use the same tools that you do today. You even put it into GitHub or Azure DevOps or whatever tool you're using for source code management the same way you do today,” says Cory O'Daniel, Co-Founder & CEO Massdriver's cloud platform integrates advanced automation and orchestration tools to deliver a seamless infrastructure management experience. It supports a wide range of cloud environments, enabling businesses to deploy applications with a few clicks. Features include real-time monitoring, automated scaling, and robust security measures. Our DevOps-as-a-Service offering demonstrates the platform's capabilities, providing hands-on DevOps support, development of Terraform and CI/CD pipelines, and architectural guidance. This model showcases how resellers can leverage Massdriver to deliver comprehensive, high-value cloud solutions to their clients. About Massdriver: Massdriver is a pioneering cloud platform designed to streamline the deployment and management of applications across multiple cloud environments. We provide a unified interface that simplifies complex infrastructure tasks, allowing businesses to focus on innovation rather than operations. With Massdriver, organizations can easily deploy, monitor, and scale their applications, ensuring high performance and reliability. Our platform is tailored to meet the needs of resellers, offering comprehensive support and customization options to help them deliver exceptional value to their clients. Visit https://www.massdriver.cloud/    

Mitch is a Principal Software Engineer on the .NET Cloud team working on .NET Aspire and ASP.NET Core. Previously Mitch has worked on Azure services, the Azure SDK, and Azure DevOps.   Topics of Discussion: [2:46] Mitch's career journey in the Microsoft ecosystem. [5:46] What makes it .NET Aspire vs. .NET8? [6:16] .NET Aspire focuses on seamless integration between app components. [8:18] Making sure the core of Aspire is cloud-agnostic. [10:48] Developer control plane. [11:40] How Aspire simplifies cross processes. [14:36] Using Aspire to manage dependencies in microservices applications. [18:18] Automating deployments with Azure DevOps and easy mode for .NET Aspire. [30:27] Securing container deployments. [34:39] Using Azure DevOps for cloud deployment and configuration management. [37:33] What are the best resources for people to dig in? [40:03] Azure subscriptions inside Microsoft. [43:43] They are only just getting started with Aspire, and with .NET 9 coming out in November.   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! GitHub Mitch Denny .NET Aspire (aspire) github.com/dotnet/aspire/tree/main/playground github.com/dotnet/aspire github.com/dotnet/eShop   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

As the president of Tegaaa Solutions, a DevOps consulting firm, Étienne helps clients achieve optimal performance and efficiency in their software development processes. With over 30 years of IT experience and 20 years of Microsoft specialization, he has the skills and knowledge to provide tailored solutions for any DevOps challenge.   He is passionate about sharing his expertise and best practices with the IT community as a Microsoft MVP for TFS and Azure DevOps since 2006, and a regular speaker at local technical conferences and user groups since 2005. He also offers mentoring and training for organizations using Visual Studio and Team Foundation Server and designs enterprise and application architectures for projects of all sizes. His mission is to empower developers and organizations to leverage the power of DevOps and Azure to deliver high-quality software faster and better.   Topics of Discussion: [3:30] Étienne's career progression from mechanical engineering to software development. [6:14] Yes, Étienne was TFS before it was cool. [7:14] Étienne's interesting specialization in aerodynamics. [11:18] Not making things too complicated. [12:49] Étienne's interest in the building process. [14:07] Building the blueprint. [17:08] GitHub vs. Azure DevOps for enterprise use. [19:49] Microsoft's struggle with GitHub's repo-centric approach in the enterprise. [24:17] The key differences in how work is tracked. [28:10 What is Entra ID? [34:08] Agility is becoming a religion, where it needs to be more of a spirit. [38:04] Kanban system for managing work in progress. [46:24] Implementing Azure DevOps for beginners, with tips and resources.   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! Etienne LinkedIn Get Started with Azure DevOps Tegaaa Solutions   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Martin is a passionate agile leader with a track record of inspiring, encouraging, and igniting momentum. Featured speaker, author, and industry thought leader, Martin has a strong track record of helping organizations build a vision and execute evolutionary and revolutionary change. His deep technical knowledge, business insight, and experience drive impactful change for organizations.   Technologist turned agilist, Martin successfully helps organizations decentralize, democratize, and evolve their way of work to build extraordinary processes and drive organizational change through culture, technology, and teamwork. He's been recognized by Microsoft as a Microsoft MVP, and he is the maintainer of the open-source Azure DevOps Migration Tools.   Topics of Discussion: [2:59] Martin's career journey. [4:51] What Martin has learned as an MVP for 15 years. [5:59] If you're not good at something, do it more. [6:52] Azure DevOps Migration tools. [10:11] Martin adopted platform engineering to streamline processes and reduce costs. [14:31] What you should know before using Martin's tools. [21:55] It's not either/or between Microsoft migration tools and Azure DevOps migration tools. [27:00] What made TFS unique. [20:03] TFGit. [30:02] The process used in your source and target, and what challenges might people expect? [31:44] Limitations of migrating data from old TFS to new Azure DevOps using Microsoft tools.   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! GitHub Migration Tools for Azure DevOps Martin — Scrum Naked Agility Agile Actually Podcast   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

In this episode, Steve, Frank and Mike discuss the benefits of using the free tier in Microsoft Azure. They explore the various free offerings available, such as Azure Cosmos DB, Azure DevOps, and speech-to-text translation. They also discuss the importance of monitoring costs and implementing processes to prevent unexpected expenses. Mike shares insights on cost optimization for Cosmos DB and announces an upcoming video on the topic.

Richard Hundhausen helps software organizations and teams deliver better products by understanding and leveraging Azure DevOps and Scrum. He is a Professional Scrum Trainer, Professional Scrum Developer, author of Professional Scrum with Azure DevOps (MS Press), and co-creator of the Nexus Scaled Scrum framework. As a software developer and consultant with over 30 years of experience, he understands that software is built and delivered by people and not by processes or tools.   Topics of Discussion: [3:03] Is it really that easy to teach developers? [3:34] Scrum implementation and best practices for developers and managers. [5:11] What is a Scrum trainer and developer? [6:40] Reminding teams to talk to each other and deliver value earlier. [6:47] Remembering not just the nouns, but the verbs: improve, collaborate, share, love the values, commit, have courage, be open, have focus, and be respectful. [8:39] The importance of having the right teams. [12:04] Improving software development efficiency through cross-functional teams. [13:47] The importance of being a self-managing team. [15:04] When we outsource everything to HR to find a good culture, that can perpetuate the “it's someone else's job” mentality. [15:24] Bigger companies vs. smaller companies. [17:44] Giving creatives the space to create. [21:09] HDD (Hypothesis-driven development) can help us learn early and adapt. [29:27] The importance of focusing on outcomes and impacts, rather than just measuring resources, activities, and outputs. [31:08] Outcomes and impacts are where we should be focused. [32:40] One percent of product owners using Scrum as intended? [33:27] Even if you don't have a product owner, have someone who orders the work.   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! Accentient Upgrade Your Team Daniel Pink Practicing Hypothesis-Driven Development in Azure DevOps “Richard Hundhausen on Professional Scrum — Ep 100”   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

About ten years ago my sister-in-law broke the screen on her mobile phone. She'd had an older iPhone and when she went to upgrade, none of the upgrade processes worked because her OS was so far behind that they couldn't transfer her information smoothly. She had been avoiding OS updates because they interrupted her life, but that was now a problem because the world had marched so far beyond her version that there weren't tools, or at least, no one was interested in trying to perform an upgrade across multiple OS versions (I think it was 3 or 5 versions). I ran into this recently with someone else I knew, but not for a mobile phone. For TFS 2015. This customer had been working along with this older system and is finally ready to upgrade to Azure DevOps in the cloud. They wanted to know if they could somehow upgrade the TFS database and move all that data easily into the cloud. I said this wasn't likely easy as this isn't an upgrade, but an export and import of a lot of data. Microsoft offered a path, but it was multiple upgrades before an export/import, which was deemed too expensive. Right now, I'm not sure what they're doing to do. Read the rest of The Dangers of Not Upgrading

Guest: MUHAMMAD MUNAWWAR KHAN Mr. Munawwar, with over nine years of experience in software development and devops, serves as a passionate technical lead at Avery Products, contributing significantly to the company's technology transformation. As a mentor at Kaggle, he supports the KaggleX BICOP Cohort 3, and he is also the founder/CTO of Edushapers, an EdTech startup dedicated to improving education in underdeveloped countries through impactful software solutions. Mr. Munawwar leverages his expertise in Azure DevOps, Model-View-Controller (MVC), Wrike, and other technologies to create scalable solutions with a global impact. Host: Mudassir Raza www.facebook.com/PodcastGrowTogether www.linkedin.com/company/grow-together-podcast

We are THRILLED to have had the opportunity to talk with Neil Benson, Founder and CEO of Customery. Neil first reached out to us to tell us everything that we did wrong with our Azure DevOps (ADO) best practices, and we knew we had to have him on the podcast. All jokes aside, much like everything we do with technology, there are so many different ways to complete something - people have differing opinions on everything from how to build forms, when to use Power Automate, and how to run their Agile teams. Neil is an Agile expert and spends his time mentoring and coaching individuals and businesses on how to run Agile optimally for their organizations. Basically, he's an expert in the field and we wanted to hear his advice (and share it with you) on how to leverage ADO that may be a little different than what we're currently doing. Visit https://www.dynamicshotdish.com for more information

#152.  Host Neil Benson is joined by the talented Dani Kahil for an insightful discussion on managing backlogs and enhancing user stories in Azure DevOps and Jira. Neil shares his experiences with Jira, highlighting some configuration challenges, while Dani expresses a strong preference for Azure DevOps. They dive into the hierarchy of backlog items, including epics, features, user stories, and tasks, and explore different approaches to tracking progress on a Kanban board. Throughout their conversation, Neil and Dani discuss the importance of refining user stories, enriching them with acceptance criteria, and prioritising features based on their value to the team or users. They also touch on the significance of releasing value quickly and iterating on functionality. Join us for an engaging conversation packed with practical insights and tips for efficient backlog management. Let's get started!Dani Kahil on LinkedIn: https://www.linkedin.com/in/danikahil/Dani's blog: https://danikahil.comKahil Consulting: https://kahilconsulting.com/Support the showCONNECT

Mike, Seth, & Tommy run through the major updates to Git, the Power BI Project type format, and everything in between. Have you utilized Git workspaces yet? Or introduced Power BI Git Projects to your workflow? https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-build-pipelines?WT.mc_id=DP-MVP-5002621

6 Agile Principles to Help You Become a Better Leader Agile principles can help you become a better team leader by improving your leadership skills in various aspects, such as communication, collaboration, feedback, adaptation, empowerment, and delivery. Here are some examples of how you can apply Agile principles to your team leadership: Communication: You can use face-to-face conversations as the preferred method of conveying information to and within your team. You can also use tools such as [Microsoft Teams] or [Slack] to facilitate online communication and collaboration . You can also communicate regularly with your customers or stakeholders to understand their needs and expectations, and to share your progress and feedback. Collaboration: You can work closely with your team members and business partners throughout the project. You can also involve them in planning, designing, testing, and reviewing your products or services. You can also use tools such as [GitHub] or [Azure DevOps] to manage your code repositories, workflows, issues, and pull requests . Feedback: You can seek feedback from your customers or stakeholders frequently and continuously. You can also give feedback to your team members regularly and constructively. Adaptation: You can welcome changing requirements or feedback from your customers or stakeholders. You can also use tools such as [Jira] or [Trello] to manage your backlog, sprints, tasks, and priorities . You can also adapt your products or services accordingly by making frequent and incremental changes or improvements. Empowerment: You can build your team around motivated individuals who have the skills, knowledge, and experience needed for the project. You can also give them the environment and support they need, such as tools, resources, training, or coaching. You can also trust them to get the job done by delegating tasks, responsibilities, or decisions to them. You can also encourage them to self-organize and self-manage their work. Delivery: You can deliver working software or services frequently and continuously to your customers or stakeholders. You can also use tools such as [Azure] or [AWS] to deploy, host, or scale your products or services . You can also measure your progress and success by using working software or services as the primary indicator. How to connect with AgileDad: - [website] ⁠https://www.agiledad.com/⁠ - [instagram] ⁠https://www.instagram.com/agile_coach/⁠ - [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠ - [Linkedin] ⁠https://www.linkedin.com/in/leehenson/⁠

Azure and GitHub - better together? While at the Copenhagen Developer Festival, Carl and Richard talked to April Edwards for a special .NET Rocks Live. April talked about how Azure and GitHub work well together, discussing Azure DevOps and GitHub Actions on the CI/CD pipeline side and how other services can interact. Lots of laughter and great questions from the live audience!

Jimmy is the creator and maintainer of the popular OSS libraries AutoMapper and MediatR. Jimmy is an independent consultant based in Austin, TX. Jimmy has received the “Microsoft Most Valuable Professional” (MVP) award every year since 2009.   Topics of Discussion: [3:45] How do we modernize old software systems? [4:55] Dividing the modernization process into small steps to minimize dependencies and validate changes along the way. [5:01] Does Jimmy have a preferred sequence of work that he has found that makes modernizing a system easier? [7:01] Modernizing legacy ASP.NET web applications with test coverage. [7:24] System web adapters. [12:02] Database migration to Azure using SQL Data Sync and Hangfire. [12:09] Any “gotchas” on the database side? [15:27] What exactly is Hangfire? [17:02] The flexibility of Hangfire in its triggers and scheduling. [23:49] How system web adapters enable easy migration of controllers and actions. [25:16] Second success story for YARP: Yet Another Reverse Proxy. [27:15] What was the thought about observability architectures? [29:02] What are some of Jimmy's favorite features? [32:08] The team modernized the telemetry system for a large organization, enabling them to query data more efficiently and gain valuable insights. [35:05] Lessons learned and best practices while modernizing.NET applications with Azure DevOps.   Mentioned in this Episode: YARP 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! Architect Tips — Video podcast! YARP: Yet Another Reverse Proxy   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

#147. When should you use Power Platform pipelines and when should you use Azure DevOps pipelines to deploy your Power Platform or Dynamics 365 applications? That's the question that Benedikt Bergmann answers in this episode of Amazing Apps.Benedikt is a Power Platform consultant known for his expertise in Application Lifecycle Management (ALM). Neil and Benedikt delve into the world of ALM, discussing its importance for small and enterprise teams alike. From tools and environments to testing and components outside of solutions. Whether you're a low code app builder or part of a large development team, this episode has something for everyone. Join us as we explore the intricacies of ALM and discover how to deploy and maintain applications in a secure, efficient, and repeatable manner.Register for Benedikt's ALM Training CourseResourcesOverview of Power Platform pipelinesMore power with pipelines in Power PlatformEasyRepro test frameworkPlaywright test frameworkPower Platform server on DiscordConnect with BenediktBenedikt on LinkedInBenedikt on GitHubBenedikt on TwitterBenedikt on Twitter Support the showCONNECT

Today we have Kevin Chant as our guest! We talk about Kevin's favorite topics: Microsoft Fabric, Azure DevOps, SQL Server, and more. Relevant links: https://www.kevinrchant.com/2023/06/13/create-your-own-microsoft-fabric-environment/  

In our latest PowerShell Podcast, we invited Microsoft MVP Björn Sundling,  on a riveting journey from being a PowerShell developer to securing Azure DevOps repositories. With a passion for speaking seeded from his first year at PSConfEU 2015, his road to the podium wasn't easy. The podcast was peppered with a detailed discussion on the automated scanner project PSSecretScanner. Offering insights into development technologies, this episode is a whirlwind tour of community involvement and encompasses his love of sharing knowledge.   Resource Links: Watch The PowerShell Podcast on YouTube: https://www.youtube.com/watch?v=M1U5VVzC4gY https://bjompen.com/#/ https://github.com/bjompen https://mastodon.nu/@bjompen https://github.com/bjompen/PSSecretScanner https://www.youtube.com/watch?v=StvroRI-WW4

Last week in security news: A Guide to S3 Logging, Optimize AWS Config for AWS Security Hub, Amazon Told Drivers Not to Worry About In-Van Surveillance Cameras. Now Footage Is Leaking Online, and More!Links: Guide to S3 Logging  Good on JumpCloud for disclosing a breach by some state-backed APT hacking group, but I learned about it from this article, and I'm a JumpCloud customer. Charlie Bel issued a security roadmap for Microsoft: Protect Azure DevOps secrets is the first item on it. What a novel idea! Amazon Told Drivers Not to Worry About In-Van Surveillance Cameras. Now Footage Is Leaking Online Yes, the compromised Microsoft key that they glossed over is incredibly important and Microsoft is downplaying it something fierce. Optimize AWS Config for AWS Security Hub to effectively manage your cloud security posture Tool of the Week: IAMActionHunter lets you query IAM permission policies

Giorgi Dalakishvili is a software developer with more than a decade of experience. He works mainly with C#, ASP.NET MVC/ASP.NET Core, REST, WCF, Xamarin, Android, iOS, Entity Framework, Azure, SQL Server, and Oracle.   Giorgi is an open-source author and contributor on GitHub and a member of the .NET Foundation and InfoQ Editor.   Topics of Discussion: [3:33] Giorgi has worked with all the frameworks and libraries that Microsoft has come out with over the past 10‒15 years. He discusses using Entity Framework and starting his small speaking engagements. [5:12] Sessionize is a website where you can put out some different topics that you'd be willing to speak on, and just reach out to different user groups to take the plunge and do some public speaking for the first time. [6:03] Other types of data with Entity Framework beyond relational data, such as hierarchical data type from SQL Server. [8:49] How it simplifies your life. [9:28] What about JSON? Are there any limitations on the back-end database? [13:00] Is the support in EF Core 7.0 good enough to give a try if you're going against SQL Server? [14:09] What other types of data are interesting to work with with Entity Framework? [14:36] Using geospatial data. What does it even look like? [18:30] Full text search, and how it's different from a regular text search. [23:20] There are a lot of features to uncover in relational databases that we aren't even aware of yet. [26:22] There are some problems and some tasks that are better solved with non-relational databases, but the majority can overlap between the two systems.   Mentioned in this Episodes: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us 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! Architect Tips — Video podcast! Azure DevOps .NET Giorgi Dalakishvili   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Mitchel Sellers is globally known as a 15-time Microsoft MVP, an ASPInsider, a DNN MVP, an MCP (Microsoft .NET, ASP.NET, and SQL Server), and CEO of IowaComputerGurus Inc. Sellers has a deep understanding of software development and, when speaking, focuses on proper architecture standards, performance, stability, security, and overall cost-effectiveness of delivered solutions. This message and his abilities resonate in the technical war room as well as the executive board room.   Mitchel is a prolific public speaker, presenting more than 400 sessions at user groups and conferences globally, such as DevUp, SDN, and Code PaLOUsa. Sellers has been the author of multiple books and a regular blogger on technology topics.   When Mitchel is not working in technology, you will find him flying his airplane, teaching others how to fly, or spending time with his family. He is also actively involved in the Open Source Community working diligently to further the movement.   Topics of Discussion: [3:02] Congrats to Mitchel on his election to a leadership position at the .NET foundation. [3:41] What is the .NET Foundation? [5:58] What about .NET Maui catches Mitchel's attention, and is it really ready for us to go for it? [6:40] Official support for Xamarin Forms is going to be ending officially in early 2024. [8:48] The .NET Maui Blazor hybrid model. [10:22] What has been Mitchel's experience pushing Maui applications to the various app stores? [13:00] The most applicable patterns when you are laying out the spread of a Maui application. [16:10] The preference for a centralized location. [21:49] The tendency to overlook analytics. [22:57] What does the analytics and telemetry suite look like, and what are the users doing with the application? [25:01] Tools like App Insights from Azure can be awesome, but they can also get very expensive. [27:10] What is the DevOps story for Maui applications these days from continuous integration and automated testing to deployments and versioning? [31:12] Using GitHub actions, which of the steps require certain operating-system-hosted agents? [34:37] What is next for Maui, both traditional and using the Blazor hybrid? [37:40] Where can we find Mitchel next?   Mentioned in this Episodes: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us 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! Architect Tips — Video podcast! Azure DevOps .NET Mitchel Sellers .NET Foundation Architect Forum Clear Measure Way GitHub Mitchel Sellers .NET Maui + GitHub Actions Mobile Sync   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Mike Brind spent the first 20 years of his working life in a series of successful sales and marketing roles, towards the end of which he was introduced to HTML and databases. A dormant inner geek took over and Mike became very much more interested in developing websites than selling advertising space on them.   As well as books such as those in the Wrox Beginner series, Mike became reliant on the enormous amount of free help provided by online communities while he learned his new craft. Mike is now one of the all-time leading contributors to the official ASP.NET forums at http://forums.asp.net and is also a moderator there.   As a result of his contributions to the ASP.NET community via the forums, and through his technical article site at http://www.mikesdotnetting.com, Mike received the Microsoft Most Valuable Professional (MVP) Award for ASP.NET from 2008 to 2018. Beginning ASP.NET Web Pages with WebMatrix is Mike's first book.   Topics of Discussion: [3:06] How did Mike decide to leave school to become a programmer? [5:42] Jeffrey and his son are programming their own video game! [7:17] What sparked his interest in Razor and writing his new book, ASP.NET Core Razor Pages in Action? [9:51] What is the framework that Mike uses in his day-to-day job? [10:37] How would Mike classify the types of websites or web applications that are perfect for Razor pages, and maybe had some difficulties with other frameworks? [14:16] Are there any commonalities that you lose if you do the application with Razor pages and not MVC? [16:32] How does Mike organize his feature folders? [18:12] How Mike organizes test libraries and test cases. [20:06] What has been Mike's experience with Playwright? [21:02] What's coming in the future of Razor and Blazor? [24:39] The modernization jump for people who have old classic ASP applications is Razor pages.   Mentioned in this Episodes: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us 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! Architect Tips — Video podcast! Azure DevOps .NET ASP.NET Core Razor Pages in Action Learn Razor Pages   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Brian Lagunas is a Microsoft MVP, a Microsoft Patterns & Practices Champion, leader of the Boise .Net Developers User Group (NETDUG), board member of Boise Code Camp, speaker, trainer, and Pluralsight author. He can be found speaking at a variety of developer events around the world. His talks always involve some form of markup (XAML or HTML), as well as how to build well-architected applications with Prism. In his spare time, he authors courses for Pluralsight, blogs, livestreams about various technologies, and manages the Prism Library. The easiest way to find Brian is on Twitter at @BrianLagunas.   Topics of Discussion: [2:21] High points in Brian's career that have shaped his way of thinking about software, including starting his career at a global infrastructure company construction company. [5:22] The mentor that taught Brian about the importance of getting your foundation right. [7:11] How today's development mindset is different. [8:40] How does Brian balance or reason those competing pressures from the outside? [9:52] Delivering quality first and creating a long-term plan for the team. [12:43] Fixing problems with the software versus working on new capabilities. [15:56] Brian's approach when he took the team over, and how he handled any resistance and pushback by showing his team firsthand better efficiency and productivity. [16:26] How Brian measured actual progress. [21:02] The value of having a subjective opinion. [22:30] What quality controls does Brian put in place? [25:42] The issue Brian and his team found. [27:51] What kind of skills did Brian have to employ to make this level of testing possible? [29:15] The importance of everyone being open to helping and learning from each other and helping out where they can. [29:50] How Brian thinks about pull requests. [32:14] Stay tuned for Brian's thoughts on static analysis. [33:41] The emotional side of things and how people feel about their work when they are focused more on development and spending less time fighting fires.   Mentioned in this Episodes: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us programming@palermo.network 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! Architect Tips — Video podcast! Azure DevOps .NET Brian Lagunas — Ep #228 Improve Pull Request Descriptions Using Templates Continuous Integration: Improving Software Quality and Reducing Risk, by Paul M. Duvall, Steve Matyas, and Andrew Glover   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Kevin is a software developer who finds great joy in teaching and learning from others. He's been honing my craft for over two and a half decades. If he's not in code, he's near it. Kevin is often working on practices and processes that improve the engineering excellence of the team.   Currently, Kevin is in an architecture/lead development position at Northern Arizona University. He develops best practices tailored to the team and company culture. Kevin is a strong believer in applying systems thinking to all he does.   Topics of Discussion: [2:13] How Kevin discovered his passion for software, and proof you can be successful even if you are bad at math! [4:51] Kevin loves giving back to others by offering his mentorship. [5:15] How we can adjust to a changing culture. [8:09] The evolution of his DevOps team. [12:11] The idea of being able to read the code. [13:06] How do you start the DevOps journey? [15:05] What is a build script? Why is it important, and what are the most important components that need to be in the build script, in Kevin's opinion? [20:16] What are the items that Kevin likes to make sure are in the DevOps environment when developers are starting a new application? [23:00] Creating a new web application in an existing environment vs. a new environment. [27:12] The importance of getting value out the door. [29:41] Safe database deployment, safe database changes. [32:45] Kevin's chosen practice for using toggling and deprecating feature flags along with some of his favorite tools and libraries. [34:01] Protecting against API changes with third-party services.   Mentioned in this Episodes: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us programming@palermo.network 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! Architect Tips — Video podcast! Azure DevOps .NET Architect Forum   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Greg is a Cloud Architect that assists organizations with cloud adoption and innovation and is currently a Public Cloud Architect at AT&T. He has been working in the IT industry since his time in the military and is a developer, teacher, speaker, and early adopter. Greg has worked in many facets of IT throughout his career and is currently the president of TampaDev, a community meetup that runs #TampaCC and various technology events throughout Tampa. Greg holds a certification as a Microsoft Certified Azure Solutions Architect Expert, and Microsoft Certified Trainer, and is an Azure MVP.   Topics of Discussion: [3:01] Greg talks about being a military veteran from the first Gulf War and then transitioning into the technology arena. [3:33] Giving back to the veteran community. [6:04] Is AI inherently irresponsible? [6:30] Greg defines responsible AI. [7:02] Thinking about AI as your personal assistant, but only presenting you with the facts. [8:53] The difference between the public models set out by the big companies, and the other aspect of creating your own model by choosing your own set of data using the GPT technology to analyze that data. [16:43] Hallucinations in AI and GPT models. [17:10] What is actionable right now for developers when they are designing it so that we can have some safeguards built in? [21:55] The difference between fact and affirmation. [23:41] The system shouldn't just give us what we want, but it should be able to route that want into something that's factual. [33:10] The design process for developers that want to create their own model. [37:11] Does Greg have any Chat GPT models?   Mentioned in this Episodes: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us programming@palermo.network 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! Architect Tips — Video podcast! Azure DevOps .NET Architect Forum “Architecting For Azure with Greg Leonardo”   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.  

Kenneth Rose, CTO at OpsLevel, joins Corey on Screaming in the Cloud to discuss how OpsLevel is helping developer teams to scale effectively. Kenneth reveals what a developer portal is, how he thinks about the functionality of a developer portal, and the problems a developer portal solves for large developer teams. Corey and Kenneth discuss how to drive adoption of a developer portal, and Kenneth explains why it's so necessary to have executive buy-in throughout that process. Kenneth also discusses how using their own portal internally along with seeking out customer feedback has allowed OpsLevel to make impactful innovations. About KenKenneth (Ken) Rose is the CTO and Co-Founder of OpsLevel. Ken has spent over 15 years scaling engineering teams as an early engineer at PagerDuty and Shopify. Having in-the-trenches experience has allowed Ken a unique perspective on how some of the best teams are built and scaled and lends this viewpoint to building products for OpsLevel, a service ownership platform built to turn chaos into consistency for engineering leaders.Links Referenced: OpsLevel: https://www.opslevel.com/ LinkedIn: https://www.linkedin.com/company/opslevel/ Twitter: https://twitter.com/OpsLevelHQ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn, about, oh I don't know, two years ago and change, I wound up writing a blog post titled, “Developer Portals are An Anti Pattern,” and I haven't really spent a lot of time thinking about them since. This promoted guest episode is brought to us by our friends at OpsLevel, and they have sent their CTO and co-founder Ken Rose, presumably in an attempt to change my perspective on these things. Let's find out. Ken, thank you for agreeing to, well, run the gauntlet, for lack of a better term.Ken: Hey, Corey. Thanks again for having me. And I've heard, you know, heard and listened to your show a bunch, and really excited to be here today.Corey: Let's begin with defining our terms. I'm curious to know what a developer portal is. ‘What would you say a developer portal means to you?' Like it's a college entrance essay.Ken: Right? Definitely. You know, so really, a developer portal is this consolidated place for developers to come to, especially in large organizations to be able to get their jobs done more easily, right? A large challenge that developers have in large organizations, there's just a lot to do and a lot to take care of. So, a developer portal is a place for developers to be able to better own, manage, and run the services, they're responsible for that run in production, and they can do that through access, easy access to self-service tooling.Corey: I guess, on some level, this turns into one of those alignment charts of, like, what is a database and, like, how prescriptive you want to be. It's like, well is a senior engineer a database because you can query them and they have information? Would you consider, for example, Kubernetes be a developer platform, and/or would the AWS console?Ken: Yeah, that's actually an interesting question, right? So, I think there's actually two—we're going to get really niggly here—there's developer platform and developer portal, right? And the word portal for me is something that sits above a developer platform. I don't know if you remember, like, the late-90s, early-2000s, like, portals were all the rage.Like, Yahoo and AltaVistas were like search portals, they were trying to, at the time, consolidate all this information on a much smaller internet to make it easy to access. A developer portal is sort of the same thing, but custom-built for developers and trying to consolidate a lot of the tooling that exists. Now, in terms of the AWS console? Yeah, maybe. Like, it has a suite of tools and suite of offerings. It doesn't do a lot on the well, how do I quickly find out what's running in production and who is responsible for it? I don't know, unless AWS shipped, like, their, you know, three-hundredth new offering in the last week that I haven't, you know, kept on top of.But you know, there's definitely some spectrum in terms of what goes into a developer portal. For me, there's kind of three main things you need. You do need some kind of a catalog, like, what's out there who owns it; you need some kind of a way to measure, like, how good are those services, like, how well built are they; and then you need some access to self-service tooling. And that last part is where, like, the Kubernetes or AWS could be, you know, sort of a dev portal as well.Corey: My experience with developer portals—there was a time when I loved it. RightScale was what I used—at some depth—back in I want to say 2010, 2011 because the EC2 console was clearly not built or designed by anyone who had not built EC2 themselves with their bare hands and sweat of their brow. And in time, the EC2 console got better where it wasn't written in hieroglyphics, as best we could tell, and it became ‘click button to launch instance.' And RightScale really didn't have a second act and they wound up getting acquired by our friends over at Flexera years later. And I haven't seen their developer portal in at least eight years as a direct result of this.So, the problem, at least when I was viewing it purely in the context of AWS services, it feels like you are competing against AWS iterating forward on developer experience, which they iterate slowly, sometimes, and unevenly across their breadth of services, but it does feel like at some level by building an internal portal, you are, first, trying to out-innovate AWS, in some ways, and two, you are inherently making the trade-off of not using recent features and enhancements that have not themselves been incorporated into the portal. That's where the, I guess the start, the genesis of my opposition to the developer portal approach comes from. Is that philosophy valid these days? Not as much. Because I can see an argument for it shifting.Ken: Yeah, I think it's slightly different. I think of a developer portal as again, it's something that sort of sits on top of AWS or Google Cloud or whatever cloud provider use, right? You give an example for example with RightScale and EC2. So, provisioning instances is one part of the activity you have to do as a developer. Now, in most modern organizations, you have, like, your product developers that ship features. They don't actually care about provisioning instance themselves. There are another group called the platform engineers or platform group that are responsible for building automation and tooling to help spin up instances and create CI/CD pipelines and get everything you need set up.And they might use AWS under the covers to do that, but the automation built on top and making that accessible to developers, that's really what a developer portal can provide. In addition, it also provides links to operational tooling that you need, technical documentation, it's everything you need as a developer to do your job, in one place. And though AWs bills itself is that, I think of them as more, they have a lot of platform offerings, right, they have a lot of infra-offerings, but they still haven't been able to, I think, customize that, unless you're an organization that builds—that has kind of gone in-all on AWS and doesn't build any of your own tooling, that's where a developer portal helps. It really helps by consolidating all that information in one place, by making that information discoverable for every developer so they have less… less cognitive load, right? We've asked developers to kind of do too much that we don't… we've asked to shift left and well, how do we make that information more accessible?Regarding the point of, you know, AWS adds new features or new capabilities all the time and, like, well you have this dev portal, that's sort of your interface for how to get things done. Like, how will you use those? Dev portal doesn't stop you from doing that, right? So, my mental model is, if I'm a developer, and I want to spin up a new service, I can just press a button inside of my dev portal in my company and do that. And I have a service that is built according to the latest standards, it has a CI/CD pipeline, it already has a—you know, it's registered in PagerDuty, it's registered in Datadog, it has all the various bits.And then there's something else that I want to do that isn't really on the golden path because maybe this is some new service or some experiment, nothing stops us from doing that. Like, you still can use all those tools from AWS, you know, kind of raw. And if those prove to be valuable for the rest of the organization, great. They can make their way into the dev portal; they can actually become a source of leverage. But if they're not, then they can also just sit there on the vine. Like, not everything that eight of us ever produces will be used by every company.Corey: Many years ago, I got a Cisco pair of certifications because recession was hitting and I needed to be better at networking. And taking those certifications, in those days before Cisco became the sad corporate dragon with no friends we all know today, they were highly germane and relevant. But I distinctly remember, even now, 15 years later, that there was this entire philosophy of pretend that the entire world is Cisco only, which in networking is absolutely never true. It feels like a lot of the AWS designs and patterns tend to assume, oh yeah, you're going to use AWS services for everything. I have never yet found that to be true, other than when I'm just trying to be obstinate.And hell is interoperability between a bunch of different things. Yes, I may want to spin up an EC2 instance and an AWS load balancer and some S3 storage or whatnot, but I'm also going to want to monitor it with PagerDuty, I'm going to want to have a CDN that isn't CloudFront because most CDN these days don't hate you in quite the same economic ways and are simpler to work with, et cetera, et cetera, et cetera. So, there's definitely a story wherein I've found that there's an—the interoperability of tying these things together is helpful. How do you avoid falling down the trap of oh, everyone should be multi-cloud, single pane of glass at cetera, et cetera? In practice that always seems to turn to custard.Ken: Yeah, I think multi-cloud and single pane of glass are actually two different things. So multi-cloud, like, I agree with you to some sense. Like, pick a cloud and go with it, like, unless you have really good business reasons to go for multi-cloud. And sometimes you do, like, years ago, I worked at PagerDuty, they were multi-cloud for a reliability reason, that hey, if one cloud provider goes down, you don't want [crosstalk 00:08:40]—Corey: They were an example I used all the time for that story—Ken: Right.Corey: —specifically the thing woke you up was homed in a bunch of different places, whereas the marketing site, the onboarding flow, the periphery stuff around it was not because it didn't need to be.Ken: Exactly.Corey: Like, the core business need of wake you up was very much multi-cloud because once upon a time, it wasn't and it went down with the rest of us-east-1 and people weren't woken up to be told their site was on fire.Ken: A hundred percent. And on the kind of like application side where, even then, pick a cloud and go with it, unless there's a really compelling business reason for your business to go multi-cloud. Maybe there's something credits or compliance or availability, right? There might be reasons, but you have to be articulate about whether they're right for you.Now, single pane of glass, I think that's different, right? I do think that's something that, ultimately, is a net boon for developers. In any large organization, there is a myriad of internal tools that have been built. And it's like, well, how do I provision a new topic in the Kafka cluster? How do I actually get access to the AWS console? How do I spin up a new service, right? How do I kind of do these things?And if I'm a developer, I just want to ship features. Like, that's what I'm incented to do, that's what I'm optimizing for. And all this other stuff I have to do as part of my job, but I don't want to have to become, like, a Kubernetes guru to be able to do it, right? So, what a developer portal is trying to do is be that single pane of glass, bringing all these common set of tools and responsibilities that you have as a developer in one place. They're easy to search for, they're easy to find, they're easy to query, they're easy to use.Corey: I should probably have asked this earlier on, but let's disambiguate for a little bit here. Because when I'm setting up to use a new service or product and kick the tires on it, no two explorations really look the same. Whereas at most responsible mature companies that are building products that are—services that are going to production use, they've standardized around a number of different approaches. What does your target customer look like? Is there a certain point of scale, a certain level of complexity, a certain maturity of process?Ken: Absolutely. So, a tool like OpsLevel or a developer portal really only makes sense when you hit some critical mass in terms of the number of services you have running in production, or the number of developers that you have. So, when you hit 20, 30, 50 developers or 20, 30, 50 services, an important part of a developer portal is this catalog of what's out there. Once you kind of hit the Dunbar number of services, like, when you have more than you keep in your head, that's when you start to need tooling like this. If you look at our customer base, they're all you know, kind of medium to large-sized companies. If you're a startup with, like, ten people, OpsLevel is probably not right for you. We use all playable internally at OpsLevel, and you know, like, we're still a small company. It's like, we make it work for us because we know how to get the most out of it, but like, it's not the perfect fit because it's not really meant for, you know, smaller companies.Corey: Oh, I hear you. I think I'm probably… I have a better AWS bill analytic system running internally here at The Duckbill Group than some banks do. So, I hear you on that front.Ken: I believe it.Corey: But also implies to me that there's no OpsLevel prospect or customer deployment that has ever been greenfield. It's always you're building existing things, there's already infrastructure in place, vendors have been selected across the board. You aren't—don't to want to starting a company day one, they're going to all right, time to spin up our AWS account and we're also going to wind up signing up for OpsLevel, from the sound of it.Ken: Correct—Corey: Accurate? Inaccurate?Ken: I think that's actually accurate. Like, a lot of the problems, we solve other problems that come as you start to scale both your product and your engineering team. And it's the problems of complexity.Corey: What do those painful problems look like? In other words, what is someone sitting at home right now listening to this, or driving to work debating whether want to ram a bridge abutment or go into the office depending on their mental state today, what painful problem did they have that OpsLevel is designed to fix?Ken: Yeah, for sure. So, let's help people self-select. So, here's my mental model for any [unintelligible 00:12:25]. There are product developers, platform developers, and engineering leaders. Product developers, if you're asking questions like, “I just got paged for the service. I don't know what this does.” Or, “It's upstream from here. Where do I find the technical documentation?” Or, “I think I have to do something with the payment service. Where do I find the API for that?”You know, when you get to that scale, a developer portal can help you. If you're a platform engineer and you have questions like, “Okay, we got to migrate. We're migrating, I don't know, from Datadog to Honeycomb, right? We got to get these fifty or a hundred or thousands of services and all these different owners to, like, switch to some new tool.” Or, “Hey, we've done all this work to ship the golden path. Like, how to actually measure the adoption of all this work that we're doing and if it's actually valuable?” Right?Like, we want everybody to be on a certain set of CI tooling or a certain minimum version of some library or framework. How do we do that? How do we measure that? OpsLevel is for you, right? We have a whole bunch of stuff around maturity.And if you're engineering leader, ultimately, questions you care about, like, “How fast are my developers working? I have this massive team, we've made this massive investment in hiring all these humans to write software and bring value for our customers. How can we be more efficient as a business in terms of that value delivery?” And that's where OpsLevel can help as well.Corey: Guardrails, whether they be economic, regulatory, or otherwise, have to make it easier than doing things incorrectly because one of the miracle aspects of cloud also turns into a bit of a problem, which is shadow IT is only ever a corporate credit card away. Make it too difficult to comply with corporate policies and people won't. And they're good actors; they're trying to get work done. They're not trying to make people's lives harder, but they don't want to spend six weeks provisioning an EC2 cluster. So, there's always that weird trade-off.Now, it feels—and please correct me if I'm wrong—once someone has rolled out OpsLevel at their organization, where it really shines is spinning up a new service where okay, great, you're going to spin up the automatic observability portion of it, you're going to spin up the underlying infrastructure in certain ways that comply with our policies, it's going to build the CI/CD pipelines around it, you're going to wind up having the various cost instrumentation rolled out to it. But for services that are already excellent within the environment, is there an OpsLevel story for them?Ken: Oh, absolutely. So, I look at it as, like, the first problem OpsLevel helps solve is the catalog and what's out there and who owns it. So, not even getting developers to spin up new services that are kind of on the golden path, but just understanding the taxonomy of what are the services we have? How do those services compose into higher-level things like systems or domains? What's the whole set of infrastructure we have?Like, I have 50 AWS accounts, maybe a handful of GCP ones, also, some Azure. I have all this infrastructure that, like, how do I start to get a handle on, like, what's out there in prod and who's responsible for it. And that helps you get in front of compliance risks, security risks. That's really the starting point for OpsLevel building that catalog. And we have a bunch of integrations that kind of slurp all this data to automatically assemble that catalog, or YAML as well if that's your thing. But that's the starting point is building that catalog and figuring out this assignment of, like, okay, this service and this human, or this—sorry—team, like, they're paired together.Corey: A number of offerings in this space, which honestly, my exposure to it is bounded simultaneously to things that are ten years old and no one uses anymore, or a bunch of things I found on GitHub. And the challenge that both of those products tend to have is that they assume certain things to be true about a given environment: that they're using Terraform to manage everything, or they're always going to be using CloudFormation, or everyone there knows Python or something else like that. What are the prerequisites to get started with OpsLevel?Ken: Yeah, so we worked pretty hard to build just a ton of integrations. I would say integrations is are just continuing thing we have going on in the background. Like, when we started, like, we only supported a GitHub. Now, we support all the gits, you know, like GitHub, GitLab, Bitbucket, Azure DevOps, like, we're building [unintelligible 00:16:19]. There's just a whole, like, long tail of integrations.The same with APM tooling. The same with vulnerability management tooling, right? And the reason we do that is because there's just this huge vendor footprint, and people, you know, want OpsLevel to work for them. Now, the other thing we try to do is we also build APIs. So, anything we have as, like, a core integration, we also have kind of like an underlying API for, so that there's, no matter what you have an escape hatch. If like, you're using some tool that we don't support or you have some homegrown thing, there's always a way to try to be able to integrate that into OpsLevel.Corey: When people think about developer portals, the most common one that pops to mind is Backstage, which Spotify wound up building, internally, championing, open-sourcing, and I believe, on some level, turned into a product because if there's one thing people want, it's to have their podcast music company become a SaaS vendor, which is weird to me. But the criticisms that I've seen about and across the board have rung relatively true, including from people internal at Spotify who have used the thing, which is, well first is underestimating the amount of effort that is necessary to maintain Backstage itself, that the build versus buy discussion is always harder to bu—engineers love to build, but they shouldn't be building things outside of their core competency half the time, and the other is driving adoption within the org where you can have the most amazing developer portal in the known universe, but if people don't use it, it may as well not exist and doing the carrot and stick approach often doesn't work. I think you have a pretty good answer that I need not even ask you to elaborate on, “Well, how do we avoid having to maintain this ourselves,” since you have a company that does this, but how do you find companies are driving adoption successfully once they have deployed OpsLevel?Ken: Yeah, that's a great question. So, absolutely. Like, I think the biggest thing you need first, is kind of cultural buy-in and that this is a tool that we want to invest in, right? I think one of the reasons Spotify was successful with Backstage and I think it was System Z before that was that they had this kind of flywheel of, like, they saw that their developers were getting, you know better faster, working happier, by using this type of tooling, by reducing the cognitive load. The way that we approach it is sort of similar, right?We want to make sure that there is executive buy-in that, like, everybody agrees this is, like, a problem that's worth solving. The first step we do is trying to build out that catalog again and helping assign ownership. And that helps people understand, like, hey, these are the services I'm responsible for. Oh, look, and now here's this other context that I didn't have before. And then helping organizations, you know, what—it depends on the problem we're trying to solve, but whether it's rolling out self-serve automation to help developers, like, reduce what was before a ton of cognitive load or if it's helping platform teams define what good looks like so they can start to level up the overall health of what's running in production, we kind of work on different problems, but it's picking one problem and then you know, kind of working with the customers and driving it forward.Corey: On some level, I think that this is going to be looked down upon inherently just by automatic reflex of folks with infrastructure engineering backgrounds. It's taken me some time to learn to overcome my own negative reaction to it. Because it's, I'm here to build things and I want to build things out in such a way that it's portable and reusable without having to be tied to a particular vendor and move on. And it took me a long time to realize that what that instinct was whispering in my ear was in fact, no, you should be your own cloud provider. If that's really what I want to do, I probably should just brush up on you know, computer science trivia from 20 years ago and then go see if I can pass Google's SRE interview.I'm not here to build the things that just provision infrastructure from scratch every company I wind up landing at. It feels like there's more important, impactful work that I can do. And let's be clear, people are never going to follow guardrails themselves when they have to do a bunch of manual steps. It has to be something that is done for them. And I don't know how you necessarily get there without having some form of blueprint or something like that, provided for them with something that is self-service because otherwise, it's not going to work.Ken: I a hundred percent agree, by the way, Corey. Like, the take that, like, automation is the only way to drive a lot of this forward is true, right? If for every single thing you're trying—like, we have a concept called a rubric and it's basically how you measure the service health. And you can—it's very customizable, you have different dimensions. But if, for any check that's on your rubric, it requires manual effort from all your developers, that is going to be harder than something you can just automate away.So, vulnerability management is a great example. If you tell developers, “Hey, you have to go upgrade this library,” okay, some percentage [unintelligible 00:20:47], if you give developers, “Here's a pull request that's already been done and has a test passing and now you just need to merge it,” you're going to have a much better adoption rate with that. Similarly with, like, applying templates being able to [up-level 00:20:57], you know, kind of apply the latest version of a template to an existing service, those types of capabilities, anything where you can automate what the fixes are, absolutely you're going to get better adoption.Corey: As you take a look at your existing reference customers—which is something I always look for on vendor websites because, like, oh, we have many customers who will absolutely not admit to being customers, it's like, that sounds like something that's easy to say—you have actual names tied to these things. Not just companies, but also individuals. If you were to sit down and ask your existing customer base, “So, why did you wind up implementing OpsLevel and what has the value that's delivered to you been since that implementation?” What do they say?Ken: Definitely. I actually had to check our website because we, you know, land new customers and put new logos on it. I was like, “Oh, I wonder what the current set is out right now?”Corey: I have the exact same challenge. Like oh, we have some mutual customers. And it's okay. I don't know if I can mention them by name because I haven't checked our own list of testimonials [unintelligible 00:21:51] lately because say the wrong thing and that's how you wind up being sued and not having a company anymore.Ken: Yeah. So, I don't—I definitely, you know, want to stay [on side 00:22:00] on that part, but in terms of, like, kind of sample reference customer, a lot of the folks that we initially worked with are the platform teams, right? They're the teams that care about what's out there, and they need to know who's responsible for it because they're trying to drive some kind of cross-cutting change across the entire, you know, production footprint. And so, the first thing that generally people will say is—and I love this quote. This came—I won't name them, but like, it's in one of our case studies.It was like, “I had, like, 50 different attempts at making a spreadsheet and they're all, like, in the graveyard, like, to be able to capture what's out there and who's responsible for it.” And just OpsLevel helping automate that has been one of the biggest values that they've gotten. The second point, then is now be able to drive maturity and be able to measure how well those services are being built. And again, it's sort of this interesting thing where we start with the platform teams. And then sometime later security teams find out about OpsLevel, and they're like, “Oh, this is a tool I can use to, like, get developers to do stuff? Like, I've been trying to get developers to do stuff for the longest time.”And they—I file Jira tickets and they just sit there and nothing gets done. But when it becomes part of this, like, overall health score that you're trying to increase a part of the across the board, yeah, it's just a way to kind of drive action.Corey: I think that there's a dichotomy of companies that emerge. And I tend to see the world through a lens of AWS bills, so let's go down that path. I feel like there are some companies presumably like OpsLevel, whereas if I—assuming you're running on top of AWS—if I were to pull your AWS bill, I would see upwards of 80% of your spend is going to be on this application called OpsLevel, the service that you provide to people. As opposed to the other side of the world, which is large enterprises, where they're spending hundreds of millions of dollars a year, but the largest application they have is a million-and-a-half a year in spend because just, they have thousands of these things scattered everywhere. That latter case is where I tend to see more platform teams, where I start to see a lot of managing a whole bunch of relatively small workloads. And developer platforms really seem to be where a lot of solutions lead, whereas 80% of our workload is one application, we don't feel the need for that as much. Is that accurate? Am I misunderstanding some aspect of it?Ken: No, a hundred percent you'd hit the nail on the head. Like, okay, think about the typical, like, microservices adoption journey. Like, you started with, you know, some small company—like us—you started with a monolith. Ah, maybe you built out a second app—Corey: Then you read on Hacker News and realize, “Oh, if we want to hire people, we've got to be doing what all the cool kids are up to.”Ken: Right. We got a microservice all the thing—but that's actually you know, microservices should come later, right, as a response to you needing scale your org and scale your—Corey: As someone who started building some application with microservices, I could not agree more.Ken: A hundred percent. So, it's as you're starting to take steps to having just more moving parts in your production infrastructure, right? If you have one moving part, unless it's like a really large moving part that you can internally break down, like, kind of this majestic monolith where you do have kind of like individual domains that are owned by different teams, but really the problem we're trying to solve, it's more about, like, who owns what. Now, if that's a single atomic unit, great, but can you decompose that? But if you just have, like, one small application, kind of like the whole team is owning everything, again, a developer portal is probably not the right tool for you. It really is a tool that you need as you start to scale your engineer work and as you start to scale the number of moving parts in your production infrastructure.Corey: I tended to use to think of that in terms of boring companies versus innovative ones and I don't think that's accurate. I think it is the question of maturity and where companies lead to. On some level, of OpsLevel starts growing and becomes larger and larger in different ways and starts doing acquisitions and launching into other areas, at some point, you don't have just one product offering, you have a multitude of them. At which point having something like that is going to be critical. But I have to ask, given that you are sort of not exactly your target customer profile, what are the sharp edges been on using it for your use case?Ken: Yeah. So, we actually have an internal Slack channel, we call OpsLevel on OpsLevel. And finding those sharp edges actually has been really useful for us. You know, all the good stuff, dogfooding and it makes your own product better. Okay, so we have our main app, we also do have a bunch of smaller things and it's like, oh yeah, you know, we have, like, I don't know, various Hackaday things that go on, it's important we kind of wind those down for, you know, compliance, we have our marketing site, we have, like, our Terraform.Like, so there's, like, stuff. It's not, like, hundreds or thousands of things, but there's more than just the main app. The second though, is it's really on the maturity piece that we really try to get a lot of value out of our own product, right? Helping—we have our own platform team. They're also trying to drive certain initiatives with our product developers.There is that usual tension of our, like, our own product developers are like, “I want to ship features.” What's this security thing I have to go take care of right now? But OpsLevel itself, like, helps reflect that. We had an operational review today and it was like, “Oh, this one service is actually now”—we have platinum as a level. It's in gold instead of platinum. It's like, “Why?” “Oh, there's this thing that came up. We got to go fix that.” “Great. Let's go actually go fix that so we're back into platinum.”Corey: Do you find that there's often a choice you have to make internally, where you could make the product more effective for your specific use case, but that also diverges from where your typical customer needs or wants the product to go?Ken: No, I think a lot of the things we find for our use case are, like, they're more small paper cuts, right? They're just as we're using it, it's like, “Hey, like, as I'm using this, I want to see the report for this particular check. Why do I have to click six times to get?” You know, like, “Wouldn't it be great if we had a button?” Right?And so, it's those type of, like, small innovations that kind of come up. And those ultimately lead to, you know, a better product for our customers. We also work really closely with our customers and developers are not shy about telling you what they don't like about your product. And I say this with love, like, a lot of our customers give us phenomenal feedback just on how our product can be better and we try to internalize that and you know, roll that feedback into the product.Corey: You have a number of integrations of different SaaS providers, infrastructure providers, et cetera, that you wind up working with. I imagine that given your scale and scope and whatnot, those offerings are dictated by what customers say, “Hey, we're using this thing. Are you going to support that or are you not going to maintain our business?” Which is a great way to wind up financing a lot of product development and figuring out what matters to people. My question for you is, if you look across the totality of your user base, what are the most popularly used integrations, if you can say?Ken: Yeah, for sure. I think right now—I could actually dive in to pull the numbers—GitHub and GitLab—or… I think GitHub, like, has slightly more adoption across our customer base. At least with our customers, almost nobody uses Bitbucket. I mean, we have, like, a small number, but, like, it's… I think, single-digit percentage. A lot of people use PagerDuty, which you know, hey, I'm an ex-PagerDuty person [crosstalk 00:28:24] and I'm glad to see that.Corey: I have a free tier PagerDuty account that will automatically page me for my home automation stuff. Specifically, if you know, the fire alarm goes off. Like, yeah, okay, there are certain things I want to be woken up for, but it's a very short list.Ken: Yeah, it's funny, the running default message when we use a test PagerDuty was, “The server is on fire.” [unintelligible 00:28:44] be like, “The house is on fire.” Like you know, go get that taken care of. There's one other tool so that's used a lot. Datadog actually is used a ton by just across our entire customer base, despite its… we're also Data—we're a Datadog partner, we're a Datadog customer, you know? It's not cheap, but it's a good product for, you know, monitoring and logs and there are [crosstalk 00:29:01]—Corey: No other than cloud infrastructure providers, I get the number one most common source of inquiries is Datadog optimization. It has now risen to a board-level concern in many cases because observability is expensive. That's a sign of success, on some level. Meanwhile, I'm sitting here, like, Date-a-dog? Oh, my God, that's disgusting. It's like Tinder for Pets. Which it turns out is not at all what they do.Ken: Nice.Corey: Yeah.[audio break 00:29:23]—optimizing their Slack integrations, their GitHub integration, et cetera. Or are they starting with the spinning up the servers piece of it?Ken: A lot of the time—and again, that first problem they're trying to solve is just get me a handle on everything we have running in production. You know, if you have multiple AWS accounts, multiple Kubernetes clusters, dozens or even hundreds of teams, God help you if you're going to try to, like, build a list manually to consolidate all that information. That's really the first part is, like, integrate Kubernetes, integrate your CI/CD pipelines, integrate Git, integrate your Cloud account, like, will integrate with everything and will try to build that map of, like, here's everything that's out there, and start to try to assign it to, like, and here's people that we think might be responsible in terms of owning the software. That's generally the starting point.Corey: Which makes an awesome amount of sense. I think going at it from the infrastructure first perspective is where I've seen most developer platforms founder. And to be fair, the job is easier now than it was years ago because it used to be that you were being out-innovated by AWS constantly. Innovation has slow down there. And you know that because of how much they say the pace of innovation has only sped up.And whenever AWS says something in a marketing context, they're insecure about it. I've learned this through the fullness of time observing that company. And these days, most customers do not use the majority of features available for any given service. They have solidified to a point where you can responsibly build on top of these things. Now, it seems that the problem is all the ‘yes, and' stuff that gets built on top of it.Ken: Yeah. Do you have an example, actually, like, one of the kinds of, like, ‘yes, and' tools that you're thinking about?Corey: Oh, absolutely. We have a bunch of AWS environment stuff so we should configure CloudWatch to look at all these things from an observability perspective. No, you should not. You should set up Datadog. And the first time someone does that by hand, they enable all have the observability and the rest and suddenly get charged approximately the GDP of Guam.And okay, maybe we shouldn't do that because then you have the downstream impact of that on your CloudWatch bill. So okay, how do we optimize this for the observability piece directly tied to that? How do we make sure that we get woken up when the site is down or preferably before that, but not every time basically, a EBS volume starts to get a little bit toasty? You have to start dialing this stuff in. And once you've found a lot of those aspects, being able to templatize that and roll that out on an ongoing basis and having the integrations all work together feels like it's the right problem to be solving.Ken: Yeah, absolutely. And the group that I think is responsible for that kind of—because it's a set of problems you described—is really, like, platform teams. Sometimes service owners for like, how should we get paged, but really, what you're describing are these kind of cross-cutting engineering concerns that platform teams are uniquely poised to help solve in an [unintelligible 00:32:03] organization, right? I was thinking what you said earlier. Like, nobody just wants to rebuild the same info over and over, but it's sort of like, it's not just building an [unintelligible 00:32:09]; it's kind of like solving this, like, how do we ship? Can we actually run stuff in prod? And not just run it but get observability and ensure that we're woken up for it and, like, what's that total end-to-end look like from, like, developers writing code to running software in production that's serving traffic? And solving all the problems [unintelligible 00:32:24], that's what I think of was platform engineering.Corey: So, my last question before we wind up wrapping this episode comes down to, I am very adept at two different programming languages, and those are brute force and enthusiasm. What implementation language is most of what you find yourself working with? And why is it in invariably going to be YAML?Ken: Yeah, that's a great question. So, I think there's, in terms of implementing OpsLevel and implementing a service catalog, we support YAML. Like, you know, there's this very common workflow, you just drop a YAML spec, basically, in your repo, if you're a service owner. And that, we can support that. I don't think that's a great take, though.Like, we have other integrations. Again, if the problem you're trying to solve is I want to build a catalog of everything that's out there, asking each of your developers hey, can you please all write YAML files that, like, describe the services you own and drop them into this repo? You've inverted this, like, database that essentially you're trying to build, like, what's out there and stored it in Git, potentially across several hundreds or thousands of repos. You put a lot of toil now on individual product developers to go write and maintain these files. And if you ever had to, like, make a blanket update to these files, there's no atomic way to kind of do that, right?So, I look at YAML as, like, I get it, you know? Like, we use the YAML for all the things in DevOps, so why not their service catalog as well, but I think it's toil. Like, there are easier ways to build a catalog. By, kind of, just integrate. Like, hook up AWS, hook up GitHub, hook up Kubernetes, hook up your CI/CD pipeline, hook up all these different sources that have information about what's running in prod, and let the software, let the tool, automatically infer what's actually running as opposed to requiring humans to manually enter data.Corey: I find that there are remarkably few technical holy wars that I cannot unify both sides on by nominating something far worse. Like, the VI versus Emacs stuff, the tabs versus spaces, and of course, the JSON versus YAML folks. My JSON versus YAML answer is XML: God's language. I find that as soon as you suggest that, people care a hell of a lot less about the differences between JSON and YAML because their job is to now kill the apostate, which is me.Ken: Right. Yeah. I remember XML, like, oh, man, 2002. SOAP. I remember SOAP as a protocol. That was a thing.Corey: Some of the earliest S3 API calls were done in SOAP, and I think they finally just used it to wash their mouths out when all was said and done.Ken: Nice. Yeah.Corey: I really want to thank you for taking the time to do your level best to attempt to convert me, and I would argue in many respects, you have succeeded. I'm thinking about this differently than I did half an hour ago. If people want to learn more, where's the best place for them to find you?Ken: Absolutely. So, you can always check out our website, opslevel.com. We're also fairly active on LinkedIn. If Twitter hasn't imploded by the time this episode becomes launched, then they can also check us out at twitter.com/OpsLevelHQ. We're always posting, just different content on, like, how to be successful with service maturity, DevOps, developer productivity, so that you know, ultimately, that you can ship out to customers faster.Corey: And we will, of course, put links to that in the [show notes 00:35:23]. Thank you so much for taking the time, not just to speak with me, but also for sponsoring this episode. It is appreciated.Ken: Cheers.Corey: Ken Rose, CTO and co-founder at OpsLevel. I'm Cloud Economist Corey Quinn and this has been a promoted guest episode of 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 which, upon further reflection, you could have posted to all of the podcast platforms if only you had the right developer platform to pull it off.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.

Matthew Renze is a data science consultant, author, and public speaker. He is the founder of Renze Consulting, an AI consulting company that has trained over 500,000 software developers and IT professionals. His clients range from small tech start-ups to Fortune 500 companies. He is also the President of Serenze Global, a 501(c)(3) non-profit organization dedicated to improving access to technology education for under-represented individuals by empowering the next generation of tech community leaders. Matthew is currently working on his Master's degree in Artificial Intelligence with a Data Science specialization at Johns Hopkins University. He currently has double degrees in Computer Science and Philosophy with a minor in Economics from Iowa State University. He is a Microsoft MVP in AI, an ASPinsider, and an author for Pluralsight, Udemy, and Skillshare. His interests include AI, ML, data science, mindfulness, technology education, and tech community leadership.   Topics of Discussion: [1:41] How Matthew got into software development and eventually AI, rebranding himself as a data scientist and then AI consultant. [5:40] Matthew is getting his Master's Degree in Artificial Intelligence. [6:04] How can we demystify AI and all the buzzwords we use? [9:13] Are there any current products that meet the definition of strong general AI? [11:03] What does weak general AI mean? [13:51] For .NET developers, what can they actually do today, with this latest generation of generative AI? [17:02] What are some examples in AI right now that Matthew has come across that clearly violate any standard of ethical boundary? [19:00] A few of the issues with AI currently or ways that AI systems are being abused: AI hallucination AI-generated misinformation Algorithmic bias and discrimination Lack of trust in AI Recommendation engines (rabbit holes) Lack of basic AI literacy [22:00] Is it even possible for these models not to be biased? [22:35] We have to make sure that we've got balanced data sets in order to get the models to train properly. [25:41] How do we regulate ethics? [27:55] The distinction between using supervised learning, and then self-supervised learning, or reinforcement learning. [39:20] How we can prevent deep fake videos. [42:01] It's important to get these tools in the hands of the right people, provide education, and move forward mindfully. [47:02] Curating your own algorithm and handling information overload. Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us programming@palermo.network 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! Architect Tips — Video podcast! Azure DevOps .NET Architect Forum Matthew Renze Developing Your AI Strategy Matthew's Website Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Cale and Russell talk to the Microsoft Program Manager for DevBox and Azure Deployment Environments, Sagar Chandra Reddy Lankala, about how Azure Deployment Environments can enable rapid deployment of on-demand dev/test environments while providing governance, security and cost management - plus some more updates from Microsoft Build 2023! Media File: https://azpodcast.blob.core.windows.net/episodes/Episode464.mp3 Sagar's links: GA blog - https://aka.ms/ade-ga-blog Sign up for Terraform support - https://aka.ms/ade-terraform-signup LinkedIn profile - https://www.linkedin.com/in/sagarchandrareddy Other updates mentioned in this episode: Public preview: Introducing NGads V620-series VMs optimized for cloud gaming | Azure updates | Microsoft Azure Generally available: Azure Data Explorer Kusto Emulator on Linux | Azure updates | Microsoft Azure Explore the latest features for Datadog—An Azure Native ISV Service Microsoft Cost Management updates—May 2023 Microsoft has made Azure Linux generally available. Repeat, Azure Linux Azure OpenAI Service - Documentation, quickstarts, API reference - Azure Cognitive Services | Microsoft Learn Azure Deployment Environments | Microsoft Azure About Azure App Spaces | Microsoft Learn Introducing Azure API Center for Centralized API Discovery and Governance (microsoft.com) GitHub Advanced Security for Azure Devops

Sagar Lad is a Technical Solution Architect with a leading multinational software company and has deep expertise in implementing Data & Analytics solutions for large enterprises using Cloud and Artificial Intelligence. He is an experienced Azure Platform evangelist with 9+ Years of IT experience and a strong focus on driving cloud adoption for enterprise organizations using Microsoft Cloud Solutions & Offerings. He loves blogging and is an active blogger on Medium, LinkedIn, and the C# Corner developer community. He was awarded the C# Corner MVP in September 2021 for his contributions to the developer community. He's also the author of three books, Mastering Databricks Lakehouse Platform, Azure Security for Critical Workloads, and Hands-On Azure Data Platform.   Topics of Discussion: [2:57] Sagar talks about the critical points in his career that led him to technology. [6:01] What turned Sagar on to a love of data? [8:39] With so much technical jargon out there, how do you simplify? [12:40] What is Data Lakehouse? [13:25] What are some common scenarios where Data Lakehouse can be really valuable? [18:53] What does unit testing mean in the data bricks world? [22:10] How long does it take to run the tests in Azure? [25:42] What's the most expensive Databricks environment that Sagar has seen on a monthly basis? [27:54] What are some of the things that are being missed around the industry? [31:42] Sagar says that when we talk about security, there are seven layers.   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us programming@palermo.network 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! Architect Tips — Video podcast! Azure DevOps .NET Clear Measure Architect Forum Sagar Lad books on Amazon Certifications: Sagar Lad on Credly LinkedIn: Sagar Lad on LinkedIn Twitter: @AzureSagar (Twitter: Sagar Lad) Medium: Sagar Lad on Medium   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.  

René is a Principal Cloud Solution Architect - Engineering (CSA-E) and technical lead for Azure DevOps and software development processes at Microsoft in Germany. In his role as CE, he helps customers adopt good development practices and processes as well as understanding the principles of DevOps. As an Azure DevOps expert, René trains customers in using the DevOps toolchain and shows ways to integrate Azure DevOps into existing heterogeneous environments.   Before his start at Microsoft in late 2008, René had been working as a developer of enterprise logistic systems for almost ten years.   Topics of Discussion: [3:05] René's start of his career and how he got into programming. [5:20] How does René define the real difference between the 1990s waterfall mindset and the agile mindset, just from a process perspective? [7:49] How DevOps is an evolution of Agile. [9:13] What is DevOps all about? [11:29] The three ways of DevOps as described in The Phoenix Project: Maximize flow or system thinking. Amplify feedback loops. The culture of continuous experimentation and learning. [16:52] The importance of creating a natural cadence in your iteration. [17:16] What's the best way to standardize across different teams? [21:13] Choosing the right tool at the right point in time. [24:10] What type of test automation does René find himself recommending? [27:50] To René, the most important thing is to get your code right. In addition, unit testing also has a very positive impact on your architecture and design because you're building a testable product. [28:50] What is Rene's view on open telemetry in a DevOps mindset?   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us programming@palermo.network 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! Architect Tips — Video podcast! Azure DevOps .NET Clear Measure Architect Forum The Phoenix Project book: A Novel about IT, DevOps, and Helping Your Business Win, by Gene Kim, Kevin Behr, and George Spafford Test-driven development: By Example, by Kent Beck Extreme Programming Explained: Embrace Change, by Kent Beck and Cynthia Andres The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data, by Gene Kim The Mythical Man-Month: Essays on Software Engineering, by Frederick Brooks Jr. The Art of Unit Testing: With examples in JavaScript, by Roy Osherove Site Reliability Engineering: How Google Runs Production Systems, by Jennifer Petoff, Niall Murphy, Betsy Beyer, and Chris Jones   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Nate Avery, Outbound Product Manager at Google, joins Corey on Screaming in the Cloud to discuss what it's like working in the world of tech, including the implications of AI technology on the workforce and the importance of doing what you love. Nate explains why he feels human ingenuity is so important in the age of AI, as well as why he feels AI will make humans better at the things they do. Nate and Corey also discuss the changing landscape of tech and development jobs, and why it's important to help others throughout your career while doing something you love. About NateNate is an Outbound Product Manager at Google Cloud focused on our DevOps tools. Prior to this, Nate has 20 years of experience designing, planning, and implementing complex systems integrating custom-built and COTS applications. Throughout his career, he has managed diverse teams dedicated to meeting customer goals. With a background as a manager, engineer, Sys Admin, and DBA, Nate is currently working on ways to better build and use virtualized computer resources in both internal and external cloud environments. Nate was also named a Cisco Champion for Datacenter in 2015.Links Referenced: Google Cloud: https://cloud.google.com/devops Not Your Dad's IT: http://www.notyourdadsit.com/ Twitter: https://twitter.com/nathaniel_avery LinkedIn: https://www.linkedin.com/in/nathaniel-avery-2a43574/ 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: Welcome to Screaming in the Cloud. I'm Corey Quinn, and my guest today is Nate Avery, who's an outbound product manager over at Google Cloud. Nate, thank you for joining me.Nate: Thank you for having me. This is really a pretty high honor. I'm super thrilled to be here.Corey: One of my questions that I have about any large company when I start talking to them and getting to know people who work over there, pretty quickly emerges, which is, “What's the deal with your job title?” And it really doesn't matter what the person does, what the company is, there's always this strange nuance that tends to wind up creeping into the company. What is an outbound product manager and what is it you say it is you do here?Nate: Okay. That's an interesting question because I've been here for about a year now and I think I'm finally starting to figure it out. Sure, I should have known more when I applied for the job, [laugh] but there's what's on the paper and then there's what you do in reality. And so, what it appears to be, where I'm taking this thing now, is I talk to folks about our products and I try to figure out what it is they like, what it is they don't like, and then how do we make it better? I take that information back to our engineers, we huddle up, and we figure out what we can do, how to do it better, how to set the appropriate targets when it comes to our roadmaps. We look at others in the industry, where we are, where they are, where we think we can maybe have an advantage, and then we try to make it happen. That's really what it is.Corey: One of the strange things that happens at big companies, at least from my perspective, given that I've spent most of my career in small ones, is that everyone has a niche. There are very few people at large companies whose job description is yeah, I basically do everything. Where do you start? And where do you stop because Google Cloud, even bounding it to that business unit, is kind of enormous? You've [got 00:02:47] products that are outbound that you manage. And I feel like I should also call out that a product being outbound is not the same thing as being outgoing. I know that people are always wondering, what's Google going to turn off next, but Google Cloud mostly does the right thing in that respect. Good work.Nate: [laugh]. Nice. So, the products I focus on are the DevOps products. So, those are Cloud Build, Cloud Deploy, Artifact Registry, Artifact Analysis. I also work with some of our other dev tooling such as Cloud Workstations. That's in public preview right now, but maybe by the time this goes to air, it'll actually be in general availability.And then I also will talk about some of our other lesser-known tools like Skaffold or maybe on occasion, I'll throw out something about minikube. And also, Cloud Code, which is a really deep browser plugin for your IDE that gives you access to lots of different Google tools. So yeah, that's sort of my area.Corey: Well, I'm going to start with the last thing you mentioned, where you have Cloud Code as an IDE tooling and a plug-in for it. I'm relatively new to the world of IDEs because I come from the world of grumpy Unix admins; you never know what you're going to be remoting into next, but it's got VI on it, so worst case, you'll have that. So, I grew up using that, and as a result, that is still my default. I've been drifting toward VS Code a fair bit lately, as I've been regrettably learning JavaScript and TypeScript, just because having a lot of those niceties is great. But what's really transformative for me has been a lot of the generative AI offerings from various companies around hey, how about we just basically tab-complete your code for you, which is astonishing. I know people love to argue about that and then they go right back to their old approach of copying and pasting their code off a Stack Overflow.Nate: Yeah. That's an interesting one. When it works, it works and it's magical. And those are those experiences where you say, “I'm going to do this thing forever and ever I'm never going to go back.” And then when it doesn't work, you find yourself going back and then you maybe say, “Well, heck, that was horrible. Why'd I ever even go down this path?”I will say everyone's working on something along those lines. I don't think that that's much of a secret. And there are just so many different avenues at getting there. And I think that this is so early in the game that where we are today isn't where we're going to be.Corey: Oh, just—it's accelerating. Watching the innovation right now in the generative AI space is incredible. My light bulb moment that finally got me to start paying attention to this and viewing it as something other than hype that people are trying to sell us on conference stages was when I use one of them to spit out just, from a comment in VS Code, “Write a Python script that will connect to AWS pricing API and tell me what something costs, sorted from most to least expensive regions.” Because doing that manually would have taken a couple hours because their data structures are a sad joke and that API is garbage. And it sat and spun for a second and then it did it. But if I tell that story as, “This is the transformative moment that opened my eyes,” I sound incredibly sad and pathetic.Nate: No, I don't think so. I think that what it does, is it… one, it will open up more eyes, but the other thing that it does is you have to take that to the next level, which is great. That's great work, gone. Now that I have this information, what do I do with it? That's really where we need to be going and where we need to think about what this AI revolution is going to allow us to do, and that's to actually put this stuff into context.That's what humans do, which the computers are not always great at. And so, for instance, I see a lot of posts online about, “Hey, you know, I used to do job X, where I wrote up all these things,” or, “I used to write a blog and now because of AI, my boss wants me to write, you know, five times the output.” And I'm thinking, “Well, maybe the thing that you're writing doesn't need to be written if it can be easily queried and generated on the fly.” You know? Maybe those blog posts just don't have that much value anymore. So, what is it that we really should concentrate on in order to help us do better stuff, to have a higher order of importance in the world? That's where I think a lot of this really will wind up going is… you know, just as people, we've got to be better. And this will help us get there.Corey: One area of nuance on this, though, is—you're right when I talked about this with some of my developer friends, some of their responses were basically to become immediately defensive. Like, “Sure, it's great for the easy stuff, but it's not going to solve the high-level stuff that senior engineers are good at.” And I get that. This ridiculous thing that I had to do is not a threat to a senior engineer, but it is arguably a threat to someone I find on Upwork or Fiverr or whatnot to go and write this simple script for me.Nate: Oh yeah.Corey: Now, the concern that I have is one of approachability and accessibility because. Senior engineers don't form fully created from the forehead of some God somewhere that emerges from Google. They start off as simply people who have no idea what they're doing and have a burning curiosity about something, in many cases. Where is the next generation going to get the experience of writing a lot of that the small-scale stuff, if it's done for them? And I know that sounds alarmist, and oh, no, the sky is falling, and are the children going to be all right, as most people my age start to get into. But I do wonder what the future holds.Nate: That's legit. That's a totally legit question because it's always kind of hanging out there. I look at what my kids have access to today. They have freaking Oracle, the Oracle at Delphi on their phone; you know, and—Corey: If Oracle the database on their phone, I would hate to imagine what the cost of raising your kids to adulthood would be.Nate: Oh, it's mighty, mighty high [laugh]. But no, they have all of this stuff at their hands and then even just in the air, right? There's ambient computing, there's any question you want answered, you could speak it into the air and it'll come out. And it'll be, let's just say, I don't know, at least 85% accurate. But my kids still ask me [laugh].Corey: Having my kids, who are relatively young, still argue and exhaust their patience on a robot with infinite patience instead of me who has no patience? Transformative. “How do I spell whatever it is?” “Ask Alexa,” becomes a story instead of, “Look it up in the dictionary,” like my parents used to tell me. It's, “If I knew how to spell it, I would need to look it up in the dictionary, but I don't, so I can't.”Nate: Right. And I would never need to spell it again because I have the AI write my whole thing for me.Corey: That is a bit of concern for me when—some of the high school teachers are freaking out about students are writing essays with this thing. And, yeah, on the one hand, I absolutely see this as alarmism, where, oh, no, I'm going to have to do my job, on some level. But the reason you write so many of those boring, pointless essays in English class over the course of the K through 12 experience is ideally, it's teaching you how to frame your discussions, how to frame an argument, how to tell a compelling story. And, frankly, I think that's something that a lot of folks in the engineering cycle struggle with mightily. You're a product slash program manager at this point; I sort of assume that I don't need to explain to you that engineers are sometimes really bad at explaining what they mean.Nate: Yeah. Dude, I came up in tech. I'm… bad at it too sometimes [laugh]. Or when I think I'm doing a great job and then I look over and I see a… you know, the little blanky, blanky face, it goes, “Oh. Oh, hold on. I'll recalibrate that for you.” It's a thing.Corey: It's such a bad trope that they have now decided that they are calling describing what you actually mean slash want is now an entire field called prompt engineering.Nate: Dude, I hate that. I don't understand how this is going to be a job. It seems to be the most ridiculous thing in the world. If you say, “I sit down for six hours a day and I ask my computer questions,” I got to ask, “Well, why?” [laugh]. You know? And really, that's the thing. It gets back—Corey: Well, most of us do that all day long. It's just in Microsoft Excel or they use SQL to do it.Nate: Yeah… it is, but you don't spend your day asking the question of your computer, “Why.” Or really, most of us ask the question, “How?” That's really what it is we're doing.Corey: Yeah. And that is where I think it's going to start being problematic for some folks who are like, “Well, what is the point of writing blog posts if Chat-GIPITY can do it?” And yes, that's how I pronounce it: Chat-GIPITY. And the response is, “Look, if you're just going to rehash the documentation, you're right. There's no point in doing it.”Don't tell me how to do something. Tell me why. Tell me when I should consider using this tool, that tool, why this is interesting to me, why it exists. Because the how, one way or another, there are a myriad ways to find out the answer to something, but you've got to care first and convincing people to care is something computers still have not figured out.Nate: Bingo. And that gets back to your question about the engineers, right? Yeah. Okay. So sure, the little low-level tasks of, “Hey I need you to write this API.” All right, so maybe that stuff does get farmed out.However, the overall architecture still has to be considered by someone, someone still has to figure out where and how, and when things should be placed and the order in which these things should be connected. That never really goes away. And then there's also the act of creation. And by creation, I mean, just new ideas, things that—you know, that stroke of creativity and brilliance where you just say, “Man, I think there's a better way to do this thing.” Until I see that from one of these generative AI products, I don't know if anyone should truly feel threatened.Corey: I would argue that people shouldn't necessarily feel threatened regardless because things always change; that's the nature of it. I saw a headline on Hacker News recently where it said that 90% of my skills are worthless, but 10% of them are 10x what they were was worth. And I think that there's a lot of truth to that because it's, if you want a job where you never have to—you don't have to keep up with the continuing field, there are options. Not to besmirch them, but accountants are a terrific example of this. Yes, there's change to accountancy rules, but it happens slowly and methodically. You don't go on vacation for two years as an accountant—or a sabbatical—come back and discover that everything's different and math doesn't work the way it once did. Computers on the other hand, it really does feel like it's keep up or you never will.Nate: Unless you're a COBOL guy and you get called back for y2k.Corey: Oh, of course. And I'm sure—and now you're sitting around, you're waiting because when the epic time problem hits in 2038, you're going to get your next call out. And until then, it's kind of a sad life. You're the Maytag repair person.Nate: Yeah. I'm bad at humor, by the way, in case you have noticed. So, you touched on something there about the rate of change and how things change and whether or not these generative AI models are going to be able to—you know, just how far can they go? And I think that there's a—something happened over the last week or so that really got me thinking about this. There was a posting of a fake AI-generated song, I think from Drake.And say what you want about cultural appropriation, all that sort of thing, and how horrible that is, what struck me was the idea that these sorts of endeavors can only go so far because in any genre where there's language, and current language that morphs and changes and has subtlety to it, the generative AI would have to somehow be able to mimic that. And not to say that it could never get there, but again, I see us having some situations where folks are worried about a lot of things that they don't need to worry about, you know, just at this moment.Corey: I'm curious to figure out what your take is on how you see the larger industry because for a long time—and yes, it's starting to fade on some level, because it's not 2006 anymore, but there was a lot of hero worship going on with respect to Google, in particular. It was the mythical city on the hill where all the smart people went and people's entire college education was centered around the idea of, well, I'm going to get a job at Google when I graduate or I'm doomed. And it never seems to work out that way. I feel like there's a much more broad awareness these days that there's no one magical company that has the answers and there are a lot of different paths. But if you're giving guidance to someone who's starting down that path today, what would it be?Nate: Do what you love. Find something that you love, figure out who does the thing that you love, and go there. Or go to a place that does a thing that you love poorly. Go there. See if you can make a difference. But either way, you're working on something that you like to do.And really, in this business, if you can't get in the door at one of those places, then you can make your own door. It's becoming easier and easier to just sort of shoehorn yourself into this space. And a lot of it, yeah, there's got to be talent, yeah, you got to believe in yourself, all that sort of thing, but the barriers to entry are really low right now. It's super easy to start up a website, it costs you nothing to have a GitHub account. I really find it surprising when I talked to my younger cousins or someone else in that age range and they start asking, like, “Well, hey, how do I get into business?”And I'm like, “Well, what's your portfolio?” You know? And I ask them, “Do you want to work for someone else? Or would you like to at least try working for yourself first?” There are so many different avenues open to folks that you're right, you don't have to go to company X or you will never be anything anymore. That said, I am at [laugh] one of the bigger companies and do there are some brilliant people here. I bump into them and it's kind of wild. It really, really is.Corey: Oh, I want to be very clear, despite the shade that I throw at Google—and contemporary peers in the big tech company space—there are an awful lot of people who are freaking brilliant. And more importantly, by far, a lot of people who are extraordinarily kind.Nate: Yeah. Yeah. So, all right, in this business, there's that whole trope about, “Yeah, they're super smart, but they're such jerks.” It doesn't have to be that way. It really doesn't. And it's neat when you run into a place that has thousands of people who do not fit that horrible stereotype out there of the geek who can't, you know, who can't get along well with others. It's kind of nice.But I also think that that's because the industry itself is opening up. I go on to Twitter now and I see so many new faces and I see folks coming in, you know, for whatever reason, they're attracted to it for reasons, but they're in. And that's the really neat part of it. I used to worry that I didn't see a lot of young people being interested in this space. But I'm starting to notice it now and I think that we're going to wind up being in good hands.Corey: The kids are all right, I think, is a good way of framing it. What made you decide to go to Google? Again, you said you've been there about a year at this point. And, on some level, there's always a sense in hindsight of, well, yeah, obviously someone went from this job to that job to that job. There's a narrative here and it makes sense, but I've never once in my life found that it made sense and was clear while you're making the decision. It feels like it only becomes clear in hindsight.Nate: Yes, I am an extremely lucky person. I am super fortunate, and I will tell a lot of people, sometimes I have the ability to fall ass-backwards into success. And in this case, I am here because I was asked. I was asked and I didn't really think that I was the Google type because, I don't know what I thought the Google type was, just, you know, not me.And yet, I… talked it out with some folks, a really good, good buddy of mine and [laugh] I'll be darned, you know, next thing, you know, I'm here. So, gosh, what can I say except, don't limit yourself [laugh]. We do have a tendency to do that and oh, my God, it's great to have a champion and what I'd like to do now, now that you mention it and it's been something that I had on my mind for a bit is, I've got to figure out how to, you know how to start, you know, giving back, paying it forward, whatever the phrase it is you want to use? Because—Corey: I like, “Send the elevator back down.”Nate: Send the elevator back down? There you go, right? If that escalator stopped, turn it back on.Corey: Yeah, escalator; temporarily, stairs.Nate: Yes. You know, there are tons of ways up. But you know, if you can help someone, just go ahead and do it. You'd be surprised what a little bit of kindness can do.Corey: Well, let's tie this back to your day job for a bit, on some level. You're working on, effectively, developer tools. Who's the developer?Nate: Who's the developer? So, there's a general sense in the industry that anyone who works in IT or anyone who writes code is a developer. Sometimes there's the very blanket statement out there. I tend to take the view that a developer is the person who writes the code. That is a developer, that's [unintelligible 00:21:52] their job title. That's the thing that they do.The folks who assist developers, the folks who keep the servers up and running, they're going to have a lot of different names. They're DevOps admins, they're platform admins, they're server admins. Whatever they are, rarely would I call them developers, necessarily. So, I get it. We try to make blanket statement, we try to talk to large groups at a time, but you wouldn't go into your local county hospital and say that, “I want to talk to the dentist,” when you really mean, like, a heart surgeon.So, let's not do that, you know? We're known for our level of specificity when we discuss things in this field, so let's try to be a little more specific when we talk about the folks who do what they do. Because I came up on that ops track and I know the type of effort that I put in, and I looked at folks across from me and I know the kind of hours that they put in, I know all of the blood sweat and tears and nightless sleeps and answering the pagers at four in the morning. So, let's just call them what they are, [laugh] right? And it's not to say that calling them a developer is an insult in any way, but it's not a flex either.Corey: You do work at a large cloud company, so I have to assume that this is a revelation for you, but did you know that words actually mean things? I know, it's true. You wouldn't know it from a lot of the product names that wind up getting scattered throughout the world. The trophy for the worst one ever though, is Azure DevOps because someone I was talking to as a hiring manager once thought that they listed that is a thing they did on their resume and was about to can the resume. It's, “Wow, when your product name is so bad that it impacts other people's careers, that's kind of impressively awful.”But I have found that back when the DevOps movement was getting started, I felt a little offput because I was an operations person; I was a systems administrator. And suddenly, people were asking me about being a developer and what it's like. And honestly, on some level, I felt like an imposter, just because I write configuration files; I don't write code. That's very different. Code is something smart people write and I'm bad at doing that stuff.And in the fullness of time, I'm still bad at it, but at least now unenthusiastically bad at it. And, on some level, brute force also becomes a viable path forward. But it felt like it was gatekeeping, on some level, and I've always felt like the terms people use to describe what I did weren't aimed at me. I just was sort of against the edge.Nate: Yeah. And it's a weird thing that happens around here, how we get to these points, or… or somehow there's an article that gets written and then all of a sudden, everyone's life is changed in an industry. You go from your job being, “Hey, can you rack and stack the server?” To, “Hey, I need you to write this YAML code that's going to virtually instantiate a server and also connect it to a load balancer, and we need these done globally.” It's a really weird transition that happens in life.But like you said, that's part of our job: it morphs, it changes, it grows. And that's the fun of it. We hope that these changes are actually for the better and then they're going to make us more productive and they're going to make our businesses thrive and do things that they couldn't be before, like maybe be more resilient. You know, you look at the number of customers—customers; I think of them as customers—who had issues because of that horrible day in 9/11 and, you know, their business goes down the tube because there wasn't an adequate DR or COOP strategy, you know? And I know, I'm going way back in the wayback, but it's real. And I knew people who were affected by it.Corey: It is. And the tide is rising. This gets back to what we were talking about where the things that got you here won't necessarily get you there. And Cloud is a huge part of that. These days, I don't need to think about load balancers, in many cases, or all of the other infrastructure pieces because Google Cloud—among other companies, as well, lots of them—have moved significantly up the stack.I mean, people are excited about Kubernetes in a whole bunch of ways, but what an awful lot of enterprises are super excited about is suddenly, a hard drive failure doesn't mean their application goes down.Nate: [Isn't that 00:26:24] kind of awesome?Corey: Like, that's a transformative moment for them.Nate: It totally is. You know, I get here and I look at the things that people are doing and I kind of go, “Wow,” right? I'm in awe. And to be able to contribute to that in some way by saying, “Hey, you know what, we'll be cool? How about we try this feature?” Is really weird, [laugh] right?It's like, “Wow, they listened to me.” But we think about what it is we're trying to do and a lot of it, strangely enough, is not just helping people, but helping people by getting out of the way. And that is huge, right? You know, because you just want it to work, but more than it just working, you want it to be seamless. What's easier than putting your key in the ignition and turning it? Well, not having to use a key at all.So, what are those types of changes that we can bring to these different types of experiences that folks have? If you want to get your application onto a Kubernetes cluster, it shouldn't be some Herculean feat.Corey: And running that application responsibly should not require a team of people, each making a quarter million bucks a year, just to be able to do it safely and responsibly. There's going to be a collapsing down of what you have to know in order to run these things. I mean, web servers used to be something that required a month of your life and a fair bit of attention to run. Now, it's a checkbox in a cloud console.Nate: Yeah. And that's what we're trying to get it to, right? Why isn't everything a checkbox? Why can't you say, “Look, I wrote my app. I did the hard part.” Let's—you know, I just need to see it go somewhere. You know? Make it go and make it stay up. And how can I do that?And also, here's a feature that we're working on. Came out recently and we want folks to try it. It's a cloud deploy feature that works for Cloud Run as well as it does for GKE. And it's… I know it's going to sound super simple: it's our canary deployment method. But it's not just canary deployment, but also we can tie it into parallel deployment.And so, you can have your new version of your app stood up alongside your old version of the app and we can roll it out incrementally in parallel around the world and you can have an actual test that says, “Hey, is this working? Is it not working?” If it does, great, let's go forward. If it doesn't, let's roll back. And some of the stuff sounds like common sense, but it's been difficult to pull off.And now we're trying to do it with just a few lines a YAML. So, you know, is it as simple as it could be? Well, we're still looking at that. But the features are in there and we're constantly looking at what we can do to iterate and figure out what the next thing is.Corey: I really want to thank you for taking the time to speak with me. If people want to learn more, where's the best place for them to find you?Nate: Best place for them to find me used to be my blog, it's Not Your Dad's IT, However, I've been pretty negligent there since doing this whole Google thing, so I would say, just look me up on Twitter at @nathaniel_avery, look me up on Google. You can go to a pretty cool search engine and [laugh]—Corey: Oh, that's right. You guys have a search engine now. Good work.Nate: That's what I hear [laugh].Corey: Someday maybe it'll even come to Google Docs.Nate: [laugh]. Yes, so yeah, that's where to find me. You know, just look me up at Nathaniel Avery. I think that handle works for almost everything, Twitter, LinkedIn, wherever, and reach out.If there's something you like about our DevOps tools, let me know. If there's something you hate about our DevOps tools, definitely let me know. Because the only reason we're doing this is to try and help people. And if we're not doing that, then we need to know. We need to know why it isn't working out.And trust me, I talk to these engineers every day. That's the thing that really keeps them moving in the morning is knowing that they're doing something to make things better for folks. Real quick, I'll close out, and I think I may have mentioned this on some other podcasts. I come from the ops world. I was that guy who had to help get a deployment out on a Friday night and it lasted all weekend long and you're staring there at your phone at some absurd time on a Sunday night and everyone's huddled together and you're trying to figure out, are we going to rollback or are we going to go forward? What are we going to do by Monday?Corey: I don't miss those days.Nate: Oh, oh God no. I don't miss those days either. But you know what I do want? I took this job because I don't want anyone else to have those days. That's really what it is. We want to make sure that these tools give folks the ability to deploy safely and to deploy with confidence and to take that level of risk out of the equation, so that folks can, you know, just get back to doing other things. You know, spend that time with your family, spend the time reading, spend that time prompting ChatGPT with questions, [laugh] whatever it is you want to do, but you shouldn't have to sit there and wonder, “Oh, my God, is my app working? And what do I do when it doesn't?”Corey: I really want to thank you for being as generous with your time and philosophy on this. Thanks again. I've really enjoyed our conversation.Nate: Thank you. Thank you. I've been a big fan of your work for years.Corey: [laugh]. Nate Avery, outbound product manager at Google Cloud. 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 hate this podcast, please leave a five-star review on your podcast platform of choice along with an angry, insulting comment that you had Chat-GIPITY write for you in YAML.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.

Maddy Montaquila is a Senior Product Manager on the .NET MAUI team and has been working with .NET mobile apps since 2018 working on Xamarin tooling. When she first joined Microsoft and worked with the Xamarin team as an intern, she realized the impact that she could have in creating amazing developer tools and frameworks, which inspired her to pursue a role as Program Manager. You can connect with her on Twitter and GitHub @maddymontaquila!   Topics of Discussion: [4:21] How did Maddy get lucked into development and the mobile side of product management? [7:39] You can distill product manager roles to the intersection of the technology and what's possible, the business, what's going to make you money, and what your customers actually want and need. [9:17] Why is it important for program managers to have at least some coding background? [10:41] When people dive into Maui, what can they expect right now? [15:44] What tools or resources does someone need to get started, and what are the limitations? [20:44] What is the current DevOps story for going from a developer workstation all the way through testing and packaging, and then finally delivering it to the App Store? [23:47] Is there a favorite deployed test framework? [27:26] Why does Maddy prefer sometimes to work in Xaml? [29:17] If you're going to reach for controls right now, is everything that they need built-in? What is the status of DevExpress? [37:03] It's a great time to be a .net developer!   Mentioned in this Episode: Clear Measure Way Architect Forum Software Engineer Forum Programming with Palermo — New Video Podcast! Email us at programming@palermo.network 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! Architect Tips — Video podcast! Azure DevOps .NetMaui Maddy on LinkedIn .NET Multi-Platform App .Net Maui Samples .Net Maui Development   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

Welcome to the newest episode of The Cloud Pod podcast! Justin, Ryan and Jonathan are your hosts this week as we discuss all the latest news and announcements in the world of the cloud and AI - including Amazon's new AI, Bedrock, as well as new AI tools from other developers. We also address the new updates to AWS's CodeWhisperer, and return to our Cloud Journey Series where we discuss *insert dramatic music* - Kubernetes!  Titles we almost went with this week: ⭐I'm always Whispering to My Code as an Individual

AI for the consumer client side, HoloLens request rejected, Azure DevOps Layoffs Microsoft CEO Satya Nadella informs employees of 10,000 layoffs Is Surface on the cutting block? Amazon to layoff 18,000 Welcome to the AI era Microsoft CEO Satya Nadella confirms Microsoft's AI moves: Azure Open AI service, ChatGPT APIs, and infusing AI across the entire Microsoft stack This is a much bigger deal than Microsoft's pivot to the cloud 20 years ago because it infuses everything that it does. When Wall Street latched onto Azure and cloud computing and made Microsoft the second biggest company in the world, the software giant effectively ignored personal computing because no one wanted to hear about legacy. That era is over. Windows 11 New Insider Preview build for the Dev channel adds a developer feature, OneDrive storage quote display New Insider Preview build comes to the ... Release Preview channel? This one is interesting. Now we know the full story of the bloodbath that was PC sales in Q4 2022: a 28.3 percent drop in unit sales YOY. Yikes Intel ships its first 6 GHz CPU, reminding us again that this—and not efficiency—is what Intel is good at 12 years after Windows 8 and Surface, Apple is adding touchscreens to the Mac. Devices US Congress nixes Army purchase of more HoloLens units Xbox Google and NVIDIA voice concerns about Microsoft acquisition of Activision Blizzard EU likely to issue warning on Microsoft acquisition of Activision Blizzard Public support for the acquisition is strong. Even about PlayStation users! Google turns the Stadia controller into a normal Bluetooth controller Tips & Picks Tip of the week: The OneDrive storage upgrades you didn't know about App pick of the week: MSEdgeRedirect Enterprise pick of the week: Azure DevOps Whisky pick of the week: Glenlivet Nadurra Hosts: Leo Laporte, Paul Thurrott, and Richard Campbell Download or subscribe to this show at https://twit.tv/shows/windows-weekly Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Check out Paul's blog at thurrott.com The Windows Weekly theme music is courtesy of Carl Franklin. Sponsors: CDW.com/LenovoClient tanium.com/twit

AI for the consumer client side, HoloLens request rejected, Azure DevOps Layoffs Microsoft CEO Satya Nadella informs employees of 10,000 layoffs Is Surface on the cutting block? Amazon to layoff 18,000 Welcome to the AI era Microsoft CEO Satya Nadella confirms Microsoft's AI moves: Azure Open AI service, ChatGPT APIs, and infusing AI across the entire Microsoft stack This is a much bigger deal than Microsoft's pivot to the cloud 20 years ago because it infuses everything that it does. When Wall Street latched onto Azure and cloud computing and made Microsoft the second biggest company in the world, the software giant effectively ignored personal computing because no one wanted to hear about legacy. That era is over. Windows 11 New Insider Preview build for the Dev channel adds a developer feature, OneDrive storage quote display New Insider Preview build comes to the ... Release Preview channel? This one is interesting. Now we know the full story of the bloodbath that was PC sales in Q4 2022: a 28.3 percent drop in unit sales YOY. Yikes Intel ships its first 6 GHz CPU, reminding us again that this—and not efficiency—is what Intel is good at 12 years after Windows 8 and Surface, Apple is adding touchscreens to the Mac. Devices US Congress nixes Army purchase of more HoloLens units Xbox Google and NVIDIA voice concerns about Microsoft acquisition of Activision Blizzard EU likely to issue warning on Microsoft acquisition of Activision Blizzard Public support for the acquisition is strong. Even about PlayStation users! Google turns the Stadia controller into a normal Bluetooth controller Tips & Picks Tip of the week: The OneDrive storage upgrades you didn't know about App pick of the week: MSEdgeRedirect Enterprise pick of the week: Azure DevOps Whisky pick of the week: Glenlivet Nadurra Hosts: Leo Laporte, Paul Thurrott, and Richard Campbell Download or subscribe to this show at https://twit.tv/shows/windows-weekly Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit Check out Paul's blog at thurrott.com The Windows Weekly theme music is courtesy of Carl Franklin. Sponsors: CDW.com/LenovoClient tanium.com/twit

The Lapsus$ hackers allege they have hacked Microsoft's Azure DevOps server containing source code for Bing, Cortana, and various other internal projects. We take a look at the big feature updates in Roku OS 11, and will the latest attempt at smart glasses take off?Starring Tom Merritt, Sarah Lane, Charlotte Henry, Roger Chang, Joe.Link to the Show Notes. See acast.com/privacy for privacy and opt-out information. Become a member at https://plus.acast.com/s/dtns.

Microsoft's Azure DevOps server containing source code for Bing, Cortana, and various other internal projects has a data breach. We take a look at the big feature updates in Roku OS 11, and will the latest attempt at smart glasses take off? Starring Tom Merritt, Sarah Lane, Charlotte Henry, Roger Chang, Joe, Amos MP3 DownloadContinue reading "Another Attempt At Smart Glasses – DTNS 4237"