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.

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

3. What does
cloud-ready
mean?

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.

8. Changing
tack.
(thinking cloud-ready)

10. Resiliency
Faster
development
time
Deployability
Automation
Maintainability
Enforcement of
design
Testability
Scalability

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

36. Demo with
RabbitMQ

37. Blog post
https://bit.ly/rabbit-topic

38. Service
Discovery

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

45. Without a gateway

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.

57. The Polly Project

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.

62. Video
https://bit.ly/apps-go-splat

63. External
Configuration

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…

68. Other
Considerations

69. Other Considerations
● 12 Factor App
● Security
● Testing
● Scalability
● Observability and Monitoring
● Distributed tracing

70. RabbitMQ:https://www.rabbitmq.com/
Steeltoe:https://steeltoe.io/
Polly:http://www.thepollyproject.org/
Links

72. Link in zoom chat
Please complete
the Survey

73. Thanks!
@LaylaCodesIt
@LaylaCodesIt @Layla-P
https://layla.dev