Browsed by
Tag: cloud

Going Cloud: the 8 don’ts

Going Cloud: the 8 don’ts

Okay, let’s face it: the world is figuring out that cloud is for everyone, and not just for large-scale enterprises. This is a big step ahead, but when it comes to smaller companies there are still many misconceptions and wrong expectations.

Wrong expectations are the main push back reason, because they usually lead to catastrophic failures and disasters that leave migrating back to a legacy infrastructure design as the only option left.

datacenter_scale

(Image Source: XKCD)

But, comes out, it’s easier than you would expect. There is a basic set of rules and guidelines, and if you follow them then there is a 99.99% change you will be successful.

Let’s start today with the 8 don’ts.

  1. Never, ever trust a single hosted service. Don’t rely on redundant database platforms, replicated block devices, and many more. They can still go down: planning for failure on the application layer is the thing to do.
  2. Don’t put all your eggs in a single bucket: cloud platforms are based on different locations by nature, so you really should leverage this feature. True geographical redundancy can be hard to achieve, but try at least to have read replicas spread over the world, so that in case of downtime of your main region your service would just be degraded and not completely unreachable.
  3. Don’t think small. Some design patterns could seem overkills at first sight, but believe me, they are not. If you focus on designing your service so that it is ready for scaling up since the beginning, you won’t have to worry about later.
  4. Don’t implement complex software platforms: micro services are the way to go. Keep them simple and easy to maintain. It will be easier to scale each of them not only from a technical point of view: imagine how easy could be handing over not a part of a complex software, but a micro service to a new dedicated development team.
  5. Never forget that performance is the key: a killer SQL query could still be affordable if you have a low number of users, but is going to be an issue in the future. Make your platform as efficient as possible, also when it doesn’t seem strictly needed (yet).
  6. Don’t forget that everything could break, everytime. Keep your instances as simple as possible, so that they are easy to maintain. If one fails or starts misbehaving, just respawn it, don’t waste your time trying to fix. In an ideal world, they should be stateless.
  7. Vertical scaling is a no go. Choose the size of your instances based on the performance you want the single request to have, but always spread multiple requests horizontally. This will help the overall availability as well.
  8. Don’t be ‘legacy’: the world around you is moving very fast, and just looking at it makes no sense. New releases of software packages usually improve their performance, and new versions of the services your cloud provider is offering you usually improve everything, especially cost. Running a legacy instance type just because your platform is too hard to upgrade to a newer operating system, makes no sense and is going to kill your business in the long term.

Here we are. And now go and build!

A look into the scale of the Cloud

A look into the scale of the Cloud

I’ve spent hours doing various kinds of maths in order to figure out how big the big cloud providers actually are, and I tought it was worth sharing (part of) the results. Before showing you the numbers, I want to make sure who reads this post fully understands the method and the results, so please don’t jump to the numbers.

The most difficult part of the job was figuring out a way for measuring their size. Provided that my aim is not to calculate how big a single cloud provider actually is, but rather how they compare to each other, I decided to count the number of public IP addresses the company is using.

This number could seem easy to understand, but believe me it is not. It means nothing if you want to measure the size of a single platform, because we don’t know how those IP addresses are being used internally, and don’t know how many of them are being used by customers.

Moreover, we are in the cloud era, and thousands of instances could be hidden behind a single frontend with a single public IP: in this case, my calculation method would count them all as a single instance. This is the reason why I’m making a distinction between leaders and low cost providers.

It’s all about their typical use case: low cost providers generally don’t host big infrastructures or clusters, so their instances are more likely to be using public IP addresses. Leaders are hosting very large scale platforms, and they are more likely to host extremely high percentages of non public facing instances.

I’m counting for each cloud provider the number of IP addresses announced by its Autonomous System(s). In addition, leaders publish a list of IPs that they use (see Sources), but I’ve found this list to be used in different ways: Microsoft Azure for example is announcing all the ranges included in its list, but Amazon is not. I double checked and the ranges not being announced are really assigned to Amazon, so this simply means they aren’t being used (yet).

