Software Engineering Daily

Google Cloud was started with a vision of providing Google infrastructure to the masses.

In 2008, it was not obvious that Google should become a cloud provider. Amazon Web Services was finding success among startups who needed on-demand infrastructure, but the traditional enterprise market was not yet ready to buy cloud resources.

Googlers liked the idea of becoming a cloud provider. But was it the right time to enter the market? Google’s advertising business was a large and growing cash cow. Executives within Google were not sure how much capital and effort should be allocated into an infrastructure business.

When Google decided to go into the cloud business, Joe Beda was one of the engineers who helped lead the effort, and joins the show as today’s guest.

Google’s internal server infrastructure is managed by Borg, a system for allocating resources to applications. Google Cloud runs on Borg, and there were a number of early engineering challenges to building the necessary functionality into Borg for running a cloud provider on top of it.

One example of a technical challenge that Google faced was the refactoring of Borg to run Google Cloud workloads.

The requirements for public infrastructure are different than those of internal Googlers. Inside of Google, developers deploy their applications to containers running on bare metal. Outside of Google, developers want to create virtual machines. Borg needed to be refactored in order to instantiate VMs.

Google solved this technical problem, as well as many other challenges, and Google Cloud slowly gained momentum in the market. But AWS remained the default choice for profitable enterprise workloads. It wasn’t until the container orchestration wars that Google found an opportunity to jump on a market segment that offered strong differentiation.

By open sourcing Kubernetes and presenting a clear vision for where the project was going, Google shifted the battlefield of the public cloud toward a competitive landscape where it has many advantages. Kubernetes also provided many other technology companies with an opportunity to get into the cloud market, creating a collaborative, multi-company ecosystem that has accelerated the pace of software faster than anyone expected.

Joe Beda has been instrumental in the evolution of the cloud native ecosystem. In today’s episode, Joe gives his memories on Google Cloud, Kubernetes, and his Kubernetes company Heptio, which he sold to VMware.

The post Kubernetes Vision with Joe Beda appeared first on Software Engineering Daily.

Containers are made to fail gracefully. When your container shuts down due to a hardware or software failure, your distributed application should be able to tolerate that failure. One simple way to be able to tolerate such a failure is to make all of your application logic “stateless.”

If your application does not maintain state, then shutting it down in the middle of a computation is not a problem–you can just restart the application, restart your computation, and get the same result.

But applications need to maintain state. We need to use databases and in-memory systems to manage long-lived user sessions and other interactions. A database is not just an on-disk abstraction–a database requires an application server to be accepting network traffic. We can run those database applications within containers.

There is a fundamental tension between stateful applications and the idea that containers are meant to tolerate failure gracefully.

Saad Ali is an engineer at Google, and he returns to the show to discuss Kubernetes storage and state management. He gave a keynote at KubeCon EU, which I spoke to him about.

New Software Daily app for iOS. You can become a paid subscriber for ad free episodes at softwareengineeringdaily.com/subscribe

The post Kubernetes Storage with Saad Ali appeared first on Software Engineering Daily.

Amazon Web Services is the leading cloud provider by a large margin. Amazon established its lead by being first to market in 2006, with Google and Microsoft taking several years to catch up to the huge business opportunity of the cloud.

Since 2008, Google Cloud has been working on cloud products for developers. It started with App Engine, which is widely used internally at Google, but has not had overwhelming public adoption. Over the last eleven years, Google has refined its understanding of how customers want to buy public cloud resources. Google Cloud products like Cloud Storage, Persistent Disk, and BigTable have given Google parity with many of the AWS public cloud offerings.

Although Google has caught up to AWS in terms of products, the enterprise market has continued to choose AWS as its default. AWS is widely perceived as  having more experience in running enterprise workloads, and a better responsiveness to customers.

In order to keep Amazon from running away with the cloud market entirely, Google needed to shift the competitive landscape to different territory. Kubernetes provided the paradigm shift that Google needed.

