Haishi Bai - Learning Dapr

by Haishi Bai and Yaron Schneider

Copyright 2020 Haishi Bai and Yaron Schneider. All rights reserved.

Printed in the United States of America.

Published by OReilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.

OReilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional salesdepartment: 800-998-9938 or corporate@oreilly.com .

• Acquisitions Editor: Jennifer Pollock
• Developmental Editor: Melissa Potter
• Production Editor: Beth Kelly
• Copyeditor: Rachel Head
• Proofreader: Arthur Johnson
• Indexer: Sue Klefstad
• Interior Designer: David Futato
• Cover Designer: Karen Montgomery
• Illustrator: OReilly Media, Inc.

• September 2020: First Edition

See http://oreilly.com/catalog/errata.csp?isbn=9781492072423 for release details.

The OReilly logo is a registered trademark of OReilly Media, Inc. Learning Dapr, the cover image, and related trade dress are trademarks of OReilly Media, Inc.

The views expressed in this work are those of the authors, and do notrepresent the publishers views. While the publisher and the authors have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of orreliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or theintellectual property rights of others, it is your responsibility toensure that your use thereof complies with such licenses and/or rights.

978-1-492-07242-3

[LSI]

On one gloomy fall afternoon in 2018, Boris Scholl, Yaron Schneider, and I (Haishi) crammed into a tiny phone room at Microsofts Redmond campus to discuss cloud application development. At the time, we were envisioning a platform-agnostic application model that would allow developers to design the topology of a distributed application in isolation from any specific platforms. The idea eventually became the Open Application Model, which described an application as a collection of services that were interconnected on a software-defined mesh.

The application model wasnt concerned with how each of the services was written. At that time, I believed coming up with a unified programming model was too ambitious; hence, we tried to strictly define that an application model would always treat a service as a black box. However, as we discussed the idea further, something seemed to be missing.

Suddenly, Yaron jumped to the whiteboard and started doodling. Through his intangible writing, a brilliant idea surfaced, which he called Reaktive (Reactive with a k, reflecting Yarons deep affection for Kubernetes)., but for now, back to the story.

A couple of days later Yaron came back with a prototype, and we were blown away. Reaktive brought capabilities such as state management, service discovery, and reliable messaging to user code without polluting that code with any SDKs or libraries; it worked with any programming language (to prove that point, Yaron even did a COBOL sample later on), and it was amazingly lightweight.

For the next couple of weeks the three of us spent a lot of time together brainstorming what functionality it would make sense to add/remove, how we should think about it in the larger Microsoft tech context, and how we would release it. Boris invited architects and developers from within Microsoft and other companies to further validate our thinking and to get early feedback. Overall it felt as if the three of us were on the right path, so we took it to Mark Russinovich, CTO of Azure, and he immediately fell in love with it. He believed the programming model had the potential to have profound impacts on framework design and distributed application development in generala vision bigger than what we had dreamed of.

Later, Mark proposed that we rename Reaktive to Actions, a combination of Actors and Functions. The name reflected a core value proposition of the new offering: a nonintrusive programming model that unifies stateless service, stateful service, functions, and actors. We all loved the name, so we kept it.

Fast-forward a year, and Actions had gone through months of developments, tons of debates, and numerous early-adopter validations. And eventually, it was ready to be introduced to the world on the Microsoft Ignite keynote stage at Orlando, FL, under a new name: ). The star fever lasted a few weeks before the team members got bored and stopped checking it every few hours.

Figure P-1. Daprs GitHub momentum, tracked with Mark Russinovichs Star Track tool

Soon we were overwhelmed, as community contributions flooded in from all directions: our partners, competitors, big names, small companieseverybody was chipping in to make Dapr more useful. This was indeed open source at its best.

Coincidentally, Kathleen Carr from OReilly contacted me through LinkedIn to see if I had any new book ideas. I proposed an Actions in Action book. It was a bold proposal: to write about something that was still being cooked. Kathleen loved the idea, though, and a few weeks later, wed signed a contract for a book to introduce Actions (now Dapr) to the world.

The fact that you are reading this book proves it was worthwhile to take the risk. Regardless of what would have happened to Dapr, youre here, and were glad you are.