Aws Revenge

This entry is part of 1 in the series Big Data

!Questo articolo esce in contemporanea con il re:Invent event di Amazon!

Su queste pagine siamo stati abbastanza scettici sul cloud anni fa. Il costo del cloud nel frattempo si è abbassato, i servizi “turnkey” sono diventati più numerosi e la concorrenza ha migliorato le cose.
Il PaaS ed il cloud sono quindi entrati nella piena maturità.

Su Amazon S3 oggi è possibile archiviare 33GB per un dollaro al mese circa. 1TB costa poco più di 30$, una cifra importante se si tiene conto che un hard disk interno da un tera lo si porta a casa per 35 € (sempre su Amazon!). E quindi ridondandolo almeno con 2 dischi, la soluzione “home made” costerebbe 70€, con un break even di meno di tre mesi. Ovviamente però bisogna poi attaccarli ad una NAS, valutare se serve una connessione internet ecc ecc.

A conti fatti per archiviare un backup di piccole dimensioni o un sito statico S3 può diventare una viable option, soprattutto se non avete il tempo di star dietro a montarvi il pc, la nas, l’adsl ecc E’ possibile limare i costi con opportuni accorgimenti (infrequent access, ecc) ma le configurazioni sono perniciose e noiose, per cui consideriamo solo il costo puro.
Un business che parta con un sito statico che ha bisogno di 10GB di spazio può stare in piedi per un euro al mese, e ha 30 mesi per capire se ha un futuro oppure no: in tal caso vi costa meno dell’hard disk “fisico”.

Similmente i servizi Simple Queue Service e DynamoDB (code e NoSQL db) sono “turn key” e  hanno un piano gratuito mensile. Sono ideali e a costo zero per piccoli sistemi di monitoring, che per forza di cose devono stare separati dalla vostra infrastruttura, altrimenti rischiano di andare offline insieme a quello che monitorano :)

EC2 Cloud computing on demand

Le macchine virtuali Windows-based includono nel costo orario anche le licenze (Windows Server,SQLServer, e anche Sharepoint) e quindi sono un ottimo punto di partenza per avere una applicazione ASP.NET up&running in poco tempo, visto e considerato che ora Visual Studio 2015 ha una versione “Community” molto completa (che vi suggerisco di provare). E’ naturale che questa soluzione deve prevedere l’uso dei servizi Amazon a contorno, altrimenti Azure di Microsoft potrebbe essere una soluzione più indicata.

Last but not least, è stato aggiunto al sistema di pagamento (billing) una previsione di spesa (forecast). La mancanza di questo strumento era sicuramente un punto debole di AWS anni fa, considerato anche il complesso sistema di billing.

La nuova dashboard consente di tenere sotto controllo i costi giornalmente, e incoraggia a provare i servizi.

 

Con la testa tra le nuvole

Il cloud computing sta diventando un termine sempre più usato (ed abusato) del panorama IT degli ultimi tre anni.

Come tutte le buzzword che si rispettino, lo abbiamo maltrattato un pochino negli anni passati, ma è  venuto il momento di affrontarlo in modo analitico, per una serie di ragioni.

Prima di tutto da uno studio risulta che quasi l’1% del traffico internet arrivi ad un nodo del cloud di Amazon. In secondo luogo, le tecnologie di virtualizzazione sono molto progredite, e anche se al momento hanno un fattore di efficacia basso (circa il 50% della velocità di un sistema nativo) l’hosting dedicato ha ancora costi proibitivi per business ristretti.

La “nuvola” promette la capacità di riconfigurazione dinamica delle risorse, e un controllo dei costi con una notevole granularità, con un loro abbattimento.

Iniziamo quindi facendo un’analisi di massima degli hosting provder virtualizzati, normalizzando i loro costi.Ecco  una modesta tabella comparativa:

[table id=4 /]

 

Note:

  • I provider comparati hanno generalmente uno SLA del 99.99%, che in un mese equivale a meno di  4 minuti e mezzo di downtime. In un anno però implica un downtime di oltre 50 minuti.
  • Nei limiti del possibile, si è cercato di comparare servizi equivalenti
  • Supponendo un mese di 30 giorni, in un mese vi sono 720 ore.

Metriche di confronto

Dalla tabella precedente si evince che il parametro più critico è la RAM fisica, seguito dallo spazio disco e dalla banda. Le ragioni sono le seguenti.

Tipicamente la banda è venduta in lotti molto alti oppure è illimitata. Lo spazio su disco ha oramai un costo risibile, poiché si trovano hard disk interni con un costo al Gb di circa 0,10€. I software di virtualizzazione inoltre possono funzionare anche con meno spazio disco di quello necessario, e quindi migliorare i consumi ed il provisioning. Ma la RAM fisica non è facile da virtualizzare: anche se alcuni sistemi riescono a farlo, per es dichiarando X Gb e allocando solo quelli realmente necessari, si tratta di una risorsa di per sé:

  • veloce da consumare
  • molto costosa
  • non genera contention
  • non scala linearmente come la memoria di massa
    Questo vuol dire che mentre è possibile, pagando molto, ottenere dischi o spazi di indirizzamento di milioni di petabyte, modellandoli come un gigantesco hard disk, questo al momento non è possibile per la RAM a costi ragionevoli, poiché è molto più limitata dall’architettura fisica.
