Quali sono le insidie più comuni dello sviluppo del cloud in cui ti sei imbattuto?

Gli otto errori del calcolo distribuito:

"Essenzialmente tutti, quando creano per la prima volta un'applicazione distribuita, formulano le seguenti otto ipotesi: tutte a dimostrazione di essere false a lungo termine e tutte causano grossi problemi e dolorose esperienze di apprendimento.

1. La rete è affidabile
2. La latenza è zero
3. La larghezza di banda è infinita
4. La rete è sicura
5. La topologia non cambia
6. C'è un amministratore
7. Il costo di trasporto è zero
8. La rete è omogenea

Per maggiori dettagli, leggi l'articolo di Arnon Rotem-Gal-Oz "

link

Supponiamo che ogni nodo / macchina / istanza fallisca spesso. La tua architettura deve essere non solo tollerante di questi errori, ma anche aspettarsi che accada frequentemente. Quindi il tuo sistema non dovrebbe sopravvivere solo a tali incidenti, non dovrebbe nemmeno essere infastidito da loro e dovrebbe (idealmente) guarire se stesso quando accadono.

È la mia esperienza che determinate istanze cloud sono in genere molto meno affidabili (in tutti i parametri) rispetto ai normali vecchi server. La loro forza sta nei loro numeri e non in nessun nodo particolare. Quindi rendi il sistema distribuito e ridondante al suo interno.

Impara dalla Scimmia del caos .

We’ve sometimes referred to the Netflix software architecture in AWS as our Rambo Architecture. Each system has to be able to succeed, no matter what, even all on its own. We’re designing each distributed system to expect and tolerate failure from other systems on which it depends.

One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage.

Le stesse insidie che le persone hanno sulle piattaforme non virtualizzate.

• App che non vengono scalate orizzontalmente.
• Scelte / implementazioni algoritmiche scadenti
• Assenza di riduzione aggraziata di funzionalità e prestazioni in risposta a carico elevato / risorse ridotte.
• Ignoranza dei problemi comuni / probabili sulle piattaforme su cui esegui e un piano per mitigare tali rischi.