Service Fabric Deployments

Editor's Notes

• #7: Problem with monolithic application is complexity of deployment and lack of scalability at a granular level.
• #8: Service Fabric allows you to scales services independently, and not limited to one service per virtual machine. Looks complex, right?
• #9: Visual Studio, Azure DevOps, Yeoman, Octopus Deploy
• #10: Service Fabric runs several Million cores at Microsoft.
• #29: The recommended VM SKU is Standard D3 or Standard D3_V2 or equivalent with a minimum of 14 GB of local SSD. Reverse proxy addresses services in the cluster that exposes HTTP endpoints including HTTPS. greatly simplifies calling other services and their methods by having a specific URI format handles the resolve, connect, retry steps required for one service to communicate with another using the Naming Service. Hides the Naming Service from you when calling other services by making this as simple as calling a URL.
• #33: The certificate must contain a private key. The certificate must be created for key exchange, exportable to a Personal Information Exchange (.pfx) file. The certificate's subject name must match the domain used to access the Service Fabric cluster. This is required to provide SSL for the cluster's HTTPS management endpoints and Service Fabric Explorer. You cannot obtain an SSL certificate from a certificate authority (CA) for the .cloudapp.azure.com domain. Acquire a custom domain name for your cluster. When you request a certificate from a CA the certificate's subject name must match the custom domain name used for your cluster.
• #35: 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.
• #44: fa