Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

.NET Fest 2019. Irina Scurtu. Forget about HTTP

68 views

Published on

Microservices should be autonomous and independent, but what happens when your business domain doesn’t allow it, and you need to get data from other microservices? You’ll soon realize that simple HTTP calls are not enough anymore, or that your app is more brittle than ever and then you switch to messaging. With messaging you need to have a different mindset and be willing to embrace new challenges.
In this session, we’ll explore different ways of getting data from one ‘micro-service’ to another and while doing that we’ll talk about the benefits or the drawbacks of choosing an approach or another.

Published in: Education
  • Be the first to comment

  • Be the first to like this

.NET Fest 2019. Irina Scurtu. Forget about HTTP

  1. 1. Тема доклада Тема доклада Тема доклада KYIV 2019 Irina Scurtu Forget about HTTP .NET CONFERENCE #1 IN UKRAINE
  2. 2. Irina Scurtu  Romania Based  Software Architect @Endava  Organizer of DotNetIasi user group  I teach .Net @irina_scurtu
  3. 3. Agenda  Monoliths& Microservices  HTTP calls – sync & async  RPC  Messaging  Queues  Message Brokers  Actor Model
  4. 4. Easy life The Monolith
  5. 5. MONOLITH  Self-contained  Single codebase  Single deploy unit  Easy life for developers  Dependencies are in your code  Single technology stack
  6. 6. MONOLITH  All or nothing deploys  Downtimes  Long build times  ~ 0 continuous delivery  Hard to test
  7. 7. Scaling the MONOLITH Scale up
  8. 8. 2 1 5 3 monolith syndrome?
  9. 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. 10. MICROSERVICES?  Introduces complexity  Cascading effects in case of failure  Need to monitor them closely
  11. 11. 2 1 5 3 Independent units
  12. 12. 2 1 5 3
  13. 13. Dou you know?
  14. 14. 150 Amazoncalls APIs to Build a Page
  15. 15. 5 billions /day Netflix  services about 5 billions API calls/day  97.7 % are internal
  16. 16. Sync Calls HTTP
  17. 17. HTTP CALLS API Response API
  18. 18. HTTP CALLS API API
  19. 19. HTTP CALLS
  20. 20. NFRs Availablity Troughput Reliability Timeouts Latency Retries Resilience
  21. 21. “It’s perfectly fine to use sync HTTP Calls”  Timeouts  Availability  Going back to coupling?  You can loose requests  Retries?
  22. 22. async Calls HTTP
  23. 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. 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. 25. Challenges Service Discovery Retry policies Timeouts Routing Tracing
  26. 26. gRPC
  27. 27. gRPC  No-code references  Contract based  Uses HTTP/2 => faster  Efficient ProtoBuf serialization => smaller payload  Available in many languages  Code generation
  28. 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. 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. 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. 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. 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. 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. 34. Trough a message broker RPC
  35. 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. 36. RPC S H Queues Request
  37. 37. RPC S Queues Response Request H
  38. 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. 39. Messaging Body Header
  40. 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. 41. Messaging
  42. 42. ASYNC Message Processing
  43. 43. S H Queues RequestRequest Queue
  44. 44. S Queues Response Request RequestRequest H Queue Response Response
  45. 45. With a DB S Queues Response Request RequestRequest H Storage
  46. 46. With a DB s Queues Response Request RequestRequest H Storage
  47. 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. 48. Solutions to eventual problems  Connection is scarce  Batch process the message  Use a semaphore to process them in batches
  49. 49. WHY USE a messaging system with MSA ?
  50. 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. 51. Scalability Scale up Scale out
  52. 52. Increased Throughput 38 267 vs 3500
  53. 53. ElasticityScale down to reduce costs
  54. 54. A lot of ‘ilities’ Reliability Flexibility Distribution Increased Throughput Scalability Elasticity Performance Agility Fault Tolerance
  55. 55. Tools/Frameworks/Systems
  56. 56. What options do I have? plenty Many more
  57. 57. Data Types Queues Actor Model Message Brokers
  58. 58. Queues Useful for point to point communication Messages are ordered and timestamped Pull-mode
  59. 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. 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. 61. Message Brokers
  62. 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. 63. Guarantees
  64. 64. RabbitMQ
  65. 65. Message Brokers Lightweight Queues are FIFO Supports AMQP protocol Easy to use, fast At-least-once delivery
  66. 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. 67. AMQP General Notes  Has the “channel” concept
  68. 68. Topic Exchange
  69. 69. References
  70. 70. Distributed systems are all about tradeoffs
  71. 71. Http is not the only option!
  72. 72. PLEASE DON’T FOLLOW ME @irina_scurtu
  73. 73. Q&A

×