Pratique du Shadowing: Armchair Architects: Resiliency in the Cloud – Core Patterns - Apprendre l'anglais à l'oral avec la vidéo

Choisissez un mode d'entraînement

Chaque mode ouvre une salle d'entraînement en plein écran.

180 phrases

Si les phrases sont trop courtes ou trop longues, cliquez sur Edit pour les ajuster.

Hey, good news.

We're back in the middle of a discussion about resiliency in the Cloud.

This time, we're going to talk about the core patterns that make that possible.

Join us.

Welcome to the Azure Enablement Show, where we'll be discussing the challenges you and our other tech savvy customers have encountered.

Together, we'll be talking with extras to find out how they think about these problems, recommended tools and best practices, and tips they've learned from years of experience that you can use.

Today on the Azure Naval Show, we do something we've never done before.

We're going to take our script and we're going to simply

rip it up because we want to talk today about architecture and architecture is a discussion.

Hey, so welcome back.

This is a continuation of a previous discussion.

We were talking with Uli and Eric about resiliency, and we started to get into some concrete patterns and architectural patterns.

I thought we should just talk about that directly.

I want to get us right back into the conversation.

Eric, when we were last talking about this, you had a whole list of concrete architectural patterns to talk about.

Can we dig into those now?

Yeah, absolutely.

Maybe we should start with the simplest one that has probably been intangibly around for a long time.

If you're designing an application and it needs to connect to a resource, whether it's a microservice or a database,

the goal would be if one of those things are unavailable, then I got to retry.

I can't just try once, give up, and then return a failure message to the user.

The goal would be, I'm going to implement a loop or some sort to say, well, the database is not available, how about now?

How about now?

But I think that this might actually be dangerous.

You can't really implement these things myopically and in a vacuum.

Sometimes you have to stack them in your implementation.

Yeah, Eric, that's a really good point.

Especially when you're on the Cloud, cloud services protect themselves from abuse effectively.

And we call that throttling.

And it's really an important part of the cloud architecture.

So if you deploy or develop a service that you want to expose, you should really think about throttling architectures in your service as well,

which means if there are too many requests coming too fast,

the service starts to effectively discard those requests because it's trying to stay up and running and be available.

So as a person that implements the retry pattern, don't increase the frequency if you're failing.

We've seen unfortunately a lot of code that does exactly that because they think that asking more often, more frequently for connection makes it better.

It's actually the opposite.

So the first time you do a 30 second interval, the second time maybe you do 45 seconds

and then you might wanna give it a five minute break to see if the service you dependent on recovers.

And so there's other patterns that then come into play, where, for example, if your database isn't available right now,

hopefully you have built a cache of the data you need to display in the pages and so forth, so that the user interaction can keep going

while you in the background are trying to retry the connection so that you get to the latest and greatest content.

So I think there's a couple of patterns that you could almost put into a pipeline,

quote unquote, where you start with retry the service uses throttling to protect itself.

Then you effectively add caching as a pattern so

that you have something to show to the user that effectively keeps the system going.

Well, let's talk about caching a little bit because I think that is the next important pattern.

Caching, many of us think that that's done for performance.

I actually want to hit my cache

and have a high cache hit ratio before I make an expensive call to the slow path

which might be the Cloud or the database backend in my data center.

But caching to me actually has multiple dimensions.

But what Uli was talking about is user experience caching.

If my app is disconnected, expectedly or unexpectedly, I need to hit the cache for performance reasons

or to cover up some type of failure that the app depends on.

But cache also has non-func, so that's more of a functional capability for caching.

But cache also has a non-functional capability, and this is what Uli was talking about in one of our other videos,

which is maybe I actually cache the hard IP endpoints of my backend services.

So when DNS fails, I can still make a connection to my back end.

Yeah, the other piece I want to add to the caching pattern.

A lot of people think a cache is a cache is a cache.

And technically speaking, that's correct.

The important thing is that you need to understand the details of the attributes of the data you're trying to cache, because not everything can be cached.

So let me explain a little bit.

So when you're looking at a catalog, most of you don't even know a physical catalog anymore but when Sears was very popular,

they used to send out catalogs in printed form.

And that catalog is actually reference data in the larger sense of the word, because the Sears guys, as soon as you call them on the phone,

they would say, hey, which version of the catalog did you use?

And they would allow you to use up to two or three catalog versions before they ask you to say, no, sorry, we can't take this order anymore.

We will send you a new one, because the reference data that was in that catalog was outdated.

And so you need to really understand the property of the data you're putting into the cache.

Reference data is something that is effectively cut off the database, can be marshalled around, copied, and so forth, because it's read-only,

