Distributed .NET with Microsoft Orleans E-Book

Bhupesh Guptha Muthiyalu

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 235

Veröffentlichungsjahr: 2022

Beschreibung

Building distributed applications in this modern era can be a tedious task as customers expect high availability, high performance, and improved resilience. With the help of this book, you'll discover how you can harness the power of Microsoft Orleans to build impressive distributed applications.
Distributed .NET with Microsoft Orleans will demonstrate how to leverage Orleans to build highly scalable distributed applications step by step in the least possible time and with minimum effort. You'll explore some of the key concepts of Microsoft Orleans, including the Orleans programming model, runtime, virtual actors, hosting, and deployment. As you advance, you'll become well-versed with important Orleans assets such as grains, silos, timers, and persistence. Throughout the book, you'll create a distributed application by adding key components to the application as you progress through each chapter and explore them in detail.
By the end of this book, you'll have developed the confidence and skills required to build distributed applications using Microsoft Orleans and deploy them in Microsoft Azure.

Leseprobe

Distributed .NET with Microsoft Orleans

Build robust and highly scalable distributed applications without worrying about complex programming patterns

Bhupesh Guptha Muthiyalu

Suneel Kumar Kunani

BIRMINGHAM—MUMBAI

Distributed .NET with Microsoft Orleans

Copyright © 2022 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Richa Tripathi

Publishing Product Manager: Kushal Dave

Senior Editor: Keagan Carneiro

Content Development Editor: Adrija Mitra

Technical Editor: Joseph Aloocaran

Copy Editor: Safis Editing

Project Coordinator: Rashika Ba

Proofreader: Safis Editing

Indexer: Manju Arasan

Production Designer: Ponraj Dhandapani

Marketing Coordinator: Pooja Yadav

First published: May 2022

Production reference: 2240522

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

978-1-80181-897-1

www.packt.com

To my parents, Mrs. Geetha Rani and Mr. Muthiyalu, for the inspiration. To my wife, Aparna, and my children, Tarak and Yashvak, for their continued support and love. To my sister Janani for encouragement throughout the long process of writing this book.

– Bhupesh Guptha Muthiyalu

To my lovely sister Suhasini, as well as my wife, Sravani, and children, Mahanya and Krithi, for their unconditional love and support.

– Suneel Kumar Kunani

Foreword

As businesses continue to shift computational workloads into the cloud, it has become increasingly vital for developers to understand and overcome the challenges of building cloud-native applications. Such applications must gracefully survive machine failures, networking blips, rolling upgrades, and other disruptions. They must scale elastically and efficiently utilize the resources that are available to them, resources that are frequently in flux. These challenges distinguish the cloud from traditional, so-called on-premises applications. Tackling these challenges can be a daunting task, typically requiring application developers to become intimately familiar with distributed systems theory and practice. In response to this, Microsoft Research embarked on a project to simplify cloud application development such that programmers who are not experts in distributed systems can productively create resilient, scalable, and efficient cloud applications. The result is Microsoft Orleans.

In 2015, Orleans was released as an open source project. Having been introduced to Orleans during my previous time working at Microsoft, I became an avid user and contributor to the project and eventually rejoined Microsoft to develop Orleans full-time. It has been my pleasure to help the project mature, lead the project through our recent transition to the .NET team at Microsoft, and work with the many teams using Orleans within Microsoft and outside of the company.

I first came to know Suneel and Bhupesh while they were building cloud services using Orleans at Microsoft and I was delighted to learn sometime later that they were planning to write a book to help others to successfully leverage Orleans.

Over the course of Distributed .NET with Microsoft Orleans, Suneel and Bhupesh will guide you through building, testing, deploying, and monitoring real-world cloud applications using Orleans and .NET. They will explore the many features of Orleans, recommended design patterns for cloud applications in general and for Orleans-based applications, as well as the details of Orleans's programming model and runtime.

With Distributed .NET with Microsoft Orleans, you'll learn the best practices for writing high-quality, reliable, scalable distributed applications with Microsoft Orleans. After you complete Suneel and Bhupesh's book, you'll have developed a foundation for understanding distributed applications and the challenges of building for the cloud, and will have developed a real-world cloud-based application and deployed it to Azure Kubernetes Service and Azure App Service. This knowledge and experience will serve you well as you go on to build future applications for the cloud using Microsoft Orleans and .NET.

Elevate your skills into the stratosphere and build resilient, scalable, and efficient cloud-native applications with Orleans.

Reuben Bond

Software Engineer at Microsoft

Contributors

About the authors