The market for cloud providers has changed completely due to Kubernetes. When Google open sourced Kubernetes, it created a common codebase for software companies to build software for managing distributed systems.

In the span of five years, Kubernetes has turned the world of cloud products into a world resembling the open source Linux ecosystem. This is a remarkable shift, and every infrastructure software vendor is still figuring out its strategy for adapting.

Adam Glick is the head of modern infrastructure and serverless marketing at Google. With Craig Box, he hosts the Kubernetes Podcast from Google, an excellent show about recent developments and evergreen concepts within the world of Kubernetes. Prior to Google, Adam worked at AWS for 3 years and Microsoft for twelve years. He has seen each of the major cloud providers up close and has a deep awareness for how each company thinks.

We had a great conversation about the cloud native landscape, podcasting, and developer marketing.

New Software Daily app for iOS. You can become a paid subscriber for ad free episodes at softwareengineeringdaily.com/subscribe

The post Kubernetes Market with Adam Glick appeared first on Software Engineering Daily.

Containers offer a lightweight abstraction for running a server. Cloud providers are able to manage billions of containers from different users, allowing for economies of scale so that each user can pay less.

Today, there is a variety of ways that users can deploy containers on a cloud provider. These containers can run in managed Kubernetes clusters, in functions-as-a-service, or in long-lived standalone container instances. User preferences are getting more sophisticated, with some users showing an interest in Knative, an open source serverless system originally created at Google.

Whichever container deployment system you choose, your application and its multiple servers need a way to route traffic, measure telemetry, and configure security policy. A service mesh abstraction can help serve these use cases.

Lachlan Evenson has worked in containers and Kubernetes since before the container orchestration wars. He was an engineer at Deis, a company which built an open source platform-as-a-service running on top of containers and Kubernetes. Deis was acquired by Microsoft, where Lachlan now works as principal program manager of Container Compute.

Lachlan joins the show to discuss containers, Kubernetes, and the Service Mesh Interface, an interoperable service mesh layer that Microsoft launched with Buoyant.

The post Service Mesh Interface with Lachlan Evenson appeared first on Software Engineering Daily.

Each cloud provider offers a different set of services which are not always compatible with each other. What are the challenges of building an application that interoperates with multiple different clouds?

The first issue is API compatibility.

Most cloud providers have a managed SQL offering, a bucket storage system, and server abstractions like virtual machines and containers. But these tools might have different APIs on each cloud. The code that you wrote to save your application data to Amazon S3 might have to be rewritten if you decide to switch your bucket storage to a different provider.

Another issue that interferes with cloud interoperability is the degree of integration on a particular cloud. If I build my application for AWS, I might be heavily integrated with Amazon’s Identity and Access Management policy system and AWS logging. Each cloud provider makes it particularly easy to connect to their integrated solutions.

There is also the problem of services on one cloud that simply do not map to a service on any other cloud. Google Cloud Bigtable does not have an equivalent service on Amazon. Microsoft CosmosDB does not have an equivalent service on Digital Ocean.

As developers, this irritates us. We want to be able to deploy our application to any cloud. We want to be able to move applications easily from one cloud to another. And we want to mix tools from different clouds together as easily as we import a library.

Bassam Tabbara is the CEO of Upbound, a company focused on making multicloud applications easier to deploy and operate. I spoke to Bassam at KubeCon EU 2019, and he described the problems of multicloud deployments and the opportunities for the cloud native ecosystem to become more cross-compatible.

The post Multicloud Future with Bassam Tabbara appeared first on Software Engineering Daily.

Kubernetes has evolved from a nascent project within Google to a thriving ecosystem of cloud providers, open source projects, and engineers.

Tim Hockin is a principal software engineer who has been with Google for 15 years. Tim joins the show to talk about the early days of the Kubernetes projects, and the engineering efforts that are under way five years into the project.

At KubeCon EU 2019, two of the prevalent subjects of discussion were service mesh and serverless–particularly the Knative project. Tim gave his perspective for how projects that are adjacent to Kubernetes are developed within the community.

