Shadowing Practice: Armchair Architects: Resiliency in the Cloud – Core Patterns - Learn English Speaking with Video
בחר מצב תרגול
כל מצב פותח חדר תרגול במסך מלא.
180 משפטים
אם המשפטים קצרים או ארוכים מדי, לחץ על ערוך כדי להתאים אותם.
1
Hey, good news.
2
We're back in the middle of a discussion about resiliency in the Cloud.
3
This time, we're going to talk about the core patterns that make that possible.
4
Join us.
5
Welcome to the Azure Enablement Show, where we'll be discussing the challenges you and our other tech savvy customers have encountered.
6
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.
7
Today on the Azure Naval Show, we do something we've never done before.
8
We're going to take our script and we're going to simply
9
rip it up because we want to talk today about architecture and architecture is a discussion.
10
Hey, so welcome back.
11
This is a continuation of a previous discussion.
12
We were talking with Uli and Eric about resiliency, and we started to get into some concrete patterns and architectural patterns.
13
I thought we should just talk about that directly.
14
I want to get us right back into the conversation.
15
Eric, when we were last talking about this, you had a whole list of concrete architectural patterns to talk about.
16
Can we dig into those now?
17
Yeah, absolutely.
18
Maybe we should start with the simplest one that has probably been intangibly around for a long time.
19
If you're designing an application and it needs to connect to a resource, whether it's a microservice or a database,
20
the goal would be if one of those things are unavailable, then I got to retry.
21
I can't just try once, give up, and then return a failure message to the user.
22
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?
23
How about now?
24
How about now?
25
But I think that this might actually be dangerous.
26
You can't really implement these things myopically and in a vacuum.
27
Sometimes you have to stack them in your implementation.
28
Yeah, Eric, that's a really good point.
29
Especially when you're on the Cloud, cloud services protect themselves from abuse effectively.
30
And we call that throttling.
31
And it's really an important part of the cloud architecture.
32
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,
33
which means if there are too many requests coming too fast,
34
the service starts to effectively discard those requests because it's trying to stay up and running and be available.
35
So as a person that implements the retry pattern, don't increase the frequency if you're failing.
36
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.
37
It's actually the opposite.
38
So the first time you do a 30 second interval, the second time maybe you do 45 seconds
39
and then you might wanna give it a five minute break to see if the service you dependent on recovers.
40
And so there's other patterns that then come into play, where, for example, if your database isn't available right now,
41
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
42
while you in the background are trying to retry the connection so that you get to the latest and greatest content.
43
So I think there's a couple of patterns that you could almost put into a pipeline,
44
quote unquote, where you start with retry the service uses throttling to protect itself.
45
Then you effectively add caching as a pattern so
46
that you have something to show to the user that effectively keeps the system going.
47
Well, let's talk about caching a little bit because I think that is the next important pattern.
48
Caching, many of us think that that's done for performance.
49
I actually want to hit my cache
50
and have a high cache hit ratio before I make an expensive call to the slow path
51
which might be the Cloud or the database backend in my data center.
52
But caching to me actually has multiple dimensions.
53
But what Uli was talking about is user experience caching.
54
If my app is disconnected, expectedly or unexpectedly, I need to hit the cache for performance reasons
55
or to cover up some type of failure that the app depends on.
56
But cache also has non-func, so that's more of a functional capability for caching.
57
But cache also has a non-functional capability, and this is what Uli was talking about in one of our other videos,
58
which is maybe I actually cache the hard IP endpoints of my backend services.
59
So when DNS fails, I can still make a connection to my back end.
60
Yeah, the other piece I want to add to the caching pattern.
61
A lot of people think a cache is a cache is a cache.
62
And technically speaking, that's correct.
63
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.
64
So let me explain a little bit.
65
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,
66
they used to send out catalogs in printed form.
67
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,
68
they would say, hey, which version of the catalog did you use?
69
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.
70
We will send you a new one, because the reference data that was in that catalog was outdated.
71
And so you need to really understand the property of the data you're putting into the cache.
72
Reference data is something that is effectively cut off the database, can be marshalled around, copied, and so forth, because it's read-only,
73
it has a fixed attribute, so it's perfect for caching.
74
There are other pieces of data like the shared inventory
75
that you have you don't want to put into a cache
76
because a cache doesn't have the properties of a database that allows you asset transactions and so forth.
77
So thinking through your data that you want to put in the cache is really important as part of this pattern.
78
And there's great documentation out there.
79
One of my favorite papers is from an ex-Microsoft person called Pat Halland.
80
And he wrote a paper in 2003 i think data on the inside
81
and data on the outside that was in the context of service oriented architecture
82
but there is a treaty in there around what data like reference data
83
and so forth is that i highly recommend any architect understand
84
and consume and then apply to their problem as best as is feasible okay
85
so we have so far retries caching um and throttling um I also heard something go by about circuits.
86
What's a circuit breaker pattern really?
87
Well, David, it's actually a way for an application to protect to effectively say,
88
look, I've now encountered so many errors from this database or whatever resource I'm trying to use,
89
and I'm okay with a certain threshold on errors, because I expect nothing goes perfect that would be awesome
90
but generally in life nothing does and
91
so i calculate i count the number of errors
92
and i start to see there are too many of them
93
and so what i'm doing is i'm throwing the circuit breaker
94
which protects my application from this rogue service or the service
95
that doesn't work and i'm indicating that i want to go down a different path
96
so for example eric mentioned the retry pattern so you keep on retrying
97
but at some point in time you have to say the service is dead
98
and the circuit breaker will then say go let down the other path
99
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.
הורד אפליקציה
כל מה שאתה צריך כדי לדבר בשטף
הגיית AIציון לכל משפט
תרגול IPAשלוט בכל צליל
אוצר מיליםבנה את מאגר המילים שלך
משחק אוצר מיליםלמד תוך כדי משחק
אותו ערוץ
![Introduction to Generative AI and LLMs [Pt 1] | Generative AI for Beginners](https://img.youtube.com/vi/lFXQkBvEe0o/mqdefault.jpg)
FOR YOU
המלץ על סרטון
C12
279 משפטים
Microservices with Databases can be challenging...
Daily ConversationUniversity StudentsWorking Adults
C11
251 משפטים
Things That Are Not What They Seem and the Truth About Life | Advanced Podcast for Conversations
Daily ConversationUniversity StudentsWorking Adults
C12
53 משפטים
Cache Systems Every Developer Should Know
Daily ConversationUniversity StudentsWorking Adults
C13
173 משפטים
STOP Running Code On Your Computer
Daily ConversationUniversity StudentsWorking Adults
C11
171 משפטים
What Does an AI Engineer Do Now? - Aparna Dhinakaran, Arize AI
Daily ConversationUniversity StudentsWorking Adults
C12
151 משפטים
We've got separation of concerns wrong
Daily ConversationUniversity StudentsWorking Adults
B21
375 משפטים
Configure storage accounts | AZ-104 | Episode 16
Daily ConversationUniversity StudentsWorking Adults
C12
82 משפטים
CAP Theorem Simplified
Daily ConversationUniversity StudentsWorking Adults
C11
689 משפטים
Database Sharding! Designing Data-Intensive Applications chapter 6
Daily ConversationUniversity StudentsWorking Adults
C1231 משפטים
Redis Crash Course - the What, Why and How to use Redis as your primary database
Daily ConversationUniversity StudentsWorking Adults
C12
52 משפטים
How to Avoid Doing UX Theatre
Daily ConversationUniversity StudentsWorking Adults
C11
346 משפטים
Trust the Process: How to Design Teams That Actually Work
Daily ConversationUniversity StudentsWorking Adults
אוצר מילים והערות הגייה לשיעור הזה
שיעור הדיבור הזה ברמה C1 מבוסס על הסרטון “Armchair Architects: Resiliency in the Cloud – Core Patterns”. המילים שחוזרות הכי הרבה: pattern, application, cache, cloud, bulkhead. בסרטון הזה יש 180 משפטים ו-2477 מילים לתרגול Shadowing. הדיבור נמשך 14:11. הדובר מדבר בקצב טבעי של כ-175 מילים בדקה, קרוב לשיחה יומיומית. 82% מהמילים נמצאות בין 3,000 המילים הנפוצות ביותר באנגלית; כדאי ללמוד את השאר לפני שמתחילים.
אוצר מילים מרכזי בסרטון הזה
15 המילים המתקדמות ביותר בסרטון, עם ההגייה והמשמעות שלהן:
| מילה | הגייה | משמעות |
|---|---|---|
| cache שם עצם | /kæʃ/ | מִצְבּוֹר, מַחְבּוֹא |
| bulkhead שם עצם | /ˈbʌlk.hɛd/ | מחיצה |
| catalogue שם עצם | /ˈkæt.əˌlɔɡ/ | קָטָלוֹג |
| throttle שם עצם | /ˈθɹɔ.tl̩/ | מַשְׁנֵק, מַצְעֶֽרֶת |
| attribute שם עצם | /ˈæt.ɹɪˌbjut/ | לוואי, לְוַאי |
| architect שם עצם | /ˈɑɹ.kɪˌtɛkt/ | אַדְרִיכָל, אדריכלית |
| disconnect פועל | /dɪskəˈnɛkt/ | ניתק |
| unquote | סוף ציטוט | |
| dictate פועל | /ˈdɪkˌteɪt/ | הכתיב |
| paradigm שם עצם | /ˈpæɹ.ə.daɪm/ | פָּרָדִיגְמָה |
| continuation שם עצם | /kənˌtɪnjʊˈeɪʃ(ə)n/ | המשך |
| feasible שם תואר | /ˈfiː.zɪ.bəl/ | בר ביצוע |
| submarine שם עצם | /sʌb.məˈɹiːn/ | צוֹלֶלֶת |
| premise שם עצם | /ˈpɹɛm.ɪs/ | הנחה |
| spill פועל | /spɪl/ | שפך |
Phrasal verbs שתשמעו
| מילה | משמעות |
|---|---|
| give up פועל | וִתֵּר |
| go down פועל | ירד |
משפטים שכדאי לחזור עליהם
משפטים קצרים ושלמים מהסרטון שאפשר להשתמש בהם בשיחה יומיומית:
- Can we dig into those now?
- What's a circuit breaker pattern really?
- Maybe that's where I'm getting confused here.
- Let's do that in a future episode.
דקדוק בסרטון הזה
המבנים שהדובר משתמש בהם הכי הרבה, עם המילים המדויקות מהסרטון:
| מבנה | בסרטון |
|---|---|
| הווה מושלם (Present perfect) have/has + past participle — פעולה שקרתה בעבר ועדיין יש לה חשיבות או השפעה עכשיו | have encountered · they've learned · we've never done |
| סביל (Passive voice) be + past participle — הדגש הוא על מה שקורה, לא על מי שעושה את הפעולה | is disconnected · can be cached · was outdated |
הגייה ששווה לשים לב אליה
הדובר משתמש ב-46 קיצורים וצורות מקוצרות, כמו I'm, you're, we're. אמרו אותם בצורה הקצרה, כפי שאתם שומעים אותם.
- הצלילים של “th”: throttle /ˈθɹɔ.tl̩/, monolithic /ˌmɑ.nəˈlɪθ.ɪk/, threshold /ˈθɹɛʃ(h)oʊld/
- הצלילים של “sh” ו-“zh”: cache /kæʃ/, partition /pɑɹˈtɪ.ʃən/, disruption /dɪsˈɹʌpʃən/, continuation /kənˌtɪnjʊˈeɪʃ(ə)n/, sufficiently /səˈfɪʃəntli/
- מילים ארוכות — שימו לב להטעמה: capability /ˌkeɪ.pəˈbɪl.ɪ.ti/, architectural /ˌɑɹkɪˈtɛkt͡ʃəɹəl/, compartmentalize /kəmˌpɑɹtˈmɛntəlˌaɪz/, expectedly /ɪkˈspɛktɪdli/, monolithic /ˌmɑ.nəˈlɪθ.ɪk/
צלילים שדוברי עברית מתקשים בהם:
- /æ/ — פתוח יותר מה-“אֶ” העברית, לא כמו “a” ב-“cup”: cache /kæʃ/, catalogue /ˈkæt.əˌlɔɡ/, attribute /ˈæt.ɹɪˌbjut/, savvy /ˈsæv.i/, paradigm /ˈpæɹ.ə.daɪm/
- /r/ — הלשון לא נוגעת בשום מקום, לא ה-“ר” הגרונית: retry /riˈtɹaɪ/, breaker /ˈbɹeɪkɚ/, throttle /ˈθɹɔ.tl̩/, compartment /kəmˈpɑɹtmənt/, attribute /ˈæt.ɹɪˌbjut/
- עיצור קולי בסוף מילה — /b/, /d/, /g/, /z/, /v/ בלי להפוך אותם לאטומים: bulkhead /ˈbʌlk.hɛd/, catalogue /ˈkæt.əˌlɔɡ/, rogue /ˈɹoʊɡ/, compartmentalize /kəmˌpɑɹtˈmɛntəlˌaɪz/, discard /dɪsˈkɑɹd/
איך לתרגל עם הסרטון הזה
- הקשיבו לכל הסרטון פעם אחת בלי לדבר, ורשמו את המילים שאתם לא מכירים.
- התחילו במהירות 0.75×, תרגלו Shadowing משפט אחר משפט, וחזרו למהירות רגילה כשזה מרגיש קל.
- הקליטו את עצמכם והשוו למקור, תוך תשומת לב למילים כמו cache, bulkhead, catalogue.
מהי טכניקת השאדואינג?
שאדואינג היא טכניקת למידת שפה מבוססת מדע שפותחה במקור להכשרת מתורגמנים מקצועיים ופופולרית על ידי הפוליגלוט ד"ר אלכסנדר ארגואלס. השיטה פשוטה אך עוצמתית: אתה מקשיב לאודיו באנגלית ילידית וחוזר עליו בקול רם מיד — כמו צל העוקב אחרי הדובר עם עיכוב של 1–2 שניות בלבד. בניגוד להאזנה פסיבית או תרגילי דקדוק, שאדואינג מכריח את המוח והשרירים בפה לעבד ולשחזר דפוסי דיבור אמיתיים בו זמנית. מחקרים מראים שזה משפר משמעותית את דיוק ההגייה, האינטונציה, הקצב, הדיבור המחובר, הבנת השמיעה ושטף הדיבור — מה שהופך אותו לאחת השיטות היעילות ביותר להכנה לIELTS Speaking ולתקשורת באנגלית בעולם האמיתי.