Download to read offline
More Related Content
Similar to From legacy to Azure Service Fabric in 360h. Odessa.
From legacy to Azure Service Fabric in 360h. Odessa.
- 1. From legacy toAzure Service Fabric in 360h By Stanislav Lebedenko Senior software developer @ Sigma software https://www.linkedin.com/in/lebedenkostanislav/ https://www.facebook.com/stas.lebedenko https://github.com/staslebedenko/bootcamp-v1
- 2. Where were we? Thestarting point Enterprise apps based on MS stack circa 2013 01 | Windows communication foundation services 02 | Wild mix of ASP.NET WebForms, MS AJAX 03 | Angular JS 05 | Classic windows services 06 | Azure and On-Premises virtual machines
- 4. Main goals 1 Beable to handle increased data throughput and scale on demand 2 Be on par with competitors, public resources should be modern and responsive 3 Introduce reliable services with fault tolerance, dynamically change service replicas count 4 Migrate small and cheap and optimize production cost along the way .5 Switch code base from .NET 4.0 to .NET Core 2.2 6 Get rid of DevOps duties, Better CI/CD and pull requests with Azure DevOps 7 Try fancy new tech, tackle chaos, add skills to Linked In :)
- 5. Focus on development, noton the infrastructure Shorter development cycle Virtually no maintenance Fast scalability on demand Fault tolerance Service Fabric runs on premises
- 6. Start small (and cheap) Checkprojected cost Consider twice cons and pros. Use three-point estimate pessimistic realistic optimistic
- 7. Architecture and tech stack NETCore, Onion, Stateless service
- 9. Expectations Vs Reality Estimated and realresult Expectation Reality
- 10. Key terms 01 |Service Fabric cluster 02 | Stateless - single partition service 03 | Stateful - multi partition service 04 | Reliable Actor - unit of compute 05 | Reliability, Durability, VM SKUs 06 | Service Fabric Load Balancer 07 | Virtual Machine Scale Set 08 | VNet for VMSS 09 | Load Balancer (probes, pools) 10 | Health probe 11 | Application insights
- 11. Infrastructure as acode Easiest of three Portal Primary Identity provider Primary tool Azure CLI Command line interface via bash For all other cases Powershell Actually have everything you need, but result code is lengthier
- 12. First issues Be preparedfor surprises. Some commands missing or deprecated in Azure CLI Sometimes Powershell is the only option Old Azure portal is needed for administrative access Lack of knowledge in particular areas of Service Fabric
- 13. SECURITY is a newfancy Securing your network Securing your cluster Keeping control over requests
- 14. Identity Server 4 IS4 Primary Identity provider .NET Core Identity Core ID Authentication application Azure Managed Identity AZ MIEasiest way to connect your applications to Key Vault
- 15.
- 16. Tricks and crutches Eachdeveloper is aware of them
- 18. Monitoring Event logging Application insights Deployyour project to Production
- 19. Scaling UP andDOWN 01 | Evaluate load on VMSS instances. 02 | Get list of instances in your region. 03 | Prepare scaling scripts. 04 | Prepare Powershell scripts for VM pfx certificates deployment. 05 | Scale up/down the VMSS is inherently an unsafe operation and so should be avoided if possible Consider it twice And backed up usage statistics. Its a bad idea to run it on Primary Node Easy and straightforward New VMSS nodes might not join your Service Fabric cluster
- 20. Consider Linux VMs 01| Twice as cheaper for 3 years 02 | More options with less SSD, more RAM 03 | Expertise in linux troubleshooting is required 04 | Issues with Nuget packages 05 | Known linux issues with .NET Core
- 21. Summary Keep up withtech Start small with concise short estimates and available resources. Look for alternatives. Migrate to Azure IaC is just brilliant and allows you to prototype, implement and deploy solutions fast. Give back to community Sharing is caring and also a good way to sharpen your skills and gain deeper understanding of technology. Learn your lessons Use of the new tech is not a walk in a park, you will learn a few lessons along the way. 01 02 03 04
- 22.
Editor's Notes
- #2 Main goal, share experience and promote easierpathways to the new technologies. You can work with newest tech even on small project, limited resources or even without them I'm an active member of Odessa Net community, trying have fun at work.
- #3 Topics Classic 3 tier apps, with Presentation, application and data layer. WCF Soap services Web Forms with MS Ajax, C# front end code, MVVM presenters and WCF service links Virtual machines with Server 2008, II7, NET Framework 4.0 - without possibility to upgrade Continuous integration with TeamCity and Octopus Deploy set up on machine without possibility to change something. Windows services executed on premises VMs Security issues and SSL 2.0, no TLS
- #4 Can be improved with Angular embedd into Microsoft AJAX Rewriting some of the pages Splitting software to pieces But still, just migrate
- #7 Gather development usage statistics, performance counters log is file based. Can you migrate all your code? Consider your data throughput in 6 months. Your customer might have plans for expansion. Estimate your hours carefully. It's wise to keep your estimate small enough, for a strong proposal, gather all maximum benefits for customer customers.
- #8 Moving from three tier to Onion is relatively easy, but you should properly understand both patterns Why 3 tier, easy to test, extend and even move business logic to Xamarin application. Main difference is dependency on Data in 3 tier, and Onion Architecture is based on the inversion of control principle. Onion Architecture is comprised of multiple concentric layers interfacing each other towards the core that represents the domain. The architecture does not depend on the data layer as in classic multi-tier architectures, but on the actual domain models. Composition Root in WebApi root is mixed bag, but its generally accepted pattern. Source of solutions arch is the experience, eShopOnContainers and general availability Between the layers of the Onion, there is a strong dependency rule: outer layers can depend on lower layers, but no code in the lower layer can depend directly on any code in the outer layer. This is essentially the Dependency Inversion Principle, just presented in terms of the overall architecture, not just single classes. To me, the essence of Onion Architecture is the application of Dependency Inversion Principle with architecturally defined priorities between layers. Jeffrey Palermo, in his original texts about Onion Architecture, stresses this a lot – the major difference between Onion Architecture and Layered Architecture is the direction of the dependencies (and hence coupling).
- #9 3 layers Infrastructure Scheduling/Orchestration Workload Infrastructure is a Virtual Machine Scale Sets. Elastic scaling of VMs Service location — A URL based mechanism for services to locate and communicate with each other. Workload Scheduling — Service Fabric provides initial workload placement, as well as re-placement in the event of a node failure. Health Monitoring — Metrics are exposed on both the overall health of the cluster, as well as the health of applications within the cluster Application Upgrade Orchestration — The system provides rolling upgrade orchestration so that an application can gracefully be upgraded, as well as fault detection supporting automatic fallback in the event of failure Application Manifest System — The system provides a robust manifest language allowing you to define to the fabric many settings regarding scale, placement, and configuration of your application within the cluster. Workload Containers — Added as a preview feature in 2016 Service Fabric can support container based workloads, specifically on the Linux variant today. Custom EXE — You can easily repackage an EXE with a manifest to be deployed to the cluster. Anything you want to run, just set it free in the fabric. Service Fabric Framework — A lot more on this below, this is the second of the two products referred to as Service Fabric. There is full GA support for Java, .Net, and preview support for .Net Core today.
- #10 Strange chart with 100% proportion Estimation vs reality. Azure Calculator particularly useful
- #11 Basics Stateless Reliable Service - everything you know. Rest, WCF, RPC and it coming with Web API template inside. Stateful Reliable Service - state is stored inside application and replicating between nodes himself, reliable dictionary and reliable queue Reliable Actor - actor model, exposes independent state and logic. ASF nodes, primary and non primary Tiers Durability tiers, amount of nodes/instances in VMSS Bronze for stateless and instances will be rebooted for Azure maintenance without notification. Use 3 minimum.You can use any vm possible.
- #13 Implement logging firsthand, seriously. We had so much pain. Move your critical configuration from appSettings to deployment profile. We learned it hard way too, this is the proper way to do it with variable and dynamic instances. Installation of the certificates on cluster machines, it took some time to get proper templates for deployment. Attempt to debug instance with visual studio resulted in total mess with load balancer. Undertanding of infrastructure issues, such as reverse proxy setup for SSL/ Serilog issues with multiple instances across nodes, even with applicatiom insights pipe. Some struggle with examples of Application insights template from microsoft
- #14 Monitor failed requests with Application insights. Use https and remove any http endpoints. Test your app with tools from Google and Mozilla. As well as back channel validation of authenticated user access rights, maybe if was overly
- #16 Do some load testing with Azure DevOps and Web Application Set up routine for application crush :), be prepared to redeploy cluster from scratch, stateless service is a benefit
- #18 Ok, you start hitting machine resources, or response time got bigger in general. Removal node from cluster migh result in issues and error state When you scale a cluster down you will see the removed node/VM instance displayed in an unhealthy state in the Service Fabric Explorer. You can: Call Remove-ServiceFabricNodeState cmd with the appropriate node name. Deploy service fabric autoscale helper application on your cluster which ensures the scaled down nodes are cleared from the Service Fabric Explorer.
- #19 Check your logging pipeline, cover as much as possible with custom actions, can you easily change target log level, to verbose on informational? Add Azure Monitor and proactive analysis Set up alerts, its mission critical stuff Are you ready for disaster, are your team take a proper drill? I`m sure you do, but in case you need a few tips and check list - you will obtain it. Usually, proper monitoring(including network impact), profiling and alerts are introduced after the first production issue, so this will be first point.
- #20 Be ready to scale Don't touch primary node, create new cluster and move state, same as with docker master node VMSS can auto scale, but you should have proper control over it. Understand difference between scale in/out and up/down Create and test short and concise scripts.
- #23 Key Vault via Azure CLI https://docs.microsoft.com/en-us/azure/key-vault/key-vault-manage-with-cli2 Fabric cluster capacity planning - https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-capacity#the-durability-characteristics-of-the-cluster Cluster creation via Portal https://docs.microsoft.com/en-gb/azure/service-fabric/service-fabric-cluster-creation-via-portal Node types and VMSS https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-cluster-nodetypes Swagger in .NET Core https://docs.microsoft.com/en-us/aspnet/core/tutorials/web-api-help-pages-using-swagger?view=aspnetcore-2.2 https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-best-practices-security Best general material - https://medium.com/@WorkloadRancher/decrypting-service-fabric-architecture-c2ef314fbf2e https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-introduction