The post Kubernetes Development with Tim Hockin appeared first on Software Engineering Daily.

Google’s cloud business was long regarded as a place where startups could build a business, but not established enterprises. For serious workloads, enterprises chose Amazon almost unanimously. This phenomenon of Amazon as the default was described by a phrase that harkened back to the days of IBM’s dominance: “nobody ever got fired for choosing AWS.”

With the rise of Kubernetes, Google has established a reputation as a reliable provider of container orchestration. As enterprises look to roll out Kubernetes workloads, Google is convincing many of them to work with Google Kubernetes Engine.

Kubernetes is one part of the changes which fall under the description of “digital transformation”. As these enterprises build out their digital transformation strategy, they are also looking for a strategy around multicloud, on-prem, policy management, and consulting partnerships.

Anthos is a platform where enterprises manage the resources and configuration of their cloud deployments, as well as a system to partner with services integrators and independent software vendors.

Aparna Sinha works on Anthos, Google Kubernetes Engine, and other projects at Google. In today’s show we discuss the process of digital transformation, as well as the tactics for how a digital transformation is actually implemented. We also talked about GKE on-prem, and the kinds of tooling needed by on-prem application deployments.

The post Google Anthos with Aparna Sinha appeared first on Software Engineering Daily.

A service mesh is an abstraction that provides traffic routing, policy management, and telemetry for a distributed application.

A service mesh consists of a data plane and a control plane. In the data plane, a proxy runs alongside each service, with every request from a service being routed through the proxy. In the control plane, an application owner can control the behavior of the proxies distributed throughout the application.

As the Kubernetes ecosystem has developed, the service mesh abstraction has become an increasingly desirable component of a “cloud native” application stack.

As companies enthusiastically adopt Kubernetes, they eventually find themselves with a large distributed system that is difficult to operate. A service mesh simplifies some of these operational difficulties, as we have explored in numerous previous episodes.

The Kubernetes community has grown to include lots of enterprises, and those enterprises want to adopt service mesh. But today, many of them are afraid to adopt the technology because there are multiple competing products, and it is unclear which one the community will centralize around–or if the community will end up supporting multiple products.

Over the next few weeks, we will be airing interviews from KubeCon EU 2019 in Barcelona. These interviews are a window into the world of the Kubernetes and the cloud-native ecosystem, which is transforming the world of infrastructure software.

The most prominent theme across these shows was that of service mesh. Why was service mesh such an important topic? Because the battle for service mesh supremacy is a classic technology competition between a giant incumbent and a startup with far fewer resources.

The Kubernetes ecosystem is beautifully engineered to allow for a marketplace of warring ideas where the most worthy competitor wins out–but in some cases there is room for multiple products to occupy different subsections of the market.

Across these episodes, one theme we will explore is the governance and the diplomacy of these competing solutions, and how the Kubernetes ecosystem is structured to allow for harmonious resolution to technology battles.

It is tempting to look at this competition between service meshes as winner-take-all. But as of late May 2019, we do not yet know if it will be winner-take-all. In order to predict how the service mesh wars will play out, the best we can do is to look at historical examples.

Container orchestration wars was a winner-take-all market. Container orchestration was a problem of such depth, such technical complexity and integration, that there had to be a single winner for the ecosystem to marshall around.

During the container orchestration wars, as Mesos and Docker Swarm and HashiCorp Nomad and Kubernetes fought for supremacy, many large enterprises made bets on container orchestration systems that were not Kubernetes. When the dust settled, Kubernetes was the victor, and these large enterprises who had adopted orchestration systems other than Kubernetes begrudgingly began thinking about how to migrate to Kubernetes.

But during the orchestration wars, many more enterprises were sitting out altogether. They did not choose Kubernetes or Mesos or Swarm. They chose to wait.

Enterprise technologists are smart, and they can tell when a technology is immature. Although many enterprises wanted an orchestration system to manage their Docker containers, they did not want to insert a heavy abstraction that they would have to tear out later on.

