.NET microservices with Azure Service Fabric
Download as PPTX, PDF0 likes518 views
The document discusses the concept of microservices, their benefits, and challenges, including the transition from monolithic architectures to microservices. It highlights Service Fabric, a Microsoft technology that supports microservices architecture, offering features such as state management, lifecycle management, and deployment automation. The document also provides resources for further exploration, including demo code and reference documentation.
.NET microservices with Azure Service Fabric
- 3. Agenda • Microservices? • Service Fabric? • Microservices in Service Fabric? Demo code on GitHub: https://github.com/n3wt0n Slides on SlideShare: https://www.slideshare.net/n3wt0n
- 5. What is a microservice? • Encapsulates a single capability • Are developed by a small engineering team • Can be written in any language and framework • Contain code plus state that is independently versioned, deployed, and scaled • Interact with other microservices over well defined interfaces and protocols such as http • Have a unique name (i.e. URL) that can be resolved • Remains consistent and available in the presence of failures • Ideal for DevOps automation!
- 6. Reasons to split a monolith into services • Scaling independently (balancing cost with speed) • Supporting different technology stacks
- 7. Reasons to split a monolith into services • Two or more clients, where clients adopt new features at will • Managing conflicting dependencies
- 8. Are microservices right for my app? Maybe, if: • Your application can be split in many different, independent pieces • You need/want independent service scalability • You need/want to have multiple technologies, multiple teams involved • You are ready to change your DevOps practices and company culture But: • Any application that binds its components over a network connection introduces delays • Security and Authentication get more complex • Microservices are more complex to deploy, manage, and monitor • You cannot assume that you can take an arbitrary system and break it into microservices. Most systems acquire too many dependencies between their modules
- 9. From Monolith to Microservices ... we 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 5 stages in a continuum…
- 10. • Comparing an in-process call to an HTTP request • Performance: Worse & increases network congestion • Unpredictable time: Managing timeouts is challenging; pass deadlines • Unreliable: Requires retry loops with exponential backup/circuit breakers • Server code must be idempotent • Security: Requires authentication, authorization, & encryption • Debugging: network issues, perf counters/events/logs, causality/call stacks IntelliSense, refactoring & compile-time type-safety)
- 11. IntelliSense, refactoring & compile-time type-safety)
- 13. Proven platform powering core Azure and Microsoft services Microsoft has deep expertise in running global services such as Cortana, Skype & Cosmos DB Service Fabric is the foundational technology powering these services & core Azure infra Sample scale of one of these services: 60 billion events per day with millions of databases Production scenarios with 3500 VMs SQL { }Power BI Dynamics Intune Cortana Skype Cosmos DB IoT Hub Events Hub SQL Database
- 14. Build: data-aware microservices Lifecycle Management Always On Availability Orchestration Programming Models Health & Monitoring Dev & Ops Tooling Auto Scaling Programming Models Dev & Ops Tooling Orchestration Lifecycle Management Health & Monitoring Always On Availability Auto Scaling .NET or Java … Built-in ASP.NET core integration; work with VS and VSTS or Eclipse and Jenkins Reliable Services Manage state reliability without a database, lowering latency Guest Executables Run existing code and orchestrate life cycle using service fabric Reliable Actors Implementation of actor design pattern (Isolated, independent unit of compute and state with single- threaded execution) Containers Orchestrate your Windows Server or Linux containers reliably at scale </>
- 15. Deploy: any code on any OS Lifecycle Management Always On Availability Orchestration Programming Models Health & Monitoring Dev & Ops Tooling Auto Scaling Programming Models Dev & Ops Tooling Orchestration Lifecycle Management Health & Monitoring Always On Availability Auto Scaling Monitor and diagnose Generate, aggregate, and analyze events with built-in tooling and integration with Azure services Docker Compose Orchestrate existing container applications natively Automate Deploy or remove applications using PowerShell, CLI, Visual Studio, and other APIs CI/CD Maximize uptime and scalability with isolated compute threads running concurrently Rolling upgrades Upgrade non-disruptively and roll-back in case of failures, automate with PowerShell
- 16. Operate: on any cloud at any scale Lifecycle Management Always On Availability Orchestration Programming Models Health & Monitoring Dev & Ops Tooling Auto Scaling Programming Models Dev & Ops Tooling Orchestration Lifecycle Management Health & Monitoring Always On Availability Auto Scaling Scale programmatically Use PowerShell, CLI, or APIs to scale programmatically achieving very high densities Use controlled chaos Test graceful and ungraceful failure scenarios Recover gracefully Recover from node or service failure gracefully; replicate data automatically Use familiar tools Such as Splunk, OMS, ELK, or AppInsights to gain deep insights or monitor application health Secure at scale Secure node-to-node communication and user access using built-in capabilities
- 18. Awesome for developers Use .NET, Java or more • Stateless and Stateful services • ASP.NET core integration Visual studio integration • Use single node cluster for dev/test purposes • Use 5-node local cluster for extensive dev/test Consistent experience across environments • Run the same environment on dev box as in production
- 19. Awesome for dev-ops Automated deployment • Use PowerShell, Service Fabric CLI or APIs Rolling upgrades for reliability • Upgrade your services in an automated fashion Visual studio team services integration • For continuous integration and deployment Integration with Jenkins and more • Use tools familiar to you for deploying Java applications
- 20. Awesome for infrastructure management Cluster management • Secure your clusters and handle failures gracefully • Scale clusters programmatically or manually • Ease maintenance with integrated OS patching PowerShell, CLI, and GUI management • Be productive and choose tools that suit your needs Applications as an ARM resource • Manage clusters as well as deploy app using templates Health monitoring • Monitor using integrated or 3rd party tool of your choice • Query health using PowerShell or APIs programmatically
- 26. Cluster V1V1 V1V1 V1V1 V2V2 V2V2 V2V2 Cluster V1V1 V1V1 V1V1 V2V2 V2V2 V2V2 Cluster (or across 2 clusters) V2V2 V2V2 V2V2 V1V1 V1V1 V1V1 LB / Rev Proxy
- 27. • All API requests must pass version info starting with v1 • New service versions must be backward compatible • What about intra-service instance requests? • During rolling update, old & new service instances run together • Failure occurs if v2 instance makes v2 API request to v1 service instance • Fix by performing a 2-phase update 1. Deploy v2 service instances (which accept v2 & v1 API requests) • But never send v2 API requests 2. After all instances are v2, reconfigure instances to send v2 API requests • OPTIONAL: After all instances upgraded, deploy again with v1 code removed
- 30. • Services start/stop, scale up/down, & crash/move • Each instance has its own endpoint (dynamically-assigned IP/port) • Clients must dynamically discover service instance endpoints and load balance between them • Beware: a new service instance could be assigned a previous instance’s endpoint • This requires certificates or some ID/uniqueness so client knows which service it’s communicating with
- 31. Who is App1/Service1?There you go: 10.0.0.8:1234
- 32. Different ways
- 36. Stateless microservices pattern Load Balancer Front End (Stateless Web) Stateless Middle-tier Compute Cache StorageQueues
- 37. Stateless microservices pattern • Stateless services can have an external endpoint • Configure the endpoint in ServiceManifest.xml (especially the port) • For external accessible services, remember to configure Load Balancer • Stateless service instances are equivalent and activated “randomly”
- 39. Stateful microservices pattern Load Balancer Front End (Stateless Web) Stateful Middle-tier Compute Cold Data Stores (Optional)
- 40. Stateful microservices pattern • Stateful services cannot have an external endpoint • Stateful services must specify partitions • Stateful service instances are not equivalent and not activated “randomly” • Stateful services use Reliable Collections to persist the data
- 41. Reliable collections • Reliable collections make it easy to build stateful services. • An evolution of .NET collections for the cloud. Collections • Single machine • Single threaded Concurrent collections • Single machine • Multi threaded Reliable collections • Multi machine • Replicated (HA) • Persistence (durable) • Asynchronous • Transactional
- 43. Some notes… • Development • Service communication
- 45. References Demo Code and Slides https://github.com/n3wt0n https://www.slideshare.net/n3wt0n Service Fabric Reference Documentation https://docs.microsoft.com/en-us/azure/service-fabric/ Service Fabric Reference Architecture https://docs.microsoft.com/en-us/azure/architecture/guide/architecture- styles/microservices#microservices-using-azure-service-fabric
Editor's Notes
- #27: https://www.thoughtworks.com/insights/blog/implementing-blue-green-deployments-aws
- #37: Scale stateless services backed by partitioned storage Increase reliability and ordering with queues Reduce read latency with caches Manage your own transactions for state consistency
- #40: Stateful services eliminate much of the latency and complexity in applications that uses the stateless pattern and are unique to Service Fabric. Application state resides in the compute tier Low latency reads and writes Partitions are first class at the service layer for scale-out Built in transactions External stores for exhaust and offline analytics