This is making the comparation yet more difficult to carry out, because in it we have players that simply announce to the internet any range they own, and others that announce only the ones actually in use or soon to be.

Finally, here are the numbers (remember the unit of measure is the single public IP address).

Leaders

Amazon Microsoft Google
Announced 11,202,304 19,593,984 1,377,024
Declared 19,022,512 7,501,920 556,800

Low Cost

OVH DigitalOcean Hetzner Linode Online.net
Announced 1,709,312 930,560 906,752 325,632 311,296

And a graph.

image

Do you think I forgot someone? Please let me know!

Giorgio

Sources

Announced: IP ranges announced from the company’s one or more Autonomous Systems.

Declared: Amazon Web Services, Google Cloud*, Microsoft Azure.

* Ref: “Where can I find Compute Engine IP ranges?”

What an IaaS service is. And what it is not.

What an IaaS service is. And what it is not.

The term “Cloud Computing” has been openly used for almost ten years now, but there are still some misconceptions around the concept itself and around some more specific words like “IaaS” (Infrastructure as a Service).

Sometimes I have to face pointless discussions with people that have completely wrong ideas and expectations: this can be annoying from my point of view, but can be catastrophic for realities deciding to make “the big move” without having completely understood what the cloud is all about.

iaas

If you have come across this post as you’re still trying to figure out what “Cloud Computing” and “IaaS” mean, then let me save your life and probably your job with some clarifications.

The market offering isn’t helping us, as service providers are confused as well and they use to define “IaaS” completely unrelated products. The US NIST has released a document containing a list of 5 “Essential Characteristics” of cloud services, but they are not so specific and won’t help you make any choice.

When words are being used in such a confused way, you have to decide which of the many interpretations is the “authoritative” one: my authorities for this article are Amazon Web Services (and not because I work for them, but because ten years ago they have been the first at offering an IaaS platform) and OpenStack (that is, AWS concepts and terms reviewed by the biggest open source community in the cloud computing world).

So, what you should expect or not expect from an IaaS offering?

  • You should expect to be billed based on a Pay as you go model. Let’s be serious, if you have to pay an one time or monthly fee for your account and/or services you are using then this is not really cloud. Offering pay as you go services is a real technical challenge for the service provider, and if they aren’t giving you this option then you should have some doubts about them being up to date with the technology. Some providers will offer you discounts on long term commitments and this is fine, but always look for the PayG option, please.
  • You should expect to have full access to API and CLI tools and not just to a GUI. This is critical also if you are not planning to use them from the beginning. Cloud is all about automation, and if you stick with a service that only offers a GUI, then you will be forever bound to your mouse (and hands): if you come from an on premise physical server environment you could not see my point right now, but in the cloud you will start using automation soon, at least in its basic form. Because it’s easy and useful.
  • You should not expect your instances (virtual machines) to be always available. This is something I’ve already blogged about a few years ago (in italian, I’m sorry) but it’s still one of the biggest, most spread and more dangerous misconceptions. Cloud services are based on commodity hardware, and thus the instances on top of that should be considered in the same way, as a commodity. The single instance could be there or couldn’t be, and your customers don’t have to notice: you have to plan for high availability at application level, taking into account the various kinds of failure. Some additional services like Block Storage, Object Storage and Load Balancing as a Service will help you achieving the high levels of availability you need. If your service provider is offering you an extreme level of HA, then you’re probably paying for something you don’t need (if you’re using 5 web nodes, then what’s the matter if one of them goes down for a while?).
  • You should expect instant provisioning: seriously, provisioning has to happen in seconds. Be careful not to underestimate this: you could be happy with a 24 hours delivery time for your first bunch of servers, but believe me you won’t be when you will need to rapidly scale because of a traffic peak. Maybe I’m being too picky here but I expect the provisioning of my account to happen in real time as well: I’m not happy with providers asking me to send a physical signed contract or my IDs before using their service.
  • You should expect the service you choose not to have limits that could (and will) impact you. Okay, not all of us need the scale of AWS, but make sure your provider won’t go out of capacity when you will need it: planning for infrastructure is their job, and from your point of view you must always be able to use the resources you need, when you need them, with no previous commitment.
  • You should (probably) expect to have access to multiple autonomous regions: being it for active-active HA or just for backup and disaster recovery purposes, doesn’t make so much sense to choose a provider that is hosting its entire platform in a single datacenter. Yes, you could choose to use 2 different services providers hosting services in different locations, but this is not going to be easy to deal with.
  • You should (probably) expect not to be locked in by small-scale service providers: always look for open standards, expecially if the company you’re buying resources from is still at a scale where going out of business from one day to another is a (remote) possibility.
  • You should not expect to be able to easily scale vertically (increase instance size, or a single resource inside the instance): cloud computing is based on horizontal scalability (that means adding building blocks, not making the existing ones bigger), and this is why service provider don’t focus so much on hot resize of instances or on the ability to add RAM if you need RAM without modifying anything else. This is related to availability as well: if you can’t afford a planned downtime on a single instance in your infrastructure, then you’re doing something wrong.

