Prepare abstract for I Handle Messages

[mikeminutillo]

No description provided.

[lailabougria]

Suggested change

In this interactive session, we will build a microservices system using an exclusive technology you can only find at the conference: volunteers from the audience. You will learn why microservices run in to problems when they're built on top of HTTP. We will add message queues to make our microservices architecture more robust and fault tolerant, and look at some other advantages we get too. You will leave the session ready to say "I Handle Messages".

In this interactive session, we will build a microservices system using an exclusive technology you can only find at the conference: volunteers from the audience. You will learn why microservices run into problems when built on top of HTTP. We will add message queues to make our microservices architecture more robust and fault-tolerant and look at some other advantages we get too. You will leave the session ready to say, "I Handle Messages".

[lailabougria]

Also, I very much like this paragraph, but I think maybe there's a way to improve the first sentence to better connect to the previous paragraph. There's a long jump between "we'll use a queue" to "we're building a microservices system using the audience". However, I'm not sure what that sentence should be :/
It would be great if that sentence also connects better to the last sentence: "You will leave the session ready to say, "I Handle Messages".", so that people have a good understanding of what they'll learn.

Maybe rephrasing the last sentence from the first paragraph helps: Message queueing technologies like RabbitMQ, Azure Service Bus, and Amazon SQS enable us to build event-driven architectures that are incredibly well-equipped at dealing with the challenges of remote/synchronous communication patterns.

[lailabougria]

Suggested change

Microservices rarely work in isolation. They talk. They collaborate. That often means making a remote call, and that's where things start to wrong. Networks go down. Important resources disappear. Remote microservices respond slowly or don't respond at all. Message queueing technologies like RabbitMQ, Azure Service Bus, and Amazon SQS can help.

Microservices rarely work in isolation. They talk. They collaborate. That often means making a remote call, and that's where things start to go wrong: Networks go down, important resources disappear, remote microservices respond slowly or don't respond at all, causing a plethora of failures that can bring a whole system down to its knees. Message queueing technologies like RabbitMQ, Azure Service Bus, and Amazon SQS can help.

It's a bit unclear to me what you mean with "Important resources disappear". Are you referring to infra failures?