Bhupesh Guptha Muthiyalu is a Microsoft Certified Professional and works at the company as a principal software engineering manager. He has 17+ years of software development experience on the .NET technology stack. His current role involves designing systems that are resilient to the iterations and changes required by the needs of enterprise businesses, validating architectural innovations, delivering solutions with high quality, managing the end-to-end ownership of products, and building diverse teams with capabilities to fulfill customer objectives. He is passionate about creating reusable components and identifying opportunities to make a product better.

"I would like to thank Sergey Bykov and Reuben Bond for their perspectives and suggestions to make this book better. I would like to extend my thanks to the Packt team, the co-authors, and the technical reviewers for the great partnership and collaboration. I am thankful to my managers and peers who supported and inspired me to write this book."

Suneel Kumar Kunani is a passionate developer who strives to learn something new every day. With over 17 years of experience in .NET and Microsoft technologies, he works on architecting and building mission-critical, highly scalable, and secure solutions at Microsoft. He loves to teach and preach the best practices in building distributed cloud solutions.

"My heartfelt gratitude goes out to Sergey Bykov and Reuben Bond for their unwavering support. I'd want to express my gratitude to the Packt team and reviewers for making the process of authoring this book so pleasant. I am thankful to my managers and colleagues for their support and encouragement as I worked on this book."

About the reviewers

Russ Hammett is an application developer and architect who is always trying to discover new ways of doing things. He previously got started working with and blogging about Orleans while working on the Automated Cryptographic Validation Protocol (ACVP) project under a Huntington Ingalls Industries contract for National Institute of Standards and Technology (NIST). While he has not used Orleans in the "traditional sense" (his own words), he hopes that by continuing to blog and read about Orleans, one day he will get there! He believes that having as many tools in your toolbox as you can helps to uncover new approaches to solving problems, so expand your horizons and go beyond your comfort zone!

Separate from his career, Russ likes to spend time with his family, cook, and play video games/blog under the handle Kritner.

Jyothsna Shenoy is a principal software engineer with over 10 years' experience in various technologies, including .NET Framework, JavaScript, Azure, and various web development frameworks. She has architected, designed, and developed a wide variety of applications, from banking and Business Process Management (BPM) enterprise tools to consumer-facing mobile applications. In her spare time, she is an avid science-fiction reader.

Table of Contents

Preface

Section 1 - Distributed Applications Architecture

Chapter 1: An Introduction to Distributed Applications

Technical requirements

Monolithic applications versus distributed applications

Common issues with monolithic apps

N-tier distributed applications

Challenges with distributed applications

Design and implementation

Data management

Messaging

Designing applications for scalability

Vertical scaling or scaling up

Horizontal scaling or scaling out

Load balancers

Caching

Distributed caching

Sharding

Designing applications for high availability

Azure data centers

Azure regions

Azure paired regions

Azure Traffic Manager

Availability sets and availability zones

SQL Always On availability groups

Architecture for high availability

Summary

Questions

Chapter 2: Cloud Architecture and Patterns for Distributed Applications

Technical requirements

A primer on common design principles

Design principles

Understanding cloud architecture styles

Microservices architecture

Event-driven architecture

Understanding cloud design patterns

The gateway aggregation pattern

The CQRS pattern

The cache-aside pattern

The priority queue pattern

The external configuration store pattern

The pipes and filters pattern

Summary

Questions

Section 2 - Working with Microsoft Orleans

Chapter 3: Introduction to Microsoft Orleans

Understanding the actor model for distributed systems

The origin of Microsoft Orleans

The Orleans runtime

The messaging system

The hosting system

The execution system

Orleans design choices

Serialization

Strong isolation

Asynchrony

The distributed directory

Eventual consistency

Message guarantees

Reliability

Cooperative multitasking

Single threading

Why should I learn about Orleans?

When to choose Orleans

Summary

Questions

Chapter 4: Understanding Grains and Silos

Technical requirements

Say hello to Orleans

Cloud-native objects – grains

Hosting silos

Creating your first Orleans application

What is happening behind the scenes?

Naming a grain

Stateless worker grains

Request scheduling in Orleans

Interleaving grain code execution

Co-hosting silos with ASP.NET core

Summary

Questions

Chapter 5: Persistence in Grains

Technical requirements

Understanding grain state persistence

Adding grain state persistence using Azure Cosmos DB

Custom persistence provider

Grains with multiple states

Grains directly interacting with storage

Summary

Further reading

Questions

Chapter 6: Scheduling and Notifying in Orleans

Technical requirements

Understanding and implementing timers

Implementing a timer in a HotelGrain

Understanding and implementing reminders

Configuration

Implementing reminders in a grain

Understanding and implementing notifications

Implementing notifications in a grain

Summary

Questions

Chapter 7: Engineering Fundamentals in Orleans

Technical requirements

Setting up the Orleans dashboard

Dashboard features

Dashboard APIs