it has a fixed attribute, so it's perfect for caching.

There are other pieces of data like the shared inventory

that you have you don't want to put into a cache

because a cache doesn't have the properties of a database that allows you asset transactions and so forth.

So thinking through your data that you want to put in the cache is really important as part of this pattern.

And there's great documentation out there.

One of my favorite papers is from an ex-Microsoft person called Pat Halland.

And he wrote a paper in 2003 i think data on the inside

and data on the outside that was in the context of service oriented architecture

but there is a treaty in there around what data like reference data

and so forth is that i highly recommend any architect understand

and consume and then apply to their problem as best as is feasible okay

so we have so far retries caching um and throttling um I also heard something go by about circuits.

What's a circuit breaker pattern really?

Well, David, it's actually a way for an application to protect to effectively say,

look, I've now encountered so many errors from this database or whatever resource I'm trying to use,

and I'm okay with a certain threshold on errors, because I expect nothing goes perfect that would be awesome

but generally in life nothing does and

so i calculate i count the number of errors

and i start to see there are too many of them

and so what i'm doing is i'm throwing the circuit breaker

which protects my application from this rogue service or the service

that doesn't work and i'm indicating that i want to go down a different path

so for example eric mentioned the retry pattern so you keep on retrying

but at some point in time you have to say the service is dead

and the circuit breaker will then say go let down the other path

and the other path could be there is a secondary service you set up

100

so there's a backup database for example that you use to do this

101

or you have a cache where you normally don't go because you want to have the last and up-to-date information

102

But in the case of the circuit breaker triggering, you might want to go to the cache so that you can survive,

103

like the Netflix example we used in the other show episode.

104

So the circuit breaker is really indicating to the application it's time to stop what you did here

105

because it's not going to get you anywhere and move down a different path.

106

And I think it can be from both sides, right?

107

The resource itself can implement the circuit breaker pattern to detect a bad

108

or rogue application that might be overwhelming it with calls and to say, I'm going to shut you down because you now are exhibiting bad behavior,

109

which is going to compromise my ability to answer all of the good citizens that are asking for my resources.

110

Yeah, I think it's very interesting

111

because I had heard of this as a protective measure on

112

the server side the server is doing its best to keep itself alive.

113

It's like a submarine where you make sure you compartmentalize things sufficiently, you close the bulkhead.

114

Maybe that's the bulkhead pattern.

115

There's a pattern called the bulkhead pattern.

116

Yeah.

117

What's the bulkhead pattern?

118

Maybe that's where I'm getting confused here.

119

The bulkhead pattern is, the way I think about it is, the bulkhead pattern is just like a ship with multiple components, as you said, David.

120

The goal would be is if the water gets into the first compartment, is not going to drag down the whole ship because there are,

121

I'm not a shipbuilder, but there are compartments or bulkheads between the sensitive areas of the vessel.

122

And so think about applying that paradigm to an application where things run in pools.

123

And so if a application component becomes jeopardized, it's the pool that gets recycled or restarted while other pools continue their functionality.

124

So it's bad behavior around a specific pool of resources

125

gets contained and it doesn't spread or spill over into the other areas of functionality of the application.

126

And again, so David, sorry, if you're looking at the bulkhead pattern,

127

it actually gets coupled very nicely with some design thinking that I think everybody should go through.

128

What Eric was focusing on was the resources like the database pools and other things.

129

But there are other things.

130

When you looked at our first episode, we talked about how Netflix separates the catalog from the recommendations from the actual streaming itself.

131

For me, that's also bulkheads because you're starting to looking at a number of application workloads because every application has multiple workloads.

132

And for me, the first step an architect needs to do is to understand the application scenario end to end

133

and then start to say, okay, how do I partition my system

134

so that I can apply different high availability requirements The worst thing I think in Archicad to do, especially in the cloud world,

135

is apply a blanket set of patterns and technologies to the entire solution,

136

because that's going to be more expensive than it needs to be.

137

And now with cloud, you can actually pick and choose what makes sense for the specific scenario that you're looking at.

138

Your all-up application is not a monolithic thing anymore.

139

Again, Eric mentioned microservices as one way of implementing it.

140

But for me, the modeling of the application is a key activity

141

that then gets augmented with the implementation like microservices and the patterns that we have mentioned so far.

142

This sounds like really good advice.

143

I think we're going to run out of time on this particular episode.

144

Do either of you have 30 seconds of a piece of

145

advice you want to give people about designing Cloud applications for failure to wrap this up?

146

Yeah.

147

I think focusing on what the experience is going to be, is going to be crucial.