Once Kubernetes won the orchestration wars, enterprise dollars piled into the space. The cloud native community has grown faster than anyone expected, because we solved the collective action problem of centralizing on a container orchestrator.

From enterprises to cloud providers to ISVs to podcasters, we share the same vision for Kubernetes: it is the Linux for distributed systems.

Within the Kubernetes ecosystem, the thought leadership tries not to pick winners. It is better for everyone if the winners are decided through competition. In order to foster competition, interfaces into Kubernetes can provide a layer of standardization along which different products can compete. Enterprises can buy into an interface without buying into any particular product.

Examples include the container networking interface (CNI) and the container storage interface (CSI). Every Kubernetes application wants storage and networking, but these Kubernetes applications do not want to be locked into a particular provider. Since there is a standardized interface for networking and storage, these applications can swap out one storage provider for another, or one networking provider for another.

How does this relate to service mesh?

In the service mesh market, Buoyant was first to market with its open source project Linkerd. Today’s guest William Morgan is the CEO of Buoyant. Over the last four years, Linkerd has slowly grown a following of dedicated users who run the open source service mesh in production.

Over the last four years, Linkerd has changed from its initial technology of the embedded JVM service proxy developed at Twitter to a Rust-based sidecar data plane and a Go-based control plane. Buoyant’s dedicated focus to the service mesh space has won over much of the community, as was evidenced by Linkerd becoming the predominant apparel brand at Kubecon EU 2019: Linkerd hats and t-shirts were everywhere at the conference.

Why did Linkerd become trendy? Ironically, because of a competing service mesh whose launch strategy was widely seen as an affront to the spirit of the cloud native community.

Istio was created within Google, and launched with a set of brittle partnerships with IBM and other companies. Istio careened into the Kubernetes ecosystem with violent fanfare, trumpeting itself as the cloud native service mesh du jour through endless banner ads, marketing email campaigns, and KubeCon programming.

Any listener to this podcast knows I am as gullible as any technologist. I’m an idealist–and I wanted to believe that Istio represented the service mesh equivalent of Kubernetes. It’s from Google, it launched with a bunch of impressive logos, and it has an inspiring vision. Looks cloud native, smells cloud native, must be cloud native, right?

Unfortunately, Istio’s early marketing aggrandizements were disconnected from the nascent realities of the project. Istio was buggy and difficult to set up. Istio quickly developed a reputation as Google-manufactured vaporware: nice idea, not nearly ready for production.

For Linkerd, the timing could not have been better.

Istio’s romantic vision of an operating plane for routing traffic, managing security policy, and measuring network telemetry had seduced the enterprise masses. With their cravings unmet by Istio, these enterprises surveyed the market and quickly found their way to Linkerd, the humble service mesh next door, who had been waiting patiently all along.

The tide has turned against Istio, and towards Linkerd. But the service mesh wars have just begun. And as easy as it is to criticize Istio, the project is not only vaporware. Istio has a vision for a detailed operating plane that will evolve together with Envoy, a service proxy sidecar developed at Lyft.

Perhaps Istio’s early embers had too much marketing gasoline poured on them initially, but the project could still succeed. Google is the most sophisticated, well-resourced company in the world–and judging from Google’s adjacent strategic messaging around Anthos and other strategic initiatives, the company has already decided that Istio will be around for the long haul.

As a community, we should be grateful to witness the folly of Istio’s carpet-bomb marketing strategy. It is validation for the earnest resilience of the cloud native community, that even under the omnipresent duress of Google marketing, the community was able to collectively reject the Istio Kool Aid.

This should come as no surprise. The Cloud Native Computing Foundation resides within the Linux Foundation, and the Kubernetes ecosystem has been ordained with the ardent technical purity of Linus Torvalds.

The CNCF was formed under the looming shadow of AWS. The CNCF was seeded with the donation of Kubernetes by Google. Much like the Linux community was positioned as a rebellious movement in reaction to Microsoft’s dominance, the Kubernetes community represents a fervent desire to open up the market to cloud providers beyond the tight-lipped, proprietary dominion of Amazon.

