Forget About HTTP - DevSum

Transcript

1. Forget about HTTP Irina Scurtu @Irina_scurtu
2. Irina Scurtu ▪ Romania Based ▪ Software Architect @Endava ▪ Organizer of DotNetIasi user group ▪ I teach .NET ▪ https://irina.codes @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
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. “It’s perfectly fine to use sync HTTP Calls” ▪ Timeouts ▪ Availability ▪ Reliability ▪ Retries? ▪ Code Coupling?
23. async Calls HTTP
24. I’m gonna use async It will solve everything!
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. Service Discovery
30. Retry Policies 01 02 03 Circuit Breaker BulkHead Fallback
31. Tracing CorelationIds
32. gRPC
33. gRPC ▪ No-code references ▪ Contract based ▪ Uses HTTP/2 => faster ▪ Efficient ProtoBuf serialization => smaller payload ▪ Available in many languages ▪ Code generation
34. .proto file gRPC API 1 API 2
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. 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; }
38. 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; }
39. 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; }
40. 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; }
41. Non functional requirements NFRs Availablity Troughput Reliability Observability Latency Fault Tolerance Resilience
42. Coupling Temporal Logical
43. Trough a message broker RPC
44. 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
45. RPC S H Queues Request
46. RPC S Queues Response Request H
48. 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
49. Messaging Body Header
50. Headers What is a ‘message’ Request Message Verb Headers Body Your Name Here Verb
51. 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 -> increases reliability
52. Messaging
53. Async Message Processing
54. S H Queues Request Request Queue
55. S Queues Response Request Request Request H Queue Response Response
56. With a DB S Queues Response Request Request Request H Storage
57. With a DB s Queues Response Request Request Request H Storage
58. 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
59. Solutions to eventual problems ▪ Connection is scarce ▪ Batch process the message ▪ Use a semaphore to process them in batches
60. Why use a messaging system with Microservices?
61. 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
62. Better Scalability Scale up Scale out
63. Increased Throughput 38 267 vs 3500
64. Elasticity Scale down to reduce costs
65. A lot of ‘ilities’ ▪Reliability ▪Flexibility ▪Reliablity ▪Increased Throughput ▪Scalability ▪Elasticity ▪Performance ▪Agility ▪Fault Tolerance
66. Tools/Frameworks/Systems
67. What options do I have? plenty Many more
68. Data Types Queues Actor Model Message Brokers
69. Queues ▪Useful for point to point communication ▪Messages are ordered and timestamped ▪Pull-mode
70. 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
71. Reactive Manifesto 71 Responsive Resilient Elastic Message driven Scalable React to workload Elastic
72. Message Brokers
73. 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
74. Guarantees
75. Message Delivery types At MOST ONCE At least once Exactly Once
76. RabbitMQ
77. Message Brokers ▪Lightweight ▪Queues are FIFO ▪Support AMQP protocol ▪Easy to use, fast ▪At-least-once delivery
78. AMQP General Notes ▪ Async by nature ▪ Guaranteed message delivery ▪ No DNS resolve ▪ Programmatic routing ▪ Retries out-of-the box ▪ Ack, Nack out of the box
79. AMQP General Notes ▪ Has the “channel” concept
82. Topic Exchange
83. References
84. Distributed systems are all about tradeoffs
85. HTTP is not the only option!
86. PLEASE DON’T FOLLOW ME @irina_scurtu
87. Q&A @irina_scurtu
88. THANK YOU! https://irina.codes @irina_scurtu