That’s it, at least for now. I’m sure moving to the cloud is the right choice almost for every company in the world, but please make sure you fully understand it before making any choice. Really.

Giorgio

Design for failure

Design for failure

“Scusa ma non siamo capaci di offrirti la stabilità di cui hai bisogno, potresti pensarci tu?”

(Anonimo Cloud-Eretico sul Design for Failure)

C’erano una volta… gli sviluppatori, e le applicazioni. Gli sviluppatori si concentravano sul codice, dando per scontata la stabilità e la scalabilità dell’infrastruttura sottostante: usavano query SQL indescrivibili, ed era compito del sistemista farle girare velocemente, scrivevano codice senza gestione delle eccezioni perchè era compito del sistemista far si che quel determinato database server fosse sempre disponibile e non restituisse mai errori. Scrivevano software impossibile da distribuire su più macchine perchè tanto il sysadmin, in qualche modo, avrebbe fatto.

La colpa di ogni rallentamento o malfunzionamento di chi era? Del sistemista. Questo ha portato chi si occupa di infrastrutture a progettare soluzioni sempre più avanzate per far sopravvivere l’applicativo alle più inimmaginabili catastrofi, senza che questo subisse mai malfunzionamenti. Qualunque disgrazia fosse accaduta alle macchine che la servivano, l’applicazione sarebbe dovuta rimanere in piedi e funzionante.

Va detto che ci siamo (quasi) riusciti. Grazie alla virtualizzazione siamo arrivati a creare quello che è a tutti gli effetti hardware indistruttubile: la macchina fisica è diventata virtuale e quella virtuale sappiamo muoverla tra diversi nodi senza spegnerla, al solo costo di qualche millisecondo di freeze.

Abbiamo così creato piattaforme che astraevano quasi completamente la complessità sottostante, usando processori virtuali che restavano disponibili anche se quelli fisici prendevano fuoco e dischi virtuali che continuavano a servire dati anche se l’intero rack di storage veniva rubato dagli alieni.

Questa soluzione non era però ottimale: la replica sincrona, per esempio, era possibile solo in ristretti contesti geografici. Il costo di queste soluzioni era spesso proibitivo, e la loro complessità alta e non necessaria. Queste strutture, per quanto immortali potessero essere, erano sempre sotto la stessa autorità amministrativa. Tutto per non dare agli sviluppatori un compito in più: gestire la disponibilità dell’applicazione.

Screen Shot 2014-01-28 at 20.58.15

(Anonimo Cloud-Eretico che non ha compreso il ‘Design for Failure’)

Poi è arrivata una nuova generazione di developers: sviluppatori che volevano più controllo, volevano poter decidere come l’applicazione avrebbe reagito a malfunzionamenti dell’infrastruttura, e soprattutto si rifiutavano di pagare al fornitore complessi meccanismi di failover perchè… non ne avevano bisogno. Sapevano fare di meglio e sapevano farlo in modo più economico ma soprattutto più effettivo, più semplice.

