Luyện nói tiếng Anh bằng Shadowing qua video: Armchair Architects: Resiliency in the Cloud – Core Patterns

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.

Phương Pháp Shadowing Là Gì?

Shadowing là kỹ thuật học ngôn ngữ có cơ sở khoa học, ban đầu được phát triển cho chương trình đào tạo phiên dịch viên chuyên nghiệp và được phổ biến rộng rãi bởi nhà đa ngôn ngữ học Dr. Alexander Arguelles. Nguyên lý cốt lõi đơn giản nhưng cực kỳ hiệu quả: bạn nghe tiếng Anh của người bản xứ và lặp lại to ngay lập tức — như một "cái bóng" (shadow) đuổi theo người nói với độ trễ chỉ 1–2 giây. Khác với luyện ngữ pháp hay học từ vựng bị động, Shadowing buộc não bộ và cơ miệng phải đồng thời xử lý và tái tạo ngôn ngữ thực tế. Các nghiên cứu khoa học xác nhận phương pháp này cải thiện đáng kể phát âm, ngữ điệu, nhịp điệu, nối âm, kỹ năng nghe và độ lưu loát khi nói — đặc biệt hiệu quả cho người luyện IELTS Speaking và muốn giao tiếp tiếng Anh tự nhiên như người bản ngữ.

Luyện nói tiếng Anh bằng Shadowing qua video: Armchair Architects: Resiliency in the Cloud – Core Patterns

Tại sao nên luyện nói qua video này?

Cấu trúc ngữ pháp & Biểu thức trong ngữ cảnh

Các cạm bẫy phát âm thường gặp

Phương Pháp Shadowing Là Gì?