Global Azure Bootcamp: Azure service fabric

Editor's Notes

• #4: Objective: Discuss the agenda for the deck Notes: The deck is broken into 4 sections that discuss: An Introduction to Azure Service Fabric and the Microservices Architecture Pattern A discussion of the key Service Fabric concepts Getting Started with the development tools for Azure Service Fabric An overview of deployment and upgrade concepts
• #5: Objective: This section will provide a high-level introduction to Azure Service Fabric and to the Microservices Architecture pattern.
• #6: Objective: To provide an initial explanation of what a Microservices architecture entails Notes: The Microservices architecture is an evolution of the older Service Oriented Architecture (SOA) pattern, building on top of the rapid develop/test/deploy cycles that have arisen due to advances in both technology and project process management. In a Traditional “Monolithic” solution, a system will often be made up of large self-contained applications which are scaled as a group. Storage is often a single entity – albeit with some redundancy – and is scoped to address the entire set of application needs. Application segmentation usually takes the form of modules, libraries, or other platform artifacts that allow some segregation of implementation, but nonetheless, the application is both deployed and scaled as a single fixed unit. In a “Microservices Architecture”, the system is deployed as a suite of smaller, independent services which communicate over lightweight protocols such as HTTP or TCP. These smaller units can be developed and deployed independently, including support for using different platforms/languages/technologies to do so. As long as the contracts between the services are enforced (or otherwise managed), different parts of the application can be developed, deployed, and scaled independently of each other. Furthermore, storage is typically scoped just to the service that needs it, offering perhaps more nuanced choices for using different kinds of storage for different parts of the solution. Of course, with this added flexibility comes some additional responsibility – there are more individual units to deploy and manage. A good DevOps pipeline greatly facilitates the ability for a team to manage the additional complexity involved in the Microservices approach to distributing an application’s functionality.
• #7: Objective: To provide a high level description of Azure Service Fabric Notes: Azure Service Fabric is a platform that manages or orchestrates one or several services across a cluster of machines. As such it is an ideal fit for applications that are designed around a Microservices architecture, though it can also accommodate other application architectures as well. Service Fabric solutions can be deployed into Microsoft Azure, on-premises, or even in other vendors clouds, though there is additional tooling and support when deployed in Microsoft Azure. As you can see, Service Fabric is not just a tool that is being made available to Azure customers, it is also a key part of the underpinnings of several components of the Microsoft Cloud, including the list shown here, among several others.
• #8: Objective: This section will discuss several key Service Fabric Concepts, including the application and service models.
• #9: Objective: Present the Core Concepts that make up a Service Fabric Application Notes: A Service Fabric Application is made up of a collection of Services, where each service id responsible for performing some distinct function. Services are composed of Code, Configuration, and Data, where code is the executable binaries, configuration consists of the service settings that affect its runtime behavior, and data is any arbitrary static data that the service will consume at runtime. Service Fabric supports several different Service models, and can be categorized as being either Stateful Services or Stateless Services (the different service models will be discussed in an upcoming slide.) At runtime, services are deployed into a Cluster, where a cluster is a scalable collection made up of a set of either physical or virtual machines. Each machine (physical or virtual) that is part of a cluster is called a Node. Service Fabric manages distribution of services across the cluster based on placement criteria identified in the service’s configuration and also on the application’s resource balancing needs. The configuration for each service will include a partition scheme for that service, as well as instance and/or replica counts. Services can split data and processing across multiple partitions, which are then spread out across the nodes in a cluster. Stateless services have instances, whereas stateful services have replicas. Instances provide availability, in that in the event of a failure of one instance, the other instances continue to function. Replicas keep the state for a service in sync across multiple partitions; should one replica fail, one of the others will take its place and a new replica will be created.
• #10: Objective: To introduce the available models for service development in Azure Service Fabric Notes: There are 3 general categories of services that Azure Service Fabric can manage – “Reliable Service & Reliable Actor Applications”, “Guest Executable Applications”, and “Container Applications”. Reliable Service & Reliable Actor Services are built on top of .NET SDK frameworks provided by Azure Service Fabric. As such, they have programmatic access to service and service-fabric functionality. This includes accessing the Service Fabric Naming Service (resolve service instance URL by name) and integration with the instance lifecycle events, among others. Additionally, service instances are create as objects under the management of Service Fabric, instead of individual processes, which allows for higher density within the host cluster. These models will be discussed more in detail shortly. Guest Executable Services allow you to create a service that hosts an arbitrary executable. This executable can be written in any language you choose, and Service Fabric will take care of execution management tasks like ensuring the application is running and other orchestration tasks. Because guest executables are not built on top of the Service Fabric APIs, they have limited access internally to the Service Fabric functionality. Container Services can be thought of as an application-within-an-application, in that multiple services can be placed within a container. This includes supporting Reliable Services which include Stateless Services within a container (Linux only), Stateful Services within a container (Windows only), or arbitrary guest executables within a container. Additional Information: https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-deploy-existing-app https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-containers-overview
• #11: Objective: To introduce the Reliable Service programming models available in Azure Service Fabric Notes: Azure Service Fabric supports 2 different Reliable Service programming models – Stateless Service and Stateful Service (along with the Stateful Actor framework, to be discussed shortly.) Stateless services (as the name implies) do not include provisions for handling in-process state. Note that a stateless service *can* maintain state, it is just that the programming framework does not provide any tooling to that end. The state must be persisted to some external storage mechanism (like a database), and is not dissimilar from a typical stateless web application design. Stateful services include access to in-process state. The stateful information is both replicated and persisted to disk. Additionally, the stateful collections that are managed by Stateful Services also support transactions to ensure consistent operations. Additional Information: https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-introduction
• #12: Objective: To introduce the concept and impact of Partitioning in a Stateless Service Notes: Let’s take a look at the different Reliable Services and see how Partitioning allows Service Fabric to provide reliability and scalability. Since Stateless Services have no inherent state, the reliability and scalability come simply from numbers. Reliability exists because if one instance goes down, there are still other instances present to handle the load. Scalability is present because adding (or removing) nodes allows the service to handle additional (or reduced) volume. Here we have a Stateless Service running in 3 Partitions distributed across 3 Nodes. (Animation) If we add two more Nodes to the service, Service Fabric simply also create two additional service instances.
• #13: Objective: To introduce the concept and impact of Partitioning in a Stateful Service Notes: Providing scalability and reliability is a little trickier in a Stateful Service. In order to do so, we need to maintain distributed replicas of the state in each partition, keeping track of a primary Partition and a number of Secondary Partitions. Reliability exists because if Service Fabric is aware of a single node going down, it can rebalance using the Secondary partition replicas located on other nodes, promoting them to Primary nodes as necessary and creating new additional Secondary replicas. Scalability is present as long as the number of Nodes approaches the number of Partitions (when scaling up.) Once you have more Nodes than Partitions, the additional Nodes do not generally contribute to expanded capacity in the system. Here we have a Stateful Service running in 5 Partitions with 3 Replicas per partition, distributed across 3 Nodes. (Animation) If we add two more Nodes to the service, Service Fabric rebalances the existing partitions, easing the load on the original 3 Nodes.
• #14: Objective: To introduce the Reliable Actors framework available in Azure Service Fabric development Notes: The Reliable Actors framework is a Virtual Actor implementation that is built on top of stateful Reliable Services. In a Virtual Actor implementation, an Actor is a unit of both logic and state that is managed by the framework. Client applications reference an actor by a unique ID. The framework manages the allocation and lifetime of individual actor instances, including “resurrecting” an actor instance which has gone dormant due to a period of inactivity. Actor instances provide a turn-based, single-threaded access model, making it possible to not have to deal with concurrency issues in a distributed programming model. With this single-threaded behavior, Timers and Reminders both offer support for running code after a function call has completed. Timers and reminders differ mainly in that Timers cannot “re-awaken” a time-expired actor, whereas Reminders will continue to execute, “waking” a dormant actor instance as necessary, until the actor unregisters the reminder or the actor is explicitly deleted. Finally, actors also support raising events back to the calling application. Because of the nature of distributed programming, these events are not strictly guaranteed to reach their listeners (if reliable messaging is required, a queue-based or similar solution is recommended.) Additional Information: https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-introduction
• #19: Objective: Introduces the concepts related to developing Service Fabric projects with Visual Studio 2017 on Windows. For Linux, see https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-get-started-linux For Mac OS, see https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-get-started-mac
• #20: Objective: Show what needs to be done to install the Service Fabric SDK and development tools in Visual Studio 2017 Notes: The Visual Studio 2017 features a different take on the previous Visual Studio installers, where “Features” are replaced by “Workloads.” To install the Service Fabric tools in Visual Studio 2017, you select the “Azure development” workload from the “Web & Cloud” section in the installer. For Visual Studio 2015, see https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-get-started Note – in Visual Studio 2015, the Azure Service Fabric SDK and tools were deployed and updated via the Web Platform Installer. In Visual Studio 2017, these components have been moved to be part of the installation and update process for Visual Studio itself.
• #21: Objective: To show how to start a new Azure Service Fabric project in Visual Studio 2017 Notes: To create a new Azure Service Fabric project in Visual Studio 2017, select File/New Project, then select the “Service Fabric Application” option from the “Cloud” node. Notice the various Service project types that can be created: Stateless & Stateful Reliable Services An Actor Service A Stateless Reliable Service provisioned with ASP.NET WebAPI endpoints A Guest Executable Service A Container Service (in Preview) A Stateless Reliable Service provisioned with ASP.NET Core (this project can also be used for web projects that include user interface elements.)
• #22: Objective: To explain the folder and content layout of a typical Service Fabric solution Notes: When you create a new Service Fabric project in Visual Studio, your solution will be set up with at least 2 projects, each containing several important files. Each solution will include one Application Project (ServiceFabricDemo in the illustration) This project includes the configuration for the overall Application managed by Service Fabric (an application can include one or more services) The services node lists the services that have been included in this application – you can open this node and add or remove services The key file in this project is the Application Manifest file. This file identifies both the application type and the application version, and specifies the services that will make up the application as well as how the applications will be laid out in the Service Fabric cluster. The project also includes one or more Publishing Profiles which enable setting different application configurations for different deployment environments (for example, local deployment vs a cloud-based test cluster vs a cloud –based production environment.) Each solution will include one or more Service Projects (DemoStatelessApi in the illustration) This project includes the configuration for the overall Application managed by Service Fabric (an application can include one or more services) These projects will each include their own Service Manifest files, with the Service Manifest describing the service type, version, and other configuration options This project will also include the service’s code and configuration files
• #23: Objective: To discuss the Service Fabric Local Cluster for local development Notes: The Service Fabric Local Cluster is included as part of the Azure Service Fabric SDK, and is meant to provide you with a complete local development and testing environment in order to accelerate your developing and deploying Service Fabric applications. The Local Cluster allows you to stand up either a 1-node or 5-node clusters – 1 node clusters are quicker to provision and deploy, but 5-node clusters are closer to real-world deployments. It’s important to note that this isn’t an emulator or simulator; the Local Cluster runs the same Service Fabric runtime that you will use in your production deployments. You can manage the Local Cluster with the Local Cluster Manager app that will be present in your Windows System Tray after you install the Service Fabric SDK, or you can use PowerShell scripts to manage the local cluster. Visual Studio “knows” about the Local Cluster and is set so that when you start the debugger, the application will be built, packaged, and deployed to the Local Cluster.
• #24: Objective: To briefly introduce the Service Fabric Explorer tool Notes: Service Fabric deployments include the Service Fabric Explorer. This is a web-based tool that helps you see and manage the status of your cluster. You can use it to: See an overview of your cluster health and overall cluster information See and manage your deployed applications & services View and manage the nodes in your cluster
• #25: Objective: This section will discuss the options for scaling VM’s (VM sizes and storage) and also the concepts of reliability via Availability Sets
• #26: Objective: Describes the concept related to deploying a Service Fabric application in Azure Notes: In Microsoft Azure, Service Fabric applications are deployed over Virtual Machine (VM) Scale Sets. VM Scale Sets provide infrastructure for scaling workloads across multiple VM’s, as well as mechanisms for cluster management, scaling, and reliability. You can choose the size (and cost) of the VM’s that you application requires, and you can segment different service types to different collections of VM’s, grouped and isolated by subnets within an Azure Virtual Network (VNet), as well as choose to choose to use public-facing or internal-only load-balancing. Management of a Service Fabric Cluster in Azure is split across the Azure tooling - including the Azure Portal, command-line interfaces, and management APIs – as well as through the Service Fabric tooling via its management APIs tools such as the Service Fabric Explorer.
• #27: Objective: Describes the concept related to Service Fabric Application Upgrades Notes: There are two models for deploying applications to Service Fabric – Full Deployments and Upgrade Deployments. Full Deployments completely tear down an existing application and push up a new instance. Any state held by the Service Fabric partitions will be lost, and users are likely to experience downtime during this kind of deployment Upgrade Deployments use a concept known as Upgrade Domains, in which nodes in the cluster are partitioned into subsets and the upgrade is performed in a series of stages in order to ensure availability. Service Fabric will monitor the health of the system during the upgrade, and if the system health becomes degraded, the upgrade will be rolled back.There are actually 3 upgrade modes – Monitored Mode upgrades perform the upgrade one Upgrade Domain at a time, moving on to the next section only when the previous one has passed all of its health checks. Unmonitored-Auto upgrades merely skip the health checks. Finally, Unmonitored-Manual upgrades require you to upgrade each Upgrade Domain yourself.Note that in order to support rolling upgrades, both versions must be forward and backward compatible (since both versions of the code will co-exist for a time) More information about upgrades: https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-application-upgrade