With such a deep spirit of insubordination, it is no surprise that the community has rejected Istio like a set of loosely coupled organs rejecting a foreign skin attempting to layer itself across them. Even though the CNCF was founded by Google, the community was formed in spite of big centralized clouds, not as a marketing vessel for their products which may or may not be open source.

Microsoft seems to understand this fact better than Google, at least in the domain of service mesh.

The day after this interview with William, Microsoft announced the Service Mesh Interface (SMI), a project it partnered with Buoyant and other companies on to create a minimal spec for what a service mesh should offer to a Kubernetes deployment. The SMI presents a safe buy-in point for enterprises who want a service mesh, but do not want to get caught in the evangelistic crossfire of Istio and Linkerd.

It is in this environment that we begin our next series of shows on the current cloud native ecosystem.

Thanks to the Cloud Native Computing Foundation for putting together an amazing podcasting zone at KubeCon, and allowing me to conduct these interviews.

We are hiring two interns for software engineering and business development! If you are interested in either position, send an email with your resume to [email protected] with “Internship” in the subject line.

The post Service Mesh Wars with William Morgan appeared first on Software Engineering Daily.

Netflix started with a DVD-by-mail product. The software infrastructure and operations practices needed for the DVD business were very different from those needed by a streaming video company.

Since the early days of Netflix, CEO Reed Hastings knew that the company would evolve to becoming a streaming video platform. But he did not know when the technology would be advanced enough to support video streaming, and he did not know how users would consume it.

Greg Burrell has worked at Netflix for 14 years. Greg was one of the first engineers to start working on video streaming, which Netflix first attempted to implement with a set top box that downloaded movies and played them on your television. After evolving this strategy, Netflix arrived at the current model of video streaming through apps on browsers and mobile devices.

As the company pivoted from DVD-by-mail to video streaming, Netflix encountered multiple challenges across engineering, operations, and communications across the company. At the time, there was no “DevOps” movement. There were not established continuous delivery practices. The available cloud technologies were immature and low level.

Greg joins the show to describe the evolutionary arc of Netflix’s engineering process. Greg also presents a model for software development that he describes as “Full Cycle Development”. At Netflix, engineering teams of full cycle developers work without dedicated operations or testing teams. It is a sophisticated approach to engineering management.

I spoke to Greg at the Fullstack Tech Radar Day, a software conference in Tel-Aviv put on by Tikal, an engineering community based out of Israel and San Francisco. This was a great conference, and we’ll be airing some additional content from it in the coming weeks.

ANNOUNCEMENTS

We are hiring two interns for software engineering and business development! If you are interested in either position, send an email with your resume to [email protected] with “Internship” in the subject line.

The post Netflix Early Days with Greg Burrell appeared first on Software Engineering Daily.

Alex Balazs is the Intuit Chief Architect and has been working at the company for almost twenty years.

Intuit’s products include QuickBooks, TurboTax, and Mint. These applications are used to file taxes, manage business invoices, conduct personal accounting, and other critical aspects of a user’s financial life. Because the applications are managing money for users, there is not much room for error.

When Intuit was started, the company made desktop software. In his time at Intuit, Alex played a key role in rearchitecting the monolithic desktop applications to be resilient, reliable web applications. Intuit originally managed this software on their own servers. Since then, Intuit has migrated to the cloud using AWS.

Alex joins the show to discuss his experience scaling Intuit, his strategy for cloud migration, and his evaluation criteria for questions of build versus buy.

RECENT UPDATES:

The FindCollabs Open has started. It is our second FindCollabs hackathon, and we are giving away $2500 in prizes. The prizes will be awarded in categories such as machine learning, business plan, music, visual art, and JavaScript. If one of those areas sounds interesting to you, check out findcollabs.com/open!

The FindCollabs Podcast is out!

We are booking sponsorships for Q3, find more details at https://softwareengineeringdaily.com/sponsor/

The post Scaling Intuit with Alex Balazs appeared first on Software Engineering Daily.