The InfoQ Podcast

In this podcast, Johnny Boursiquot, Site Reliability Engineer at Heroku, sat down with InfoQ podcast co-host Daniel Bryant and discussed topics that included: why Go is a useful language for building Function-as-a-Service (FaaS) style applications; how Heroku implement the role of Site Reliability Engineer (SRE); and why the ability to teach is such a valuable skill. Why listen to this podcast: - Go is a useful language for building Function-as-a-Service (FaaS) style applications. The ability to build Go applications into a static binary reduces the need for dependency management, and the quick runtime and application start time is good for initiation and scaling - The FaaS development toolchain has improved over the years. Many cloud providers now provide local runtimes, e.g. AWS SAM Local, and service simulators, e.g. LocalStack. Testing in production is facilitated by the ability to do dark launches and canary releasing at the ingress/API gateway - Developing “serverless” applications typically does not remove the need for operational expertise on a development team. Designing systems appropriately and getting the most out of the runtime (with minimal cost) requires knowledge of the underlying infrastructure components - The role of Site Reliability Engineering (SRE) looks different across practically every organisation. The Heroku SRE team have adapted well-established patterns and practices into their roles. They act as “diplomats”, working closely with product teams to share knowledge around operational best practices - The ability to teach is a valuable skill, regardless of your job. Teaching people to code or to embrace important operational principles is extremely rewarding. - Engineers who teach must seek to escape the pull of their ego; by focusing on the needs of the people you are teaching, much more progress can be made. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2UV0tqK You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2UV0tqK

In this podcast, Matt Debergalis, Founder and CTO at Apollo, sat down with InfoQ podcast co-host Daniel Bryant. Topics discussed included: the motivations for GraphQL, the Apollo Data Graph platform, data modelling in an enterprise context, and how incrementally adopting GraphQL can help with decoupling the evolution of frontend and backend systems. Why listen to this podcast: - The challenges of defining client-side-friendly data models, building maintainable and composable backend APIs, and moving data from the cloud to a client application contributes to making modern software development difficult and time consuming. - GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data. GraphQL lets application developers describe the data they need and bring that data into the screens that they are building for their users. - The Apollo Data Graph platform is a middleware layer that provides a way of decoupling the core business APIs from the client-side consumption patterns. Apollo can implement cross-cutting concerns, such as transaction management, which mitigates the need to implement this in (potentially multiple) client-side applications. - Apollo makes it possible to build a “data graph”: a series of graphs that are composed from an organisation’s data for use within client-side applications. A data graph is especially valuable in larger enterprises because it is here that many (money making) systems with existing APIs need to be combined to meet new business requirements. - GraphQL can be adopted in an incremental fashion. To begin adoption just build the simplest possible graph that matches the needs of the first application, the first screen, or the first component that is required to transition over to the graph. Then let that graph evolve. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/3fhaeqP You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/3fhaeqP

In this podcast, Lin Sun, senior technical staff member and master inventor at IBM, and Neeraj Poddar, engineering lead and architect at Aspen Mesh, sat down with InfoQ co-host Daniel Bryant. Topics discussed included: the evolution of service mesh data planes and control planes, the new Istio 1.5 architectures, Istio WebAssembly extension support, and the future of service mesh technology. Why listen to this podcast: - A service mesh in one implementation approach to provide service discovery, traffic management, and cross-cutting communication concerns that engineers see when they adopt (micro)service-based. - The data plane of most modern service mesh implementations run out-of-process as a proxy sidecar. This has evolved from library based implementations, such as Airbnb’s SmartStack or Netflix’s OSS libraries. - The recent release of Istio 1.5 saw the deployment packaging of the control plane move from a microservice-based approach to that of a monolithic implementation, named “istiod”. - Istio now also supports data plane extensions written in WebAssembly (Wasm). These extensions can modify requests and responses and perform out-of-band actions, such as authentication and authorization. - Standardisations like the Service Mesh Interface (SMI) can add a lot of value, but the user requirements, common use cases, and the core abstractions of the underlying technology must be well understood. - Multi-cluster and mesh expansion (out-of-cluster) support is continually improving in Istio and many other service mesh implementations.

