Cloud Engineering Archives - 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. ANNOUNCEMENTS New Software Daily app for iOS. Use the app to access all 1000+ episodes in one place; find all shows related to a particular technology (such as streaming data, cryptocurrencies, Kubernetes, or learning to program); connect with other listeners through the comments section; access our transcripts and our related links; everything in the app is free, though you can also become an ad-free listener and support the show for $10/month or $100/year at softwaredaily.com/subscribe We are booking sponsorships, find more details at https://softwareengineeringdaily.com/sponsor/ 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 jeff@softwareengineeringdaily.com with “Internship” in the subject line. 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. ANNOUNCEMENTS Upcoming conferences I’m attending: Datadog Dash July 16th and 17th in NYC, Open Core Summit September 19th and 20th in San Francisco 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 jeff@softwareengineeringdaily.com with “Internship” in the subject line. FindCollabs is the company I am building, we launched several new features recently. If you have a cool project you are working on, I would love to see it. I check out every project that gets posted to FindCollabs, and I’ve been interviewing people from some of these projects on the FindCollabs podcast New Software Daily app for iOS. You can become a paid subscriber for ad free episodes at softwareengineeringdaily.com/subscribe 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. ANNOUNCEMENTS New Software Daily app for iOS. Use the app to access all 1000+ episodes in one place; find all shows related to a particular technology (such as streaming data, cryptocurrencies, Kubernetes, or learning to program); connect with other listeners through the comments section; access our transcripts and our related links; everything in the app is free, though you can also become an ad-free listener and support the show for $10/month or $100/year at softwaredaily.com/subscribe We are booking sponsorships, find more details at https://softwareengineeringdaily.com/sponsor/ 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 jeff@softwareengineeringdaily.com with “Internship” in the subject line. 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. ANNOUNCEMENTS New Software Daily app for iOS. Use the app to access all 1000+ episodes in one place; find all shows related to a particular technology (such as streaming data, cryptocurrencies, Kubernetes, or learning to program); connect with other listeners through the comments section; access our transcripts and our related links; everything in the app is free, though you can also become an ad-free listener and support the show for $10/month or $100/year at softwaredaily.com/subscribe We are booking sponsorships, find more details at https://softwareengineeringdaily.com/sponsor/ 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 jeff@softwareengineeringdaily.com with “Internship” in the subject line. 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. ANNOUNCEMENTS New Software Daily app for iOS. Use the app to access all 1000+ episodes in one place; find all shows related to a particular technology (such as streaming data, cryptocurrencies, Kubernetes, or learning to program); connect with other listeners through the comments section; access our transcripts and our related links; everything in the app is free, though you can also become an ad-free listener and support the show for $10/month or $100/year at softwaredaily.com/subscribe We are booking sponsorships, find more details at https://softwareengineeringdaily.com/sponsor/ 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 jeff@softwareengineeringdaily.com 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 New Software Daily app for iOS. Use the app to access all 1000+ episodes in one place; find all shows related to a particular technology (such as streaming data, cryptocurrencies, Kubernetes, or learning to program); connect with other listeners through the comments section; access our transcripts and our related links; everything in the app is free, though you can also become an ad-free listener and support the show for $10/month or $100/year at softwaredaily.com/subscribe We are booking sponsorships, find more details at https://softwareengineeringdaily.com/sponsor/ 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 jeff@softwareengineeringdaily.com 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.

Modern server infrastructure usually runs in a virtualized environment. Virtual servers can exist inside of a container or inside of a virtual machine. Containers can also run on virtual machines. Kubernetes has allowed developers to manage their multiple containers, whether those containers are running in VMs or on bare metal (servers without VMs). As organizations expand their Kubernetes deployments, the overhead of those deployments is becoming a relevant concern. So-called “Kubesprawl” can occur within organizations due to a lack of best practices on when new clusters should be spun up or spun down, and when clusters should be shared by teams or shared by services. Paul Czarkowski is a principal technologist with Pivotal. He joins the show to discuss virtualization, Kubernetes, and the state of the cloud native ecosystem. RECENT UPDATES: FindCollabs is a company I started recently The FindCollabs Podcast is out! FindCollabs is hiring a React developer FindCollabs Hackathon #1 has ended! Congrats to ARhythm, Kitspace, and Rivaly for winning 1st, 2nd, and 3rd place ($4,000, $1000, and a set of SE Daily hoodies, respectively). The most valuable feedback award and the most helpful community member award both go to Vynce Montgomery, who will receive both the SE Daily Towel and the SE Daily Old School Bucket Hat We are booking sponsorships for Q3, find more details at https://softwareengineeringdaily.com/sponsor/ Podsheets is our open source set of tools for managing podcasts and podcast businesses New version of Software Daily, our app and ad-free subscription service The post Kubernetes Virtualization with Paul Czarkowski appeared first on Software Engineering Daily.

