1. Тема доклада
Тема доклада
Тема доклада
KYIV 2019
Irina Scurtu
Forget about HTTP
.NET CONFERENCE #1 IN UKRAINE

2. Irina Scurtu
 Romania Based
 Software Architect @Endava
 Organizer of DotNetIasi user group
 I teach .Net
@irina_scurtu

3. Agenda
 Monoliths& Microservices
 HTTP calls – sync & async
 RPC
 Messaging
 Queues
 Message Brokers
 Actor Model

4. Easy life
The Monolith

5. MONOLITH
 Self-contained
 Single codebase
 Single deploy unit
 Easy life for developers
 Dependencies are in your code
 Single technology stack

6. MONOLITH
 All or nothing deploys
 Downtimes
 Long build times
 ~ 0 continuous delivery
 Hard to test

7. Scaling the MONOLITH
Scale up

8. 2
1 5
3
monolith syndrome?

9. MICROSERVICE
 it’s that thing that is not a monolith
 With it’s own database
 Easy to deploy
 Standalone
 Easy to maintain
Is it?

10. MICROSERVICES?
 Introduces complexity
 Cascading effects in case of failure
 Need to monitor them closely

11. 2
1 5
3
Independent
units

12. 2
1 5
3

15. Dou you
know?

16. 150 Amazoncalls
APIs to Build a Page

17. 5 billions
/day
Netflix
 services about 5
billions API
calls/day
 97.7 % are internal

18. Sync Calls
HTTP

19. HTTP CALLS
API
Response
API

20. HTTP CALLS
API API

21. HTTP CALLS

22. NFRs
Availablity
Troughput
Reliability
Timeouts
Latency
Retries
Resilience

23. “It’s perfectly
fine to use sync
HTTP Calls”
 Timeouts
 Availability
 Going back to
coupling?
 You can loose
requests
 Retries?

24. async Calls
HTTP

25. “It’s perfectly fine to use async HTTP Calls”
You’ll have exactly the same issues as with sync
calls
Distribute load?!
You can serve more request
You can serve the requests faster

27. HTTP General Notes
 Sync by nature
 Make a TCP connection for each request
 No retry out of the box
 No delivery guarantees
 Location transparency
 Good for public facing APIs
 Familiar
 Easy to debug

28. Challenges
Service Discovery
Retry policies
Timeouts
Routing
Tracing

29. gRPC

30. gRPC
 No-code references
 Contract based
 Uses HTTP/2 => faster
 Efficient ProtoBuf serialization => smaller payload
 Available in many languages
 Code generation

31. syntax = "proto3";
option csharp_namespace = "MyFirstGrpc";
package Fibonacci;
// The service definition.
service Fibo {
rpc ComputeFibonacci(RequestedNumber) returns (FibonacciResult){}
}
//the request message format
message RequestedNumber {
int32 number = 1;
}
//the response message format
message FibonacciResult {
int32 result = 1;
}

32. syntax = "proto3";
option csharp_namespace = "MyFirstGrpc";
package Fibonacci;
// The service definition.
service Fibo {
rpc ComputeFibonacci(RequestedNumber) returns (FibonacciResult){}
}
//the request message format
message RequestedNumber {
int32 number = 1;
}
//the response message format
message FibonacciResult {
int32 result = 1;
}

33. syntax = "proto3";
option csharp_namespace = "MyFirstGrpc";
package Fibonacci;
// The service definition.
service Fibo {
rpc ComputeFibonacci(RequestedNumber) returns (FibonacciResult){}
}
//the request message format
message RequestedNumber {
int32 number = 1;
}
//the response message format
message FibonacciResult {
int32 result = 1;
}

34. syntax = "proto3";
option csharp_namespace = "MyFirstGrpc";
package Fibonacci;
// The service definition.
service Fibo {
rpc ComputeFibonacci(RequestedNumber) returns (FibonacciResult){}
}
//the request message format
message RequestedNumber {
int32 number = 1;
}
//the response message format
message FibonacciResult {
int32 result = 1;
}