Today on the InfoQ Podcast, Wes Reisz talks with one of the thought leaders in Microservices, CI/CD, and Cloud -- Sam Newman. The podcast covers many of the topics, techniques, and patterns that Sam writes about in his latest book, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith. Topics covered in the podcast include understanding the problem you’re trying to solve, organizational/people changes when it comes to microservice architectures, database strategies for decomposing monolithic datastores, and why we’re seeing projects reverting from microservices to monoliths. Why listen to this podcast: - Fundamentally, microservices are distributed systems. Distributed systems have baggage (complexity) that comes along with them. The best way to deal with this complexity is not to address it. Try to solve the problem in other ways before choosing to take an organization to microservices. - A common issue that large enterprises run into that might be a strong indicator for implementing microservices occurs when lots of developers are working on a given problem and they’re getting in each other’s way. - A useful structure to follow with microservices is to make sure each service is owned by exactly one team. One team can own more than one service but having clear ownership of who owns a service helps in some of the operational challenges with microservices. - A release train should be a stop in the journey towards continuous delivery. It’s not the destination. If you find that you can only release in a release train, you are likely building a distributed monolith. - There are challenges of operating microservices when the end customer has to operate and manage it. These challenges are part of why we’re seeing projects move from microservices to process monoliths. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2XvGzmF You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2XvGzmF

In this podcast, Tracy Miranda sat down with InfoQ podcast co-host Daniel Bryant. Miranda, Director of Open Source Community at CloudBees, and board chair at the Continuous Delivery Foundation (CDF), discussed topics that included: the aims of the CDF and an outline of the current hosted projects, the need for open standards and interoperability in the CD space, and the benefits offered by progressive delivery and software supply chain management. Why listen to this podcast: - The Continuous Delivery Foundation (CDF) serves as the vendor-neutral home of many projects within continuous delivery space, including: Jenkins, Jenkins X, Spinnaker, Tekton, and Screwdriver.cd - Jenkins X is a Kubernetes-native continuous delivery solution for cloud applications. This project uses a completely new architecture and code base in comparison with the original Jenkins project. - Spinnaker is an open source, multi-cloud continuous delivery platform. The Tekton Pipelines project provides Kubernetes-style custom resources for declaring continuous integration and delivery pipelines. Spinnaker can use Tekton as its pipeline engine. - In addition to providing a neutral home for projects within the CD space, the CDF is also aiming to help define appropriate terminology, open standards, and abstractions. This will assist with interoperability between CD components, and also promote innovation in the areas that can provide the most value. - The CDF is also aiming to facilitate software testing, progressive delivery, and software supply chain management. Wide ranging topics such as observability and security are important will play an important role here. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/3bzoYiz You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/3bzoYiz

In this podcast, Marty Abbott and Tanya Cordrey sat down with InfoQ podcast co-host Daniel Bryant. Abbott, CEO and co-founder of AKF Partners, and Cordrey, partner at AKF Partners, discussed topics that included: their learning from working together in the early days of eBay, why and how to avoid creating software systems that are composed of deep call chains of microservices, and how to build effective product teams. Why listen to this podcast: - First introduced in the book “The Art of Scalability”, the AKF Scale Cube is a model for segmenting software components, defining microservices, and scaling products. It also creates a common language for teams to discuss scale related options in designing solutions. - The microservice architectural pattern is best used for implementing the “breadth” of business functionality. Engineers should avoid building deep call chains of services, as this can increase the probability of failure, and can also increase the challenges of locating and diagnosing issues. Code libraries can often be used more effectively to implement “depth” within services. - The AKF Availability Cube is a new model to guide discussions on how to achieve high availability. This model can also be used as a mathematical tool to evaluate the theoretical “as designed” availability of existing systems. - Building products using cross-functional teams is an effective approach. However, care should be taken not to accidentally create unnecessarily large teams, as this can add communication and coordination friction to the delivery process. - Teams should make a conscious choice to adopt new technologies, and understand the benefits and tradeoffs with doing so. Managing risk, and in particular, technology lifespan risk, is an important part of the value engineers provide to the business. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2AbpZjT You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2AbpZjT

In this podcast, Daniel Bryant sat down with Dave Sudia, senior DevOps engineer at GoSpotCheck. Topics discussed included: the benefits of PaaS; building a platform with Kubernetes as the foundation; selecting open source components and open standards in order to facilitate the evolution of a platform; and why care should be taken to prioritize the developer experience and create self-service operation of the platform. Why listen to this podcast: - When starting a business and searching for product-market fit, creating an application using a monolithic code base deployed onto a commercial Platform as a Service (PaaS) product is a very effective way of iterating fast and minimising operational costs. - There may come a point where the PaaS cannot provide bespoke requirements, or it has trouble scaling, or the costs become prohibitive. At this point many teams choose to build a custom platform using cloud technologies, such as Kubernetes. - Building a Kubernetes platform can be an effective solution, but appropriate effort needs to be put into designing, building, and maintaining the platform. The platform effectively becomes another product within the business that must be managed accordingly. - Embracing open standards provides many benefits, especially for the long term. Implementations that are consumed through well-defined interfaces and abstraction can be more readily swapped at a later point in time. It is also generally easier to integrate components that share common interfaces. - Attention and resources must be provided to create an effective developer experience for the platform. It is essential to prioritize self-service operations, and also to understand the core requirements of the engineers and QA specialists that will be using the platform during their daily work. - Establishing an effective continuous delivery pipeline can enable more repeatable and scalable testing of applications, and also allows the codification of cross-functional requirements. - The cloud native landscape has now evolved to a point where most of the frameworks and tooling required to build a platform have become viable for general purpose usage. However, some assembly may still be required, and engineers should be prepared for change, as the ecosystem moves fast. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/3bj3BTp You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/3bj3BTp