148

It will dictate what type of application design practices that you use and what failure and resiliency patterns that you employ.

149

I think thinking about it, to Uli's point, there's functional and non-functional implementations of these resiliency patterns.

150

Where I was talking about connection pooling and resource pooling,

151

he was talking about functional segmentations of capabilities and being able to have the bulkhead concept apply to those.

152

Think about things functionally to the infrastructure level, from a Cloud perspective and a microservice point of view.

153

Think about things from a functional level, which would be the apps and their domain and separation of concerns,

154

and then implement the patterns that will feed and support the desired user experience, both in failure and non-failure states.

155

Yeah, the only thing I would add here, Eric, is in the cloud world, we're living with two different life cycles.

156

In the on-premise world, what happens is your application gets deployed and then it's tightly managed from a change management perspective.

157

Infrastructure, your changes are very, very managed together.

158

And so that disruption is minimal.

159

In the cloud, the cloud provider will continue to make changes, enhancements to the services you rely on.

160

And in the general case, nothing happens.

161

You don't know this.

162

But you need to be prepared that some of these changes effectively lead to problems in your application.

163

And you can't ask the cloud provider to synchronize with your change management process because, again, you are just one of hundreds of thousands of customers running on that cloud.

164

So you need to think through how you live

165

or survive cloud failures or changes in the cloud service that you rely on.

166

and recollect your application and continue to run.

167

That's a new thing that the Cloud has really introduced that I think a lot of people struggle with at first,

168

but there are great news that there are patterns out there that can help you with that as well.

169

Maybe, David, we should do an episode on chaos engineering as a practice?

170

Yeah, I'm definitely up for that.

171

Let's do that in a future episode.

172

I think this is a really good place to stop.

173

Thank you both.

174

I look forward to talking with you some more on some other topics.

175

Awesome.

176

Thank you, David.

177

Thanks, David.

178

That was a really cool set of conversations.

179

I hope you get a chance to watch those episodes.

180

We're going to move on to another topic here on Armchair Architects as part of the Azure Enablement Show.

Télécharger l'application

Tout pour parler couramment

Prononciation IAChaque phrase notée

Phonétique (IPA)Maîtrisez chaque son

VocabulaireEnrichissez votre lexique

Jeu de vocabulaireApprenez en jouant

Scanner le QR

Download on theApp Store Get it onGoogle Play

Même chaîne

Introduction to Generative AI and LLMs [Pt 1] | Generative AI for Beginners

Business EnglishUniversity StudentsWorking Adults

FOR YOU

Vidéo recommandée

279 phrases

Redis Crash Course - the What, Why and How to use Redis as your primary database

Daily ConversationUniversity StudentsWorking Adults

Vocabulaire et conseils d’expression pour cette leçon

Cette vidéo contient 180 phrases et 2477 mots à répéter en shadowing. La partie parlée dure 14:11. Le locuteur parle à un rythme naturel d’environ 175 mots par minute, proche d’une conversation courante. 82 % des mots font partie des 3 000 mots les plus courants en anglais ; le reste mérite d’être vu avant de commencer.

Vocabulaire clé de cette vidéo

15 mots moins courants de la vidéo, avec leur prononciation et leur sens :

cache /kæʃ/ (nom) — cache, mémoire cache. Such a store of physical supplies, placed by humans or other animals for practical reasons.
cloud /ˈklaʊ̯d/ (nom) — nuage. A visible mass of water droplets suspended in the air.
database /ˈdeɪtəˌbeɪs/ (nom) — base de données, banque de données. A collection of (usually) organized information in a regular structure, usually but not necessarily in a machine-readable format accessible by a computer.
catalogue /ˈkæt.əˌlɔɡ/ (nom) — catalogue. A systematic list of books, names, pictures, etc.
functional /ˈfʌŋkt͡ʃənəl/ (adjectif) — fonctionnel. In good working order.
implement /ˈɪmpləmənt/ (verbe) — appliquer, exécuter. To bring about; to put into practice; to carry out.
breaker /ˈbɹeɪkɚ/ (nom) — casseur. Something that breaks (something else).
architecture /ˈɑː.kɪˌtɛk.t͡ʃə/ (nom) — architecture. The art and science of designing and managing the construction of buildings and other structures, particularly if they are well proportioned and decorated.
resource /ɹɪˈzɔːs/ (nom) — ressource. Something that one uses to achieve an objective, e.g. raw materials or personnel.
implementation /ˌɪmplɪmənˈteɪʃən/ (nom) — mise en œuvre. The process of moving an idea from concept to reality. In business, engineering and other fields, implementation refers to the building process rather than the…
capability /ˌkeɪ.pəˈbɪl.ɪ.ti/ (nom) — capacité. The power or ability to generate an outcome.
topic /ˈtɑpɪk/ (nom) — sujet, thème. A subject; a theme; a category or general area of interest.
infrastructure /ˈɪnfɹəˌstɹʌkt͡ʃə/ (nom) — infrastructure. An underlying base or foundation for a building, organization, or system.
server /ˈsɝvɚ/ (nom) — serveur. A program that provides services to other programs or devices, either in the same computer or over a computer network.
concrete /ˌkɑnˈkɹit/ (adjectif) — concret. Real, actual, tangible.

