Implementing the Reactive Manifesto with Azure and AWS

The Reactive Manifesto describes applications which are responsive, event-driven, scalable and resilient. This course shows you how to design, build, deploy and run Reactive applications in the cloud.
Course info
Rating
(107)
Level
Intermediate
Updated
Oct 30, 2013
Duration
3h 54m
Table of contents
Introducing the Course
Reactive Application Architecture
Reacting to Events
Reacting to Requests
Reacting to Failure
Reacting to Load
Course Summary
Description
Course info
Rating
(107)
Level
Intermediate
Updated
Oct 30, 2013
Duration
3h 54m
Description

Reactive solutions use a modern architecture to run smoothly and efficiently. In this course, you’ll learn how to build event-driven .NET applications, which dual-run on Windows Azure and Amazon Web Services. Learn how to deliver solutions which automatically scale up to meet demand, scale down to save costs, and can survive the failure of individual components, individual data centres, or even the whole cloud.

About the author
About the author

Elton is an independent consultant specializing in systems integration with the Microsoft stack. He is a Microsoft MVP, blogger, and practicing Technical Architect.

More from the author
Modernizing .NET Framework Apps with Docker
Intermediate
3h 42m
Dec 28, 2017
More courses by Elton Stoneman
Section Introduction Transcripts
Section Introduction Transcripts

Reacting to Events
Hi. My name's Elton, and welcome to Reacting to Events, the next module in Implementing the Reactive Manifesto with Azure and AWS. In this module we're going to start building our reactive application beginning with an event-driven website using server push, which will give our users an interactive experience. We're going to start it simple, and we'll focus on Azure for the first couple of modules. I already have a console application, which publishes events to an Azure topic, and another console app, which subscribes to them. So I'll demo those, to give a feel for how the communication works across Azure service bus. Then move over the presentation layer creating new ASP. NET SignalR website which will subscribe to the same topic and relay notifications out to clients. So, in the module we are going to look at Pub-sub messaging across Azure, with Topics, publishers and subscribers. We'll look at how SignalR and the underlying websocket technologies work. And how they enable a reactive design. We'll be supporting server push to broadcast notifications and client pull so when a client first connects, they can query the current status. And we'll look at configuring the startup for our web server, so when a new instance gets created, it's ready to start servicing clients as soon as it comes online. The reactive traits we'll focus on in this module are making the application responsive and event-driven. Of course, the presentation layer also needs to be scalable and resilient. And we'll lay the building blocks for that. But we'll cover them in more detail later in the course when we deploy the site to Azure and AWS. So, let's look at how Pub-sub messaging works in Azure.

Reacting to Failure
Hi. My name is Elton, and welcome to Reacting to Failure, the next module in Implementing the Reactive Manifesto with Azure and AWS. So far in the course, we've built our application based on the reactive architecture, and we've implemented the building blocks for all the reactive traits. And now we go into micro application robust by reacting gracefully to component failure. No matter how clever our solution architecture is, when it comes to fault tolerance, the basic approach is always the same. Add redundancy with spare components, which can take on the work if one component fails. In this module, we'll progressively add more levels of redundancy to our deployment. We're at level 0 at the moment, with no redundancy, so any failures will affect our app. Well go up to level 1 adding instances to our Azure deployment, so we get redundancy within the data center. And then to level 2 adding more instances in a different data center, which will give us availability if the DC in one region goes down. And then we'll add a whole new level of redundancy by deploying the application stack to Amazon Web Services. Running the application side by side on Azure and AWS so we get redundancy between clouds. And we'll finish by adding redundancy between data centers with an AWS, so we end up with a very highly available solution. By the end of the module, our solution will survive the loss of an Azure data center or an AWS data center, or one Azure DC, and an AWS DC, and even the loss of one entire cloud. And we'll have some fun in the demos, killing off big chunks of infrastructure and watching the app carry on regardless.