RECENT UPDATES: FindCollabs is a company I started recently The FindCollabs Podcast is out! FindCollabs is hiring a React developer FindCollabs Hackathon #1 has ended! Congrats to ARhythm, Kitspace, and Rivaly for winning 1st, 2nd, and 3rd place ($4,000, $1000, and a set of SE Daily hoodies, respectively). The most valuable feedback award and the most helpful community member award both go to Vynce Montgomery, who will receive both the SE Daily Towel and the SE Daily Old School Bucket Hat We are booking sponsorships for Q3, find more details at https://softwareengineeringdaily.com/sponsor/ Podsheets is our open source set of tools for managing podcasts and podcast businesses New version of Software Daily, our app and ad-free subscription service Google’s strategy for cloud computing is centered around providing open source runtime systems and a high quality developer experience. Google is highly differentiated in its approach to the cloud. To understand Google’s strategy, it is useful to first set the context for the current competitive environment of cloud providers. <If you want to skip straight to the interview with Eric Brewer, begin at 30:33> Amazon Web Services (AWS) popularized cloud computing in 2006. AWS was first to market, which has given the company a large competitive advantage over the rest of the industry. It took Google several years to realize how big the public cloud market was, and how good the economics of running a cloud provider could be. Microsoft also realized the opportunity several years after AWS was started. The multi-year lead that AWS had on getting to market has given the company tremendous leverage. Because AWS is the most widely trusted, accepted default in the market, AWS is able to deepen that relationship more and more over time, despite the fact that the proprietary APIs of AWS create a level of lock-in that bears some resemblance to the lock-in of Microsoft Windows or Oracle’s relational database systems. The brief history of software gives us examples of what is supposed to happen next. When a large company is operating a proprietary developer platform, the open source software ecosystem reflexively comes out with an alternative, open source solution that is better than the proprietary system, right? We saw this with the Linux project, which channeled the developer resentment of the proprietary Windows operating system software into the development of the best server operating system to date: Linux. The difference between Microsoft Windows in the 90s and AWS today is that, for the most part, developers do not resent AWS. AWS keeps its prices low, and embodies a spirit of innovation despite the fact that AWS is partly built around a repeated process of taking open source projects, packaging them up into cloud services, and integrating them closely with other AWS tools, making it harder to move away from AWS. In its pioneering offerings of managed services, AWS made it easier to set up tools that had previously been impossible for less-experienced developers to operate. Distributed systems became approachable. Companies like Netflix, Lyft, and Heroku were built on the simplified operational model of AWS. AWS also innovates outside of this business model of repackaging open source projects. When AWS pioneered the function-as-a-service model, they created an easy way to scale stateless computation. They presented the developer world with an entirely new compute model: event-driven programming, with services communicating to each other via functional glue code running in cheap, transient containers. There is strong criticism of the event-driven, AWS Lambda-bound “serverless” compute model. And those critics make a valid point: AWS Lambda is a proprietary API. To build your app around an event-driven architecture glued together with Lambda functions is to lock yourself tightly to Amazon infrastructure. But the critics of this model do not seem to be the ones who are actually locked in. Critics of Amazon’s proprietary strategy tend to be those with a strong incentive to be critical. Another common criticism of AWS comes from commercial open source companies such as Redis Labs and Elastic, which are vendors of the Redis open source in-memory data system, and the open source Elasticsearch search and retrieval system respectively. These vendors argue that AWS has violated the spirit of open source by repackaging open source software as profitable software and failing to contribute back to the open source ecosystem with commensurate open source contributions. AWS has repackaged both Redis and Elasticsearch as AWS Elasticache and Amazon Elasticsearch Service respectively. These vendors frame their relationship to AWS as zero sum, and are turning to licensing changes as their strategy of choice for creating a new defensible moat against AWS. In various Internet forums, the indignant commercial open source software vendors and AWS have both made their cases to the developer community. If you are a developer who just wants to build your software, these arguments are an unsettling distraction. In addition to worrying about fault tolerance and durability guarantees and cost management, you now have to worry about licensing. And as you observe these circumstances, with open source vendors accusing cloud providers of improper behavior, you might begin to wonder: what actually are the rules of open source? By what set of commandments are we judging who is good and who is bad? And who is to judge what is fair or unfair activity by Amazon, which was the first company to prove to all of us just how influential cloud computing could be? This is the competitive landscape of the cloud circa April 2019, when I attended Google Cloud Next, Google’s annual cloud developer conference. Throughout the conference, the optimism and playful spirit of Google was present everywhere. There were colorful shapes and cartoonish diagrams that looked like building blocks made for children. In the expo hall, there were food pillars from which free candy and salted snacks could be grabbed all day long. On one side of the expo hall, a demonstration from IKEA showed how the company was partnering with Google to run its furniture business more like a software company. Stretching across the expo hall in a carpeted distance of multiple football fields, the various vendors showed off their latest wares in a bazaar of multicloud, hybrid cloud, and Kubernetes-compliant sales pitches. Over the last decade, large enterprises have opened up their wallets more and more, realizing just how valuable cloud infrastructure can be for their businesses. The more they spend, the more efficient their workers become, and the faster their businesses can improve. For modern enterprise, the cloud is the closest thing to magic that we have. Knowledge workers are becoming unshackled from the painful, slow pace of early technological corporatism. The cloud can empower all of us–and rather than replacing our jobs with machines, the cloud will allow us to better express our humanity within our work. The twin forces of consumer mobile computing on the client side and cloud computing on the server side are compounding faster than we can measure. Five years ago, a common analogy was to compare the smartphone to a “remote control for your life”. Today the smartphone feels more like a magic wand than a remote control. We can summon tremendous forces from the magical cloud by merely speaking the right command into our wand-like smartphone. Someday even the world of Harry Potter may look antiquated relative to our reality. Why carry around a wand when you can use your Airpods to cast your spells via hands-free voice command? The cloud’s magical effects on corporate enterprise operations are exciting to watch. I go to a lot of conferences, and I prefer to walk around the expo hall rather than to go to any sessions. At the expo hall, you see the distance between vendor hype and the realities of the enterprise. From my vantage point, that distance gets shorter every year: enterprises truly are adopting DevOps, continuous delivery, machine learning, and data platforms. From insurance companies to banks to farming companies to furniture outlets: the “digital transformation” is actually happening. This is great for consumers, and great for employees at the large corporations that are being digitally transformed. What is it like to work at a large, 100 year old enterprise that is going through digital transformation? It is certainly much more appealing than it was a decade ago. The servile, bureaucratic, rent-seeking hierarchies of the 80s, 90s, and early 2000s are slowly being refurbished into enterprises where bottoms-up innovation, individualism, and artistic energy are assets rather than liabilities. We are moving out of the age of boring cubicle industrialism towards a vision in which work is truly creative and fulfilling for every member of the corporation. And Google evangelizes this ideal stronger than any other company in the world. With the tremendous cash flows from its advertising business, Google reinvests heavily into its employee base. Many employees at Google have worked there for a decade and show no intention of leaving, having found a job, but more importantly a culture and an engineering environment that is unrivaled. Speaking subjectively: my sense is that Google’s internal engineering tools are the best in the world. For many years, Google has been the strongest magnet for talent in the realm of Internet infrastructure and machine learning. In terms of sophistication, the rest of the software industry has been playing catch-up to Google since the days of the MapReduce paper. Speaking of the MapReduce paper: even back in 2004, Google was willing to share its findings with the outside world. Google was tactical about which innovations it would open up about, but it does seem that Google has truly tried to embody some of the publishing philosophies of academia. Google’s early investments in an academic-like environment have borne considerable fruit. The curiosity and cross-institutional collaboration enabled by Google’s willingness to speak openly about its research have made Google a refuge for academics, including today’s guest Eric Brewer. Beyond its considerable contributions as a publisher of computer science theory, Google has also become the model software engineering practitioner. Google has scaled its internal tools to make its thousands of developers highly productive. Given its success with its internal developers, it should come as no surprise that Google has strong opinions about the best way to build services for external developers. I have often wondered what it is actually like to work within Google as an engineer. I have worked at Amazon, and seen their internal tooling. At Amazon, the level of tooling gave engineers tremendous leverage. But from talking to more experienced engineers, my sense is that nobody holds a candle to the internal tools of Google. Drishti CTO Krish Chaudhury was a recent guest on this podcast. He spent nearly a decade at Google working on computer vision projects. Today he is building his own computer vision company. When I asked him if we yet had “Google Infrastructure for Everyone”, he sighed deeply and wistfully before answering with an unequivocal “no”. This hints at what Google wants to do with its cloud. Google does not think of Google Cloud as commodity cloud computing services. The vision for Google Cloud is to be the premier cloud, the deluxe set of services and hardware that provides “Google Infrastructure For Everyone”. This is a moonshot, and in order to accomplish it, Google will need to forego certain short term opportunities for cash grabs. But it is undoubtedly a more fiscally wise strategy for Google to optimize growth of the 2029 Q3 cloud market rather than that of 2019 Q3. From a conglomerate standpoint, Google already has a cash cow. Google has won today’s war, and it only makes sense to focus on tomorrow’s. In Google’s approach to the cloud, we see a cultural distinction between Amazon and Google. The cultures of Amazon and Google are partly deliberate, but partly driven by the nature of their businesses’ respective revenue streams. Amazon built its e-commerce business in a low-margin, highly competitive environment. Amazon won its customers over through a slow process of building trust. In its delivery of physical goods, Amazon formed close relationships with customers. Amazon would repeatedly listen to these customers and use that feedback to improve their products. This “flywheel” of iterative improvement is the core engine that keeps Amazon improving incrementally. Amazon also has made far-flung, ambitious investments–but the size and scope of Amazon’s moonshots were constrained for many years by its lack of any singularly large cash cow. Fire Phone notwithstanding, Amazon’s moonshots have often been thrifty asymmetric bets, requiring minimal upfront investment but presenting huge potential payoff. Google, on the other hand, has been in a much more luxurious financial position for most of its life. Google has a high margin advertising business that accounts for ~84% of its revenues, subsidizing everything else in Google (and Alphabet). Because it has such a big cash cow in a totally different area of the business, Google can afford to take an extremely long-term approach to its vision for the cloud. For Google, the goal is not to maximize the profit margins of the cloud over the next two years. Google can afford to think of cloud profitability in the increment of decades. In the business of cloud computing, Google has turned the weakness of being a late mover into a wide set of strengths. The AWS console presents its users with a sprawling array of possibilities. Google Cloud has a lower surface area. Google is more opinionated about the right way to do things–and it is easier for Google to build in an opinionated fashion because there are fewer legacy customers and edge cases to support. AWS supports the majority of the market, so it is in a position where it must keep those customers happy in order to hold onto its moat. So what are Google’s strong opinions about the way that a cloud should operate? Google’s espoused vision is that of the “open cloud”: a cloud environment where organizations could easily move workloads from one cloud provider to another. If we take the purest, most aspirational interpretation of “open cloud”, the full stack would be open source. Identity and access management systems would be portable as well, and cloud providers would work together to reduce the switching costs between each other, even in cases of data gravity. As virtuous as the idea of the “open cloud” sounds, it is also strategically convenient for Google. Since it lags behind Amazon and Microsoft in terms of adoption, a gradual shift towards a widely standardized open cloud would theoretically make it easier for Google to recover market share as the cloud market matures. Whatever Google’s true motives are, the “open cloud” strategy has been tremendously bountiful to the developer community. By open sourcing Kubernetes and pouring resources into it, Google brought an end to the painful, wasteful container orchestration wars. In its donation of Kubernetes to the Cloud Native Computing Foundation (which it also is a heavy financial donor to), Google created an ostensibly open, positive sum environment for the rivaling cloud providers to congregate productively. In the area of machine learning, Google open sourced TensorFlow and invested heavily into tutorials, documentation, YouTube videos, and other resources. Google built JavaScript libraries and auditability and visualization tools. Google has marshalled an entire ecosystem around TensorFlow. Some of Google’s commercial open source efforts have had less favorable results. The Istio service mesh project seems to have been promoted with the same playbook that Kubernetes and TensorFlow followed, but with a less usable tool. In Istio, we see Google’s expertise in marketing perhaps taken too far. Why is Istio a problematic case study? Because, despite the fact that there are multiple open source service mesh products on the market with significant production usage, Istio has managed to make so much noise about itself that it is convincing the market that the battle for service mesh superiority is a foregone conclusion–in spite of widespread reports that Istio is currently difficult to operate and not ready for production workloads. From the blog posts, to the KubeCon programming to the expo hall hype, the cloud native developer community has been hammered with the same messaging about service mesh: Istio is the best, don’t bother with the rest. Perhaps Google is just doing us all a favor with Istio. Maybe it really will be the best service mesh, it’s just not quite there yet. Maybe Google is just ironing out the kinks, and the marketing roadmap happened to proceed at a faster pace than the engineering roadmap. Or maybe I have been talking too much to the other service mesh companies. Honestly I don’t really know how these meshes trade off against each other, though I have certainly asked previous guests for comparisons. And it’s so early in the huge space that has been bucketed within the category of “service mesh” that maybe Google is acting with best intentions and trying to get out ahead of another container orchestration war. Speaking as a developer who prefers to work on application abstractions far above the world of security policy and load balancing and canarying, I would personally be fine with Google running it’s open source marketing playbook with Istio, winning everyone over, and saving our energy for more productive deliberations. I am fine with Google picking winners where it deems such actions appropriate. But this gets at a tension of the “open cloud”. What kind of openness are we really talking about here? If I can’t see the strategic roadmap of Google Cloud or the backroom conversations, is it still open? When the open source repos remain in Google’s control, is that open source, or marketing? When Google tinkers with an operating system like Fuscia in the open, but we are left to speculate as to why they are working on it, or what purpose it serves, is that open source or marketing? If Google is such an open cloud, why not open source a detailed ten year strategic roadmap, and pass the buck to Amazon to do the same? In any case, I’m not passing judgment on whether Google has done something morally wrong by pushing Istio so hard. I just think it was strategically unwise. With Istio, Google made it a little too obvious just how much narrative control it has over the public developer market. Perhaps this narrative control should come as no surprise. Of all the major clouds, Google is the most well-versed in open source. From its contributions to Linux to its maintenance of a complicated Android ecosystem, Google knows how to play its cards in the game of open source diplomacy. In battle, a classic strategy for competing with a rival that has an advantage is to force that rival onto territory that you are more familiar with. There are many historical cases where a small army was able to defeat a large army due to its ability to maneuver the battle front to a favorable environment. Through its open cloud strategy, this is exactly what Google is doing. Google is open sourcing the best way that it knows how to build and run infrastructure software. This is happening slowly but steadily. To some extent, the other major providers including Amazon will have no choice but to follow Google into a battleground that was built by Google. And as developers, we will get to reap all the rewards of this competition. Our infrastructure will become more standardized, more fault tolerant, cheaper, better designed, and easier to use. And who knows, maybe someday we will actually be able to easily move workloads from one cloud to another. To the extent that I am a software engineering journalist, I feel inclined to scrutinize all of the cloud providers. But to the extent that I am an engineer and a business person, I feel only admiration and love for the cloud providers. Cloud computing has brought the cost of starting an Internet business down to zero. Cloud computing has opened up my eyes to a world of creative possibilities that knows no boundaries, and for that I will always be a fan of all of the rivaling cloud companies because they all have played a role in creating the current software landscape. Eric Brewer is a Google Fellow and VP Infrastructure. He is well-known for his work on the CAP theorem, a distributed systems concept that formalized the tradeoffs between consistency, availability, and partition tolerance in a distributed system. At Google, Eric is as much a strategist and product creator as he is a theoretician. He has worked on database systems such as Spanner, machine learning systems such as TensorFlow, and container orchestration systems such as Kubernetes and GKE. Eric joins the show to talk about Google’s philosophy as a cloud provider, and how his understanding of distributed systems has evolved since joining the company. The post Cloud with Eric Brewer appeared first on Software Engineering Daily.