Today on The InfoQ Podcast, Wes Reisz talks with Peter Bourgon. Peter is a distributed system engineer working on Fastly. His area of interest is around coordination free replicated systems. The two engineers talk about the space of Conflict-Free Replicated Data Types (CRDTs) specifically in the context of edge compute. Topics covered on the podcast include Edge compute, CRDTs, CAP Theorem, and challenges around building distributed systems. Why listen to this podcast: - CRDTs (conflict-free replicated data types) are a class of coordination free replication systems (or systems that don’t require strategies such as leader election). - An easy way to think of a CRDT is as an associative, commutative, and idempotent data structure plus the operations needed to use it. The edge is an overloaded term that people tend to define based on where they sit on a spectrum between the customer and the data center. Fastly’s edge is away from the data center and but not to the telephone pole or handset. - RAFT and Gossip are two alternative approaches to using a coordination free replication system like CRDTs. To get the properties of a CRDT and have useful data types, you have to pay a cost in size and often bytes on the wire. These are challenges that continue to need solutions. - Modern Distributed systems and data structures like CRDTs require you to start thinking about state in the system itself. It’s not unusual for a system today to give you multiple results back that the system will have to handle or merge. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/3dTZOO4 You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/3dTZOO4

In this podcast, Daniel Bryant sat down with Joe Duffy, founder and CEO at Pulumi, and discussed several infrastructure-themed topics: the evolution of infrastructure as code (IaC), the way in which the open source Pulumi framework allows engineers to write IaC using general purpose programming languages such as JavaScript and Go, and the future of multi-cloud environments. Why listen to this podcast: ● Infrastructure as Code (IaC) enables engineers to programmatically define the configuration and provisioning of computing infrastructure, on-premises hardware, and cloud services. ● Traditional IaC tools were often imperative, requiring engineers to define and enumerate the necessary steps and SDK calls in order to configure the underlying infrastructure. ● Modern IaC tools like HashiCorp’s Terraform, AWS CloudFormation and other related cloud vendor tooling enable engineers to write declarative code to define a required state of the infrastructure. The tools parse the declarative configuration and take appropriate action to enact the specified state, for example, calling SDKs and APIs, verifying results, iterating etc. ● Pulumi is an open source framework that enables engineers to define IaC using general purpose programming languages, such as Node, Python, .NET Core, and Go. ● Pulumi allows imperative specification of IaC. Engineers can use their favourite language-specific features, idioms, and patterns. The use of language modules, packages, and libraries can also enable code reuse. ● Under the hood, Pulumi transforms code written in the supported languages to a declarative specification model. This model is then used to enact the required infrastructure state. ● Frameworks like Pulumi enable engineers to deploy and configure infrastructure across multiple cloud vendors and services (including Kubernetes clusters). More on this: Quick scan our curated show notes on InfoQ https://bit.ly/3dyxVee You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/3dyxVee

In this podcast Charles Humble spoke to Dylan Schiemann, co-creator of Dojo and InfoQ’s JavaScript and Web Development lead editor, about the history and current state of Dojo, and key emerging trends in the JavaScript landscape today. Key topics include Dojo’s adoption of Typescript, web components, and client-side libraries such as Svelte and Stencil. Why listen to this podcast: - Modern Dojo (2.0 and upwards) is focussed on being a very small, opinionated reactive framework, but with a lot of the components you need to build a modern JavaScript application built in. - The framework tries to align closely to standards, for example using Web Components extensively for UI components, alongside ES modules and promises. The use of standards, as well as the convergence towards the reactive programming model for web UI, has improved interoperability, though there are some limitations such as the lack of an easy way to share resources across web components. - Dojo was one of the first frameworks to make the decision to switch to Typescript, though it took some time to make that transition. The switch was mainly motivated by TypeScript’s support for interfaces, but it wasn’t until Typescript 2.6 they felt able to ship Dojo 2. - On the client side we’re paying close attention to Svelte and Stencil as two particularly interesting client-side frameworks. - We’ve moved Web Components from early adopter to early majority on the trend report, based on the fact that all browsers accept IE now natively support it, but also large companies such as Apple, Nike and ESPN are deploying web components and their sites. Apple’s iTunes implementation, for example, now uses web components. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2Qy75Jr You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2Qy75Jr