Questi sviluppatori non chiedevano più a chi vendeva infrastrutture hardware immortale, chiedevano semplicemente del ferro: di qualunque tipo, prestazioni, forma, colore e dimensione, ed in ogni luogo. Si sarebbero occupati loro di inoltrare meno richieste ai processori meno potenti, di tenere in RAM i dati se i dischi della macchina erano troppo lenti. Si sarebbero curati loro di evitare di interrogare un database server che non rispondeva più ai comandi.

Volevano occuparsi, soprattutto, delle azioni di disaster recovery nel caso in cui un intero datacenter fosse andato a fuoco. Perchè nessuno meglio dello sviluppatore può sapere come deve reagire una applicazione a determinati eventi e di cosa questa ha bisogno.

Hanno poi iniziato a chiamarlo ‘Design for Failure’. La disponibilità non è più compito di chi gestisce l’infrastruttura: è l’applicazione ad esser progettata per far fronte a ogni evento o disgrazia, e la struttura sottostante fa solo il sollevamento pesi.

Nel modello ‘Design for Failure’ ognuno fa il suo lavoro: lo sviluppatore conosce l’applicazione e si occupa di farla funzionare, il gestore dell’infrastruttura si occupa delle prestazioni ma non si infila più in infiniti tunnel senza uscita per garantirne la disponibilità. Tutti risparmiano, perchè è tutto più semplice, con meno sovrapposizioni. Tutti vincono: perde solo chi non ha voglia di innovare.

Ecco perchè questo modello non è un fallimento, come tanti lo descrivono: è il futuro.

Ingegneria del Cloud Computing

Ingegneria del Cloud Computing

Glossy Blue Cloud with ShadowMi auguro di non essere più su questo pianeta il giorno in cui qualcuno istituirà il corso di laurea in Ingegneria del Cloud Computing. Se dovessi ancora essere qui quando quel momento arriverà… ragazzi, sapete cosa fare.

La scorsa settimana ho scoperto che ci sono università che offrono corsi in materia di cloud: per ora si tratta di singoli corsi, i nostri classici 10 CFU. Mi sono documentato, ho cercato i programmi, le slide ed il materiale didattico. Il risultato è stato catastrofico: ho avuto modo di notare quanto il modello di insegnamento “passivo” universitario possa impoverire i concetti. Mi rendo conto che il problema sia il modello in sè (lo confermano persone parecchio più autorevoli di me) e so anche che impoverisce ogni materia, non solo il cloud, ma quest’ultimo mi tocca più da vicino, e penso di avere le competenze per cercare (e trovare, ovviamente) il pelo nell’uovo nonchè il diritto (dovere?) di criticare.

Faccio una premessa (e vi avviso già che me la tirerò non poco). Sono sul campo dal 2006/2007: gli anni in cui venivano lanciate le prime offerte “cloud” (2/3 anni prima del vero e proprio boom). Sono di quelli che l’hanno visto nascere e crescere, di quelli che hanno fatto in tempo a chiedersi “cos’è sta roba?” e che a questa domanda hanno trovato 150 risposte diverse, che hanno visto lanciarsi sul mercato i player che oggi sono i “big” del settore, sono tra quelli che hanno partecipato alle discussioni sullo sviluppo o anche solo sul naming dei vari componenti che lo rendono possibile.

Ho visto scorrere sangue in conseguenza a domande come “Hey, cos’è il cloud?”, date le centinaia di opinioni diverse in merito. Fin dagli albori ho iniziato a intravedere i vantaggi (e le sfide) che questo nuovo modello portava, e ho subito iniziato a lavorarci (forse sarebbe più onesto dire “giocarci”, almeno per quanto riguarda i primi tempi): è stato amore a prima vista. Ci ho dedicato, in un modo o nell’altro, ogni giorno della mia vita professionale fino ad oggi, e continuo a farlo. So come si usa, so come lo si rende possibile, so perchè va usato e quando.

