Software Engineering Daily

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.

The post Cloud Costs with Ran Rothschild appeared first on Software Engineering Daily.

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 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 post Schedulers with Adrian Cockcroft Holiday Repeat appeared first on Software Engineering Daily.

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.

The post Liquid Software with Baruch Sadogursky appeared first on Software Engineering Daily.

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.

The post Fission: Serverless on Kubernetes with Soam Vasani appeared first on Software Engineering Daily.

Matt Klein has worked for three rapidly growing Internet companies. At AWS, he worked on EC2, the compute-as-a-service product that powers a large percentage of the Internet. At Twitter, he helped scale the infrastructure in the chaotic days before Twitter’s IPO. Today he works at Lyft, building systems to allow for ride sharing infrastructure to work more safely and reliably.

Hypergrowth Internet companies are faced with quickly growing demands on their software. The demands on the software expose problems with the core infrastructure. Simultaneously, the company tries to ramp up its hiring process. More engineers get hired, and the institutional knowledge within the company starts to weaken. Documentation gets out of date. Senior engineers burn out and leave the company.

When a company starts growing quickly, communications can break down. A hypergrowth company can suffer from a lack of “human scalability”. Matt Klein has observed these challenges at AWS, Twitter, and Lyft. In his article “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.

The post Scaling Lyft with Matt Klein appeared first on Software Engineering Daily.

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.

The post Flogo: Event-Driven Ecosystem with Leon Stigter and Matt Ellis appeared first on Software Engineering Daily.

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]

The post DevSecOps with Edward Thomson appeared first on Software Engineering Daily.

Deepak Singh is the director of compute services at AWS, where he works on cloud products relating to containers, Linux, and High Performance Computing. In today’s show, Deepak describes how the market for containers and serverless has evolved, and how Amazon thinks about product strategy.

Back in 2014, Docker containers were becoming a popular way to deploy and manage application infrastructure. Containers allowed people to take advantage of their servers in a more economical way. Containers let developers move faster by quickly setting up and tearing down small composable units of software.

As these containers grew in number within software companies, companies started figuring out that they needed tooling to manage and orchestrate all these containers. Infrastructure software companies realized that there would be a big business in providing orchestration software to developers who needed to manage these high volumes of containers. This led to the “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.

The post AWS Containers with Deepak Singh appeared first on Software Engineering Daily.

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.

The post DevOps at Microsoft with Martin Woodward appeared first on Software Engineering Daily.