Download to read offline
Uploaded byDaniel Toomey
Service Fabric Deployments
The document compares monolithic and microservices application architectures. A monolithic application contains most functionality within a few processes, while a microservices application separates functionality into independent services. Azure Service Fabric is a platform for building and managing microservices applications, allowing development and management of containers and microservices on any OS at scale on any cloud.
More Related Content
![[Jun AWS 201] Elastic Beanstalk for Startups](https://cdn.slidesharecdn.com/ss_thumbnails/aws201elasticbeanstalkforstartups-130708040156-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Service Fabric Deployments
More from Daniel Toomey
Service Fabric Deployments
- 3.
- 4.
- 6. Monolithic application approach •A monolithic application has most of its functionality within a few processes that are componentized with libraries. • Scales by cloning the app on multiple servers/VMs/Containers App 1
- 7. App 1 Monolithic applicationapproach Microservices application approach • A microservice application separates functionality into separate smaller services. • Scales out by deploying each service independently creating instances of these services across servers/VMs/containers • A monolithic application has most of its functionality within a few processes that are componentized with libraries. • Scales by cloning the app on multiple servers/VMs/Containers App 1 App 2
- 8. Run and secure servicesreliably at any scale Operate Deploy any code at any scale using tools you know Deploy Build new or transform existing applications Build Azure Service Fabric Build, deploy, and operate applications, using any OS, at any scale, on any cloud
- 9. Power BI Dynamics Intune Cortana Skype Cosmos DB IoTHub Event Hub SQL Database Azure Monitor Core Azure Services Archive Storage Azure DevOps Stream Analytics Azure Database for PostgreSQL Azure Database for MySQL Azure Container Registry Event Grid
- 10. Scenarios powered byService Fabric Lift & shift to containers Mission-critical business SaaS IoT data processing Low-latency data processing apps …one powerful Microservices platform for Windows Server and Linux. Any workload, running anywhere. New cloud- native apps
- 11. From monolith toMicroservice 5 stages in a continuum… ... Service Fabric can support any stage you choose New or transformed microservices app 5 Parts of existing monolith extracted 4 Existing Monolith + new microservices 3 Monolith Hosted as guest executable or container 2 Traditional app 1
- 12. To build, deploy,and operate… …containers or microservices on any OS on any cloud Programming Models Dev & Ops Tooling Orchestration Lifecycle Management Health & Monitoring Always On Availability Auto Scaling Azure On-premises infrastructure Other cloudsDev machine
- 13. Azure Cloud Services (Weband Worker Roles) • 1 service instance per VM with uneven workloads • Lower compute density • Slow in deployment & upgrades (VM Bound) • Slower in scaling and disaster recovery
- 14. Azure Cloud Services (Weband Worker Roles) Azure Service Fabric (Microservices) • 1 service instance per VM with uneven workloads • Lower compute density • Slow in deployment & upgrades (VM Bound) • Slower in scaling and disaster recovery • Many microservices per VM • High microservices density • Fast deployment & upgrades • Fast scaling and failover within the cluster
- 16. App1 App2 Service Fabric- Deployment App Type Packages Service Fabric Cluster VMs
- 17. App1 App2 Handling MachineFailures #FAIL App Type Packages Service Fabric Cluster VMs
- 18. Purple NodesGreen Nodes App1App2 Orchestration Basics - Constraints App Type Packages Service Fabric Cluster VMs
- 19. App1 App2 Orchestration Basics- Capacity App Type Packages Service Fabric Cluster VMs
- 20. App1 App2 Orchestration Basics- Balancing App Type Packages Service Fabric Cluster VMs
- 21. App1 App2 Orchestration Basics– Scaleout Service App Type Packages Service Fabric Cluster VMs
- 22. App1 App2 Orchestration Basics– Scaleout Cluster App Type Packages
- 23. UD3 UD2 UD1 App1 App2 Orchestration Basics- Upgrade App2.1 App Type Packages Service Fabric Cluster VMs
- 24. Stateful Microservices -Replication Primary Secondary Replication App Type Packages Service Fabric Cluster VMs
- 25. Node 5Node 4Node3 Node 6Node 2Node 1 Services can be partitioned for scale-out You can choose your own partitioning scheme Service partitions are striped across machines in the cluster Replicas automatically scale out & in on cluster changes P2 S S S P4 S P1 S P3S S S
- 34. Application Service Service Service NodeNode Node Node Cluster Partitions
- 35. Services are composedof code/config/data packages Code packages define an entry point (dll or exe) Config packages define service specific config information Data package define static resources (e.g. images) Packages can be independently versioned <ServiceManifest Name="QueueService" Version="1.0"> <ServiceTypes> <StatefulServiceType ServiceTypeName="QueueServiceType" HasPersistedState="true" /> </ServiceTypes> <CodePackage Name="Code" Version="1.0"> <EntryPoint> <ExeHost> <Program>ServiceHost.exe</Program> </ExeHost> </EntryPoint> </CodePackage> <ConfigPackage Name="Config" Version="1.0" /> <DataPackage Name="Data" Version="1.0" /> </ServiceManifest>
- 38.
- 40. Node “failure”: Rolling deployment: Deploymentfailure: CI/CD:
- 42.
- 43.
- 45.
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