Silo Stats

Understanding unit testing in Orleans

Adding real-time telemetry

Enabling application logging in Application Insights

Summary

Questions

Section 3 - Building Patterns in Orleans

Chapter 8: Advanced Concepts in Orleans

Technical requirements

Streaming in Orleans

Implicit subscriptions

Looking into heterogeneous silos

Understanding grain interface versioning

Grain activation with versions

How to deploy new versions of grains

Summary

Questions

Chapter 9: Design Patterns in Orleans

Technical requirements

Distributed cache

Batch message processing with Dispatcher

Cadence with timers

Aggregating with the Reduce pattern

Summary

Questions

Section 4 - Hosting and Deploying Orleans Applications to Azure

Chapter 10: Deploying an Orleans Application in Azure Kubernetes

Technical requirements

Understanding Azure Kubernetes

Steps to run an Orleans application in Azure Kubernetes

Leveraging Azure Kubernetes hosting

Creating a Docker image

Pushing the Docker image to Azure Container Registry

Deploying to Azure Kubernetes

Summary

Questions

Further reading

Chapter 11: Deploying an Orleans Application to Azure App Service

Technical requirements

Introduction to Azure App Service

What is included in an App Service plan?

Creating the required Azure resources

Configuring the application to run on App Service

Geographically distributing the application

Deploying an Orleans application to App Service

Summary

Questions

Other Books You May Enjoy

ii Preface

Download the example code files iii

iv Preface

Section 1 - Distributed Applications Architecture

Every journey begins with a first step. We will start by learning about distributed applications. These are becoming more and more common as the demand for highly scalable and available applications is increasing, and they are large and intricate. This section will provide you with a basic understanding of distributed systems by taking a quick look at the types of distributed systems and the different patterns to architect them.

In this section, we will cover the following topics:

Chapter 1, An Introduction to Distributed ApplicationsChapter 2, Cloud Architecture and Patterns for Distributed Applications

Chapter 1: An Introduction to Distributed Applications

In today's world of digital platforms, all applications are expected to be highly scalable, available, and reliable with world-class performance. Many IT companies use the term ARP, which stands for availability, reliability, performance, and have a guaranteed service-level agreement (SLA) for each. Any SLA below 99.99% (four nines) is not acceptable for an application given the challenging and highly competitive world we are in. Some mission-critical applications guarantee a higher SLA of >=99.999% (five nines). To meet increasing user demands and requirements, an application needs to be highly scalable and distributed.

Distributed applications are applications/programs that run on multiple computers and communicate with each other through a well-defined interface over a network to process data and achieve the desired output. While they appear to be one application from the end user's perspective, distributed applications typically have multiple components.

This chapter will cover the following:

Monolithic applications versus distributed applicationsChallenges with distributed applicationsDesigning your application for scalabilityDesigning your application for high availability

Technical requirements

A basic understanding of Azure is all that is required to read this chapter.

Monolithic applications versus distributed applications

In the following diagram, we have a classic monolithic hotel booking application with all the UX and business processing services deployed in a single application server tightly coupled together with the database on the left side. We have a basic N-tier distributed hotel booking application with UX, business processing services, and a database all decoupled and deployed in separate servers on the right side.

Figure 1.1 – Monolithic application (left) versus an N-tier distributed application (right)

Monolithic architecture was widely adopted 15-20 years ago, but plenty of problems arose for software engineering teams when systems grew and business needs expanded with time. Let's see some of the common issues with this approach.

Common issues with monolithic apps

Let's have a look at the scaling issues:

In a monolithic app, there will be no option to scale up UX and services separately as they are tightly coupled. Sometimes scaling doesn't help due to conflicting needs of the resources.As most components use a common backend storage, there will be a possibility of locks when everyone tries to access the data at the same time leading to high latency. You can scale up but there will be physical limits to what a single instance of storage can scale.

Here are some issues associated with availability, reliability, and performance SLAs:

Any changes in the system will need the deployment of all UX and business components, leading to downtime and low availability.Any non-persistent state-like session stored in a web app will be lost after every deployment. This will lead to abandoning all the workflows that were triggered by the user.Any bugs such as memory leaks or any security bugs in any module make all the modules vulnerable and have the potential to impact the whole system.Due to the highly coupled nature and the sharing of resources within modules, there will always be resource starvation or unoptimized usage of resources, leading to high latency in the system.

Lastly, let's see what the impacts are on the business and engineering team:

The impact of a change is difficult to quantify and needs extensive testing. Hence, it slows down the rate of delivery to production. Even a small change would need the entire system to be deployed.Given a single highly coupled system, there will always be physical limits on collaboration across teams to deliver a feature.New scenarios such as mobile apps, chatbots, and analysis engines will take more effort as there are no independent reusable components and services.Continuous deployment is almost impossible.