L’I/O su disco genera contention. Cioé se si mettono troppe macchine virtuali sullo stesso dispositivo fisico, esse competeranno per l’utilizzo del disco, che essendo soggeto ad una inerzia fisica molto maggiore della RAM, potrebbe ridurre le prestazioni dei sistemi in modo significaivo.
La memoria RAM può generare contention, ma essendo molto più veloce questo aspetto è molto più tollerabile/ignorabile.
Una vecchia legge dell’informatica sostiene che per raddopiare le performance di un sistema è necessario spendere il quadruplo. Da questo se ne desume che un sistema virtualizzato (che mediamente è il 50% più lento di uno fisico) dovrebbe costare un quarto di un server dedicato, per essere economicamente accettabile.
 Detto questo, il primo servizio che analizziamo in dettaglio è l’Amazon Web Services, per una panoramica sugli altri cloud provider vi rimandiamo a questa discussione su quora.

Amazon Web Services

Uno dei plus di Amazon Web Services (AWS) è che offre una serie di servizi ridotti a titolo gratuito per un anno. Al momento è l’unico cloud provider con questa aggressiva strategia di vendita. Nella nostra comparazione però guarderemo ai costi puri, ipotizzeremo cioé di trovarci a pagare il prezzo pieno.

L’impatto con la procedura di registrazione ha dato una impressione di eccessiva “fiscalità”:viene forzatamente richiesto un numero di telefono che il sistema chiamerà per una verifica.

Giocando con il calcolatore incluso sul sito web di aws, i costi generalmente si aggirano intorno ai $20 per una istanza micro (che ha circa 600MB di RAM) supponendo un consumo di banda medio.L’istanza micro che abbiamo provato risulta essere un S.O. Linux virtualizzato con xen con modeste prestazioni.

La creazione della istanza di test è risultata però molto ben organizzata: è possibile creare una macchina virtuale linux in pochissimo tempo, configurando sia il firewall che  una chiave SSH per l’accesso. La macchina virtuale che abbiamo provato è quella standard fornita da Amazon, e siamo riusciti ad installare su di essa un server Redis in pochissimo tempo.

Purtroppo le istanze micro hanno delle “latenze forzate”, per cui il tentativo di utilizzare troppo tempo di CPU nella unità di tempo porta ad un “congelamento” della istanza micro.
E’ quindi difficile installare un server ad alto assorbimento di CPU su tali istanze, poiché se provate a connettere client molto aggressivi a un server su’istanza micro, riceverete errori di rete casuali (“socket reset to peer”, “connection timeout”, ecc) rendendolo di fatto poco affodabile.
Nessun provider di VPS citato sopra arriva a questo basso livello di affidabilità (a meno di non andare sui veri cheap hosting che però costano meno della metà di AWS).

Le istanze micro sono ideali per:

  • Modesti blog
  • Piccoli server GIT ospitati in SSH
  • Attività batch a basso carico e non critiche

 

E’ possibile creare un clone della macchina in modo molto rapido: basta effettuare una “snapshot” del disco virtuale (chiamato EBS nel gergo inziatico di Amazon) e poi creare da esso una AMI (AMazon Image file).

Punti di forza di aws sono la possibilità di installare velocemente un array di micro istanze server, e di poterle rimuovere in qualsiasi momento.

Trattandosi di un servizio a consumo, da’ i suoi risultati migliori se vi dotate di una infrastruttura che spenga dinamicamente i server che non prevedete di usare.

Se invece avete la necessità di un numero fisso di server sempre operativi, i costi di AWS iniziando ad essere comparabili a quelli di un qualsiasi provider linux.

Questo articolo del 2011 mostra come l’uso di istanze riservate porti a vantaggi solo dopo un attenta disanima, e leggiamo (italico aggiunto da noi):

As a result of all this, it is pretty undesirable to buy reserve instances unless you have a very stable environment, both technically and scale-wise. That sentence doesn’t describe the typical cloud use case in my opinion.
[…]
In the end, one of the reasons people move to the cloud in the first place is to get rid of the constraints of hardware.  When Amazon just puts those constraints back in place, it becomes undesirable. Frankly even now, I tried to just pay Amazon up front rather than actually buy reserve, but they’re not really enterprise friendly yet from a finance point of view so I couldn’t make that happen, so in the end I reluctantly bought reserve.
[…]

Inoltre qualsiasi provider di macchine virtuali vi farà uno sconto se acquistate in lotti da 3, 6 o 12 mesi, e sarà piuttosto disponibile ad aumentarvi/ridurvi un po’ la RAM se sapete impostare bene una marketing email: questo azzera i presunti vantaggi di AWS per volumi ridotti.

