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

13.
Dou you
know?

14.
150 Amazoncalls
APIs to Build a Page

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

16.
Sync Calls
HTTP

17.
HTTP CALLS
API
Response
API

18.
HTTP CALLS
API API

19.
HTTP CALLS

20.
NFRs
Availablity
Troughput
Reliability
Timeouts
Latency
Retries
Resilience

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

22.
async Calls
HTTP

23.
“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

24.
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

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

26.
gRPC

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

28.
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;
}

29.
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;
}

30.
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;
}

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.
Trough a message
broker
RPC

35.
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

36.
RPC
S H
Queues
Request

37.
RPC
S
Queues
Response
Request
H

38.
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

39.
Messaging Body
Header

40.
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

41.
Messaging

42.
ASYNC Message Processing

43.
S H
Queues
RequestRequest
Queue

44.
S
Queues
Response
Request
RequestRequest
H
Queue
Response
Response

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

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

47.
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

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

49.
WHY USE a messaging
system with MSA ?

50.
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

51.
Scalability
Scale up
Scale out

52.
Increased Throughput
38 267 vs 3500

53.
ElasticityScale down to
reduce costs

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

55.
Tools/Frameworks/Systems

56.
What options do I have?
plenty
Many more

57.
Data Types
Queues
Actor Model
Message Brokers

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

59.
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

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

61.
Message Brokers

62.
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

63.
Guarantees

64.
RabbitMQ

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

66.
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

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

68.
Topic Exchange

69.
References

70.
Distributed systems are
all about tradeoffs

71.
Http is not
the only
option!

72.
PLEASE DON’T FOLLOW
ME
@irina_scurtu

73.
Q&A