35. syntax = "proto3";
option csharp_namespace = "MyFirstGrpc";
package Fibonacci;
// The service definition.
service Fibo {
rpc ComputeFibonacci(RequestedNumber) returns (FibonacciResult){}
}
//the request message format
message RequestedNumber {
int32 number = 1;
}
//the response message format
message FibonacciResult {
int32 result = 1;
}

36. syntax = "proto3";
option csharp_namespace = "MyFirstGrpc";
package Fibonacci;
// The service definition.
service Fibo {
rpc ComputeFibonacci(RequestedNumber) returns (FibonacciResult){}
}
//the request message format
message RequestedNumber {
int32 number = 1;
}
//the response message format
message FibonacciResult {
int32 result = 1;
}

37. Trough a message
broker
RPC

38. RPC
 A kind of API call
Done through a message broker
 Ties systems together but preserves their
encapsulations
Makes an external system look ‘local’
No direct code dependencies

39. RPC
S H
Queues
Request

40. RPC
S
Queues
Response
Request
H

42. Gain vs Loss
You don’t lose the requests
You can add more handler instances
You can ‘apparently’ spread the load
You can process more requests
 Need to match the request
to the response
 Is still sync

43. Messaging Body
Header

44. Messaging
Gives you loosely coupled integration
Doesn’t require both systems to be up
Messages ca be transformed in transit - Enrichers
Messaging systems trade consistency for availability
You don’t lose messages
Involves a Producer and a consumer

45. Messaging

46. ASYNC Message Processing

47. S H
Queues
RequestRequest
Queue

48. S
Queues
Response
Request
RequestRequest
H
Queue
Response
Response

49. With a DB
S
Queues
Response
Request
RequestRequest
H
Storage

50. With a DB
s
Queues
Response
Request
RequestRequest
H
Storage

51. Gains
• Is a reaction to the problems
of distributed systems
• Process more requests
• Process request faster
• Don’t lose requests
 You move the potential
issues to another
subsystem (DB in our case)
 Eventual consistency
remains a problem
Loss

52. Solutions to eventual problems
 Connection is scarce
 Batch process the message
 Use a semaphore to process them in batches

53. WHY USE a messaging
system with MSA ?

54. Agility
Faster development
No integration process
You depend only on a response
Teams have ownership and full understanding of the codebase
You can switch technologies if needed

55. Scalability
Scale up
Scale out

56. Increased Throughput
38 267 vs 3500

57. ElasticityScale down to
reduce costs

58. A lot of ‘ilities’
Reliability
Flexibility
Distribution
Increased Throughput
Scalability
Elasticity
Performance
Agility
Fault Tolerance

59. Tools/Frameworks/Systems

60. What options do I have?
plenty
Many more

61. Data Types
Queues
Actor Model
Message Brokers

62. Queues
Useful for point to point communication
Messages are ordered and timestamped
Pull-mode

63. Actor model
Born from Reactive Programming
Actors are processes that encapsulate behavior
Actors are more than message consumers
Can delegate and create new actors
Can supervise children
At most once delivery

64. Reactive Manifesto
Message Driven
ResilientElastic
Responsive
Async message
Loose coupling
Location transparency
Scalable
React to workload
changes
Failures are self contained
Recovery
Isolation

65. Message Brokers

66. Message Brokers
One process sends a message to a named queue/topic
One or many consumers
Handles connections and disconnections
Dead-letter queue concept
Message Guarantees ( 3 types)
Different Protocols

67. Guarantees

68. RabbitMQ

69. Message Brokers
Lightweight
Queues are FIFO
Supports AMQP protocol
Easy to use, fast
At-least-once delivery

70. AMQP General Notes
 Async by nature
 Guaranteed message delivery
 At-least once, exactly once, at most once delivery
 No DNS resolve
 Programmatic routing
 Retries out-of-the box
 Ack, Nack out of the box
 Has the “channel” concept

71. AMQP General Notes
 Has the “channel”
concept

74. Topic Exchange

75. References

76. Distributed systems are
all about tradeoffs

77. Http is not
the only
option!

78. PLEASE DON’T FOLLOW
ME
@irina_scurtu

79. Q&A