Software Engineering Daily

Market strategy defines how a company is positioning itself to be successful. This strategy encompasses engineering, sales, marketing, recruiting, and everything else within a company. Herb Cunitz has led teams at Hortonworks, VMware, SpringSource, and several other companies over his 30 year career in software. After working as president of Hortonworks, Herb started AccelG2M. AccelG2M works with software companies to define their go-to-market strategy. Software companies require a great deal of long-term strategic thinking. Engineering, sales, marketing, and leadership must work together to build a plan that will allow the company to reach an exit: either an acquisition or an IPO. Executives at a software company must create a clear strategy and communicate it to the employees throughout the organization. The strategy must be implemented, meeting deadlines and hitting milestones. New team members must be recruited, and unsuccessful workers must be let go. In today’s show, Herb provides some invaluable strategic wisdom for anyone working in software–whether you are an engineer, salesperson, or investor.

Software companies today rely on group chat applications. The world of startups and small businesses is dominated by Slack. But for some large enterprises, regulatory constraints prevent them from using Slack. Slack is a web application that is hosted in the cloud, and regulated industries such as banking often need to run their applications on their own on-prem infrastructure. Mattermost is an open source alternative to Slack that can be self-hosted. This means that all of the networking complexities and scalability challenges that are controlled in the cloud by Slack need to be handled by open source code rather than managed services running in the cloud. Because it is open source, Mattermost can also be redesigned and customized. Uber designed their own custom version of Mattermost called uChat. Corey Hulen is a co-founder and the CTO of Mattermost. He joins the show to discuss the motivation for building Mattermost and the engineering challenges of building an open source chat system. For more episodes about building chat systems, we’ve done several shows about Slack, covering the engineering, security, and chat system.

Wes Bos has created popular courses on React, GraphQL, and JavaScript. With hundreds of thousands of students, Wes has earned a cult following for his fun, practical lessons on web development. The courses produced by Wes teach developers how to build useful applications such as a complete e-commerce store. Wes has built a career around studying and evangelizing JavaScript. His approach to education centers around practice, repetition, and hacking on fun projects. He also co-hosts a podcast called SyntaxFM, and is a frequent Twitter user. Wes is a rare mix of developer, teacher, businessman, and designer. Throughout his work, there is an artist’s sense of attention to detail, and a modern entrepreneur’s sense of pricing and marketing. His sites, such as JavaScript30 and React For Beginners have the deliberate style of someone who has been building websites for a very, very long time.In today’s episode, Wes Bos joins the show to give his perspective on JavaScript, entrepreneurship, and podcasting. To learn more about Wes’s business and his background, check out the IndieHackers podcast with him.

A bank account is a platform for apps to be built on top of. If that sounds like a weird idea, think about the features of a bank account. Most users only have a single bank account, making it a tool for identity and authentication. The series of transactions in a bank account provides a data set that can be used for analyzing payment history and issuing loans, or insurance. But there are difficulties to building a platform on top of banking. There are thousands of different banks. If you want to build an application that integrates with a user’s bank, you need to be able to integrate with any bank that the user might use–whether it’s Bank of America, Wells Fargo, or Chase. Plaid is a company that builds APIs for users to connect to banks. Applications such as Venmo, Betterment, and Coinbase use Plaid to connect with the bank accounts of their users. Jean-Denis Greze joins the show to explain how applications use Plaid, and how Plaid has scaled its infrastructure to handle a high volume of requests. He also discusses the potential of banking as a platform, and the strategy for expanding the APIs that Plaid can offer to developers. Fintech Daily is a new podcast from Software Engineering Daily covering payments, cryptocurrencies, trading, and the intersection of finance and technology. We are looking for volunteer hosts for Fintech Daily, and if you are interested in working with us to conduct interviews, send an email to [email protected]. You can find the podcast on iTunes, Google, and everywhere else, and if you are interested in hosting, don’t hesitate to reach out.

When a startup finds product market fit, the adoption of that product can grow rapidly, turning a startup into a high growth company. All of a sudden, a startup that was struggling to find its first customer is bombarded with new challenges. The startup has to hire tens of new employees. This requires raising capital, so the startup has to meet with investors and lawyers. A rapid influx of new customers puts a strain on the engineering and customer service elements of the company. There is too much to do, and there is only so much time in a day. The CEO of the high-growth company is up late into the night, answering emails and losing sleep. But these are good problems to have, and the company is in a state of exuberance. The CEO must balance psychological health with the stressful task of scaling a company. Elad Gil is an entrepreneur and author of “High Growth Handbook”, a book of lessons and guidelines about how to navigate a startup that has found product market fit, and is beginning to scale. High Growth Handbook includes interviews with experienced entrepreneurs such as Marc Andreessen and Patrick Collison, whom Elad met with as he wrote the book. Elad joins the show to discuss his book, and his own personal lessons of working with companies such as Twitter, Google, Stripe, and Coinbase. Elad has worked at several high growth companies and invested in others, and he has gathered a lot of wisdom from these different experiences.

Releasing software has inherent risk. If your users don’t like your new feature, they might stop using your product immediately. If a software bug makes it into production, it can crash your entire application. Releasing software gradually has many benefits. A slow rollout to an increasing population of users allows you to test your software in multiple real-world environments before it goes live to everyone. A system of AB testing different versions of your software lets you see how different flavors of your software perform against similar audiences. Edith Harbaugh is the CEO of LaunchDarkly, a system for feature management. LaunchDarkly allows developers to deploy new software releases in a controlled fashion. Edith joins the show to discuss how to implement feature flagging, and why an intelligent release process can lead to a more scientific, predictable environment for software development. Edith is also the host of To Be Continuous, a podcast about continuous delivery, software engineering, and DevOps.

The Berkeley AMPLab was a research lab where Apache Spark and Apache Mesos were both created. In the last five years, the Mesos and Spark projects have changed the way infrastructure is managed and improved the tools for data science. Because of its proximity to Silicon Valley, Berkeley has become a university where fundamental research is blended with a sense of industry applications. Students and professors move between business and academia, finding problems in industry and bringing them into the lab where they can be studied without the day-to-day pressures of a corporation. This makes Berkeley the perfect place for research around “serverless”. Serverless computing abstracts away the notion of a server, allowing developers to work at a higher level and be less concerned about the problems inherent in servers–such as failing instances and unpredictable network connections. With serverless functions-as-a-service, the cloud provider makes guarantees around the execution of serverless code–such as with AWS Lambda. With serverless backend services, the cloud provider makes guarantees around the reliability of a database or queueing system. The cloud provider is operating servers to power this functionality. But the user is not exposed to those servers. Today’s show centers around the serverless functions-as-a-service. This is a new paradigm of computing, and there are many open questions. How can the servers for our functions be quickly provisioned? How can we parallelize batch jobs into functions as a service? How can large numbers of serverless functions communicate with each other reliably to coordinate? In production applications, functions-as-a-service are mostly used for “event-driven” applications. But the potential for functions-as-a-service is much larger. Ion Stoica is a professor of computer science at Berkeley, where he leads the RISELab. He is the co-founder of Conviva Networks and Databricks. Databricks is the company that was born as a result of the research on Apache Spark. Ion now serves as executive chairman of Databricks. Ion joins the show to describe why serverless computing is exciting, the open research problems, and the solutions that researchers at the RISELab are exploring.

Robotics, genomics, and backend infrastructure: as an in vestor, it can be difficult to assess the viability of a startup that is on the cutting edge in any of these areas. A robotics startup requires a team with an integrated understanding of hardware and software. A genomics company will not only have to develop a successful healthcare product, but will have to bring it to market through regulation. And in the world of backend infrastructure, building a business that will be differentiated from giant cloud providers gets harder every day. Amplify Partners is a venture capital fund with an emphasis on technical investments. Their portfolio includes infrastructure companies like Datadog and Gremlin, as well as pharmaceutical and hardware companies. Sunil Dhaliwal is the founder of Amplify Partners, and joins the show to discuss the thesis of Amplify. The investments that Amplify makes are in technical companies–which makes these financing decisions complex enough to require detailed, individualized research. But there are commonalities among the founding teams. Sunil lays out a useful rubric for anyone who is looking to learn about venture capital investing.

Building software was simplified by cloud providers. With the cloud, it became much easier to deploy a server, spin up a database, and scale an application. Cloud providers like AWS gave developers access to these infrastructure primitives like storage and compute. On top of those primitives, numerous API companies have been built. An API company offers a more specific set of services. Twilio offers SMS text messaging API services. Stripe offers payment API services. These APIs give developers another level of tooling to build software out of. Developers can now think of entire applications in terms of APIs, and the number of APIs is growing rapidly. From business services such as booking a flight to machine learning models like image classification, the “API economy” has given developers a huge catalog of tools. Since developers have this additional leverage, software can be built with smaller teams. The codebase can also be smaller. But one area where the complexity is growing is the number of APIs that need to be managed. For each API, there is a different system for integrating the API into your application. Different API providers have different levels of reliability. Another area of difficulty is the discoverability of APIs. If I don’t know about a flight search API, I am never going to think of what applications I could build on top of that. There are APIs for generating memes, and APIs for easily querying what music is trending across the world. RapidAPI is a marketplace for APIs. It includes search and discovery features for the wide variety of different APIs that can be found across the internet. RapidAPI is also a system for integrating with multiple APIs through it’s API management system. Iddo Gino is the CEO and founder of RapidAPI, and he joins the show to discuss the motivation for creating an API marketplace, as well as the engineering behind RapidAPI.

The Bitcoin main chain is a large distributed ledger of transactions. Bitcoin is useful for maintaining a trusted record of payments, but is not practical for small day-to-day payments. Bitcoin payment channels allow users to issue small payments to each other without paying the high transaction cost and latency of going through the main chain. When payment channels are connected to each other, a “lightning network” is formed. Lightning network is often referred to as a “second layer” scalability solution. Alex Bosworth is a lightning infrastructure lead at Lightning Labs, a company that builds infrastructure for scaling blockchains. In today’s show, Alex explains how Bitcoin payment channels work, and provides some context on how developed the modern infrastructure is in terms of practical use cases for Bitcoin.

Demand for live streaming video over the internet is increasing. After the emergence of early live streaming platforms, like Twitch and Facebook Live, more forms of video have become accessible over live streams, such as sports. Live streaming is a harder engineering problem than delivering a static video file because the information distributed on a live stream is constantly changing. DZN, spelled D-Z-N, is a live streaming service for watching fight events, such as boxing. The workloads for live streaming can be highly bursty. When a fight is scheduled to happen, the vast majority of traffic will hop on to watch the fight 20 seconds before the fight starts. A huge number of users logs into DZN and starts watching all at the same time. This quick spike in traffic means that DZN has to have servers spun up and be ready in advance. Luca Mezzarlira and Yan Cui are engineers at DZN. Yan was previously on the show in a few amazing episodes to talk about serverless infrastructure and the complexities of real-time video game software development. Those episode links are in the show notes. I highly recommend checking them out. Today’s show is a discussion of architecting a system to handle a high bandwidth customer use case. I hope you like it.

Not every company wants to move to the public cloud. Some companies have already built data centers, and can continue to operate their business with their own servers. Some companies have compliance issues with the public cloud, and want to operate their own servers to avoid legal risk. Operating a data center is not easy. Operating systems need to be updated and security vulnerabilities need to be patched. Servers fail, and their workloads need to be automatically scheduled onto other servers to avoid downtime. In contrast to classic on-prem data center management, the cloud provides many benefits: automatic updates, an infinite pool of resources, fully programmable infrastructure as code. In the cloud, developers can provision infrastructure with an API request. Continuous delivery pipelines can be spun up at the click of a button. This tooling makes it dramatically easier for developers to move quickly, and for a business to move faster. Companies that operate their own data center want to be able to have these benefits of the cloud while still controlling their own infrastructure. Today’s guest Bob Fraser works at HPE on OneView, a tool for managing on-prem infrastructure like a cloud. Bob describes the difficulties of managing legacy on-prem infrastructure, and the advantage of building a management layer on top of data center infrastructure to make it more programmable. We’ve done lots of shows recently about Kubernetes in the context of cloud computing. Today’s show outlines how modern on-prem infrastructure can be managed like a cloud. Full disclosure: HPE is a sponsor of Software Engineering Daily.

Podcasts have surged in popularity, but the podcast ecosystem remains difficult to work with. Podcast listeners have difficulty finding episodes. Podcast creators have difficulty finding out how to get started. The advertising marketplaces for podcasts are immature, and it can be difficult to build a business as a podcaster. Podcasting is unlike almost any other media format that we consume on the Internet. There is not an algorithmic feed of podcasts–we subscribe to podcasts we like and we see everything that gets published. Podcasting originated with Apple, who has not shown much interest in the podcast medium. Anchor is a platform that makes it easy for users to publish podcasts. Today, a large percentage of the new podcasts created on the Internet are started on Anchor. Nir Zicherman is the CTO at Anchor, and he joins the show to discuss the strange world of podcast technology, and how Anchor is building a business.

Cloud computing changed the economics of running a software company. Before the cloud, a software company had to purchase physical machines which often required thousands of dollars paid up front. The cloud allowed developers to deploy their applications for free, to operate a business for cheap, and to scale without hiring a dedicated team to manage the servers. Building in the cloud is cheap, but scaling in the cloud can get expensive. A growing company can often save money by changing which cloud instances and services they use. Reducing the number of server instances, changing the size of compute instances, and changing rules around auto scaling. By using monitoring, dashboards, and regular analysis of where money is spent, a business can find thousands of dollars of wasted spend per month. There are also broad strategic decisions around cost. One area to study is the use of “managed” services like Amazon DynamoDB, Google BigQuery, and Amazon Lambda. These services are proprietary, and can lead to lock-in. Sometimes they can be quite expensive. But they can save developers hours of time because they are easy to use, and provide high uptime guarantees. Ran Rothschild works at DoIT International, a company that helps businesses figure out how to save money on their cloud infrastructure. He joins the show to discuss the places where the most money is wasted and how startups can manage their infrastructure in a cost-effective manner. He also tells some stories about significant overspend. Full disclosure: DoIT International is a sponsor of Software Engineering Daily.

Slack is a real-time messaging system for work communication. On Slack, chat rooms as big as 100,000 people have productive conversations. This might sound like the same problem solved by social networks like Facebook, where billions of users communicate over a newsfeed. But the engineering constraints of a messaging system are different than that of a social network. On a newsfeed, the order in which events appear is not chronological. Events can be out of order. You can miss events. When a user posts a message to a social network, there are not strict guarantees around when other people will see that message. On Slack, messages have strong guarantees around arrival. When I send a message, everyone else who is in the room and connected should quickly receive that message as well. The messages need to be ordered and delivered exactly once. All messages on Slack are persisted. We have covered the architecture and security model of Slack in previous shows. In today’s show, Keith Adams returns to discuss how messages are processed and broadcast in Slack. The problem of Slack’s messaging system is similar to the distributed systems problem of “atomic broadcast”, in which a single process broadcasts a message which needs to be received by all other processes correctly–or else received by none of them. In Keith’s last show, he talked through the benefits of building a large system on PHP. He worked on infrastructure at Facebook, which was also a PHP application. It’s worth noting that both Slack and Facebook have scaled a monolithic architecture.

Many people have saved some money which they want to invest for the future. Some people are happy investing their money in a roboadviser, which programmatically puts money into long-term investments. Other people want a more personal approach involving a certified financial planner (CFP). A CFP is a human who allocates capital for an individual based off of that individual’s preferences. A CFP spends time and effort researching the options for a client. If the client only has a small amount of money (say, $15,000), it is not worth it for the CFP to spend much time on that account. As a result, there is a type of client who has saved a little bit of money, but has not saved enough to be an important client for a CFP. Facet Wealth is a software company that makes software for CFPs to work more effectively with their client accounts. Facet Wealth has in-house CFPs who work with this software to manage client accounts. In addition, Facet Wealth buys client accounts from independent CFPs who have small accounts which they do not have time to manage. This is an innovative way to aggregate users onto the platform. Gorkem Sevinc is CTO at Facet Wealth. He joins the show to describe the business and the software architecture of the company. We touched on many different areas–from human-computer interaction to the future of investing. We recently launched a new podcast: Fintech Daily! Fintech Daily is about payments, cryptocurrencies, trading, and the intersection between finance and technology. You can find it on fintechdaily.co or Apple and Google podcasts. We are looking for other hosts who want to participate. If you are interested in becoming a host, send us an email: [email protected]

Parity is a company that builds blockchain infrastructure. Parity has built several open source projects and works with enterprises to put blockchain technology in production. Gavin Wood is the founder of Parity, and he joins the show to talk about the state of blockchain technology and what his company is currently focused on. Four years ago, Gavin helped start the Ethereum project, so he has lots of context on decentralized technology. Gavin envisions a world with many different blockchains for many different use cases. These blockchains will interact with each other to enable trusted relationships between parties. One project that Parity has created is Substrate, a technology that allows developers to quickly stand up a blockchain with the right privacy level. Another project is Polkadot, which allows blockchains to connect and interoperate with each other. Gavin and I discussed why the world needs a variety of blockchains–and whether all of these different blockchains should need their own cryptocurrency. Gavin described the use case of blockchains for mediating supply chain trust. We also talked about the technologies used to build these projects, including WebAssembly and Rust.

Originally posted on June 23, 2016. Pieter Hintjens grew up writing software by himself. The act of writing code brought him great pleasure, but the isolated creative process disconnected him from the rest of the world. As his life progressed he became involved in open source communities, and he discovered a passion for human interaction. Open source software succeeds or fails on the strength of the community. One story of success is ZeroMQ, a popular open source distributed messaging system that was started by Pieter Hintjens. In this episode, Pieter gives his thoughts on human nature, distributed systems, and death. “A Protocol For Dying” is a blog post Pieter wrote recently, where he discussed his terminal diagnosis of cancer, and how it has reframed his perspective on life.

Originally posted on May 12, 2016. When you are deciding who to marry, you are using an algorithm. The same is true when you are looking for a parking space, playing a game of poker, or deciding whether or not to organize your closet. Algorithms To Live By is a book about the computer science of human decisions. It offers strategies for how to think through everyday life like a computer scientist. Brian Christian has a background in computer science and philosophy, and is an author of Algorithms to Live By. He joins the show to explain how the same algorithms and data structures we use for our computer programs can be applied to the real world.

Originally posted on May 12, 2015. Humans have now been defeated by computers at heads up no-limit holdem poker. Some people thought this wouldn’t be possible. Sure, we can teach a computer to beat a human at Go or Chess. Those games have a smaller decision space. There is no hidden information. There is no bluffing. Poker must be different! It is too human to be automated. The game space of poker is different than that of Go. It has 10^160 different situations–which is more than the number of atoms in the universe. And the game space keeps getting bigger as the stack sizes of the two competitors gets bigger. But it is still possible for a computer to beat a human at calculating game theory optimal decisions–if you approach the problem correctly. Libratus was developed by CMU professor Tuomas Sandholm, along with my guest today Noam Brown. The Libratus team taught their AI the rules of poker, they gave it a reward function (to win as much money as possible), and they told it to optimize that reward function. Then they had Libratus train itself with simulations. After enough training, Libratus was ready to crush human competitors, which it did in hilarious, entertaining fashion. There is a video from Engadget on YouTube about the AI competing against professional humans. In this episode, Noam Brown explains how they built Libratus, what it means for poker players, and what the implications are for humanity–if we can automate poker, what can’t we automate? Stay tuned at the end of this episode for the Indeed Prime tip on hiring developers.

Featured Image Photo Credits Originally posted on July 11, 2016. Negotiation is an important skill for software engineers. The salary you negotiate at the beginning of your job could be a difference of tens of thousands of dollars over the course of an engineer’s career, but intimidating recruiters and exploding offers scare many engineers from negotiating at all. Today, Haseeb Qureshi returns to the show to discuss his epic story of salary negotiation. On a previous episode, Haseeb discussed leaving his career as a poker player to join a coding boot camp and start down the path of a software engineer. In this episode and his recent blog post, Haseeb describes his approach to the job search and salary negotiation process, which eventually landed him at Airbnb with a $250,000 annual salary–after about a year of learning to code.

Originally published on July 6, 2016. Scheduling is the method by which work is assigned to resources to complete that work. At the operating system level, this can mean scheduling of threads and processes. At the data center level, this can mean scheduling Hadoop jobs or other workflows that require the orchestration of a network of computers. Adrian Cockcroft worked on scheduling at Sun Microsystems, eBay, and Netflix. In each of these environments, the nature of what was being scheduled was different, but the goals of the scheduling algorithms were analogous–throughput, response time, and cache affinity are relevant in different ways at each layer of the stack. Adrian is well-known for helping bring Netflix onto Amazon Web Services, and I recommend watching the numerous YouTube videos of Adrian talking about that transformation.

The volume of data in the world is always increasing. The costs of storing that data is always decreasing. And the means for processing that data is always evolving. Sensors, cameras, and other small computers gather large quantities of data from the physical world around us. User analytics tools gather information about how we are interacting with the Internet. Logging servers collect terabytes of records about how our systems are performing. From the popularity of MapReduce, to the rise of open source distributed processing frameworks like Spark and Flink, to the wide variety of cloud services like BigQuery: there is an endless set of choices for how to analyze gigantic sets of data. Machine learning training and inference is another dimension of the modern data engineering stack. Whereas tools like Spark and BigQuery are great for performing ad-hoc queries, systems like TensorFlow are optimized for the model training and deployment process. Stitching together these tools allows a developer to compose workflows for how data pipelines progress through a data engineering system. One popular tool for this is Apache Airflow, which was created in 2014 and is widely used at companies like Airbnb. Over the next few years, we will see a proliferation of new tools in the world of data engineering–and for good reason. There is a wealth of opportunity for companies to leverage their data to make better decisions, and potentially to clean and offer their internal data as APIs and pre-trained machine learning models. Today, there is a vast number of enterprises who are modernizing their software development process with Kubernetes, cloud providers, and continuous delivery. Eventually, these enterprises will improve their complex software architecture, and will move from a defensive position to an offensive one. These enterprises will shift their modernization efforts from “DevOps” to “DataOps”, and thousands of software vendors will be ready to sell them new software for modernizing their data platform. There is not a consensus for the best way to build and run a “data platform”. Nearly every company we have talked to on the show has a different definition and a different architecture for their “data platform”: Doordash, Dremio, Prisma, Uber, MapR, Snowflake, Confluent, Databricks… We don’t expect to have a concise answer for how to run a data platform any time soon–but on the bright side, data infrastructure seems to be improving. Companies are increasingly able to ask questions about their data and get quick answers, in contrast to the data breadlines that were so prevalent five years ago. Today we cover yet another approach to large scale data processing. Reflow is a system for incremental data processing in the cloud. Reflow includes a functional, domain specific language for writing workflow programs, a runtime for evaluating those programs incrementally, and a scheduler for dynamically provisioning resources for those workflows. Reflow was created for large bioinformatics workloads, but should be broadly applicable to scientific and engineering computing workloads. Reflow evaluates programs incrementally. Whenever the input data or the program changes, only the outputs that depend on the changes are recomputed. This minimizes the amount of recomputation that needs to be performed across a computational graph. Marius Eriksen is the creator of Reflow and an engineer at GRAIL. He joins the show to discuss the motivation for a new data processing system–which involves explaining why workloads in bioinformatics are different than in some other domains.

The software release process is a barrier between written code and a live production environment that affects users. A software release process can involve a variety of different practices. Code might be tested for bugs using automation and manual testing. Static analysis tools can look at the code for potential memory leaks. A software release might go out to a small percentage of the total user base before it gets deployed to the entire audience. At some organizations, a software release can be slow and painful. The release might be bottlenecked by a manual approval step, which slows down developers from quickly deploying their own changes. If a consistent version history of software is not maintained, a release can be hard to roll back in the event of an error. In the case of a large, monolithic architecture, a release can be scary, because it can be hard to understand how the monolithic codebase functions. This set of challenges within the release process lowers the quality of software, and can make it frustrating to build software. The release process is just one area of software development that many organizations have a desire to smooth out. Over the past ten years, a set of technologies and philosophies have provided improvements to the software development process. DevOps, continuous delivery, microservices, cloud providers, and serverless tools all make it easier for a company to focus on its core competency and release software faster. Baruch Sadogursky is an author of Liquid Software, a book about continuous updates and DevOps. Liquid Software describes an idealized vision of what today’s architecture could aspire to. The focus of the book is continuous updates, which allow for rapidly improving, evolving software quality. Baruch joins the show to discuss how software has changed in the last twenty years, and how the future of software development could look. Full disclosure: Baruch works at JFrog, which is a sponsor of Software Engineering Daily.

Modern software consists of sprawling international networks of servers. Users contact these servers to access applications. Microservices talk to each other to fulfill complicated requests. Databases and machine learning frameworks crunch terabytes of information to provide complicated answers. Across this infrastructure, there is a lot of different activities–and a lot of vulnerabilities. Without a reliable model for security and trust, software can be easily compromised. In the past, systems were often protected by a “firewall”, which is a security system around the perimeter of the network. A problem with this model is that if the attacker is able to penetrate the firewall, they can compromise anywhere in the network. Firewalls can be penetrated, so a much better security model is to assume that your network has already been compromised, and to require every internal system to identify and authenticate with each other. “Zero-trust security” is a security model that requires internal systems to communicate with each other as if they were potentially compromised. Evan Gilman is the author of Zero Trust Networks: Building Secure Systems in Untrusted Networks. He also works on SPIFFE, a system for managing identity and trust within a zero-trust network. In a previous episode about Google BeyondCorp, Max Saltonstall talked about zero-trust networking in the context of user and device authentication. In today’s episode, Evan discusses another side of zero-trust networking: workload identity and authentication. Just as Google BeyondCorp outlines an architecture for allowing devices to communicate with the network, the SPIFFE project outlines a system for workloads to identify and authenticate themselves. Workloads can range from MapReduce jobs to microservices to frontend application servers.

Serverless computing abstracts away the idea of a server node. Serverless lets programmers treat compute resources as high-level, reliable APIs, rather than unreliable, low-level compute nodes that might fail. Serverless dramatically improves the efficiency of programmers. Instead of thinking of a database as a set of servers that need to be sharded and replicated, the programmer can think of a database as a place to read and write data. Instead of modeling an application as a large monolith running on an application server in a container or a VM, the programmer can think of their application as a decoupled set of functions. Serverless computing is a natural evolution of software engineering in a world with cloud providers. The first version of FaaS came out of AWS with their Lambda service, which allows users to run functions in the cloud. Those functions are scheduled onto a physical server somewhere in an Amazon data center. They are executed, and they return the result. With AWS Lambda, programmers got a new abstraction to model their applications with. But it requires the use of a closed-source API. Lambda is not open source, and this makes some developers reluctant to integrate with it too tightly. Fission is an open source framework for serverless functions built on Kubernetes. Fission allows developers to deploy functions-as-a-service without being locked in to any specific cloud provider. Soam Vasani is the creator of Fission and an engineer at Platform9. In a previous episode, Soam talked about the architecture for Fission and the design choices for solving the cold start and scheduling problems. Soam joins the show today to discuss how serverless applications have evolved since last spoke more than a year ago. He also talks about how Fission itself has evolved, and the features that an open source serverless platform needs to have in order to compete with a fully developed cloud provider. Full disclosure: Platform9 is a sponsor of Software Engineering Daily.

Policies define which users and applications can access and modify resources in a computer system. In a file system, a user might have permission to read or write to a file. In a cloud infrastructure deployment, a user might have the rights to deploy a new server. One microservice may or may not have the necessary permissions to talk to another microservice. All of these are use cases where a “policy” defines the behavior within a computer system. Policies in a company can be managed in a range of ways: configuration files, dashboards, and centralized permissions databases. A policy engine is a system for managing and automating the policy creation and deployment within an organization. Microservices need to verify each request that comes in to ensure that the request has the correct permissions. To check those permissions, a microservice can contact the policy engine. The policy engine has all the information from the whole organization about who is allowed to do what. However, talking to the policy engine over the network can be a slow process. Open Policy Agent is a deployable agent that can run as a sidecar next to a service, and check policies by looking inside of a cache. Torin Sandall is a core committer to the Open Policy Agent project, and he joins the show to talk about policy management, the Open Policy Agent, and the Kubernetes ecosystem (and surprisingly, WebAssembly).

TLA+ is a formal specification language. TLA+ is used to design, model, and verify concurrent systems. TLA+ allows a user to describe a system formally with simple, precise mathematics. TLA+ was designed by Leslie Lamport, a computer scientist and Turing Award winner. Leslie joins the show to talk about the purpose of TLA+. Since its creation in 1999, TLA+ has been used to discover bugs in systems such as Amazon S3, DynamoDB, Xbox, and Cosmos DB. “TLA” stands for “temporal logic of actions”, a logical system that can be used to describe the behaviours of concurrent systems. This podcast is meant as a brief introduction of TLA+. To go deeper, check out the TLA+ website and the TLA+ video course (note: these videos are highly entertaining because of Leslie’s dry, unpredictable sense of humor).

Mapillary is a company that processes high volumes of images to develop a labeled 3-D model of the physical world. Mapillary’s APIs allow developers to build applications that are aware of stop signs, buildings, streets, trees, and other physical objects in real-world space. The potential use cases for Mapillary are numerous, ranging from self-driving cars to augmented reality. We can now build a 3-D model of the real world. It’s not a perfect representation of reality, but it is much better than we had just a few years ago. What has changed? How have the tools advanced such that we are able to build an API for accessing accurate information about the physical world around us? Mapillary is possible because of a combination of modern developments. High quality smartphone cameras enable users to crowdsource images of the world around them. Cloud computing allows for cheap workload processing. Newer computer vision techniques allow 2-D images to be stitched together in a 3-D representation. Deep learning architectures improve the classification and segmentation of objects in an image. Peter Kontschieder is the head of research at Mapillary, and he joins the show to talk about the technologies and research that has enabled Mapillary to build a futuristic business–an API for accessing information about the physical world. Software Engineering Daily is looking for sponsors. If you are interested in reaching over 50,000 developers, you can go to softwareengineeringdaily.com/sponsor to find out more, and you can send us a message. We’d love to hear from you. And if you are an engineer working at a company that is marketing to developers, or hiring developers, if you tell your marketing department or your recruiting department about softwareengineeringdaily.com/sponsor, that is one way to help us out.

An instruction set defines a low level programming language for moving information throughout a computer. In the early 1970’s, the prevalent instruction set language used a large vocabulary of different instructions. One justification for a large instruction set was that it would give a programmer more freedom to express the logic of their programs. Many of these instructions were rarely used. Think of your favorite programming language (or your favorite human language). What percentage of words in the vocabulary do you need to communicate effectively? We sometimes call these language features “syntactic sugar”. They add expressivity to a language, but may not improve functionality or efficiency. These extra language features can have a cost. Dave Patterson and John Hennessy created the RISC architecture: Reduced Instruction Set Compiler architecture. RISC proposed reducing the size of the instruction set so that the important instructions could be optimized for. Programs would become more efficient, easier to analyze, and easier to debug. Dave Patterson’s first paper on RISC was rejected. He continued to research the architecture and advocate for it. Eventually RISC became widely accepted, and Dave won a Turing Award together with John Hennessy. Dave joins the show to talk about his work on RISC and his continued work in computer science research to the present. He is involved in the Berkeley RISELab and works at Google on the Tensor Processing Unit. Machine learning is an ocean of new scientific breakthroughs and applications that will change our lives. It was inspiring to hear Dave talk about the changing nature of computing, from cloud computing to security to hardware design.

Open source projects benefit from the network effects of a large audience of developers. A popular open source project will be contributed to and used by thousands of developers, who are continuously testing, deploying, and improving the software. The open source movement has created massive communities and a thriving, collaborative economy. Infrastructure software companies are increasingly built within an open source business model. Databases, queueing systems, orchestrators, operating systems, and search engines have been started as freely available open source projects, and leveraged into billion dollar businesses. In previous shows we have talked about business strategy, go-to-market tactics, and licensing of infrastructure software. There remains plenty of room for more open source infrastructure companies. We still need better databases and distributed systems management. But over time, open source will move up the stack. From Netflix to Uber to social networks to payments systems–all software verticals will become open source because the benefits of making your software open source outweigh the costs. For many software business models, the competitive advantage is not found in their source code–it’s in their data, their network effects, their sales strategy, and their brand. Therefore, it makes sense that someday the source code will be freely available, democratizing the infrastructure concerns and letting these software businesses move up the value chain and become less operationally intensive at the bottom of the stack. Rather than asking “why should we open source our code”, these companies will be asking “why shouldn’t we open source our code?” Joseph Jacks is the founder of OSS Capital, a venture capital firm that invests exclusively in commercial OSS startup companies. Joe believes that over time, open source eats everything. In today’s show, we talk about the future of open source businesses, the impact of licensing, cloud providers, and cryptocurrencies.

Open source software powers everything we do on the Internet. Google runs on Linux servers. Content sites are served by WordPress. Our data is queued in Kafka clusters and stored in MongoDB instances. The success of an open source project often leads to the creator of that open source software becoming wealthy. An open source project can be monetized through enterprise add-ons, or consultation, or simplified hosting. The creators of open source software know their domains so well, that they are usually well-suited to operate this kind of open source business. Open source business model success stories include Elastic (ElasticSearch), Cloudera (Hadoop), and Red Hat. The rise in usage of cloud providers has changed the viability of some open source business models. AWS can monetize almost any open source project more profitably than the creators. This is because AWS has established distribution channels. If I already run my application on AWS, and I am looking for someone to provide me with a hosted version of a database, I will probably choose the hosted database that AWS provides. The Commons Clause is a license that open source projects can use to protect their code from being profited from. Redis, an open source in-memory object storage system, recently licensed their code with the Commons Clause with the goal of improving the business of Redis Labs, a company built by the creators of the Redis project. Kevin Wang joins the show to discuss everything open source–from business models to security vulnerabilities to licensing. Kevin is the CEO at FOSSA, a system for managing open source licensing and security. Kevin was involved in the creation of the Commons Clause and has written about it in detail.

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.

Online labor marketplaces are widely used for one-to-one transactions. On Uber, a rider hires a driver for transportation. On TaskRabbit, a homeowner hires a cleaner to come clean their kitchen. These types of marketplaces are not as widely used for one-to-many transactions, but they can be just as useful. A warehouse owner would want to hire a group of workers to help with holiday shipments. A conference organizer would want to hire a group of event staffers to help run the conference. Wonolo is an on-demand staffing platform. Businesses post jobs and workers apply for those jobs. The types of work include event staffing, warehouse operations, merchandising, and other general labor tasks. In past shows, we have covered on-demand work platforms such as Fiverr, Thumbtack, Uber, and Instacart. Wonolo presents another variation in the business model and software architecture of the gig economy. Jeremy Burton is the CTO and chief data scientist at Wonolo. He joins the show to talk about building and scaling Wonolo, and some of the key strategic decisions that Wonolo has made along the way. As with any successful marketplace business, Wonolo has solved the chicken and egg problem of how to get supply and demand on the platform simultaneously. The company has grown deliberately, setting up operations in one city at a time to make sure that they can provide a good experience in both sides of the market in each of the new geographies. Jeremy and I also talked about the broader effects that the gig economy could potentially have on the labor market. Gig economy platforms use a 5-star rating system and written reviews to judge workers, instead of a resume system. The gig economy allows for rapid job liquidity, and the potential for workers to steadily “level up” more quickly than they might be able to in a typical corporate job. These aspects of the gig economy are rarely discussed, so it was enlightening to hear Jeremy’s views on them.

Google Search allows humans to find and access information across the web. A human enters an unstructured query into the search box, the search engine provides several links as a result, and the human clicks on one of those links. That link brings up a web page, which is a set of unstructured data. Humans can read and understand news articles, videos, and Wikipedia pages. Google Search solves the problem of organizing and distributing all of the unstructured data across the web, for humans to consume. Diffbot is a company with a goal of solving a related, but distinctly different problem: how to derive structure from the unstructured web, understand relationships within that structure, and allow machines to utilize those relationships through APIs. Mike Tung is the founder of Diffbot. He joins the show to talk about the last decade that he has spent building artificial intelligence applications, from his research at Stanford to a mature, widely used product in Diffbot. I have built a few applications with Diffbot, and I encourage anyone who is a tinkerer or prototype builder to play around with it. It’s an API for accessing web pages as structured data. Diffbot crawls the entire web, parsing websites, using NLP and NLU to comprehend those pages, and using probabilistic estimations to draw relationships between entities. It’s an ambitious product, and Mike has been working on it for a long time. I enjoyed our conversation. We recently launched a new podcast: Fintech Daily! Fintech Daily is about payments, cryptocurrencies, trading, and the intersection between finance and technology. You can find it on fintechdaily.co or Apple and Google podcasts. We are looking for other hosts who want to participate. If you are interested in becoming a host, send us an email: [email protected]

David Cancel has started five companies, most recently Drift. Drift is a conversational marketing and sales platform. David has a depth of engineering skills and a breadth of business experience that make him an amazing source of knowledge. In today’s episode, David discusses topics ranging from the technical details of making a machine learning-driven sales platform to the battle scars from his early career, when he spent a lot of time building products that people did not want. He has found success by focusing on building software that the market has shown a desire for. Chatbots were a popular, trendy subject a few years ago. The success of chatbots manifested in them fading into the background, and becoming a subtle, increasing part of our everyday interactions. Not every online interaction can be replaced by a chatbot, but many online interactions can be made more efficient by using chatbots. Chatbots can serve well-defined information, like product features, or the hours of operation of a business. When a chatbot gets a question that it cannot answer, the bot can route the conversation to a human. When a customer lands on a web page of a company using Drift, they see a chat box appear in the corner of the screen. The customer is able to communicate through that chat box with a bot that represents the company. The customer can learn about the product, schedule a call with a salesperson, and get other useful utilities from the Drift sales bot. The Drift chatbot messaging system is handled by Elixir/Erlang. Erlang is widely known as the messaging language that was used to scale WhatsApp while maintaining high availability. On the backend, Java services take the interactions from the Driftbot and pull it into a CRM, which allows sales and marketing people to manage information about the customers that are interacting with the chatbot. David gives lots more detail around the engineering stack, the deployment model, and his thoughts on the business and modern engineering. We recently launched a new podcast: Fintech Daily! Fintech Daily is about payments, cryptocurrencies, trading, and the intersection between finance and technology. You can find it on fintechdaily.co or Apple and Google podcasts. We are looking for other hosts who want to participate. If you are interested in becoming a host, send us an email: [email protected]

Engineers who start companies often find themselves building something they have no experience with: a hiring process. Hiring engineers today is not as systematic as building software. We don’t have lots of data that tells us what makes for an effective programming interview question. The smartest tech companies in the world are still making hiring mistakes–often through the “false negative” of rejecting candidates who did not do well in their interview process or through the “false positive” of hiring candidates who did well in the interview, but were not a good fit for the job. If you are a hiring manager or a company founder, you will eventually have to build a hiring process. If you don’t treat that hiring process scientifically, you will likely make some mistakes. Ammon Bartram has conducted more than 1000 interviews with engineers, accumulating a vast amount of data. This data was gathered deliberately and scientifically, through closely tracked interview questions and a consistent end-to-end process for the job candidate. Ammon joins the show to talk about the data set he has accumulated, the conclusions from all of these interviews, and how engineering organizations can use this data to develop a smart, data-driven hiring process. Ammon is co-founder of Triplebyte, a company that helps match engineers and tech companies. Triplebyte also publishes lots of research and blog articles about conducting good interviews, developer salaries, and bootcamps vs. computer science degrees. Full disclosure: Triplebyte is a sponsor of Software Engineering Daily. (However, Ammon has been a guest several times before on the show, since before Triplebyte was a sponsor, and I always enjoy getting to talk to him.)

I like to write music, and a year ago I started working on an album called “Gig Economy”. The plan for the album was to hire musicians from gig economy platforms like Fiverr and Upwork to perform on songs that I produced. The album is finished and I’m happy with the result, so I’m sharing it on the podcast today as an extra episode released on a Sunday. We’ll be back tomorrow with content about software engineering. Writing this album made me think about the future of work. I love music, but I am not a professional musician. I take the craft seriously, but perhaps not as seriously as someone who has made music their full-time career. I’ve never taken the time to network with musicians and develop collaborative relationships. The gig economy allowed me to pay creative people to collaborate with me. The transactional nature of my relationship with the collaborators meant that both of us had the incentive structure to work effectively. This improved quality and kept the pace of the project moving quickly. Today, the gig economy is widely regarded as a mode of work that removes individuality. Critics of the gig economy say that it turns workers into a commodity. If you use Uber, you aren’t thinking about the human who is driving you. As long as your driver has a high rating, you are satisfied. My experience producing this album with gig economy musicians showed a different side of our new employment systems. I found artists who I deeply enjoyed working with. There was no ambiguity about our relationship. Nobody was flaky. I paid these collaborators well, and in return they helped me fulfill an artistic vision. Without gig economy platforms, I could not have written this album. The gig economy is a playground for creativity. If you want to get paid to work as an artist, you can do so as long as you have a laptop. If you are a corporate worker making a good salary, but you spend your weekend producing art, you can pay artists to help you complete your vision. The greatest works of art are often the result of a talented workforce directed by an established leader. The gig economy lets you become a leader and recruit a team of creative, proven artists in a single day. I hope you enjoy “Gig Economy”. If you would rather listen on Spotify or YouTube, links are below. If you like the album, please share it on Twitter or Facebook. If you listened all the way through and have feedback for me, I’d love to know your thoughts. You can send me a tweet @the_prion or an email: [email protected]

BloxRoute Labs is a company that is developing a blockchain distribution network (BDN). Much like a CDN pushes media files out to the edges of the web to make them faster to access, a BDN pushes out information to miners in the network. Of course, this means that the BDN could potentially be centralized infrastructure. In order to make the BDN effectively decentralized and trustworthy, BloxRoute claims to have a provably trustable network protocol, to go with its token-based incentive system that keeps its goals aligned with that of the larger blockchain world. Aleksander Kuzmanovic is the founder of BloxRoute Labs, as well as a professor of computer science at Northwestern University. His co-founders of BloxRoute include former guests of the show Emin Gun Sirer and Soumya Basu. The BloxRoute founders have a strong theoretical background and a great reputation in the cryptocurrency community, unlike the vast majority of founders who have issued a token. As we have heard in previous episodes, most of the founders of companies that issue tokens cannot give a good explanation for why their protocol needs a token. Tokens are a great idea that have mostly been applied as a mechanism to get rich quickly. However, BloxRoute has a credible explanation for their token, and I asked some very pointed questions to Aleksander in today’s episode to try to vet the project for legitimacy, and his reasoning made sense.

A smart security camera takes in a high volume of video images and processes those images using a set of machine learning models. Those models can be used to identify interesting snippets of movement throughout the day, and decide which of those snippets to keep. Some of the video snippets might contain movement of birds–but other video snippets might contain footage of intruders. As the video stream is processed on the smart security camera, and machine learning models are used to classify the entities in the video stream, some of the data gets thrown out as useless. Some of the data gets sent to the cloud for additional processing. Some of the data might trigger an alert that there is an intruder on the premises. Each piece of video data is an “event”. These events are processed and acted upon. Modern applications are highly interactive, and have lots of “events”. Other examples of event data streams are website traffic data, self-driving car data, time-series logging data, and video game session data. Building applications that respond to these high volumes of events requires us to program triggers to react to data streams, actions to take in response to the data streams, and workflows to orchestrate what the overall picture of our application is doing as the application is consuming this large data stream. Flogo is an event-driven ecosystem for building applications around streams of events. Leon Stigter and Matt Ellis work on Flogo at TIBCO, and they join the show to discuss event-driven application development and their work on Flogo. They also talk about the constraints of machine learning applications at the edge, and how event processing systems like Flogo can be used to handle large data streams on edge devices.

Engineers can build applications faster by using tools that abstract away infrastructure. Major cloud providers offer this tooling in the form of functions-as-a-service, as well as managed services such as Google BigQuery or Azure Container Instances. The term “serverless” refers to these functions-as-a-service and the managed services–because when you use these tools, you are not making calls to specific servers–you are making calls to APIs that abstract away the servers from you, while guaranteeing uptime and reliability. In previous shows we have covered Heroku, Firebase, serverless functions, serverless event driven application development, and a few startups that are built almost entirely on serverless infrastructure. “Serverless” is a way of describing backend services that are represented by an API. But what about the rest of the application stack that you use to build on top of serverless? You still need to use JavaScript to define the custom code of your application. You still need to use HTML markup to describe the look and feel of your application. The “JAM Stack” is a way of building applications consisting of JavaScript, APIs, and markup. Phil Hawksworth is the head of developer relations at Netlify, and he joins the podcast to explain how these JAM Stack applications are developed and deployed, and how developers can use the JAM stack to rapidly build new systems. We recently launched a new podcast: Fintech Daily! Fintech Daily is about payments, cryptocurrencies, trading, and the intersection between finance and technology. You can find it on fintechdaily.co or Apple and Google podcasts. We are looking for other hosts who want to participate. If you are interested in becoming a host, send us an email: [email protected]

DevSecOps emphasizes moving security out of a siloed audit process and distributing security practices throughout the software supply chain. In the past, software development usually followed a waterfall development process. Each step in building software was serialized, one after another. First, software was planned. Then it was built. Then it was tested. Finally, the software received a security audit at the end. If a security vulnerability was not discovered during that audit, it was likely that the software would be released with the vulnerability. With continuous delivery, we can be continuously checking for security. Every new release can be tested against a battery of automated security tests. The open source libraries we use can be scanned to make sure they are up-to-date with patched versions. Static analysis can discover memory leaks and buffer overrun vulnerabilities. Edward Thomson is the principal program manager for Azure DevOps at Microsoft. He joins the show to talk about how an organization can adopt DevSecOps and introduce security practices into continuous delivery pipelines. We also talk more philosophically about security–defining the most common security risks of a software company today, from “shadow IT infrastructure” to phishing. Full disclosure: Microsoft is a sponsor of Software Engineering Daily. We recently launched a new podcast: Fintech Daily! Fintech Daily is about payments, cryptocurrencies, trading, and the intersection between finance and technology. You can find it on fintechdaily.co or Apple and Google podcasts. We are looking for other hosts who want to participate. If you are interested in becoming a host, send us an email: [email protected]

Google Search is a highly interactive JavaScript application. As you enter a query, results are being automatically suggested to you before you even finish typing. When you press enter, some of your search results may be widgets that represent the weather, the price of a stock, a recipe for green bean soup, or a language translation for a phrase. These complex frontend components are loading dynamically–the Google Search application cannot prefetch every single possible widget that you might ask for–but the results do load very quickly. Google has many other examples of advanced JavaScript engineering. The company is mostly known for backend engineering inventions like MapReduce, TensorFlow, Dremel, and Spanner. To turn these backend tools into user facing products, Google develops its own JavaScript frameworks and infrastructure to deliver information from the backend to the frontend. “Backend” and “frontend” are not precise terms. At Google, there are so many layers of infrastructure between a user and the data center. If you are an engineer working on a service at Google, you probably have several “frontends” and “backends” on either side of you. Malte Ubl is a senior staff engineer at Google. He’s heavily involved in Google’s JavaScript infrastructure, and has written about managing large JavaScript applications in detail. He also works on AMP, an open-source project for delivering web pages in a fast, performant format. He joins the show to describe Google’s history with JavaScript frameworks, the process of building frontends and middleware to deliver JavaScript applications, and the engineering behind AMP. There are criticisms of AMP, but some of them misunderstand how the AMP technology actually works. AMP allows pages to be cached, prefetched, and served to a user more quickly. AMP does not necessarily centralize pages around being served from Google Search. A good example of AMP speeding up pages outside of Google is reddit. We recently launched a new podcast: Fintech Daily! Fintech Daily is about payments, cryptocurrencies, trading, and the intersection between finance and technology. You can find it on fintechdaily.co or Apple and Google podcasts. We are looking for other hosts who want to participate. If you are interested in becoming a host, send us an email: [email protected]

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.

Linux has created much more value for Google than it has for Linus Torvalds. Ruby on Rails has created more value for Airbnb than it has for David Heinemeier Hansson. Successful open source projects create more value than their creators’ capture–and that’s one reason why collections of people on the Internet are often inspired to work together on open source. When an engineer creates an open source project, and that open source project finds a large audience, that engineer can often build a successful business. SpringSource, Cloudera, and Elastic are examples of massively successful enterprises that were founded by the creators of open source software. But in other cases, the value of an open source project gets largely captured by cloud providers that create a closed source version of the open source project and offer it as a service. Shaun Connolly has worked in senior strategic roles at software companies such as SpringSource, VMWare, and Hortonworks. Throughout his decades of experience, much of his time has been spent figuring out how to monetize open source projects intelligently. Shaun joins the show to talk about his past experiences building enterprises, as well as modern issues–such as how to compete with major cloud providers. We also discuss the Commons Clause license, a new software license that open source projects can use to try to protect their value from being entirely captured by a cloud provider. Software Engineering Daily is looking for sponsors. If you are interested in reaching over 50,000 developers, you can go to softwareengineeringdaily.com/sponsor to find out more, and you can send us a message. We’d love to hear from you. And if you are an engineer working at a company that is marketing to developers, or hiring developers, if you tell your marketing department or your recruiting department about softwareengineeringdaily.com/sponsor, that is one way to help us out.

