Building Cloud Ready Apps
Download as PPTX, PDF0 likes104 views
This document provides an overview of building cloud-ready applications in .NET. It defines what makes an application cloud-ready, discusses common issues with legacy applications, and recommends design patterns and practices to address these issues, including loose coupling, high cohesion, messaging, service discovery, API gateways, and resiliency policies. It includes code examples and links to additional resources.
Building Cloud Ready Apps
- 1. Building Cloud Ready Apps in .NET
- 2. Layla Porter ● Developer advocate for .NET, VMware Tanzu ● Microsoft MVP, GitHub Star and Progress Ninja ● Founder, #WomenOfDotNet ● Pineapple connoisseur
- 4. A “cloud-ready” application is a legacy software program that has been modified to run on a cloud computing infrastructure.
- 5. Where you are now. and why you're probably not cloud-ready
- 6. What's wrong with my app? Hard to scale Hard to maintain Hard to release Hard to monitor Not resilient Tightly coupled
- 7. Cloudy Ready? Well, no, not really.
- 11. How do we get there? And things you may have heard of.
- 12. Build well-considered applications using good design principles and thoughtful processes
- 13. Some good patterns and ideas to get you started.
- 14. A sniff of domain driven design…. We're just skirting around the edge, here.
- 15. Loose coupling and High Cohesion This is a core design principle to keep in the forefront of your mind
- 16. Elements within a module have high cohesion and are tightly related to each other. This enables us to keep code loosely coupled, where we can write code within one module without impacting other modules.
- 17. The road to modularity And the modular monolith…
- 18. The options
- 19. You think you may need to go here
- 20. But, you'll end up here…
- 21. What you need to do
- 22. Where to start decomposition
- 23. Look for areas with High Cohesion and start there I told you it was important!
- 24. N-tier monolith Make vertical slices modular monolith
- 25. Large modules - keep things simple
- 26. Large modules - breaking them down into smaller modules as the need arises
- 27. Incrementally - choose one "domain" area and start with that Incrementally - choose one "domain" area and start with that Monolith Monolith Satellite
- 28. Implementation ideas for Cloud-Readiness Especially useful with modular and distributed apps
- 29. Messaging
- 30. Messaging is a form of asynchronous communication, often called non-blocking, is a way of passing information between different components of a system or different systems where the components do not need to be synchronized in real-time. It enables systems to communicate and work together while being decoupled from each other, which makes it a useful approach in many scenarios. What is it?
- 32. ● When there is a need to decouple components or systems and allow them to work independently. ● When processing time varies, and components or systems need to wait for a response. ● When there is a need to scale up the system or components. When should it be used?
- 33. ● A message broker is a middleware that enables communication between different components or systems using asynchronous communication. ● It receives messages from the sender (Producer) and delivers them to the recipient(s) (Consumer) based on predefined rules. ● It provides features such as message queuing, message transformation, and message routing. Message brokers
- 34. Error handling Asynchronous communication can result in errors, such as message loss, message duplication, or message processing failure
- 39. Like a phonebook for your apps
- 40. ● Service Discovery provides a centralized way of managing services in a distributed system. ● It allows services to register themselves with a registry and discover other services and their endpoints. Yay! Less work for us! ● This enables services to communicate with each other in a dynamic and scalable way. Benefits
- 41. Some common Service Discovery options Step 2 Service registry and discovery server for building distributed systems. Eureka Distributed service networking layer to connect, secure, and configure services across any runtime platform Consul Centralized service for maintaining config, naming, distributed synchronization, etc ZooKeeper
- 43. Demo with Steeltoe and Netflix Eureka
- 44. API Gateways
- 46. With a gateway
- 47. ● Acts as an entry point for all external requests to a system's backend. ● Provides a unified interface for clients to interact with the system's different microservices and APIs. ● Can handle tasks such as authentication, rate limiting, caching, and load balancing. In short…. An API gateway
- 48. Pros and Cons of API Gateway ● Provides a unified interface for clients to interact with ● Allows for centralized management of API versioning and security. ● Can improve performance by handling tasks such as load balancing and caching. ● Adds additional complexity to the system architecture. ● Requires careful consideration of security and access control, as API Gateway can act as a single point of failure. ● May introduce additional latency and overhead, especially for small-scale systems. Pros: Cons:
- 49. Blog posts .NET 6 & YARP https://bit.ly/net6_yarp .NET 6 & YARP & Eureka https://bit.ly/net6_yarp _eureka YARP Video https://bit.ly/yarp-video
- 50. Resiliency
- 51. An HTTP client needs to be resilient to failures, having policies in place and the ability to fail gracefully when failure cannot be avoided.
- 52. Policies are rules that define how an application should behave in different situations. Resilient applications use policies to handle errors, failures, and other unexpected events. What are policies
- 53. Retries ● A way to handle transient errors in distributed systems. ● When an error occurs, the application can automatically retry the operation, typically with some delay or backoff. ● Can help improve system availability and reduce the impact of temporary failures.
- 54. Circuit Breaker ● Helps prevent cascading failures in distributed systems. ● When a service fails or becomes unresponsive, it can prevent further requests from being sent to that service. ● Can help improve system availability and reduce the impact of failures.
- 56. Fallback ● A backup plan an application can use when a primary service or resource is unavailable. ● Resilient applications use fallbacks to provide a degraded, but still functional, user experience during failures.
- 58. Policy Premise AKA How does the policy mitigate Retry Many faults are transient and may self- correct after a short delay. "Maybe it's just a blip" Allows configuring automatic retries. Circuit-breaker When a system is seriously struggling, failing fast is better than making users/callers wait. Protecting a faulting system from overload can help it recover. "Stop doing it if it hurts" "Give that system a break" Breaks the circuit (blocks executions) for a period, when faults exceed some pre-configured threshold. Fallback Things will still fail - plan what you will do when that happens. "Degrade gracefully" Defines an alternative value to be returned (or action to be executed) on failure. Timeout Beyond a certain wait, a success result is unlikely. "Don't wait forever" Guarantees the caller won't have to wait beyond the timeout.
- 59. Policy Premise AKA How does the policy mitigate Bulkhead Isolation When a process faults, multiple failing calls can stack up (if unbounded) and can easily swamp resource (threads/ CPU/ memory) in a host. This can affect performance more widely by starving other operations of resource, bringing down the host, or causing cascading failures upstream. "One fault shouldn't sink the whole ship" Constrains the governed actions to a fixed-size resource pool, isolating their potential to affect others. Cache Some proportion of requests may be similar. "You've asked that one before" Provides a response from cache if known. Stores responses automatically in cache, when first retrieved.
- 60. Policy Premise AKA How does the policy mitigate PolicyWrap Different faults require different strategies; resilience means using a combination. "Defence in depth" Allows any of the above policies to be combined flexibly.
- 61. Combining Policies Resilient applications often use a combination of policies, such as retries, circuit breakers, and fallbacks, to provide a robust and reliable user experience.
- 64. How does is work?
- 65. ● Easily update configuration on running apps without downtime ● Ensure multiple instances of an app are using the same configuration ● Share config across multiple applications and services ● Versioning of configuration ● Decouples config from code Why?
- 66. Don't dox yourself! External configuration isn't always secret.
- 67. Providers Blob Storage Azure app configuration Spring Cloud Config Server Kubernetes Config maps and more…
- 69. Other Considerations ● 12 Factor App ● Security ● Testing ● Scalability ● Observability and Monitoring ● Distributed tracing
- 72. Link in zoom chat Please complete the Survey