Les verbes à particule que vous entendrez

think about /ˈθɪŋk əˌbaʊt/ (verbe) — penser à, réfléchir à. To ponder.
look at (verbe) — regarder. To observe or watch.
rely on (verbe) — se fier à, compter sur. To be confident in.
ask for (verbe) — demander. To request; to order.
cover up (verbe) — cacher, dissimuler. To conceal or disguise.
cut off /ˌkʌt ˈɔf/ [ˌkɐɾ ˈɔf] (verbe) — tailler, couper. To remove by cutting.
dig into (verbe) — se plonger, s'attaquer (à). To research a particular subject.
find out (verbe) — découvrir, savoir. To discover, as by asking or investigating.

Prononciation à surveiller

Le locuteur utilise 46 contractions et formes réduites, comme I'm, you're, we're. Prononcez-les sous leur forme courte, telles que vous les entendez.

Les sons « th »: threshold /ˈθɹɛʃ(h)oʊld/, throttle /ˈθɹɔ.tl̩/, monolithic /ˌmɑ.nəˈlɪθ.ɪk/
Les sons « sh » et « zh »: cache /kæʃ/, implementation /ˌɪmplɪmənˈteɪʃən/, ratio /ˈɹeɪ.ʃoʊ/, interaction /ˌɪn.təˈɹæk.ʃən/, crucial /ˈkɹuː.ʃəl/
Mots longs — placez bien l’accent: architecture /ˈɑː.kɪˌtɛk.t͡ʃə/, implementation /ˌɪmplɪmənˈteɪʃən/, capability /ˌkeɪ.pəˈbɪl.ɪ.ti/, infrastructure /ˈɪnfɹəˌstɹʌkt͡ʃə/, architectural /ˌɑɹkɪˈtɛkt͡ʃəɹəl/

Comment s’entraîner avec cette vidéo

Écoutez la vidéo en entier une fois sans parler et notez les mots que vous ne connaissez pas.
Commencez à la vitesse 0,75×, répétez phrase par phrase, puis revenez à la vitesse normale quand cela devient facile.
Enregistrez-vous et comparez avec l’original, en faisant attention à des mots comme cache, cloud, database.

La grammaire de cette vidéo

Les structures que le locuteur utilise le plus, avec les mots exacts de la vidéo :

Structure	Dans la vidéo
Present perfect have/has + participe passé — une action passée qui compte encore maintenant	have encountered · they've learned · we've never done
Voix passive be + participe passé — l’accent est mis sur ce qui arrive, pas sur qui le fait	is disconnected · can be cached · was outdated

Qu'est-ce que la technique du Shadowing ?

Le Shadowing est une technique d'apprentissage des langues fondée sur la science, développée à l'origine pour la formation des interprètes professionnels. Le principe est simple mais puissant : vous écoutez de l'anglais natif et le répétez immédiatement à voix haute — comme une ombre suivant le locuteur avec un décalage de 1 à 2 secondes. Les recherches montrent une amélioration significative de la précision de la prononciation, de l'intonation, du rythme, des liaisons, de la compréhension orale et de la fluidité.

Technique du shadowing : lire le guide complet étape par étape →

Pratique du Shadowing: Armchair Architects: Resiliency in the Cloud – Core Patterns - Apprendre l'anglais à l'oral avec la vidéo

Choisissez un mode d'entraînement

Télécharger l'application

Introduction to Generative AI and LLMs [Pt 1] | Generative AI for Beginners

Microservices with Databases can be challenging...

STOP Running Code On Your Computer

Trust the Process: How to Design Teams That Actually Work

Cache Systems Every Developer Should Know

We've got separation of concerns wrong

How Do I Reverse Brain Rot?

Configure storage accounts | AZ-104 | Episode 16

CAP Theorem Simplified

The Only SaaS Moats Left in 2026

Database Sharding! Designing Data-Intensive Applications chapter 6

LangChain in 5 Minutes (Explained Clearly)