Search is part of almost every application. Users search for movies to watch. Engineers search through terabytes of log messages to find exceptions. Drivers search through maps to find a destination. Search remains an unsolved problem, with lots of room for optimization. Many search applications have been built Elasticsearch, an open source distributed search engine. Elasticsearch is the code that powers some search-as-a-service products offered by major cloud providers. After eight years of open source development, Elasticsearch is excellent at core search functionalities, such as indexing data, sharding, and serving queries. With improved access to machine learning tools, search applications can advance in new and interesting ways. For example, an incoming search query can be sent to an API for natural language processing before being served by the search engine. A natural language processing API can derive additional meaning from the query, adding metadata to a search query. Machine learning can also be applied to better understand how people are searching across your search index, and to optimize the search index to incorporate those user preferences. Liam Cavanagh is the principal program manager on Azure Search. He joins the show to talk about the architecture of a search index, how search queries are served by an index, and how machine learning APIs can be used to improve queries.

Virtual machines are operating system instances that run alongside each other on the same physical host. The virtual machines running on a physical host are managed by a hypervisor running on the physical host. A cluster of two physical servers could have four virtual machines running across those two physical instances. Those four virtual machines can communicate over a virtual switch. A network switch allows packets of bytes to be routed between machines. With a physical network switch, a dedicated physical device sits in the computer network to do this routing. A virtual network switch provides this packet routing without needing a dedicated physical hardware device for routing. Open vSwitch is a distributed virtual multilayer switch. Open vSwitch provides network switching for hardware virtualization environments. Ben Pfaff is a core contributor to Open vSwitch, and he joins the show to talk about operating system virtualization. Ben was an early employee at Nicira, a company that made significant developments in software-defined networking before being acquired by VMware in 2012.

A data warehouse provides fast access to large data sets for analytics, data science, and dashboards. A data warehouse differs from a transactional database, because you often do not need to update specific records. Because of the read-only nature of the access patterns, and the high volumes of data being queried, the design of a data warehouse is very different than a transactional database. With a transactional database (such as MySQL or MongoDB), it is important to have consistency guarantees. For example, consider a transactional database that serves as the backend for banking applications. If multiple frontend servers are hitting that transactional database to withdraw money, you need the records to be quickly updated. You need to avoid race conditions, so that two servers cannot withdraw the entire bank account balance simultaneously from different locations. In contrast to transactional databases, a data warehouse is often used to process a query that encompasses a big data set. For example, Netflix might want to answer the question: “how many users that watched House of Cards also watched Black Mirror?” Netflix has a lot of users, so they will want to be accessing those user records in a way that lets them scan through the records quickly. Christian Kleinerman is the VP of product at Snowflake Computing. Snowflake’s main product is a cloud data warehouse. In today’s show, we talk about the difference between a data warehouse, a data lake, and a transactional database, and the process of moving data sets between them, often known as ETL. This show continues our series on data engineering and data platforms. As companies accumulate more and more data, the complexity of managing that data and taking full advantage of it is escalating. Christian gives his perspective on these changing trends, and describes the plans for Snowflake to evolve as a business.

The Windows operating system is one of the most widely used pieces of software in history. Windows was started before there was any alternative to a monolithic codebase, because Microsoft was building software before the Internet was widely used by consumers. Networked computers gave rise to web applications, and software engineers began to rethink how to build everything. Software development got reimagined with agile. Monolithic codebases got broken up into service-oriented architecture. Instead of going to a store to buy a box with software in it, users downloaded software from the Internet, and that software was regularly updated. Software that is regularly updated needs to be regularly tested. Instead of a single round of testing for every round of boxed software that was shipped to a store, continuous testing and delivery gradually became the norm. The process of releasing and operating software became its own set of engineering challenges–which was tackled by the “operations” or “sys admin” team at a software company. Now there were two different sets of engineers–those who were developing the software and those who were operating the software. The incentives of these two types of engineers were not completely aligned. The software developers wanted to build software quickly and release new features. The operators wanted things to release software slowly, because if something broke then the operators were the first line of defense for fixing it. These problems between development and operations gave rise to the “DevOps” movement, in which developers and operations started working more closely together and sharing responsibilities. Incentives became aligned, and new types of software was created to facilitate more harmonious relationships between developers and operations–for example, continuous delivery pipelines. Today, most enterprises are still undergoing a transformation from monolithic software release cycles to continuous delivery. This is often referred to as a “DevOps Transformation”. A DevOps Transformation requires the entire organization to reorient itself around faster software release cycles. This can be a painful process, and we have covered it in many past shows. Hearing case studies from enterprises can be helpful for figuring out how to reorient your own enterprise. Microsoft is a useful case study in shifting towards DevOps. Windows is perhaps the biggest monolithic codebase in history. The fact that Microsoft could rearchitect Windows to be easier to work with should provide some reassurance to other enterprises who are currently undergoing their own migrations. Martin Woodward has been at Microsoft for 13 years and he joins the show to talk about how software delivery within the company has evolved. We discussed the move from boxed software delivery to delivery via the cloud, and focused on a few specific, longstanding products such as Windows. Martin has been part of the effort to build Azure DevOps, which is a product that offers similar tools to the ones Microsoft built internally for DevOps as a service. We also talk about the specific difficulties that enterprises often have when moving toward DevOps. Full disclosure: Microsoft is a sponsor of Software Engineering Daily.

Google Brain is an engineering team focused on deep learning research and applications. One growing area of interest within Google Brain is that of generative models. A generative model uses neural networks and a large data set to create new data similar to the ones that the network has seen before. One approach to making use of generative models is GANs: generative adversarial networks. GANs can use a generative model (which creates new examples) together with a discriminator model (which can classify examples). As an example, let’s take the task of generating new pictures of cats. We want an artificial cat picture generator. First, we train a discriminator by feeding it billions of example pictures of cats. We now have a model that can tell what a cat is. Next, we make a model that generates completely random images. We feed those randomly generated images to the discriminator. The discriminator outputs a “loss” for these random images. Loss is a metric we can use to represent how far off a given image is from being something that the discriminator would recognize as a cat. Finally, you can feed this “loss” back into the generative model, so that the generative model will adjust its weights in a way that will reduce loss. Over time, the generator gets better and better at reducing loss, until the discriminator starts believing that some of these semi-random images are actually cats. Generative model systems have produced useful applications, such as object detection, image editing, and text-to-image generation. Today’s guest Doug Eck works on the Magenta team at Google Brain. Magenta uses applications of deep learning to produce tools and experiments around music, art, and creativity. In a previous show, Doug described his vision for humans and computers to work together on creative tasks such as music. Today, we dive into some of the core machine learning building blocks that make machine creativity possible.