Let's see how these issues are addressed in a distributed application.

N-tier distributed applications

N-tier architecture divides the application into n tiers:

Presentation (known as the UX layer, UI layer, and the work surface)Business (known as the business rules layer and services layer)Data (known as the data storage and access layer)

Let's have a look at the advantages of a distributed application:

These tiers can be owned, managed, and deployed separately. For example, any bug fixes or changes in the UX or service will need regression testing and deployment of only that portion.Multiple presentation layers, such as web, mobile, and bots, can leverage the same business and data tiers as they are decoupled.Better scalability: I can scale up my UX, services, and database independently. For example, in the following diagram, I have horizontally scaled out each of the tiers independently.

Figure 1.2 – N-tier Distributed application scaled out

The separation of concerns has been taken care of. The presentation tier containing the user interface is separated from the services tier containing business logic, which is again separated from the data access tier containing the data store. High-level components are unaware of the low-level components consuming them. The data access tier is unaware of the services consuming it, and the services are unaware of the UX consuming them. Each service is separated based on business logic and the functionality it is supposed to provide.Encapsulation has been taken care of. Each component in the architecture will interact with other components through a well-defined interface and contracts. We should be able to replace any component in the diagram without worrying about its internal implementation if it adheres to the contract. The loosely coupled architecture here also helps in faster development and deployment to the market for customers. Multiple teams can work in parallel on each of their components independently. They share the contract and timelines for integration testing at the beginning of the project with each other and once internal implementation and unit tests are done, they can start with integration testing.

In this section, we discussed the advantages of distributed applications over monolithic applications and how easy it is to scale each of the tiers independently. In the next section, we will see challenges with distributed applications.

Challenges with distributed applications

When you start developing distributed applications, you will run into the following common set of challenges that all developers face:

Design and implementationData managementMessaging

Design and implementation

The decisions made during the design and implementation phase are very important. There are several challenges, such as designing for high availability and scalability. Some design changes in the later stages of the project might incur huge costs in terms of changes to development, testing, and so on, depending on the nature of the change. Hence, it is very important to arrive at the right design choices at the beginning.

Data management

As data is spread across different regions and servers in distributed applications, there are several challenges, such as data availability, maintaining data consistency in different locations across multiple servers, optimizing your queries and data store for good performance, caching, security, and many more.

Messaging

As all components are loosely coupled in distributed applications, asynchronous messaging will be widely used for functionalities such as sending emails, uploading files, and so on. The user doesn't have to wait for these operations to be completed as these can happen asynchronously in the background and then send notifications to the user on completion. While there are several benefits, such as high performance, better scaling, and so on, there are several challenges as well with asynchronous messaging, such as handling large messages, processing messages in a defined order, idempotency, handling failed messages, and many more.

In the next section, we will see how to design applications for scalability.

Designing applications for scalability

Scalability is the ability of a system to adapt itself to handle a growing number of incoming requests successfully by increasing the resources available to the system. Scalability is measured by the total number of requests your application can process and respond to successfully. How do you know your application has reached its threshold of the maximum capacity limit? When it is busy processing current requests in the pipeline and can no longer take any incoming requests and process them successfully. Also, your application may not perform as expected, resulting in performance issues, and some requests will start to fail by timing out. At this stage, we must scale our application for business continuity. Let's look at the options available.

Vertical scaling or scaling up

Vertical scaling or scaling up means adding more resources to individual application servers and increasing the hardware capacity. Users send requests and the application processes the requests, reads/writes to the database, and sends responses back to the users. If the user base grows and the number of incoming requests becomes high, the application server will be overloaded, resulting in longer processing times and latency in responding to users. In this case, we can scale up the application server hardware to a higher hardware capacity, as shown in the following diagram.

Figure 1.3 – Vertical scaling (scaling up)

Horizontal scaling or scaling out

Horizontal scaling or scaling out means adding more processing servers/machines to a system. Let's say my application is running on one server and can process up to 1,000 requests per minute. I could scale out by adding 4 more servers and could process 4,000 more requests per minute, as shown in the following screenshot.

Figure 1.4 – Horizontal scaling (scaling out)

Tip

Having a single server is always a bottleneck beyond a certain load, no matter how many CPU cores and memory you have. That's when horizontal scaling or scaling out may help.

Load balancers

Load balancers help in increasing scalability by distributing incoming traffic to healthy servers within a region when the amount of simultaneous traffic increases. Load balancers have health probe monitors to monitor a given port on each of the servers to check the health, and if they're found to be unhealthy, the server is disabled from the load balancer and incoming traffic. When the next health probe test passes, the server is added back to the load balancer.

Caching

Caching is