Prime conclusioni su AWS

Tra i plus di AWS c’è la possibilità di avere istanze di MS-Windows Server ad un prezzo accettabile, con una installazione di base di IIS e SQL Server “Express”.

Tra i contro, l’eccessiva complessità del sistema di compravendita che fa sì che sia confuso capire quanto effettivamente si spenda, e che ricorda molto da vicino le confuse tariffe degli operatori telefonici mobili Italiani (Tim, Vodafone, Tre…).

Per approfondire, guardate anche questo articolo per configurare da zero la vostra linux box.

 

 

WISP Manifesto

We talked about ”Web applIcation Service Provider” (WISP) in the past days. So what are the specification for a Service Provder wanting to be a WISP?

Let’try to sketch them together:

WISP Hypothesis

  • A WISP must offer a set of XML-RPC API (WISP API) to configure the services. They must be simpler than SOAP, and must support at least two languages picked from  Python,Ruby,Java,PHP, Perl.
  • WISP API should be provided always in SSL way.
  • WISP API specification will be provided on subsequent articles
  • WISP must provide a minimal set of LAMP applications, like WebMail, CMS (i.e. WordPress). Also WISP must provide at least one “dashboard” web interface to set up a dashboard for the WISP API
  • For simplicity, the web application are deployed as  two tiered: database tier and web tier. Anyway you can build complex system connecting a lot of 2-tier application
  • On the database tier, WISP must give at least one Relational Database (like MySQL or PostgresSQL) and one NoSQL solution, altrought NoSQL forest is a bit tricky.
  • About email, at least an IMAP server and SMTP server must be provided
  • It should be possible to define “logical user” to segregate email mailboxes and web application
  • The amount of RAM allowed to be consumed by application should be considered only on the application tier. Database and webmail will be offered on a “best effort” base, with clear defined limits.
    For special needs, a “private” database instance could be installed
  • The Service Level Agreement (SLA) should be at least 99.99%
  • WISP has the freedom to choose the underling Operating System. By the way, the web application should try to be agnostic (even if Linux is always the first choice for a LAMP stack)
  • WISP must provide bandwidth and disk space in a very cheap way. For this reason, the “usage meter” should be easy to compute and very liberal on disk space, while very strong on single application memory usage

SkyRocket computing not Cloud!

As you know, we at Gioorgi are not so Cloud-Computing enthusiastic.

Anyway, we watch every buzz-word, every good idea also if it born in an evil empire :) Cloud computing is SOA and huge. As software architect, Cloud computing is doomed to fail for some simple reasons:

  • Amazon and other Cloud solutions give you the freedom to build virtualized environment.
    Big players like to build their Virtual Machines, and often they have tons of Citrix and VMware license in it.
    But big players like Financial institutions (i.e. Banks) and Telecom-based business (Vodafone, Verizon, Wind, Telecom Italia and so on) will never leave their business to a third entity: for safety and for business reasons!
  • Small player will be lucky to enter in the Cloud big-buzzword but they need a cheap application platform. And Cloud is not easy to deploy neither cheap!

On a SkyRocket instead then on Clouds

These two companies

are very different examples of what we called a “Web applIcation Service Provider” (WISP).
WISPs provide an API to build applications. I have chosen this two one because they are very different, but the result is the same. You get a way to install pre-configured web application, with a fix-schematic.
This schema has the following highlights:

  • It asks to us to have less freedom  on the operating system side (for instance, you cannot pretend to choose the operating system version, like you can do on a linode).
  • Require less constraints on disk space and bandwidth usage. For instance, Linode asks about 1$ per Gb/mo while WebFaction starts from $0,10 per Gb/mo. Customer asks about ten the space for giving the WISP the freedom on operating system image!
  • Security is a concern, because often the web application service provider (WISP) will scale keeping on the same web farm more applications. But Security is a concern also on Cloud Computing, so the difference surely is there, but for your business the risks are the same.
  • the proposed webapps are often LAMP stack, for instance:
    • WordPress
    • Drupal
    • Joomla
    • RubyOnRails Stack
    • Django Stack
    • Multi version PHP, Python
    • Databases like MongoDB, MySQL etc.
    • System-like utilities like WebDav Apache pre-configurations, Awstats

    As you see this schema mix some  typical infrastuture application (like awstats or webmail, for instance) with totally different software like databases (MongoDB, MySql…)  and CMS (drupal, joomla…).

A lot of this tool can be centralized and the security managed in a very unix-like fashion.

So what is your experience? Would you rather by a Linux Box virtualized with Xen, an Amazon Cloud or a WISP-like solution?

 

 

Cloud outrange… again

At Gioorgi.com we are not a true cloud fan, and reality is going on to collect proofs for us…

On June 20, 2011, Dropbox had a serious security bug. It was possible to login to an account with “a wrong password”. Like to say Dropbox account system was naked, because “a small number of users[…] could have logged into an account without the correct password”!

Continue reading “Cloud outrange… again”