RECENT UPDATES: FindCollabs is a company I started recently The FindCollabs Podcast is out! FindCollabs is hiring a React developer FindCollabs Hackathon #1 has ended! Congrats to ARhythm, Kitspace, and Rivaly for winning 1st, 2nd, and 3rd place ($4,000, $1000, and a set of SE Daily hoodies, respectively). The most valuable feedback award and the most helpful community member award both go to Vynce Montgomery, who will receive both the SE Daily Towel and the SE Daily Old School Bucket Hat We are booking sponsorships for Q3, find more details at https://softwareengineeringdaily.com/sponsor/ Podsheets is our open source set of tools for managing podcasts and podcast businesses New version of Software Daily, our app and ad-free subscription service Intricately is a company that maps the breadth and depth of cloud infrastructure usage. Using a combination of clever algorithms, data engineering, and web crawlers, Intricately derives information about how different companies spend money on infrastructure. Fima Leshinsky is the CEO and co-founder at Intricately. In his previous job at Akamai, he began to study how a cloud provider such as Akamai could figure out how much its competitors were charging certain customers. Since CDN infrastructure is a commodity with reasonably low switching cost, a provider that can undercut its competitors significantly can have an edge in the marketplace. From his work at Akamai, Fima felt there was a market opportunity to provide this kind of service to the broader market of cloud providers. There are more cloud providers than ever before, and the kind of data that Intricately aggregates is highly useful to this competitive marketplace. Fima joins the show to talk about the modern landscape of cloud providers, and how to build a system that maps the Internet. The post Intricately: Mapping the Internet with Fima Leshinsky appeared first on Software Engineering Daily.