Ecco perchè secondo me con l’università non può funzionare:

  • Nel cloud, in tutte le sue forme (SaaS/PaaS/IaaS) ci sono ancora troppe di discussioni aperte (la definizione stessa non è univoca). C’è parecchia instabilità, su tutti i livelli: com’è possibile insegnarne una singola versione, facendola passare per verità rivelata? Com’è possibile pretendere che qualcuno impari questa “verità rivelata” da un libro, quando se ci si mettesse a studiare su Google (anche se, purtroppo, non sembra pratica comune) emergerebbero milioni di opinioni diverse su ogni singola parola? Stiamo forse nuovamente premiando chi si mette li piegato sul libro e impara tutto a memoria senza mai guardarsi intorno?
  • I professori che tengono questi corsi, a quanto ho visto, non sono esattamente dei giovincelli. Parlo di persone che hanno passato gli ultimi 20/30 anni di vita nella didattica. Questo fa di loro degli ottimi professori, ma forse non ne fa degli ottimi insegnanti per un modello, il cloud computing, che esiste si e no da 6 anni: quante ore possono averci dedicato sul campo? Zero? Forse non sono nemmeno stati in prima linea abbastanza tempo per comprendere come mai è nato, quali sono le richieste che l’hanno fatto crescere, ed in quali ambiti si colloca. Come insegnano, ma soprattutto cosa insegnano? Parlano forse per sentito dire come la peggior pettegola di paese?
  • La volatilità dei concetti è estrema: parlando in generale, e non del singolo servizio dello specifico fornitore, quello che è vero oggi potrebbe non esserlo più domani. La difficoltà nello spiegare cosa sia un’istanza cloud è enorme: chiedetemi piuttosto cos’è un’istanza Amazon EC2, che a differenza della prima è qualcosa di ben definito.

Con questa poca esperienza e con questa miriade di discussioni attualmente in sviluppo, come si può pretendere di valutare con un numero le competenze di uno studente?

Mi spiego con un esempio: 4 anni fa, lo storage a blocchi tra le nuvole era presente in due forme. Quella persistente, affidabile, ultra ridondata ma tremendamente lenta, e quello locale, più veloce ma estremamente instabile e inaffidabile. Era opinione comune che i RDBMS “classici” come MySQL e Oracle non potessero essere spostati nella cloud, perchè avidi di IOPS. Se qualcuno mi avesse chiesto di elencare le differenze tra un VPS ed un Cloud Server avrei sicuramente citato questo punto: 4 anni fa, sarebbe stato parte della definizione.

Poi le cose sono cambiate: è arrivato chi ha messo una SAN ad alte prestazioni dietro agli hypervisor, offrendo storage ridondato ma ad alte prestazioni. Amazon ha lanciato gli EBS con “Provisioned IOPS”, che permettono di prevedere e garantire le prestazioni di un certo storage. Altri player hanno messo sul mercato soluzioni SSD-based sulle quali quasi non ci si accorge di essere in un ambiente virtuale.

Nel giro di pochi mesi, la “lentezza” dei dischi è sparita dalla definizione: non era più parte del cloud. MySQL tra le nuvole è diventato d’un tratto non solo possibile ma anche ottimale. Tutto è cambiato, di nuovo. A che cosa sarebbe servito spendere 10 CFU, 300 ore di studio, per imparare definizioni che erano già predestinate a diventare superate (e quindi, sbagliate)?

Questa è per tutti una grande occasione per buttare via il modello di insegnamento verticale, che evidentemente in questa materia non può funzionare, e per comprendere la dinamicità con cui ci si deve formare in un ambiente lavorativo, in contrasto con quello scolastico.

Lasciate che ad insegnarvi il cloud siano le centinaia di persone che l’hanno fatto, e non dei professori che, mentre tutti noi traslocavamo tra le nuvole, erano in aula a spiegare.

%d bloggers like this: