Stefan Prodan

Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. Although it improves the management and scaling of infrastructure and applications, Kubernetes frequently has challenges managing the complexity of releasing applications. Git is the most widely used version-control system in the software industry today. GitOps is a set of procedures that uses the power of Git to provide both revision and change control within the Kubernetes platform. Flux is an open source project that implements GitOps-driven continuous deployment for Kubernetes. In this episode we speak with Priyanka Ravi and Stefan Prodan from Weaveworks.   This Interview was recorded at KubeCon Europe and wouldn’t have been possible without the generous support from The Linux Foundation. Jordi Mon Companys is a product manager and marketer that specializes in software delivery, developer experience, cloud native and open source. He has developed his career at companies like GitLab, Weaveworks, Harness and other platform and devtool providers. His interests range from software supply chain security to open source innovation. You can reach out to him on Twitter at @jordimonpmm Sponsorship inquiries: sponsor@softwareengineeringdaily.com The post GitOps for Kubernetes with Priyanka Ravi and Stefan Prodan appeared first on Software Engineering Daily.

<a href="https://kubernetes.io/docs/concepts/overview/" rel="nofollow" target="_blank">Kubernetes</a> is an open-source system for automating deployment, scaling, and management of containerized applications. Although it improves the management and scaling of infrastructure and applications, Kubernetes frequently has challenges managing the complexity of releasing applications. Git is the most widely used version-control system in the software industry today. GitOps is a set of procedures that uses the power of Git to provide both revision and change control within the Kubernetes platform. <a href="https://fluxcd.io/" rel="nofollow" target="_blank">Flux</a> is an open source project that implements GitOps-driven continuous deployment for Kubernetes. In this episode we speak with <a href="https://twitter.com/pinkyyravi?lang=en" rel="nofollow" target="_blank">Priyanka Ravi</a> and <a href="https://twitter.com/stefanprodan" rel="nofollow" target="_blank">Stefan Prodan</a> from <a href="https://www.weave.works/" rel="nofollow" target="_blank">Weaveworks</a>. This Interview was recorded at <a href="https://streaklinks.com/Bg_PFnbkpFTSagwvgwYbEPZW/https%3A%2F%2Fevents.linuxfoundation.org%2Fkubecon-cloudnativecon-europe%2F" rel="noopener nofollow" target="_blank">KubeCon Europe</a> and wouldn’t have been possible without the generous support from <a href="https://www.linuxfoundation.org/" rel="nofollow" target="_blank">The Linux Foundation</a>. <a href="https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2023/03/jordi.png" rel="nofollow" target="_blank"></a><a href="https://www.linkedin.com/in/jordimoncompanys/" rel="nofollow" target="_blank">Jordi Mon Companys</a> is a product manager and marketer that specializes in software delivery, developer experience, cloud native and open source. He has developed his career at companies like GitLab, Weaveworks, Harness and other platform and devtool providers. His interests range from software supply chain security to open source innovation. You can reach out to him on Twitter at <a href="https://twitter.com/JordiMonPMM" rel="nofollow" target="_blank">@jordimonpmm</a> Sponsorship inquiries: <a href="https://cms.megaphone.fm/organizations/619b680e-d813-11ea-9750-e7ecac406436/podcasts/e60108fe-e328-11ea-b2b6-1348249f900a/episodes/3913370a-bc44-11ed-ace6-8b1f96d82bba/sponsor@softwareengineeringdaily.com" rel="noopener noreferrer nofollow" target="_blank">sponsor@softwareengineeringdaily.com</a> The post <a href="https://softwareengineeringdaily.com/2023/05/02/gitops-for-kubernetes/" rel="nofollow" target="_blank">GitOps for Kubernetes with Priyanka Ravi and Stefan Prodan</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

GitOps for Kubernetes with Priyanka Ravi and Stefan Prodan

Simon Ritter

What are the reasons why we need to improve performance? The JVM is a powerful piece of software – this is the reason why Java has maintained its popularity over the past 26+ years. But… there are some ways that the JVM works that can impact the performance of your applications. One of the biggest challenges is latency – how quickly can we respond to a request from a user to access your application. That comes down to garbage collection – which leads to pauses and a bad customer experience. Garbage collection pauses can vary. But they impact application performance. The bigger the heap, the longer your pauses…but how do you optimize? What about warm-up time? That’s also a big challenge. We’ve addressed these problems without re-writing code from scratch – and that leads to better Java performance without any code changes. This episode explores how you can use a performance JVM to make applications start fast, go fast, and stay fast. Full disclosure: Azul is a sponsor of Software Engineering Daily. Sponsorship inquiries: sponsor@softwareengineeringdaily.com Transcript The post Improved Java Performance Sans Code Changes with Simon Ritter appeared first on Software Engineering Daily.

<a href="https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2023/03/simon.png" rel="nofollow" target="_blank"></a>What are the reasons why we need to improve performance? The JVM is a powerful piece of software – this is the reason why Java has maintained its popularity over the past 26+ years. But… there are some ways that the JVM works that can impact the performance of your applications. One of the biggest challenges is latency – how quickly can we respond to a request from a user to access your application. That comes down to garbage collection – which leads to pauses and a bad customer experience. Garbage collection pauses can vary. But they impact application performance. The bigger the heap, the longer your pauses…but how do you optimize? What about warm-up time? That’s also a big challenge. We’ve addressed these problems without re-writing code from scratch – and that leads to better Java performance without any code changes. This episode explores how you can use a performance JVM to make applications start fast, go fast, and stay fast. Full disclosure: Azul is a sponsor of Software Engineering Daily. Sponsorship inquiries: <a href="https://cms.megaphone.fm/organizations/619b680e-d813-11ea-9750-e7ecac406436/podcasts/e60108fe-e328-11ea-b2b6-1348249f900a/episodes/3913370a-bc44-11ed-ace6-8b1f96d82bba/sponsor@softwareengineeringdaily.com" rel="noopener noreferrer nofollow" target="_blank">sponsor@softwareengineeringdaily.com</a> <a href="http://softwareengineeringdaily.com/wp-content/uploads/2023/03/SED1536-Simon-Ritter.pdf" rel="nofollow" target="_blank">Transcript</a> The post <a href="https://softwareengineeringdaily.com/2023/03/13/improved-java-performance/" rel="nofollow" target="_blank">Improved Java Performance Sans Code Changes with Simon Ritter</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Improved Java Performance Sans Code Changes with Simon Ritter

Mathias Biilmann Christensen

Netlify is a cloud-based platform that provides web developers with an all-in-one workflow to build, deploy, and manage modern web projects. Matt Biilmann is the CEO of Netlify and he joins us today. This episode is hosted by Mike Bifulco. To learn more about Mike visit mikebifulco.com Sponsorship inquiries: sponsor@softwareengineeringdaily.com     The post Netlify with Mathias Biilmann Christensen appeared first on Software Engineering Daily.

<a href="https://www.netlify.com/" rel="nofollow" target="_blank">Netlify</a> is a cloud-based platform that provides web developers with an all-in-one workflow to build, deploy, and manage modern web projects. <a href="https://twitter.com/biilmann?lang=en" rel="nofollow" target="_blank">Matt Biilmann</a> is the CEO of Netlify and he joins us today. This episode is hosted by Mike Bifulco. To learn more about Mike visit <a href="https://mikebifulco.com/" rel="nofollow" target="_blank">mikebifulco.com</a> Sponsorship inquiries: <a href="sponsor@softwareengineeringdaily.com" rel="nofollow" target="_blank">sponsor@softwareengineeringdaily.com</a> The post <a href="https://softwareengineeringdaily.com/2023/03/02/netlify/" rel="nofollow" target="_blank">Netlify with Mathias Biilmann Christensen</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Netlify with Mathias Biilmann Christensen

Martin Mao

Maintaining availability in a modern digital application is critical to keeping your application operating and available and to keep meeting your customers growing demands. There are many observability platforms out there and certainly Prometheus is a popular open source solution for cloud native companies yet operating an observability platform, costs money, and all of the platforms are highly data intensive. Managing costs and data retention policies is critical to keeping your application operating healthy and operating available. Chronosphere is the leading observability platform for scaling cloud native applications. Focusing on managing costs by managing data. Martin Mao is the co-founder and CEO of Chronosphere and he is our guest today . This episode is hosted by Lee Atchison. Lee Atchison is a software architect, author, and thought leader on cloud computing and application modernization. His most recent book, Architecting for Scale (O’Reilly Media) is an essential resource for technical teams looking to maintain high availability and manage risk in their cloud environments. Lee is the host of his podcast, Modern Digital Business, an engaging and informative podcast produced for people looking to build and grow their digital business with the help of modern applications and processes developed for today’s fast-moving business environment. Subscribe at mdb.fm. Follow Lee, at leeatchison.com. Sponsorship inquiries: sponsor@softwareengineeringdaily.com The post Cloud Native Observability with Martin Mao appeared first on Software Engineering Daily.

<a href="https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2022/08/Martin-Mao.png" rel="nofollow" target="_blank"></a>Maintaining availability in a modern digital application is critical to keeping your application operating and available and to keep meeting your customers growing demands. There are many observability platforms out there and certainly Prometheus is a popular open source solution for cloud native companies yet operating an observability platform, costs money, and all of the platforms are highly data intensive. Managing costs and data retention policies is critical to keeping your application operating healthy and operating available. <a href="https://chronosphere.io/" rel="nofollow" target="_blank">Chronosphere</a> is the leading observability platform for scaling cloud native applications. Focusing on managing costs by managing data. <a href="https://twitter.com/martin_c_mao" rel="nofollow" target="_blank">Martin Mao</a> is the co-founder and CEO of Chronosphere and he is our guest today . This episode is hosted by Lee Atchison. Lee Atchison is a software architect, author, and thought leader on cloud computing and application modernization. His most recent book, <a href="https://leeatchison.com//ref-amzn-arch-for-scale" rel="nofollow" target="_blank">Architecting for Scale</a> (O’Reilly Media) is an essential resource for technical teams looking to maintain high availability and manage risk in their cloud environments. Lee is the host of his podcast, <a href="https://mdb.fm/?utm_campaign=swengdaily&amp;utm_source=mdb&amp;utm_medium=podcast" rel="nofollow" target="_blank">Modern Digital Business</a>, an engaging and informative podcast produced for people looking to build and grow their digital business with the help of modern applications and processes developed for today’s fast-moving business environment. Subscribe at <a href="http://mdb.fm/" rel="nofollow" target="_blank">mdb.fm</a>. Follow Lee, at <a href="http://leeatchison.com" rel="nofollow" target="_blank">leeatchison.com</a>. Sponsorship inquiries: <a href="sponsor@softwareengineeringdaily.com" rel="nofollow" target="_blank">sponsor@softwareengineeringdaily.com</a> The post <a href="https://softwareengineeringdaily.com/2022/08/31/cloudnativeobservabilitywithmartinmao/" rel="nofollow" target="_blank">Cloud Native Observability with Martin Mao</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Cloud Native Observability with Martin Mao

Lee Atchison

/*! elementor - v3.14.0 - 26-06-2023 */ .elementor-widget-text-editor.elementor-drop-cap-view-stacked .elementor-drop-cap{background-color:#69727d;color:#fff}.elementor-widget-text-editor.elementor-drop-cap-view-framed .elementor-drop-cap{color:#69727d;border:3px solid;background-color:transparent}.elementor-widget-text-editor:not(.elementor-drop-cap-view-default) .elementor-drop-cap{margin-top:8px}.elementor-widget-text-editor:not(.elementor-drop-cap-view-default) .elementor-drop-cap-letter{width:1em;height:1em}.elementor-widget-text-editor .elementor-drop-cap{float:left;text-align:center;line-height:1;font-size:50px}.elementor-widget-text-editor .elementor-drop-cap-letter{display:inline-block}				Originally published on February 12, 2022.Lee Atchison spent seven years at Amazon working in retail, software distribution, and Amazon Web Services. He then moved to New Relic, where he has spent four years scaling the company’s internal architecture. From his decade of experience at fast-growing web technology companies, Lee has written the book Architecting for Scale, from O’Reilly.As an application scales, it becomes significantly more complicated while at the same time receiving more traffic. The intersection of these two problems leads to a variety of discussions around availability, risk management, and microservices. Sponsorship inquiriessponsor@softwareengineeringdaily.com The post Architecting for Scale with Lee Atchison appeared first on Software Engineering Daily.

/*! elementor - v3.14.0 - 26-06-2023 */ .elementor-widget-text-editor.elementor-drop-cap-view-stacked .elementor-drop-cap{background-color:#69727d;color:#fff}.elementor-widget-text-editor.elementor-drop-cap-view-framed .elementor-drop-cap{color:#69727d;border:3px solid;background-color:transparent}.elementor-widget-text-editor:not(.elementor-drop-cap-view-default) .elementor-drop-cap{margin-top:8px}.elementor-widget-text-editor:not(.elementor-drop-cap-view-default) .elementor-drop-cap-letter{width:1em;height:1em}.elementor-widget-text-editor .elementor-drop-cap{float:left;text-align:center;line-height:1;font-size:50px}.elementor-widget-text-editor .elementor-drop-cap-letter{display:inline-block}				<a href="https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2022/02/lee.jpg" rel="nofollow" target="_blank"></a>Originally published on February 12, 2022.<a href="https://twitter.com/leeatchison?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor" rel="nofollow" target="_blank">Lee Atchison</a> spent seven years at Amazon working in retail, software distribution, and Amazon Web Services. He then moved to New Relic, where he has spent four years scaling the company’s internal architecture. From his decade of experience at fast-growing web technology companies, Lee has written the book Architecting for Scale, from O’Reilly.As an application scales, it becomes significantly more complicated while at the same time receiving more traffic. The intersection of these two problems leads to a variety of discussions around availability, risk management, and microservices. Sponsorship inquiries <a href="mailto:sponsor@softwareengineeringdaily.com" rel="noopener noreferrer">sponsor@softwareengineeringdaily.com</a> The post <a href="https://softwareengineeringdaily.com/2022/08/24/architecting-for-scale-with-lee-atchison/" rel="nofollow" target="_blank">Architecting for Scale with Lee Atchison</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Architecting for Scale with Lee Atchison

Cloud native applications utilizing microservice architectures has grown into one of the most popular application architectural patterns in recent years. The value of leveraging dynamic cloud resources, along with the flexibility and scalability of microservice architectures, creates a strong paradigm that’s hard to miss. The strong adoption of Kubernetes has strengthened the pattern enormously. The unique structure and requirements of Kubernetes has led to an increased need for Kubernetes specific monitoring and diagnostics tools. There has been a large number of companies who have jumped at this opportunity. One of those companies is Komodor, a Kubernetes diagnostics platform that focuses on Kubernetes troubleshooting for the entire Kubernetes stack. Itiel Shwartz is the co-founder and CTO of Komodor, and he joins us today. Full disclosure: Komodor is a sponsor of Software Engineering Daily. Sponsorship inquiries: sponsor@softwareengineeringdaily.com The post K8s Troubleshooting with Itiel Shwartz appeared first on Software Engineering Daily.

<a href="https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2022/08/Rectangle-167.png" rel="nofollow" target="_blank"></a>Cloud native applications utilizing microservice architectures has grown into one of the most popular application architectural patterns in recent years. The value of leveraging dynamic cloud resources, along with the flexibility and scalability of microservice architectures, creates a strong paradigm that’s hard to miss. The strong adoption of Kubernetes has strengthened the pattern enormously. The unique structure and requirements of Kubernetes has led to an increased need for Kubernetes specific monitoring and diagnostics tools. There has been a large number of companies who have jumped at this opportunity. One of those companies is<a href="https://komodor.com/" rel="nofollow" target="_blank"> Komodor</a>, a Kubernetes diagnostics platform that focuses on Kubernetes troubleshooting for the entire Kubernetes stack. <a href="https://twitter.com/itielshwartz" rel="nofollow" target="_blank">Itiel Shwartz</a> is the co-founder and CTO of Komodor, and he joins us today. Full disclosure: Komodor is a sponsor of Software Engineering Daily. Sponsorship inquiries: <a href="sponsor@softwareengineeringdaily.com" rel="nofollow" target="_blank">sponsor@softwareengineeringdaily.com</a> The post <a href="https://softwareengineeringdaily.com/2022/08/16/kubernetes-troubleshooting-with-itiel-shwartz-and-lee-atchison/" rel="nofollow" target="_blank">K8s Troubleshooting with Itiel Shwartz</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

K8s Troubleshooting with Itiel Shwartz

Michael Grinich

Enterprise-grade authentication is often an essential ingredient to virtually all applications in today’s world. However, companies often have a hard time understanding the value of that authentication especially during the early stages of product development. And hardening of an application is often left as an afterthought. Add enterprise-level requirements such as single sign-on and two-factor authentication and other requirements that the once afterthought becomes are now major issues. Delaying launch schedules and new feature launches. WorkOS is dramatically shortening this development time by providing tools to allow in integrating complex enterprise standards with just a few lines of code, allowing developers to focus on core products and features. Michael Grinich is the CEO of WorkOS and is my guest today. Sponsorship inquiries: sponsor@softwareengineeringdaily.com The post WorkOS with Michael Grinich appeared first on Software Engineering Daily.

<a href="https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2022/07/Michael-Grinich.png" rel="nofollow" target="_blank"></a>Enterprise-grade authentication is often an essential ingredient to virtually all applications in today’s world. However, companies often have a hard time understanding the value of that authentication especially during the early stages of product development. And hardening of an application is often left as an afterthought. Add enterprise-level requirements such as single sign-on and two-factor authentication and other requirements that the once afterthought becomes are now major issues. Delaying launch schedules and new feature launches. <a href="https://workos.com/" rel="nofollow" target="_blank">WorkOS</a> is dramatically shortening this development time by providing tools to allow in integrating complex enterprise standards with just a few lines of code, allowing developers to focus on core products and features.<a href="https://twitter.com/grinich" rel="nofollow" target="_blank"> Michael Grinich</a> is the CEO of WorkOS and is my guest today. Sponsorship inquiries: <a href="sponsor@softwareengineeringdaily.com" rel="nofollow" target="_blank">sponsor@softwareengineeringdaily.com</a> The post <a href="https://softwareengineeringdaily.com/2022/07/06/workos-with-michael-grinich/" rel="nofollow" target="_blank">WorkOS with Michael Grinich</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

WorkOS with Michael Grinich

Eric Muntz

Mailchimp is an all-in-one marketing platform for growing businesses, empowering millions of customers around the world to launch, build, and grow their businesses with world-class marketing technology, award-winning customer support, and inspiring content.  Eric Muntz is Mailchimp’s CTO, responsible for the engineering teams that design, implement, and maintain Mailchimp’s products and infrastructure. He joins the show to take us through the engineering behind Mailchimp’s infrastructure.  Sponsorship inquiries: sponsor@softwareengineeringdaily.com     The post Mailchimp Engineering with Eric Muntz appeared first on Software Engineering Daily.

<a href="https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2022/06/Eric-Muntz.png" rel="nofollow" target="_blank"></a>Mailchimp is an all-in-one marketing platform for growing businesses, empowering millions of customers around the world to launch, build, and grow their businesses with world-class marketing technology, award-winning customer support, and inspiring content. Eric Muntz is Mailchimp’s CTO, responsible for the engineering teams that design, implement, and maintain Mailchimp’s products and infrastructure. He joins the show to take us through the engineering behind Mailchimp’s infrastructure. Sponsorship inquiries: <a href="sponsor@softwareengineeringdaily.com" rel="nofollow" target="_blank">sponsor@softwareengineeringdaily.com</a> The post <a href="https://softwareengineeringdaily.com/2022/06/28/mailchimp-engineering-with-eric-muntz/" rel="nofollow" target="_blank">Mailchimp Engineering with Eric Muntz</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Mailchimp Engineering with Eric Muntz

Venture capital investment has continued to flow into technology startups.  No one builds technology from scratch.  There are cloud services, software libraries, 3rd party services, and software platforms that modern entrepreneurs must adopt to build their products efficiently and quickly.  These layers of infrastructure are a key area for many investors. Tim is a partner at Menlo Ventures where he invests in cloud and data infrastructure, AI/ML and cyber security.  He joins the show to discuss what goes into a smart investment. Sponsorship inquiries: sponsor@softwareengineeringdaily.com   The post Technical Venture Capital with Tim Tully appeared first on Software Engineering Daily.

<a href="https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2022/06/Tim-Tully.png" rel="nofollow" target="_blank"></a>Venture capital investment has continued to flow into technology startups.  No one builds technology from scratch.  There are cloud services, software libraries, 3rd party services, and software platforms that modern entrepreneurs must adopt to build their products efficiently and quickly.  These layers of infrastructure are a key area for many investors. Tim is a partner at Menlo Ventures where he invests in cloud and data infrastructure, AI/ML and cyber security.  He joins the show to discuss what goes into a smart investment. Sponsorship inquiries: <a href="sponsor@softwareengineeringdaily.com" rel="nofollow" target="_blank">sponsor@softwareengineeringdaily.com</a> The post <a href="https://softwareengineeringdaily.com/2022/06/27/technical-venture-capital-with-tim-tully/" rel="nofollow" target="_blank">Technical Venture Capital with Tim Tully</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Technical Venture Capital with Tim Tully

Webb Brown

This episode is hosted by Lee Atchison. Lee Atchison is a software architect, author, and thought leader on cloud computing and application modernization. His most recent book, Architecting for Scale (O’Reilly Media) is an essential resource for technical teams looking to maintain high availability and manage risk in their cloud environments.Lee is the host of his podcast, Modern Digital Business, an engaging and informative podcast produced for people looking to build and grow their digital business with the help of modern applications and processes developed for today’s fast-moving business environment. Subscribe at mdb.fm.Follow Lee, at leeatchison.com.As companies move more and more workloads to the cloud, cost management in the cloud is becoming critically important. Modern application development methodology increasingly involves moving to service and microservice architectures enabled by the cloud and kubernetes is the backbone of this modern infrastructure trend. Managing costs of kubernetes clusters is therefore becoming increasingly important. Kubecost is the company focused on giving visibility into kubernetes resources, allowing you to reduce your overall kubernetes based infrastructure spend. Webb Brown is the founder of Kubecost and joins us today.             Sponsorship inquiries: sponsor@softwareengineeringdaily.com. The post Kubernetes Spend with Webb Brown appeared first on Software Engineering Daily.

This episode is hosted by Lee Atchison. Lee Atchison is a software architect, author, and thought leader on cloud computing and application modernization. His most recent book, <a href="https://leeatchison.com//ref-amzn-arch-for-scale" rel="nofollow" target="_blank">Architecting for Scale</a> (O’Reilly Media) is an essential resource for technical teams looking to maintain high availability and manage risk in their cloud environments. Lee is the host of his podcast, <a href="https://mdb.fm/?utm_campaign=swengdaily&amp;utm_source=mdb&amp;utm_medium=podcast" rel="nofollow" target="_blank">Modern Digital Business</a>, an engaging and informative podcast produced for people looking to build and grow their digital business with the help of modern applications and processes developed for today’s fast-moving business environment. Subscribe at <a href="https://mdb.fm/?utm_campaign=swengdaily&amp;utm_source=mdb&amp;utm_medium=podcast" rel="nofollow" target="_blank">mdb.fm</a><a href="http://mdb.io/" rel="nofollow" target="_blank">.</a> Follow Lee, at <a href="http://leeatchison.com/?utm_campaign=swengdaily&amp;utm_source=mdb&amp;utm_medium=podcast" rel="nofollow" target="_blank">leeatchison.com</a>.<a href="https://i0.wp.com/softwareengineeringdaily.com/wp-content/uploads/2022/06/Webb-Brown.png" rel="nofollow" target="_blank"></a>As companies move more and more workloads to the cloud, cost management in the cloud is becoming critically important. Modern application development methodology increasingly involves moving to service and microservice architectures enabled by the cloud and kubernetes is the backbone of this modern infrastructure trend. Managing costs of kubernetes clusters is therefore becoming increasingly important. <a href="https://www.kubecost.com/" rel="nofollow" target="_blank">Kubecost</a> is the company focused on giving visibility into kubernetes resources, allowing you to reduce your overall kubernetes based infrastructure spend. Webb Brown is the founder of Kubecost and joins us today.             Sponsorship inquiries: <a href="sponsor@softwareengineeringdaily.com" rel="nofollow" target="_blank">sponsor@softwareengineeringdaily.com</a>. The post <a href="https://softwareengineeringdaily.com/2022/06/16/kubernetes-spend-with-webb-brown/" rel="nofollow" target="_blank">Kubernetes Spend with Webb Brown</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Kubernetes Spend with Webb Brown

Episodes about building and scaling large software projects

Cloud Engineering Archives - Software Engineering Daily

William Morgan

The container orchestration wars ended in 2016 with Kubernetes being the most popular open source tool for deploying and managing infrastructure. Since that time, most large enterprises have been implementing a “platform strategy” based around Kubernetes. A platform strategy is a plan for creating a consistent experience for software engineers working throughout an enterprise. At most companies, a software engineer should be thinking about business logic–whether that logic is related to banking, insurance, oil and gas, or e-commerce.  Today, engineers at many enterprises need to think about continuous delivery, application deployment, security policy management, and other deeply technical problems that have nothing to do with the business that they are actually working at. Kubernetes is a foundational open source building block that allows enterprises to base the rest of their infrastructure decisions around. Kubernetes has made it much more viable for enterprises to pursue a platform strategy. With widespread adoption of Kubernetes, there is a business opportunity for companies that can offer other platform solutions that build on top of Kubernetes. A service mesh is one such tool. A service mesh provides networking and security features for all the services in an organization. The service mesh category is a large business opportunity because it sits on the critical path of every network request that goes through an enterprise. It is a potential insertion point for lots of other products including logging agents, distributed tracing, network packet scanning, security policy management, and A/B testing. The potential for business expansion is why so many businesses are entering the service mesh category today, from cloud providers to API gateways. Buoyant was one of the first companies to work on a service mesh tool, with the Linkerd open source project. William Morgan is the CEO of Buoyant, and he returns to the show to discuss the competitive dynamics of the service mesh market. Sponsorship inquiries: sponsor@softwareengineeringdaily.com Announcements  We are hiring a content writer and also an operations lead. Both of these are part-time positions working closely with Jeff and Erika. If you are interested in working with us, send an email to jeff@softwareengineeringdaily.com.  The post Linkerd Market Strategy with William Morgan appeared first on Software Engineering Daily.

The container orchestration wars ended in 2016 with Kubernetes being the most popular open source tool for deploying and managing infrastructure. Since that time, most large enterprises have been implementing a “platform strategy” based around Kubernetes. A platform strategy is a plan for creating a consistent experience for software engineers working throughout an enterprise. At most companies, a software engineer should be thinking about business logic–whether that logic is related to banking, insurance, oil and gas, or e-commerce.  Today, engineers at many enterprises need to think about continuous delivery, application deployment, security policy management, and other deeply technical problems that have nothing to do with the business that they are actually working at. Kubernetes is a foundational open source building block that allows enterprises to base the rest of their infrastructure decisions around. Kubernetes has made it much more viable for enterprises to pursue a platform strategy. With widespread adoption of Kubernetes, there is a business opportunity for companies that can offer other platform solutions that build on top of Kubernetes. A service mesh is one such tool. A service mesh provides networking and security features for all the services in an organization. The service mesh category is a large business opportunity because it sits on the critical path of every network request that goes through an enterprise. It is a potential insertion point for lots of other products including logging agents, distributed tracing, network packet scanning, security policy management, and A/B testing. The potential for business expansion is why so many businesses are entering the service mesh category today, from cloud providers to API gateways. Buoyant was one of the first companies to work on a service mesh tool, with the Linkerd open source project. William Morgan is the CEO of Buoyant, and he returns to the show to discuss the competitive dynamics of the service mesh market. Sponsorship inquiries: <a href="mailto:sponsor@softwareengineeringdaily.com">sponsor@softwareengineeringdaily.com</a> Announcements <ul> <li>We are hiring a content writer and also an operations lead. Both of these are part-time positions working closely with Jeff and Erika. If you are interested in working with us, send an email to jeff@softwareengineeringdaily.com.</li> </ul> The post <a href="https://softwareengineeringdaily.com/2019/12/06/linkerd-market-strategy-with-william-morgan/" rel="nofollow" target="_blank">Linkerd Market Strategy with William Morgan</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Linkerd Market Strategy with William Morgan

Ranga Rajagopalan

Computational load is the amount of demand that is being placed on a computer system. “Load” can take the form of memory, CPU, network bandwidth, disk space, and other finite resources.  When we design systems, we need to prepare for high-load events. On a social network, people are much more active in the mornings. On an e-commerce site, Black Friday causes many more users to come online for discount shopping. Our distributed application must be able to scale in response to these spikes in traffic. Cloud computing has changed the popular software architecture patterns, and load balancing has changed along with it. With on-demand, infinite infrastructure, we don’t need to worry about ordering servers and provisioning. With infrastructure as code, it becomes simpler to manage lots of deployable units–so we can break up our monolith into microservices, and have hundreds or thousands of virtual machines or containers running. Enterprises that were started before cloud computing have large on-premise server deployments–but today, many of them also use the cloud. The cloud can be used to augment their classic on-prem deployments with cloud platform-as-a-service features. The cloud can also be used as a reliable way to scale during high load events. Today, a common architectural pattern is to have your application broken up into services. Each of those services has multiple instances. When the load on a particular service is under lots of demand, you create more instances to handle the increased load. How do you monitor the load on each service? How do you know when to spin up new instances of the service? Load analysis and load balancing across different services can be implemented by placing “agents” throughout your infrastructure. These agents gather data about services and service instances, and route that data to a centralized place. The centralized “control plane” can be used to make decisions about load-balancing and traffic routing. Ranga Rajagopalan worked on networking at Cisco for a decade before co-founding Avi Networks as CTO. Avi Networks builds modern load balancing software, and in today’s episode, Ranga describes the requirements of load balancing. We talked about the evolution of network infrastructure, the impact of the cloud, and the technical decisions that his team has made when architecting Avi Networks. Full disclosure: Avi Networks is a sponsor of Software Engineering Daily. The post Elastic Load Balancing with Ranga Rajagopalan appeared first on Software Engineering Daily.

Computational load is the amount of demand that is being placed on a computer system. “Load” can take the form of memory, CPU, network bandwidth, disk space, and other finite resources. When we design systems, we need to prepare for high-load events. On a social network, people are much more active in the mornings. On an e-commerce site, Black Friday causes many more users to come online for discount shopping. Our distributed application must be able to scale in response to these spikes in traffic. Cloud computing has changed the popular software architecture patterns, and load balancing has changed along with it. With on-demand, infinite infrastructure, we don’t need to worry about ordering servers and provisioning. With infrastructure as code, it becomes simpler to manage lots of deployable units–so we can break up our monolith into microservices, and have hundreds or thousands of virtual machines or containers running. Enterprises that were started before cloud computing have large on-premise server deployments–but today, many of them also use the cloud. The cloud can be used to augment their classic on-prem deployments with cloud platform-as-a-service features. The cloud can also be used as a reliable way to scale during high load events. Today, a common architectural pattern is to have your application broken up into services. Each of those services has multiple instances. When the load on a particular service is under lots of demand, you create more instances to handle the increased load. How do you monitor the load on each service? How do you know when to spin up new instances of the service? Load analysis and load balancing across different services can be implemented by placing “agents” throughout your infrastructure. These agents gather data about services and service instances, and route that data to a centralized place. The centralized “control plane” can be used to make decisions about load-balancing and traffic routing. Ranga Rajagopalan worked on networking at Cisco for a decade before co-founding Avi Networks as CTO. Avi Networks builds modern load balancing software, and in today’s episode, Ranga describes the requirements of load balancing. We talked about the evolution of network infrastructure, the impact of the cloud, and the technical decisions that his team has made when architecting Avi Networks. Full disclosure: Avi Networks is a sponsor of Software Engineering Daily. The post <a href="https://softwareengineeringdaily.com/2017/10/31/elastic-load-balancing-with-ranga-rajagopalan/" rel="nofollow" target="_blank">Elastic Load Balancing with Ranga Rajagopalan</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Elastic Load Balancing with Ranga Rajagopalan

Eduardo Laureano

On Software Engineering Daily, we have been covering the “serverless” movement in detail. For people who don’t use serverless functions, it seems like a niche. Serverless functions are stateless, auto-scaling, event-driven blobs of code. You might say “serverless sounds kind of cool, but why don’t I just use a server? It’s a paradigm I’m used to.” Serverless is exciting not because of what it adds but because of what it subtracts. The potential of serverless technology is to someday not have to worry about scalability at all. Today, we take for granted that if you start a new company, you are building it on cloud infrastructure. The problem of maintaining server hardware disappeared for 99% of startups, which unlocked a wealth of innovation. The cloud also simplified scalability for most startups–but there are still plenty of companies that struggle to scale. Significant mental energy is spent on the following questions: How many database replicas do I need? How do I configure my load balancer? How many nodes should I put in my Kafka cluster? Serverless functions are important because they are auto-scaling component that sits at a low level. This makes it easy to build auto scaling systems on top of them. Auto scaling databases, queueing systems, machine learning tools, and user applications.  And since the problem is being solved at such a low level, the pricing competitions will also take place at the low level, meaning that systems built on serverless functions will probably see steep declines in costs in the coming years. Serverless computing could eventually become free or nearly free, with the major cloud providers using it as a loss leader to onboard developers to higher level services. All of this makes for an exciting topic of discussion, that we will be repeatedly covering. Today’s show is with Eduardo Laureano, the principal program manager of Azure Functions. It was a fantastic conversation and we covered applications of serverless, improvements to the “cold start problem,” and how the Azure Functions platform is built and operated. Full disclosure: Microsoft is a sponsor of Software Engineering Daily. Meetups for Software Engineering Daily are being planned! Go to softwareengineeringdaily.com/meetup if you want to register for an upcoming Meetup. In March, I’ll be visiting Datadog in New York and Hubspot in Boston, and in April I’ll be at Telesign in LA. Summer internship applications to Software Engineering Daily are also being accepted. If you are interested in working with us on the Software Engineering Daily open source project full-time this Summer, send an application to internships@softwareengineeringdaily.com. We’d love to hear from you. The post Serverless Systems with Eduardo Laureano appeared first on Software Engineering Daily.

On Software Engineering Daily, we have been covering the “serverless” movement in detail. For people who don’t use serverless functions, it seems like a niche. Serverless functions are stateless, auto-scaling, event-driven blobs of code. You might say “serverless sounds kind of cool, but why don’t I just use a server? It’s a paradigm I’m used to.” Serverless is exciting not because of what it adds but because of what it subtracts. The potential of serverless technology is to someday not have to worry about scalability at all. Today, we take for granted that if you start a new company, you are building it on cloud infrastructure. The problem of maintaining server hardware disappeared for 99% of startups, which unlocked a wealth of innovation. The cloud also simplified scalability for most startups–but there are still plenty of companies that struggle to scale. Significant mental energy is spent on the following questions: How many database replicas do I need? How do I configure my load balancer? How many nodes should I put in my Kafka cluster? Serverless functions are important because they are auto-scaling component that sits at a low level. This makes it easy to build auto scaling systems on top of them. Auto scaling databases, queueing systems, machine learning tools, and user applications. And since the problem is being solved at such a low level, the pricing competitions will also take place at the low level, meaning that systems built on serverless functions will probably see steep declines in costs in the coming years. Serverless computing could eventually become free or nearly free, with the major cloud providers using it as a loss leader to onboard developers to higher level services. All of this makes for an exciting topic of discussion, that we will be repeatedly covering. Today’s show is with Eduardo Laureano, the principal program manager of Azure Functions. It was a fantastic conversation and we covered applications of serverless, improvements to the “cold start problem,” and how the Azure Functions platform is built and operated. Full disclosure: Microsoft is a sponsor of Software Engineering Daily. Meetups for Software Engineering Daily are being planned! Go to <a href="http://softwareengineeringdaily.com/meetup" rel="nofollow" target="_blank">softwareengineeringdaily.com/meetup</a> if you want to register for an upcoming Meetup. In March, I’ll be visiting Datadog in New York and Hubspot in Boston, and in April I’ll be at Telesign in LA. Summer internship applications to Software Engineering Daily are also being accepted. If you are interested in working with us on the Software Engineering Daily open source project full-time this Summer, send an application to <a href="mailto:internships@softwareengineeringdaily.com">internships@softwareengineeringdaily.com</a>. We’d love to hear from you. The post <a href="https://softwareengineeringdaily.com/2018/02/22/serverless-systems-with-eduardo-laureano/" rel="nofollow" target="_blank">Serverless Systems with Eduardo Laureano</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Serverless Systems with Eduardo Laureano

Corey Quinn

Amazon Web Services changed how software engineers work. Before AWS, it was common for startups to purchase their own physical servers. AWS made server resources as accessible as an API request, and has gone on to create higher-level abstractions for building applications. For the first few years of AWS, the abstractions were familiar. S3 provided distributed, reliable object storage. Elastic MapReduce provided a managed Hadoop system. Kinesis provided a scalable queue. Amazon provided developers with managed alternatives to complicated open source software. More recently, AWS has started to release products that are unlike anything else. A perfect example is AWS Lambda, the first function-as-a-service platform. Other newer AWS products include Ground Station, a service for processing satellite data and AWS DeepRacer, a miniature race car for developers to build and test machine learning algorithms on. As AWS has grown into new categories, the blog announcements of new services and features have started coming so frequently that it is hard to keep track of it all. Corey Quinn is the author of “Last Week in AWS”, a popular newsletter about what is changing across Amazon Web Services. Corey joins the show to give his perspective on the growing, shifting behemoth that is Amazon Web Services–as well as the other major cloud providers that have risen to prominence. He’s also the host of the Screaming in the Cloud podcast, which you should check out if you like this episode. The post AWS Analysis with Corey Quinn appeared first on Software Engineering Daily.

Amazon Web Services changed how software engineers work. Before AWS, it was common for startups to purchase their own physical servers. AWS made server resources as accessible as an API request, and has gone on to create higher-level abstractions for building applications. For the first few years of AWS, the abstractions were familiar. S3 provided distributed, reliable object storage. Elastic MapReduce provided a managed Hadoop system. Kinesis provided a scalable queue. Amazon provided developers with managed alternatives to complicated open source software. More recently, AWS has started to release products that are unlike anything else. A perfect example is AWS Lambda, the first function-as-a-service platform. Other newer AWS products include Ground Station, a service for processing satellite data and AWS DeepRacer, a miniature race car for developers to build and test machine learning algorithms on. As AWS has grown into new categories, the blog announcements of new services and features have started coming so frequently that it is hard to keep track of it all. Corey Quinn is the author of “<a href="https://lastweekinaws.com/" rel="nofollow" target="_blank">Last Week in AWS</a>”, a popular newsletter about what is changing across Amazon Web Services. Corey joins the show to give his perspective on the growing, shifting behemoth that is Amazon Web Services–as well as the other major cloud providers that have risen to prominence. He’s also the host of the <a href="https://www.screaminginthecloud.com/" rel="nofollow" target="_blank">Screaming in the Cloud podcast</a>, which you should check out if you like this episode. The post <a href="https://softwareengineeringdaily.com/2019/01/11/aws-analysis-with-corey-quinn/" rel="nofollow" target="_blank">AWS Analysis with Corey Quinn</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

AWS Analysis with Corey Quinn

Matt Klein

Matt Klein has worked for three rapidly growing Internet companies. At AWS, he worked on EC2, the compute-as-a-service product that powers a large percentage of the Internet. At Twitter, he helped scale the infrastructure in the chaotic days before Twitter’s IPO. Today he works at Lyft, building systems to allow for ride sharing infrastructure to work more safely and reliably. Hypergrowth Internet companies are faced with quickly growing demands on their software. The demands on the software expose problems with the core infrastructure. Simultaneously, the company tries to ramp up its hiring process. More engineers get hired, and the institutional knowledge within the company starts to weaken. Documentation gets out of date. Senior engineers burn out and leave the company. When a company starts growing quickly, communications can break down. A hypergrowth company can suffer from a lack of “human scalability”. Matt Klein has observed these challenges at AWS, Twitter, and Lyft. In his article “The Human Scalability of ‘DevOps’”, he explains why these problems manifest and what can be done to alleviate them.  In a previous show, Matt discussed the engineering challenges at Lyft that led him to create Envoy, a service proxy. This episode covers some broad technical topics–DevOps, site reliability engineering, platform engineering–but the episode is mostly about how a hypergrowth company can manage culture, hiring, and engineering organization.  Matt is a very fun guest to have because he questions some of the strange practices that have been widely adopted by successful companies. Internet companies are a very new phenomenon, and the management tactics that they have adopted are not well proven–so it is great to have someone like Matt provide a fresh perspective on ways that companies can scale their technology and their organization more effectively.   Show Notes  The human scalability of “DevOps” – Matt Klein – Medium How to scale DevOps: Recipes for larger organizations A Beginner’s Guide to Scaling DevOps – DZone DevOps DevOps vs. SRE: What’s the Difference Between Them, and Which One Are You? | OverOps Blog How do I do DevOps at Scale? – Plutora Five Top Tips for DevOps At Scale – DevOps.com Scaling DevOps at Pearson – DevOps.com In praise of fungible developers | Echo One  The post Scaling Lyft with Matt Klein appeared first on Software Engineering Daily.

Matt Klein has worked for three rapidly growing Internet companies. At AWS, he worked on EC2, the compute-as-a-service product that powers a large percentage of the Internet. At Twitter, he helped scale the infrastructure in the chaotic days before Twitter’s IPO. Today he works at Lyft, building systems to allow for ride sharing infrastructure to work more safely and reliably. Hypergrowth Internet companies are faced with quickly growing demands on their software. The demands on the software expose problems with the core infrastructure. Simultaneously, the company tries to ramp up its hiring process. More engineers get hired, and the institutional knowledge within the company starts to weaken. Documentation gets out of date. Senior engineers burn out and leave the company. When a company starts growing quickly, communications can break down. A hypergrowth company can suffer from a lack of “human scalability”. Matt Klein has observed these challenges at AWS, Twitter, and Lyft. In his article <a href="https://medium.com/@mattklein123/the-human-scalability-of-devops-e36c37d3db6a" rel="nofollow" target="_blank">“The Human Scalability of ‘DevOps’”</a>, he explains why these problems manifest and what can be done to alleviate them. In a previous show, Matt discussed <a href="https://softwareengineeringdaily.com/2017/02/14/service-proxying-with-matt-klein/" rel="nofollow" target="_blank">the engineering challenges at Lyft that led him to create Envoy</a>, a service proxy. This episode covers some broad technical topics–DevOps, site reliability engineering, platform engineering–but the episode is mostly about how a hypergrowth company can manage culture, hiring, and engineering organization. Matt is a very fun guest to have because he questions some of the strange practices that have been widely adopted by successful companies. Internet companies are a very new phenomenon, and the management tactics that they have adopted are not well proven–so it is great to have someone like Matt provide a fresh perspective on ways that companies can scale their technology and their organization more effectively. <h2>Show Notes</h2> <ul> <li><a href="https://medium.com/@mattklein123/the-human-scalability-of-devops-e36c37d3db6a" rel="nofollow" target="_blank">The human scalability of “DevOps” – Matt Klein – Medium</a></li> <li><a href="https://techbeacon.com/how-scale-devops-recipes-larger-organizations" rel="nofollow" target="_blank">How to scale DevOps: Recipes for larger organizations</a></li> <li><a href="https://dzone.com/articles/a-beginners-guide-to-scaling-devops" rel="nofollow" target="_blank">A Beginner’s Guide to Scaling DevOps – DZone DevOps</a></li> <li><a href="https://blog.takipi.com/devops-vs-sre-whats-the-difference-between-them-and-which-one-are-you/" rel="nofollow" target="_blank">DevOps vs. SRE: What’s the Difference Between Them, and Which One Are You? | OverOps Blog</a></li> <li><a href="https://www.plutora.com/blog/devops-at-scale" rel="nofollow" target="_blank">How do I do DevOps at Scale? – Plutora</a></li> <li><a href="https://devops.com/five-top-tips-devops-scale/" rel="nofollow" target="_blank">Five Top Tips for DevOps At Scale – DevOps.com</a></li> <li><a href="https://devops.com/scaling-devops-pearson/" rel="nofollow" target="_blank">Scaling DevOps at Pearson – DevOps.com</a></li> <li><a href="https://rrees.me/2014/06/22/in-praise-of-fungible-developers/" rel="nofollow" target="_blank">In praise of fungible developers | Echo One</a></li> </ul> The post <a href="https://softwareengineeringdaily.com/2018/11/02/scaling-lyft-with-matt-klein/" rel="nofollow" target="_blank">Scaling Lyft with Matt Klein</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Scaling Lyft with Matt Klein

Martin Kleppman

Martin Kleppmann

The Internet was designed as a decentralized system.  Theoretically, if Alice wants to send an email to Bob, she can set up an email client on her computer and send that email to Bob’s email server on his computer. In reality, very few people run their own email servers. We all send our emails to centralized services like Gmail, and connect to those centralized services using our own client—a browser on our laptop or a mobile application on our smart phone. Gmail is popular because nobody wants to run their own email server—it’s too much work. With Gmail, our emails our centralized, but centralization comes with convenience. Similar centralization happened with online payments.  If Alice wants to send $5 to Bob, she needs to go through centralized banking infrastructure. Alice tells her bank to send $5 from her bank account to Bob’s bank account. This is not how it works in the physical world. if Alice wants to pay cash to Bob, she doesn’t have to go and meet him at a physical bank. She just takes out a $5 bill from her wallet and hands it to him.  The invention of Bitcoin proved that digital wallets and peer-to-peer payments are possible. But running your own wallet is like running your own email server. It is inconvenient, and so we trade decentralization for convenience once again. We use services like Coinbase, where users buy and sell cryptocurrencies in a centralized provider. There are people in the cryptocurrency community who hate the idea of Coinbase. These people keep their cryptocurrency spread out on their own hardware wallets. Some of these people also run their own email servers. Are these people just adding unnecessary inconvenience to their lives for no reason? No. These are smart, successful people. They don’t like to waste time. So what are they doing running their own email servers? Distributed systems theory teaches the risk of centralized computer systems. If you have a single server that all your communication has to be routed through, your computer network will stop functioning if that server dies. Today, civilization is reliant on centralized computer systems. This is fundamentally dangerous. The 2008 financial crisis proved how risky it is to centralize our money in the hands of a few people. The Equifax breach proved how risky it is to centralize our identity in the hands of a few people.  What happens if Dropbox runs out of money and has to shut down? What happens if all of the data centers at Amazon Web Services get wiped simultaneously? What happens if Coinbase gets hacked and every user at Coinbase loses all their money? We have seen centralized systems collapse. The people who are running their own email servers are not crazy. Even if Gmail disappears tomorrow, they will still have access to their emails. With the example of email, we see that deploying and managing a decentralized system is possible.  Decentralization is a desirable feature of computer systems. So how do we make more of our applications decentralized? The cypherpunks were working for decades to make decentralized money a reality. Satoshi Nakamoto invented the blockchain, and we now have a computer science construct that enables decentralized money. The blockchain also enables many other decentralized applications. By solving a specific problem, Satoshi came up with a general solution. This is how progress often happens in computer science. In order to fix a system, we create a new tool. That tool can be applied to other systems that we don’t anticipate. The blockchain is a tool that solves one set of problems in distributed systems. Conflict-free replicated data types are another type of tool.  Conflict-free replicated data types (or CRDTs for short) are objects that can be mutated by multiple users at the same time without creating data corruption. The most common example of a conflict-free replicated data type is the shopping cart.  Let’s say Alice and Bob share an account on an ecommerce web site. Alice is building a house, and she wants to buy some tools online. Alice has a shopping cart with a hammer in it. Bob logs into the ecommerce web site from a different computer at the same time Alice is logged in. Bob just wants to buy a tuxedo—he doesn’t know why Alice left a hammer in the shopping cart, so he clicks a button to remove all the items from the shopping cart. At the exact same moment, Alice clicks from her computer to add a drill to the shopping cart. The server receives both requests: Bob wants to delete all items in the shopping cart, Alice wants to add a drill to the shopping cart. Both requests occurred at the exact same time, but we have to decide how to process them in some order. This is a situation known as a conflict.  Which request should execute first? Should the resulting shopping cart be empty? Should the shopping cart only have a drill in it? In either case, Alice or Bob is going to be disappointed—there is no way to avoid that. But we need some way to resolve the conflict deterministically. We do not want to have to send a message to both Alice and Bob that says “sorry, our shopping cart cannot handle your request. Please try again later.” We need the shopping cart to be a conflict-free shopping cart—and today’s episode is about the different techniques that can be used for conflict resolution. The shopping cart is a simple example where user collaboration leads to conflicts. Imagine all the other ways you collaborate with other users: chat systems like Slack, social networks like Facebook, document systems like Google Docs.  One way to resolve a conflict is through a technique called operational transform. Operational transform requires all the operations in the distributed system to be funneled through a centralized server. When a conflict occurs, the centralized server detects the problem and figures out how to resolve it. Google Docs uses operational transform to resolve the frequent conflicts that occur when two users are sharing a text document. But operational transform only works if you have a centralized server. An alternative solution is conflict-free replicated data types, which maintain each user’s replica of the data in a format that allows the client copies to resolve conflicts in a peer-to-peer fashion—without a centralized server.  Last example: Alice and Bob are now collaborating on a document that uses a CRDT data structure under the hood. Whenever they send their local changes to each other, any conflicts that occur can be resolved directly on the client. Alice and Bob can collaborate on a document just like they can send emails to each other.  With CRDTs, we can build decentralized, collaborative applications. But CRDTs are hard to use. Just like with blockchain technology, we don’t yet have the simple, elegant abstractions that let inexperienced programmers build peer-to-peer applications without the fear of conflicts. Martin Kleppman is a distributed systems researcher and the author of Data Intensive Applications. Martin is concerned by the centralization of our computer networks, and he works on CRDT technology in order to make it easier for people to build peer-to-peer applications. Most of the people who know how to build systems with CRDTs are distributed systems PhDs, database experts, and people working at huge internet companies. How do you make developer-friendly CRDTs? How do you allow random hackers to build peer-to-peer applications that avoid conflicts? Start by making a CRDT out of the most widely used, generalizable data structure in modern application development: the JSON object. In today’s episode, Martin and I talk about conflict resolution, CRDTs, and decentralized applications. This is Martin’s second time on the show, and his first interview is the most popular episode to date. You can find a link to that episode in the show notes for this episode, or you can find it in the Software Engineering Daily app for iOS and for Android. In other podcast players, you can only access the most recent 100 episodes. With these apps, we are building a new way to consume content about software engineering. They are open-sourced at github.com/softwareengineeringdaily. If you are looking for an open source project to get involved with, we would love to get your help. The post Decentralized Objects with Martin Kleppmann appeared first on Software Engineering Daily.

The Internet was designed as a decentralized system. Theoretically, if Alice wants to send an email to Bob, she can set up an email client on her computer and send that email to Bob’s email server on his computer. In reality, very few people run their own email servers. We all send our emails to centralized services like Gmail, and connect to those centralized services using our own client—a browser on our laptop or a mobile application on our smart phone. Gmail is popular because nobody wants to run their own email server—it’s too much work. With Gmail, our emails our centralized, but centralization comes with convenience. Similar centralization happened with online payments. If Alice wants to send $5 to Bob, she needs to go through centralized banking infrastructure. Alice tells her bank to send $5 from her bank account to Bob’s bank account. This is not how it works in the physical world. if Alice wants to pay cash to Bob, she doesn’t have to go and meet him at a physical bank. She just takes out a $5 bill from her wallet and hands it to him. The invention of Bitcoin proved that digital wallets and peer-to-peer payments are possible. But running your own wallet is like running your own email server. It is inconvenient, and so we trade decentralization for convenience once again. We use services like Coinbase, where users buy and sell cryptocurrencies in a centralized provider. There are people in the cryptocurrency community who hate the idea of Coinbase. These people keep their cryptocurrency spread out on their own hardware wallets. Some of these people also run their own email servers. Are these people just adding unnecessary inconvenience to their lives for no reason? No. These are smart, successful people. They don’t like to waste time. So what are they doing running their own email servers? Distributed systems theory teaches the risk of centralized computer systems. If you have a single server that all your communication has to be routed through, your computer network will stop functioning if that server dies. Today, civilization is reliant on centralized computer systems. This is fundamentally dangerous. The 2008 financial crisis proved how risky it is to centralize our money in the hands of a few people. The Equifax breach proved how risky it is to centralize our identity in the hands of a few people. What happens if Dropbox runs out of money and has to shut down? What happens if all of the data centers at Amazon Web Services get wiped simultaneously? What happens if Coinbase gets hacked and every user at Coinbase loses all their money? We have seen centralized systems collapse. The people who are running their own email servers are not crazy. Even if Gmail disappears tomorrow, they will still have access to their emails. With the example of email, we see that deploying and managing a decentralized system is possible. Decentralization is a desirable feature of computer systems. So how do we make more of our applications decentralized? The cypherpunks were working for decades to make decentralized money a reality. Satoshi Nakamoto invented the blockchain, and we now have a computer science construct that enables decentralized money. The blockchain also enables many other decentralized applications. By solving a specific problem, Satoshi came up with a general solution. This is how progress often happens in computer science. In order to fix a system, we create a new tool. That tool can be applied to other systems that we don’t anticipate. The blockchain is a tool that solves one set of problems in distributed systems. Conflict-free replicated data types are another type of tool. Conflict-free replicated data types (or CRDTs for short) are objects that can be mutated by multiple users at the same time without creating data corruption. The most common example of a conflict-free replicated data type is the shopping cart. Let’s say Alice and Bob share an account on an ecommerce web site. Alice is building a house, and she wants to buy some tools online. Alice has a shopping cart with a hammer in it. Bob logs into the ecommerce web site from a different computer at the same time Alice is logged in. Bob just wants to buy a tuxedo—he doesn’t know why Alice left a hammer in the shopping cart, so he clicks a button to remove all the items from the shopping cart. At the exact same moment, Alice clicks from her computer to add a drill to the shopping cart. The server receives both requests: Bob wants to delete all items in the shopping cart, Alice wants to add a drill to the shopping cart. Both requests occurred at the exact same time, but we have to decide how to process them in some order. This is a situation known as a conflict. Which request should execute first? Should the resulting shopping cart be empty? Should the shopping cart only have a drill in it? In either case, Alice or Bob is going to be disappointed—there is no way to avoid that. But we need some way to resolve the conflict deterministically. We do not want to have to send a message to both Alice and Bob that says “sorry, our shopping cart cannot handle your request. Please try again later.” We need the shopping cart to be a conflict-free shopping cart—and today’s episode is about the different techniques that can be used for conflict resolution. The shopping cart is a simple example where user collaboration leads to conflicts. Imagine all the other ways you collaborate with other users: chat systems like Slack, social networks like Facebook, document systems like Google Docs. One way to resolve a conflict is through a technique called operational transform. Operational transform requires all the operations in the distributed system to be funneled through a centralized server. When a conflict occurs, the centralized server detects the problem and figures out how to resolve it. Google Docs uses operational transform to resolve the frequent conflicts that occur when two users are sharing a text document. But operational transform only works if you have a centralized server. An alternative solution is conflict-free replicated data types, which maintain each user’s replica of the data in a format that allows the client copies to resolve conflicts in a peer-to-peer fashion—without a centralized server. Last example: Alice and Bob are now collaborating on a document that uses a CRDT data structure under the hood. Whenever they send their local changes to each other, any conflicts that occur can be resolved directly on the client. Alice and Bob can collaborate on a document just like they can send emails to each other. With CRDTs, we can build decentralized, collaborative applications. But CRDTs are hard to use. Just like with blockchain technology, we don’t yet have the simple, elegant abstractions that let inexperienced programmers build peer-to-peer applications without the fear of conflicts. Martin Kleppman is a distributed systems researcher and the author of Data Intensive Applications. Martin is concerned by the centralization of our computer networks, and he works on CRDT technology in order to make it easier for people to build peer-to-peer applications. Most of the people who know how to build systems with CRDTs are distributed systems PhDs, database experts, and people working at huge internet companies. How do you make developer-friendly CRDTs? How do you allow random hackers to build peer-to-peer applications that avoid conflicts? Start by making a CRDT out of the most widely used, generalizable data structure in modern application development: the JSON object. In today’s episode, Martin and I talk about conflict resolution, CRDTs, and decentralized applications. This is Martin’s second time on the show, and his first interview is the most popular episode to date. You can find<a href="https://softwareengineeringdaily.com/2017/05/02/data-intensive-applications-with-martin-kleppmann/" rel="nofollow" target="_blank"> a link to that episode</a> in the show notes for this episode, or you can find it in <a href="https://itunes.apple.com/us/app/software-engineering-daily-podcast-app/id1253734426?mt=8" rel="nofollow" target="_blank">the Software Engineering Daily app for iOS</a> and <a href="https://play.google.com/store/apps/details?id=com.koalatea.thehollidayinn.softwareengineeringdaily" rel="nofollow" target="_blank">for Android</a>. In other podcast players, you can only access the most recent 100 episodes. With these apps, we are building a new way to consume content about software engineering. They are open-sourced at <a href="https://github.com/SoftwareEngineeringDaily" rel="nofollow" target="_blank">github.com/softwareengineeringdaily</a>. If you are looking for an open source project to get involved with, we would love to get your help. The post <a href="https://softwareengineeringdaily.com/2017/12/08/decentralized-objects-with-martin-kleppman/" rel="nofollow" target="_blank">Decentralized Objects with Martin Kleppmann</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Decentralized Objects with Martin Kleppmann

Liz Rice

A Kubernetes cluster presents multiple potential attack surfaces: the cluster itself, a node running on the cluster, a pod running in the node, a container running in a pod. If you are managing your own Kubernetes cluster, you need to be aware of the security settings on your etcd, your API server, and your container build pipeline. Many of the security risks of a Kubernetes cluster can be avoided by using the default settings of Kubernetes, or by using a managed Kubernetes service from a cloud provider or an infrastructure company. But it is useful to know about the fundamentals of operating a secure cluster, so that you can hopefully avoid falling victim to the most common vulnerabilities. Liz Rice wrote the book Kubernetes Security with co-author Michael Hausenblas. Liz works at Aqua Security, a company that develops security tools for containerized applications. In today’s show, Liz gives an overview of the security risks of a Kubernetes cluster, and provides some best practices including secret management, penetration testing, and container lifecycle management.   Show Notes  Kubernetes Security by Michael Hausenblas, Liz Rice – O’Reilly Media Open Source Security Podcast – Talking about Kubernetes and container security with Liz Rice Keynote: Running with Scissors – Liz Rice, Technology Evangelist, Aqua Security  The post Kubernetes Security with Liz Rice appeared first on Software Engineering Daily.

A Kubernetes cluster presents multiple potential attack surfaces: the cluster itself, a node running on the cluster, a pod running in the node, a container running in a pod. If you are managing your own Kubernetes cluster, you need to be aware of the security settings on your etcd, your API server, and your container build pipeline. Many of the security risks of a Kubernetes cluster can be avoided by using the default settings of Kubernetes, or by using a managed Kubernetes service from a cloud provider or an infrastructure company. But it is useful to know about the fundamentals of operating a secure cluster, so that you can hopefully avoid falling victim to the most common vulnerabilities. Liz Rice wrote the book Kubernetes Security with co-author Michael Hausenblas. Liz works at Aqua Security, a company that develops security tools for containerized applications. In today’s show, Liz gives an overview of the security risks of a Kubernetes cluster, and provides some best practices including secret management, penetration testing, and container lifecycle management. <h2>Show Notes</h2> <ul> <li><a href="https://www.oreilly.com/library/view/kubernetes-security/9781492039075/" rel="nofollow" target="_blank">Kubernetes Security by Michael Hausenblas, Liz Rice – O’Reilly Media</a></li> <li><a href="https://www.opensourcesecuritypodcast.com/2018/11/episode-123-talking-about-kubernetes.html" rel="nofollow" target="_blank">Open Source Security Podcast – Talking about Kubernetes and container security with Liz Rice</a></li> <li><a href="https://www.youtube.com/watch?v=ltrV-Qmh3oY" rel="nofollow" target="_blank">Keynote: Running with Scissors – Liz Rice, Technology Evangelist, Aqua Security</a></li> </ul> The post <a href="https://softwareengineeringdaily.com/2019/02/14/kubernetes-security-with-liz-rice/" rel="nofollow" target="_blank">Kubernetes Security with Liz Rice</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Kubernetes Security with Liz Rice

Deepak Singh

Deepak Singh is the director of compute services at AWS, where he works on cloud products relating to containers, Linux, and High Performance Computing. In today’s show, Deepak describes how the market for containers and serverless has evolved, and how Amazon thinks about product strategy. Back in 2014, Docker containers were becoming a popular way to deploy and manage application infrastructure. Containers allowed people to take advantage of their servers in a more economical way. Containers let developers move faster by quickly setting up and tearing down small composable units of software.  As these containers grew in number within software companies, companies started figuring out that they needed tooling to manage and orchestrate all these containers. Infrastructure software companies realized that there would be a big business in providing orchestration software to developers who needed to manage these high volumes of containers. This led to the “container orchestration wars”, in which a variety of companies such as Red Hat, CoreOS, Docker, and Mesosphere all began to offer platforms for managing containerized applications.  During the container orchestration wars, many large enterprises such as banks and telcos resisted picking any specific container orchestration system because there was no clear winner. Enterprises were hesitant to place a large bet on an infrastructure orchestration tool that might go out of fashion. Amazon had a large number of customers that wanted to orchestrate their containers, but it was unclear how the market for open source container orchestration was going to unfold. Around this time, Amazon created ECS, a closed-source container orchestration system. In the following years, Kubernetes was released and became the most popular container orchestrator. Amazon released EKS, a managed Kubernetes service. They also released AWS Lambda for running serverless functions and AWS Fargate for spinning up long-lived container instances. Deepak and I discuss the history of containers at Amazon, but we also discuss how developer preferences are changing towards managed services, and how AWS is able to continually build off of its own tools to build higher and higher level services for developers.   Show Notes  AWS Fargate – Run containers without having to manage servers or clusters Amazon ECS Features – run containers in production AWS re:Invent 2017: Containers on AWS – State of the Union (CON201) – YouTube Amazon ECS – run containerized applications in production Amazon Elastic Container Service for Kubernetes | AWS News Blog Amazon Container Services – Highly Scalable, Easy to Use Container Management and Registry Services Amazon EKS – Managed Kubernetes Service What is Docker? | AWS How to Deploy Docker Containers – AWS  The post AWS Containers with Deepak Singh appeared first on Software Engineering Daily.

Deepak Singh is the director of compute services at AWS, where he works on cloud products relating to containers, Linux, and High Performance Computing. In today’s show, Deepak describes how the market for containers and serverless has evolved, and how Amazon thinks about product strategy. Back in 2014, Docker containers were becoming a popular way to deploy and manage application infrastructure. Containers allowed people to take advantage of their servers in a more economical way. Containers let developers move faster by quickly setting up and tearing down small composable units of software. As these containers grew in number within software companies, companies started figuring out that they needed tooling to manage and orchestrate all these containers. Infrastructure software companies realized that there would be a big business in providing orchestration software to developers who needed to manage these high volumes of containers. This led to the “<a href="https://softwareengineeringdaily.com/2018/01/13/the-gravity-of-kubernetes/" rel="nofollow" target="_blank">container orchestration wars</a>”, in which a variety of companies such as Red Hat, CoreOS, Docker, and Mesosphere all began to offer platforms for managing containerized applications. During the container orchestration wars, many large enterprises such as banks and telcos resisted picking any specific container orchestration system because there was no clear winner. Enterprises were hesitant to place a large bet on an infrastructure orchestration tool that might go out of fashion. Amazon had a large number of customers that wanted to orchestrate their containers, but it was unclear how the market for open source container orchestration was going to unfold. Around this time, Amazon created ECS, a closed-source container orchestration system. In the following years, Kubernetes was released and became the most popular container orchestrator. Amazon released EKS, a managed Kubernetes service. They also released AWS Lambda for running serverless functions and AWS Fargate for spinning up long-lived container instances. Deepak and I discuss the history of containers at Amazon, but we also discuss how developer preferences are changing towards managed services, and how AWS is able to continually build off of its own tools to build higher and higher level services for developers. <h2>Show Notes</h2> <ul> <li><a href="https://aws.amazon.com/fargate/" rel="nofollow" target="_blank">AWS Fargate – Run containers without having to manage servers or clusters</a></li> <li><a href="https://aws.amazon.com/ecs/features/" rel="nofollow" target="_blank">Amazon ECS Features – run containers in production</a></li> <li><a href="https://www.youtube.com/watch?v=JXnhAZZnzQg" rel="nofollow" target="_blank">AWS re:Invent 2017: Containers on AWS – State of the Union (CON201) – YouTube</a></li> <li><a href="https://aws.amazon.com/ecs/" rel="nofollow" target="_blank">Amazon ECS – run containerized applications in production</a></li> <li><a href="https://aws.amazon.com/blogs/aws/amazon-elastic-container-service-for-kubernetes/" rel="nofollow" target="_blank">Amazon Elastic Container Service for Kubernetes | AWS News Blog</a></li> <li><a href="https://aws.amazon.com/containers/" rel="nofollow" target="_blank">Amazon Container Services – Highly Scalable, Easy to Use Container Management and Registry Services</a></li> <li><a href="https://aws.amazon.com/eks/" rel="nofollow" target="_blank">Amazon EKS – Managed Kubernetes Service</a></li> <li><a href="https://aws.amazon.com/docker/" rel="nofollow" target="_blank">What is Docker? | AWS</a></li> <li><a href="https://aws.amazon.com/getting-started/tutorials/deploy-docker-containers/" rel="nofollow" target="_blank">How to Deploy Docker Containers – AWS</a></li> </ul> The post <a href="https://softwareengineeringdaily.com/2018/10/19/aws-containers-with-deepak-singh/" rel="nofollow" target="_blank">AWS Containers with Deepak Singh</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

AWS Containers with Deepak Singh

Alexis Le-Quoc

Alexis Le-Quoc started Datadog in 2010, after living through the Internet boom and bust cycle of the late 90s and early 2000s. In 2010, cloud was just starting to become popular. There was a gap in the market for infrastructure monitoring tools, which Alexis helped fill with the first version of Datadog.  Since 2010, the number of different cloud infrastructure products has proliferated. There were new databases, queueing systems, virtualization and containerization tools. Web 2.0 took off, and thousands of new Internet businesses got started. Many of these businesses used Datadog to monitor their increasingly wide range of infrastructure configurations–and Datadog began to scale. On today’s show, Alexis tells the story of how Datadog grew from its first product into a variety of tools–infrastructure monitoring, logging, and application performance monitoring. Monitoring is a unique challenge–there is a ton of data, the data is latency sensitive, and the data is operationally important. These engineering constraints provide for a great conversation. Alexis is the CTO of Datadog, and we talked about cloud providers, building a business, infrastructure, and how to scale engineering management. Full disclosure: Datadog is a sponsor of Software Engineering Daily. The post Building Datadog with Alexis Le-Quoc appeared first on Software Engineering Daily.

Alexis Le-Quoc started Datadog in 2010, after living through the Internet boom and bust cycle of the late 90s and early 2000s. In 2010, cloud was just starting to become popular. There was a gap in the market for infrastructure monitoring tools, which Alexis helped fill with the first version of Datadog. Since 2010, the number of different cloud infrastructure products has proliferated. There were new databases, queueing systems, virtualization and containerization tools. Web 2.0 took off, and thousands of new Internet businesses got started. Many of these businesses used Datadog to monitor their increasingly wide range of infrastructure configurations–and Datadog began to scale. On today’s show, Alexis tells the story of how Datadog grew from its first product into a variety of tools–infrastructure monitoring, logging, and application performance monitoring. Monitoring is a unique challenge–there is a ton of data, the data is latency sensitive, and the data is operationally important. These engineering constraints provide for a great conversation. Alexis is the CTO of Datadog, and we talked about cloud providers, building a business, infrastructure, and how to scale engineering management. Full disclosure: Datadog is a sponsor of Software Engineering Daily. The post <a href="https://softwareengineeringdaily.com/2018/05/02/building-datadog-with-alexis-le-quoc/" rel="nofollow" target="_blank">Building Datadog with Alexis Le-Quoc</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Building Datadog with Alexis Le-Quoc

A backend application can have hundreds of services written in different programming frameworks and languages.  Across these different languages, log messages are produced in different formats. Some logging is produced in XML, some are produced in JSON, some is in other formats. These logs need to be unified into a common format and centralized for any developer who wants to debug. The popularity of Kubernetes is making it easier for companies to build this kind of distributed application, where different services of different languages are communicating over a network, with a variety of log message types. Fluentd is a tool for solving this problem of log collection and unification. In today’s episode, Eduardo Silva joins the show to describe how Fluentd is deployed to Kubernetes, and what the role of Fluentd is within a Kubernetes logging pipeline.  We also discuss the company where Eduardo works–Treasure Data. The story of Treasure Data is unusual. The team started out doing log management but has found itself moving up the stack, into marketing analytics, sales analytics, and customer data management. This story might be useful for anyone who is an open-source developer thinking about how to evolve your project into a business. The post FluentD with Eduardo Silva appeared first on Software Engineering Daily.

A backend application can have hundreds of services written in different programming frameworks and languages. Across these different languages, log messages are produced in different formats. Some logging is produced in XML, some are produced in JSON, some is in other formats. These logs need to be unified into a common format and centralized for any developer who wants to debug. The popularity of Kubernetes is making it easier for companies to build this kind of distributed application, where different services of different languages are communicating over a network, with a variety of log message types. Fluentd is a tool for solving this problem of log collection and unification. In today’s episode, Eduardo Silva joins the show to describe how Fluentd is deployed to Kubernetes, and what the role of Fluentd is within a Kubernetes logging pipeline. We also discuss the company where Eduardo works–Treasure Data. The story of Treasure Data is unusual. The team started out doing log management but has found itself moving up the stack, into marketing analytics, sales analytics, and customer data management. This story might be useful for anyone who is an open-source developer thinking about how to evolve your project into a business. The post <a href="https://softwareengineeringdaily.com/2018/01/15/fluentd-with-eduardo-silva/" rel="nofollow" target="_blank">FluentD with Eduardo Silva</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

FluentD with Eduardo Silva

Applications need to be ready to scale in response to high-load events. With mobile applications, this can be even more important. People rely on mobile applications such as banking, ride sharing, and GPS. During Black Friday, a popular ecommerce application could be bombarded by user requests–you might not be able to complete a request to buy an item at the Black Friday discount. If you attend the Superbowl, and then try to catch an Uber after leaving, all the other people around you might be summoning a car at the same time, and the system might not scale. In order to prepare infrastructure for high volume, mobile development teams often create end-to-end load tests. After recording incoming mobile traffic, that mobile traffic can be replicated and replayed, to measure a backend’s response to the mobile workload. Paulo Costa and Rodrigo Coutinho are engineers at OutSystems, a company that makes a platform for building low-code mobile applications. In this episode, Paulo and Rodrigo discuss the process of performing end-to-end scalability testing for mobile applications backed by cloud infrastructure.  We talked about the high level process of architecting the load test, and explored the tools used to implement it. Full disclosure: OutSystems is a sponsor of Software Engineering Daily. The post Load Testing Mobile Applications with Paulo Costa and Rodrigo Coutinho appeared first on Software Engineering Daily.

Applications need to be ready to scale in response to high-load events. With mobile applications, this can be even more important. People rely on mobile applications such as banking, ride sharing, and GPS. During Black Friday, a popular ecommerce application could be bombarded by user requests–you might not be able to complete a request to buy an item at the Black Friday discount. If you attend the Superbowl, and then try to catch an Uber after leaving, all the other people around you might be summoning a car at the same time, and the system might not scale. In order to prepare infrastructure for high volume, mobile development teams often create end-to-end load tests. After recording incoming mobile traffic, that mobile traffic can be replicated and replayed, to measure a backend’s response to the mobile workload. Paulo Costa and Rodrigo Coutinho are engineers at OutSystems, a company that makes a platform for building low-code mobile applications. In this episode, Paulo and Rodrigo discuss the process of performing end-to-end scalability testing for mobile applications backed by cloud infrastructure.  We talked about the high level process of architecting the load test, and explored the tools used to implement it. Full disclosure: OutSystems is a sponsor of Software Engineering Daily. The post <a href="https://softwareengineeringdaily.com/2018/02/08/load-testing-mobile-applications-with-paulo-costa-and-rodrigo-coutinho/" rel="nofollow" target="_blank">Load Testing Mobile Applications with Paulo Costa and Rodrigo Coutinho</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Load Testing Mobile Applications with Paulo Costa and Rodrigo Coutinho

Randall Hunt

Developers can build networked applications today without having to deploy their code to a server. These “serverless” applications are constructed from managed services and functions-as-a-service. Managed services are cloud offerings like database-as-a-service, queueing-as-a-service, or search-as-a-service. These managed services are easy to use. They take care of operational burdens like scalability and outages. But managed services typically solve a narrow use case. You can’t build an application entirely out of managed services. Managed services are scalable and narrow. Functions-as-a-service are scalable and flexible. With managed services, you make remote calls to a service with a well-defined API. With functions-as-a-service, you can deploy your own code. But functions-as-a-service execute against transient, unreliable compute resources. They aren’t a good fit for low latency computation, and the code you run on them should be stateless. Managed services and functions-as-a-service are the perfect complements.  Managed services provide you with well-defined server abstractions that every application needs—like databases, search indexes, and queues. Functions as a service offer flexible “glue code” that you can use to create custom interactions between the managed services. The term “serverless” is used to describe the applications that are built entirely with managed services and functions as a service. Serverless applications are dramatically simpler to build and easier to operate than cloud applications of the past. The costs of managed services can get expensive, but the costs of functions as a service can cost 1/10th of what it might take to run a server that is handling your requests. Whether the size of your bill will increase or decrease as your company becomes “serverless” is less of an issue than the fact that your employees will be more productive: serverless applications have less operational burden, so developers spend more time architecting and implementing software.  It has been 5 years since the Netflix infrastructure team was talking about the aspirational goal of a “no-ops” software culture. Your software should be so well-defined that you do not need regular intervention of ops staff to reboot your servers and reconfigure your load balancers. Serverless is a newer way of moving operational expense into capital expense. Today’s guest Randall Hunt is a senior technical evangelist with Amazon Web Services. He travels around the world meeting developers and speaking at conferences about AWS Lambda, the functions as a service platform from Amazon. Randall has given some excellent talks about how to architect and build serverless applications (which I will add to the show notes), and today we explore those application patterns further. Show Notes Serverless Services – Randall Hunt Randall Hunt at AWS Summit Seoul Serverless, What is it Good For? Randall Hunt The post Serverless Applications with Randall Hunt appeared first on Software Engineering Daily.

Developers can build networked applications today without having to deploy their code to a server. These “serverless” applications are constructed from managed services and functions-as-a-service. Managed services are cloud offerings like database-as-a-service, queueing-as-a-service, or search-as-a-service. These managed services are easy to use. They take care of operational burdens like scalability and outages. But managed services typically solve a narrow use case. You can’t build an application entirely out of managed services. Managed services are scalable and narrow. Functions-as-a-service are scalable and flexible. With managed services, you make remote calls to a service with a well-defined API. With functions-as-a-service, you can deploy your own code. But functions-as-a-service execute against transient, unreliable compute resources. They aren’t a good fit for low latency computation, and the code you run on them should be stateless. Managed services and functions-as-a-service are the perfect complements. Managed services provide you with well-defined server abstractions that every application needs—like databases, search indexes, and queues. Functions as a service offer flexible “glue code” that you can use to create custom interactions between the managed services. The term “serverless” is used to describe the applications that are built entirely with managed services and functions as a service. Serverless applications are dramatically simpler to build and easier to operate than cloud applications of the past. The costs of managed services can get expensive, but the costs of functions as a service can cost 1/10th of what it might take to run a server that is handling your requests. Whether the size of your bill will increase or decrease as your company becomes “serverless” is less of an issue than the fact that your employees will be more productive: serverless applications have less operational burden, so developers spend more time architecting and implementing software. It has been 5 years since <a href="http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html" rel="nofollow" target="_blank">the Netflix infrastructure team was talking about the aspirational goal of a “no-ops” software culture</a>. Your software should be so well-defined that you do not need regular intervention of ops staff to reboot your servers and reconfigure your load balancers. Serverless is a newer way of moving operational expense into capital expense. Today’s guest Randall Hunt is a senior technical evangelist with Amazon Web Services. He travels around the world meeting developers and speaking at conferences about AWS Lambda, the functions as a service platform from Amazon. Randall has given some excellent talks about how to architect and build serverless applications (which I will add to the show notes), and today we explore those application patterns further. <h2>Show Notes</h2> <a href="https://youtu.be/Qbsk7GLPYwk" rel="nofollow" target="_blank">Serverless Services – Randall Hunt</a> <a href="https://youtu.be/DBqy-m0VM9U" rel="nofollow" target="_blank">Randall Hunt at AWS Summit Seoul</a> <a href="https://youtu.be/F8-y_d7l-2c" rel="nofollow" target="_blank">Serverless, What is it Good For? Randall Hunt</a> The post <a href="https://softwareengineeringdaily.com/2017/12/07/serverless-applications-with-randall-hunt/" rel="nofollow" target="_blank">Serverless Applications with Randall Hunt</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Serverless Applications with Randall Hunt

Erik St

Go is a language designed to improve systems programming. Go includes abstractions that simplify aspects of low level engineering that are historically difficult—concurrency, resource allocation, and dependency management. In that light, it makes sense that the Kubernetes container orchestration system was written in Go. Erik St. Martin is a cloud developer advocate at Microsoft, where he focuses on Go and Kubernetes. He also hosts the podcast “Go Time,” and has written a book on Go called Go In Action. Recently, Erik helped build the virtual Kubelet project, which allows Kubernetes nodes to be backed by services outside of that cluster. If you want your Kubernetes cluster to leverage abstractions such as serverless functions and standalone container instances, you can use Virtual Kubelet to treat these other abstractions as nodes. Erik also discussed his experience using Kubernetes at Comcast—which was a great case study. Near the end of the show, he also talked about organizing Gophercon, a popular conference for Go programmers—if you are organizing a conference or thinking about organizing one, it will be useful information to you. Full disclosure: Microsoft, where Erik works, is a sponsor of Software Engineering Daily. The post Go Systems with Erik St. Martin appeared first on Software Engineering Daily.

Go is a language designed to improve systems programming. Go includes abstractions that simplify aspects of low level engineering that are historically difficult—concurrency, resource allocation, and dependency management. In that light, it makes sense that the Kubernetes container orchestration system was written in Go. Erik St. Martin is a cloud developer advocate at Microsoft, where he focuses on Go and Kubernetes. He also hosts the podcast “Go Time,” and has written a book on Go called Go In Action. Recently, Erik helped build the virtual Kubelet project, which allows Kubernetes nodes to be backed by services outside of that cluster. If you want your Kubernetes cluster to leverage abstractions such as serverless functions and standalone container instances, you can use Virtual Kubelet to treat these other abstractions as nodes. Erik also discussed his experience using Kubernetes at Comcast—which was a great case study. Near the end of the show, he also talked about organizing Gophercon, a popular conference for Go programmers—if you are organizing a conference or thinking about organizing one, it will be useful information to you. Full disclosure: Microsoft, where Erik works, is a sponsor of Software Engineering Daily. The post <a href="https://softwareengineeringdaily.com/2018/04/11/go-systems-with-erik-st-martin/" rel="nofollow" target="_blank">Go Systems with Erik St. Martin</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Go Systems with Erik St. Martin

Akshay Shah

Upcoming events:  A Conversation with Haseeb Qureshi at Cloudflare on April 3, 2019 FindCollabs Hackathon at App Academy on April 6, 2019 Uber’s infrastructure supports millions of riders and billions of dollars in transactions. Uber has high throughput and high availability requirements, because users depend on the service for their day-to-day transportation. When Uber was going through hypergrowth in 2015, the number of services was growing rapidly, as was the load across those services. Using a cloud provider was a risky option, because the costs could potentially grow out of control. Uber made a decision early on to invest in physical hardware in order to keep costs at a reasonable level. In the last 3 years, Uber’s infrastructure has stabilized. The platform engineering team has built systems for monitoring, deployment, and service proxying. Developing and maintaining microservices within Uber has become easier. Prashant Varanasi and Akshay Shah are engineers who have been with Uber for more than three years. They work on Uber’s platform engineering team, and their current focus is on the service proxy layer, a sidecar that runs alongside Uber services providing features such as load balancing, service discovery, and rate limiting. Prashant and Akshay join the show to talk about Uber infrastructure, microservices, and the architecture of a service proxy. We also talk in detail about the benefits of using Go for critical systems infrastructure, and some techniques for profiling and debugging in Go. The post Uber Infrastructure with Prashant Varanasi and Akshay Shah appeared first on Software Engineering Daily.

Upcoming events: <a href="https://softwareengineeringdaily.com/meetup" rel="nofollow" target="_blank">A Conversation with Haseeb Qureshi at Cloudflare on April 3, 2019</a> <a href="https://softwareengineeringdaily.com/hackathon" rel="nofollow" target="_blank">FindCollabs Hackathon at App Academy on April 6, 2019</a> Uber’s infrastructure supports millions of riders and billions of dollars in transactions. Uber has high throughput and high availability requirements, because users depend on the service for their day-to-day transportation. When Uber was going through hypergrowth in 2015, the number of services was growing rapidly, as was the load across those services. Using a cloud provider was a risky option, because the costs could potentially grow out of control. Uber made a decision early on to invest in physical hardware in order to keep costs at a reasonable level. In the last 3 years, Uber’s infrastructure has stabilized. The platform engineering team has built systems for monitoring, deployment, and service proxying. Developing and maintaining microservices within Uber has become easier. Prashant Varanasi and Akshay Shah are engineers who have been with Uber for more than three years. They work on Uber’s platform engineering team, and their current focus is on the service proxy layer, a sidecar that runs alongside Uber services providing features such as load balancing, service discovery, and rate limiting. Prashant and Akshay join the show to talk about Uber infrastructure, microservices, and the architecture of a service proxy. We also talk in detail about the benefits of using Go for critical systems infrastructure, and some techniques for profiling and debugging in Go. The post <a href="https://softwareengineeringdaily.com/2019/04/01/uber-infrastructure-with-prashant-varanasi-and-akshay-shah/" rel="nofollow" target="_blank">Uber Infrastructure with Prashant Varanasi and Akshay Shah</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Uber Infrastructure with Prashant Varanasi and Akshay Shah

Saad Ali

In a cloud infrastructure environment, failures happen regularly. The servers can fail, the network can fail, and software bugs can crash your software unexpectedly. The amount of failures that can occur in cloud infrastructure is one reason why storage is often separated from application logic. A developer can launch multiple instances of their application, with each instance providing a “stateless” environment for serving API requests. When the application needs to save state, it can make a call out to a managed cloud infrastructure product. Managed cloud databases provide a reliable place to manage application state. Managed object storage systems like Amazon S3 provide a reliable place to store files. The pattern of relying on remote cloud services does not work so well for on-prem and hybrid cloud environments. In these environments, companies are managing their own data centers and their own storage devices. As companies with on-prem infrastructure adopt Kubernetes, there is a need for ways to manage on-prem storage through Kubernetes. Saad Ali is a senior engineer at Google, where he works on Kubernetes. He is also a part of the Kubernetes Storage Special Interest Group. Saad joins the show talk about how Kubernetes interacts with storage, and how to manage stateful workloads on Kubernetes. We discuss the basics of Kubernetes storage, including persistent volumes and the container storage interface. The post Stateful Kubernetes with Saad Ali appeared first on Software Engineering Daily.

In a cloud infrastructure environment, failures happen regularly. The servers can fail, the network can fail, and software bugs can crash your software unexpectedly. The amount of failures that can occur in cloud infrastructure is one reason why storage is often separated from application logic. A developer can launch multiple instances of their application, with each instance providing a “stateless” environment for serving API requests. When the application needs to save state, it can make a call out to a managed cloud infrastructure product. Managed cloud databases provide a reliable place to manage application state. Managed object storage systems like Amazon S3 provide a reliable place to store files. The pattern of relying on remote cloud services does not work so well for on-prem and hybrid cloud environments. In these environments, companies are managing their own data centers and their own storage devices. As companies with on-prem infrastructure adopt Kubernetes, there is a need for ways to manage on-prem storage through Kubernetes. Saad Ali is a senior engineer at Google, where he works on Kubernetes. He is also a part of the Kubernetes Storage Special Interest Group. Saad joins the show talk about how Kubernetes interacts with storage, and how to manage stateful workloads on Kubernetes. We discuss the basics of Kubernetes storage, including persistent volumes and the container storage interface. The post <a href="https://softwareengineeringdaily.com/2019/01/07/stateful-kubernetes-with-saad-ali/" rel="nofollow" target="_blank">Stateful Kubernetes with Saad Ali</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Stateful Kubernetes with Saad Ali

Thomas Wuerthinger

Java programs compile into Java bytecode. Java bytecode executes in the Java Virtual Machine, a runtime environment that compiles that bytecode further into machine code, and optimizes the runtime by identifying “hot” code paths and keeping those hot code paths executing quickly.  The Java Virtual Machine is a popular platform for building languages on top of. Languages like Scala and Clojure compile down to Java bytecode, and can take advantage of the garbage collection system and the code path optimizations of the JVM. But when Scala and Clojure compile into Java bytecode, the code “shape”–the way that the programs are laid out in memory–is not the same as when Java programs compile into Java bytecode. Executing bytecode that comes from Scala will have certain performance penalties relative to a functionally identical program written in Java. GraalVM is a system for interpreting languages into Java bytecode that can run efficiently on the JVM. Any language can be interpreted into an abstract syntax tree that the GraalVM can execute using the JVM. Languages that can run on GraalVM include JavaScript, R, Ruby, and Python. Thomas Wuerthinger is a senior research director at Oracle and the project lead for GraalVM. He joins the show to explain the motivation for GraalVM, the architecture of the project, and the future of language interoperability. It was an exciting discussion and I learned a lot about the Java ecosystem. The post GraalVM with Thomas Wuerthinger appeared first on Software Engineering Daily.

Java programs compile into Java bytecode. Java bytecode executes in the Java Virtual Machine, a runtime environment that compiles that bytecode further into machine code, and optimizes the runtime by identifying “hot” code paths and keeping those hot code paths executing quickly. The Java Virtual Machine is a popular platform for building languages on top of. Languages like Scala and Clojure compile down to Java bytecode, and can take advantage of the garbage collection system and the code path optimizations of the JVM. But when Scala and Clojure compile into Java bytecode, the code “shape”–the way that the programs are laid out in memory–is not the same as when Java programs compile into Java bytecode. Executing bytecode that comes from Scala will have certain performance penalties relative to a functionally identical program written in Java. GraalVM is a system for interpreting languages into Java bytecode that can run efficiently on the JVM. Any language can be interpreted into an abstract syntax tree that the GraalVM can execute using the JVM. Languages that can run on GraalVM include JavaScript, R, Ruby, and Python. Thomas Wuerthinger is a senior research director at Oracle and the project lead for GraalVM. He joins the show to explain the motivation for GraalVM, the architecture of the project, and the future of language interoperability. It was an exciting discussion and I learned a lot about the Java ecosystem. The post <a href="https://softwareengineeringdaily.com/2018/08/03/graalvm-with-thomas-wuerthinger/" rel="nofollow" target="_blank">GraalVM with Thomas Wuerthinger</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

GraalVM with Thomas Wuerthinger

Bryan Boreham

Prometheus

Prometheus is an open source monitoring system and time series database. Prometheus includes a multi-dimensional data model, a query language called PromQL, and a pull model for gathering metrics from your different services. Prometheus is widely used by large distributed systems deployments such as Kubernetes and Cloud Foundry. Prometheus gathers metrics from your services by periodically scraping those services. Those metrics get gathered, compressed, and stored onto disk for querying. But Prometheus is designed to store all of its records on one host in one set of files–which limits the scalability and availability of those metrics. Cortex is an open source project built to scale Prometheus. Cortex effectively shards Prometheus by parallelizing the “ingestion” and storage of Prometheus metrics. Cortex can take metrics from multiple Prometheus instances and store them across a distributed NoSQL database like DynamoDB, BigTable, or Cassandra. Bryan Boreham is an engineer at Weaveworks, where he works on deployment, observability, and monitoring tools for containers and microservices. He wrote much of the code for Cortex, and we met up at KubeCon North America to talk about the motivation for creating Cortex, the broader landscape of Kubernetes monitoring, and other approaches to scaling Prometheus. The post Prometheus Scalability with Bryan Boreham appeared first on Software Engineering Daily.

Prometheus is an open source monitoring system and time series database. Prometheus includes a multi-dimensional data model, a query language called PromQL, and a pull model for gathering metrics from your different services. Prometheus is widely used by large distributed systems deployments such as Kubernetes and Cloud Foundry. Prometheus gathers metrics from your services by periodically scraping those services. Those metrics get gathered, compressed, and stored onto disk for querying. But Prometheus is designed to store all of its records on one host in one set of files–which limits the scalability and availability of those metrics. Cortex is an open source project built to scale Prometheus. Cortex effectively shards Prometheus by parallelizing the “ingestion” and storage of Prometheus metrics. Cortex can take metrics from multiple Prometheus instances and store them across a distributed NoSQL database like DynamoDB, BigTable, or Cassandra. Bryan Boreham is an engineer at Weaveworks, where he works on deployment, observability, and monitoring tools for containers and microservices. He wrote much of the code for Cortex, and we met up at KubeCon North America to talk about the motivation for creating Cortex, the broader landscape of Kubernetes monitoring, and other approaches to scaling Prometheus. The post <a href="https://softwareengineeringdaily.com/2019/01/21/prometheus-scalability-with-bryan-boreham/" rel="nofollow" target="_blank">Prometheus Scalability with Bryan Boreham</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Prometheus Scalability with Bryan Boreham

Clayton Coleman

Kubernetes is in production clusters around the world with hundreds of thousands of containers. Kubernetes provides a distributed systems management environment for small startups and giant enterprises with applications ranging from microservices to machine learning pipelines.  Because the use cases are already so wide-ranging, and the project has had so much adoption, the focus of many of the Kubernetes core contributors is stability. Clayton Coleman joins the show to talk about the impact that Kubernetes is having on software engineering and the efforts of the community to improve stability. Clayton is the lead engineer for OpenShift, a platform-as-a-service from Red Hat.  Autoscaling, monitoring, and etcd are a few of the topics we discuss. Improvements to each of these areas are making Kubernetes easier to work with. There is a possibility that the Prometheus monitoring system will get pulled into Kubernetes itself, and we explore the pros and cons of this architectural decision. From his experience working on OpenShift, Clayton also has a lot to share around the idea of a platform-as-a-service. Platform-as-a-service tooling can make enterprises significantly more  productive, serving as a layer between a cloud provider and a developer that is shipping application code.  Cloud providers can be complex to learn how to work with. As enterprises adopt cloud more aggressively, they are using platform-as-a-service tools as an interface for developers to work with those clouds in a more opinionated way. Kubernetes is used as a foundation for platforms like OpenShift, because Kubernetes can orchestrate resources on a cloud in a way that makes it easier for a deployment to be multicloud, or portable between clouds. In our previous episode with Clayton 2 years ago, we covered the basics of OpenShift and the developments that were occurring around Kubernetes at the time. In today’s show we go deeper into how the Kubernetes ecosystem is evolving, and his personal experience working on OpenShift. Full disclosure: Red Hat (where Clayton works) is a sponsor of Software Engineering Daily. The post Kubernetes Impact with Clayton Coleman appeared first on Software Engineering Daily.

Kubernetes is in production clusters around the world with hundreds of thousands of containers. Kubernetes provides a distributed systems management environment for small startups and giant enterprises with applications ranging from microservices to machine learning pipelines. Because the use cases are already so wide-ranging, and the project has had so much adoption, the focus of many of the Kubernetes core contributors is stability. Clayton Coleman joins the show to talk about the impact that Kubernetes is having on software engineering and the efforts of the community to improve stability. Clayton is the lead engineer for OpenShift, a platform-as-a-service from Red Hat. Autoscaling, monitoring, and etcd are a few of the topics we discuss. Improvements to each of these areas are making Kubernetes easier to work with. There is a possibility that the Prometheus monitoring system will get pulled into Kubernetes itself, and we explore the pros and cons of this architectural decision. From his experience working on OpenShift, Clayton also has a lot to share around the idea of a platform-as-a-service. Platform-as-a-service tooling can make enterprises significantly more  productive, serving as a layer between a cloud provider and a developer that is shipping application code. Cloud providers can be complex to learn how to work with. As enterprises adopt cloud more aggressively, they are using platform-as-a-service tools as an interface for developers to work with those clouds in a more opinionated way. Kubernetes is used as a foundation for platforms like OpenShift, because Kubernetes can orchestrate resources on a cloud in a way that makes it easier for a deployment to be multicloud, or portable between clouds. In our <a href="https://softwareengineeringdaily.com/2016/05/31/kubernetes-openshift-clayton-coleman/" rel="nofollow" target="_blank">previous episode with Clayton</a> 2 years ago, we covered the basics of OpenShift and the developments that were occurring around Kubernetes at the time. In today’s show we go deeper into how the Kubernetes ecosystem is evolving, and his personal experience working on OpenShift. Full disclosure: Red Hat (where Clayton works) is a sponsor of Software Engineering Daily. The post <a href="https://softwareengineeringdaily.com/2018/08/30/kubernetes-impact/" rel="nofollow" target="_blank">Kubernetes Impact with Clayton Coleman</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Kubernetes Impact with Clayton Coleman

Steve Newman

Google Docs is used by millions of people to collaborate on documents together. With today’s technology, you could spend a weekend coding and build a basic version of a collaborative text editor. But in 2004 it was not so easy.  In 2004 Steve Newman built a product called Writely, which allowed users to collaborate on documents together. Initially, Writely was hosted on a single server that Steve managed himself. All of the reads and writes to the documents went through that single server. Writely rapidly grew in popularity, and Steve went through a crash course in distributed systems as he tried to keep up with the user base. In 2006, Writely was acquired by Google, and Steve spent his next four years turning Writely into Google Docs. Eventually he moved onto other projects within Google—“Cosmo” and “Megastore Replication.” When Steve left the company in 2010, he took with him the lessons of logging and monitoring that keep Google’s infrastructure observable. Large organizations have terabytes of log data to manage. This data streams off the servers that are running our applications. That log data gets processed in a “metrics pipeline” and turned into monitoring data. Monitoring data aggregates log data in a more presentable format.  Most of the log messages that get created will never be seen with human eyes. These logs get aggregated into metrics, then compressed, and (in many cases) eventually thrown away. Different companies have different sensitivity around their logs, so some companies may not garbage collect any of their logs! When a problem occurs in our infrastructure, we need to be able to dig into our terabytes of log data and quickly find the root cause of a problem. If our log data is compressed and stored on disk, it will take longer to access it. But if we keep all of our logs in memory, it could get expensive. To review: if I want to build a logging system from scratch today I need to build: a metrics pipeline for converting log data into monitoring data; a complicated caching system, a way to store and compress logs; a query engine that knows how to ask questions to the log storage system; a user interface so I don’t have to inspect these logs via command line… The list of requirements goes on and on—which is why there is a huge industry around log management. And logging keeps evolving!  One example we covered recently is distributed tracing, which is used to diagnose requests that travel through multiple endpoints. After Steve Newman left Google, he started Scalyr, a product that allows developers to consume, store, and query log messages. I was looking forward to talking to Steve about data engineering, and the query engine that Scalyr has architected, but we actually spent most of our conversation talking about the early days of Writely, and his time at Google—particularly the operational challenges of Google’s infrastructure. Full disclosure: Scalyr is a sponsor of Software Engineering Daily. The post High Volume Logging with Steve Newman appeared first on Software Engineering Daily.

Google Docs is used by millions of people to collaborate on documents together. With today’s technology, you could spend a weekend coding and build a basic version of a collaborative text editor. But in 2004 it was not so easy. In 2004 Steve Newman built a product called Writely, which allowed users to collaborate on documents together. Initially, Writely was hosted on a single server that Steve managed himself. All of the reads and writes to the documents went through that single server. Writely rapidly grew in popularity, and Steve went through a crash course in distributed systems as he tried to keep up with the user base. In 2006, Writely was acquired by Google, and Steve spent his next four years turning Writely into Google Docs. Eventually he moved onto other projects within Google—“Cosmo” and “Megastore Replication.” When Steve left the company in 2010, he took with him the lessons of logging and monitoring that keep Google’s infrastructure observable. Large organizations have terabytes of log data to manage. This data streams off the servers that are running our applications. That log data gets processed in a “metrics pipeline” and turned into monitoring data. Monitoring data aggregates log data in a more presentable format. Most of the log messages that get created will never be seen with human eyes. These logs get aggregated into metrics, then compressed, and (in many cases) eventually thrown away. Different companies have different sensitivity around their logs, so some companies may not garbage collect any of their logs! When a problem occurs in our infrastructure, we need to be able to dig into our terabytes of log data and quickly find the root cause of a problem. If our log data is compressed and stored on disk, it will take longer to access it. But if we keep all of our logs in memory, it could get expensive. To review: if I want to build a logging system from scratch today I need to build: a metrics pipeline for converting log data into monitoring data; a complicated caching system, a way to store and compress logs; a query engine that knows how to ask questions to the log storage system; a user interface so I don’t have to inspect these logs via command line… The list of requirements goes on and on—which is why there is a huge industry around log management. And logging keeps evolving!  One example we covered recently is distributed tracing, which is used to diagnose requests that travel through multiple endpoints. After Steve Newman left Google, he started Scalyr, a product that allows developers to consume, store, and query log messages. I was looking forward to talking to Steve about data engineering, and the query engine that Scalyr has architected, but we actually spent most of our conversation talking about the early days of Writely, and his time at Google—particularly the operational challenges of Google’s infrastructure. Full disclosure: Scalyr is a sponsor of Software Engineering Daily. The post <a href="https://softwareengineeringdaily.com/2017/12/15/high-volume-logging-with-steve-newman/" rel="nofollow" target="_blank">High Volume Logging with Steve Newman</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

High Volume Logging with Steve Newman

Varun Talwar

The service mesh abstraction allows for a consistent model for managing and monitoring the different components of a microservices architecture.  In the service mesh pattern, each service is deployed with a sidecar container that contains a service proxy. These sidecars are collectively referred to as the “data plane.” Each sidecar provides the service that it is deployed next to with a set of features such as security policy, rate limiting, and monitoring instrumentation. The sidecars in the data plane communicate with a central module called a control plane. In the control plane, an engineer can operate across these individual services at scale, by pushing out updates to them. Kubernetes has made it easier to manage large fleets of microservices, and has led to wider adoption of service mesh. Istio is one of the most popular service mesh products. In today’s show, Varun Talwar returns to the show to describe the state of the Istio project and the process of deploying Istio to a cluster. Varun is the CEO of Tetrate, a company building an enterprise-ready service mesh. Prior to Tetrate, Varun was at Google, where he helped found the gRPC and Istio projects. Sponsorship inquiries: sponsor@softwareengineeringdaily.com ANNOUNCEMENTS  FindCollabs is a place to find collaborators and build projects. We recently launched GitHub integrations. It’s easier than ever to find collaborators for your open source projects. And if you are looking for some people to start a project with, FindCollabs we have topic rooms that allow you to find other people who are interested in a particular technology, so that you can find people who are curious about React, or cryptocurrencies, or Kubernetes, or whatever you want to build with. Podsheets is an open source podcast hosting platform that we recently launched. We are building Podsheets with the learnings from Software Engineering Daily, and our goal is to be the best place to host and monetize your podcast. If you have been thinking about starting a podcast, check out podsheets.com.  New SEDaily app for iOS and for Android. It includes all 1000 of our old episodes, as well as related links, greatest hits, and topics. You can comment on episodes and have discussions with other members of the community. I’ll be commenting on each episode, so if you hear an episode that you have some commentary on, jump onto the app, or on SoftwareDaily.com to share your thoughts. And you can become a paid subscriber for ad free episodes at softwareengineeringdaily.com/subscribe. Altalogy is the company who has been developing much of the software for the newest app, and if you are looking for a company to help you with your mobile and web development, I recommend checking them out.     The post Service Mesh Deployment with Varun Talwar appeared first on Software Engineering Daily.

The service mesh abstraction allows for a consistent model for managing and monitoring the different components of a microservices architecture.  In the service mesh pattern, each service is deployed with a sidecar container that contains a service proxy. These sidecars are collectively referred to as the “data plane.” Each sidecar provides the service that it is deployed next to with a set of features such as security policy, rate limiting, and monitoring instrumentation. The sidecars in the data plane communicate with a central module called a control plane. In the control plane, an engineer can operate across these individual services at scale, by pushing out updates to them. Kubernetes has made it easier to manage large fleets of microservices, and has led to wider adoption of service mesh. Istio is one of the most popular service mesh products. In today’s show, Varun Talwar returns to the show to describe the state of the Istio project and the process of deploying Istio to a cluster. Varun is the CEO of Tetrate, a company building an enterprise-ready service mesh. Prior to Tetrate, Varun was at Google, where he helped found the gRPC and Istio projects. Sponsorship inquiries: <a href="mailto:sponsor@softwareengineeringdaily.com">sponsor@softwareengineeringdaily.com</a> <h2>ANNOUNCEMENTS</h2> <ul> <li><a href="https://findcollabs.com/" rel="nofollow" target="_blank">FindCollabs</a> is a place to find collaborators and build projects. We recently launched GitHub integrations. It’s easier than ever to find collaborators for your open source projects. And if you are looking for some people to start a project with, FindCollabs we have topic rooms that allow you to find other people who are interested in a particular technology, so that you can find people who are curious about React, or cryptocurrencies, or Kubernetes, or whatever you want to build with.</li> <li><a href="http://podsheets.com" rel="nofollow" target="_blank">Podsheets</a> is an open source podcast hosting platform that we recently launched. We are building Podsheets with the learnings from Software Engineering Daily, and our goal is to be the best place to host and monetize your podcast. If you have been thinking about starting a podcast, check out <a href="http://podsheets.com" rel="nofollow" target="_blank">podsheets.com</a>. </li> <li><a href="https://itunes.apple.com/us/app/software-engineering-daily/id1253734426?mt=8" rel="nofollow" target="_blank">New SEDaily app for iOS</a> and for <a href="https://play.google.com/store/apps/details?id=com.koalatea.sedaily" rel="nofollow" target="_blank">Android</a>. It includes all 1000 of our old episodes, as well as related links, greatest hits, and topics. You can comment on episodes and have discussions with other members of the community. I’ll be commenting on each episode, so if you hear an episode that you have some commentary on, jump onto the app, or on <a href="https://www.softwaredaily.com/" rel="nofollow" target="_blank">SoftwareDaily.com</a> to share your thoughts. And you can become a paid subscriber for ad free episodes at <a href="https://softwareengineeringdaily.com/subscribe" rel="nofollow" target="_blank">softwareengineeringdaily.com/subscribe</a>. <a href="http://altalogy.com" rel="nofollow" target="_blank">Altalogy</a> is the company who has been developing much of the software for the newest app, and if you are looking for a company to help you with your mobile and web development, I recommend checking them out.   </li> </ul> The post <a href="https://softwareengineeringdaily.com/2019/08/14/service-mesh-deployment-with-varun-talwar/" rel="nofollow" target="_blank">Service Mesh Deployment with Varun Talwar</a> appeared first on <a href="https://softwareengineeringdaily.com" rel="nofollow" target="_blank">Software Engineering Daily</a>.

Service Mesh Deployment with Varun Talwar

The best podcast episodes on parenting. Interviewing experts and talking through common issues surrounding parenting. This topic is filled with important lessons and insights for anyone listening. Add episodes you're interested into your queue below!

OwlTail

Best Parenting Podcasts

The best self improvement podcast episodes. From improving productivity, to finding purpose in your life to what constitutes freedom, this topic is on anything and everything that can help people to improve their lives. Add episodes you're interested into your queue below!