Jump to content

Lorenzo Monni

Members
  • Content Count

    37
  • Joined

  • Last visited

Everything posted by Lorenzo Monni

  1. Lorenzo Monni

    Il nuovo HostingTalk.it

    Un grande passo avanti rispetto alla precedente, complimenti! Anch'io sono per la svolta "minimal", ma capisco anche l'urgenza di riuscire a coprire tutti i campi necessari in homepage.
  2. Io invece sì, almeno facendo tesoro delle mie esperienze e di quanto ho studiato. Il problema non è avere rapporti di clientela con la concorrenza - tutti i fornitori sono potenziali concorrenti, in ogni settore - ma l'esclusività di questi rapporti. E poi dipende ovviamente anche dalle dimensioni del business, una piccola azienda può dipendere al cento per cento da una grande azienda (e a 'sto punto mi chiedo anche perché non mettersi d'accordo per un'acquisizione), ma un servizio così grande come bacino di utenza quale è quello di Netflix dovrebbe prendersi la briga di programmare una via di fuga presso un altro provider, Rackspace o simili.
  3. E non c'è nulla di male, il problema è dipendere in maniera assolutamente esclusiva da un proprio competitor, cosa non propriamente sana, non credi? Come già scritto, se l'idea di Netflix è quella di avere tutta la sua infrastruttura su Amazon per forza di cose dovrà pur esserci un vantaggio nei costi che supera l'entità del rischio.
  4. Errore mio, ecco l'articolo ufficiale: Case Study nel cloud, come la startup Viamente usa il cloud di Seeweb - CloudTalk.it
  5. Io rispondevo per quanto riguarda CloudTalk, visto che tu hai citato cloudtalk nella tua critica. Non mi occupo degli articoli di Stefano. In articoli tipo questo sono citati anche Seflow, e offerte tipo quella di Vodafone e Telecom che non sono sponsor, quotidianamente si parla anche di servizi potenzialmente avversari degli stessi sponsor che compaiono nella home page.
  6. Giusto per dare il mio contributo, Seflow non sarà citata nell'articolo di oggi di Stefano, ma comunque è stata citata nel primo articolo di introduzione di cloudtalk: Cloud italiano, le ultime “nuvole” nate ed il perché del fenomeno - CloudTalk.it e altre volte sempre nello stesso sito: SeFlow annuncia nuovi prezzi per eCloud - CloudTalk.it Quali compagnie italiane di cloud computing mancano di cui non ci si occupa? Serverplan e poi? E' giusto scatenare questo putiferio per una compagnia mancante?
  7. Ciao, un esempio di utilizzatori in Italia è dato da alcune testate giornalistiche online che ad esempio usano Seeweb, citate in questo post. Che io sappia è comunemente usato anche da molte startup legate all'incubatore H-Farm. Ci sono poi tutta una serie di grandi compagnie italiane che probabilmente usano infrastrutture private cloud (tipo Trenitalia), ma con quelle non so se riusciresti a farci un'intervista. I provider stessi mettono a volte a disposizione degli use cases, per esempio in questa pagina di AWS ci sono una valanga di esempi di compagnie che lo usano ognuno a suo modo. Questa ad esempio è l'esperienza della compagnia di videogiochi Sega (giusto per farti vedere come sono poste). Come base spero possa esserti utile.
  8. Personalmente sia il primo che il secondo progetto classificati mi sembrano interessanti e con buone opzioni di sviluppo, anzi molto più interessanti di altre startup italiane che fanno cose non particolarmente utili, tipo app per android di promemoria che hai lasciato il termosifone acceso o social network sugli appassionati di formaggi. :asd:
  9. Stiamo dicendo la stessa cosa in maniera diversa, io rispondevo a cose tipo: In linea puramente teorica (ovvero, se AWS non dice balle), per resistere a problemi tipo quello di lunedì non è assolutamente necessario avere istanze in regioni diverse.
  10. Intendo dire che quando si parla a valle di un'interruzione bisognerebbe sempre riferirsi ai SLA del provider per parlare della bontà del servizio, e per capire se abbia mantenuto o meno le promesse. I livelli di servizio garantiti di AWS che io sappia si riferiscono a downtime che colpiscano più di una zona di disponibilità, il downtime di lunedì non so se verrà conteggiato nei SLA per questo motivo. AWS stessa è abbastanza attenta nello spiegare come utilizzare il proprio servizio e fare il deploy delle applicazioni, in documenti come questo: http://media.amazonwebservices.com/AWS_Building_Fault_Tolerant_Applications.pdf Questo a prescindere dai costi da sostenere per la ridondanza geografica ed il failover.
  11. Ah ok, ho sbagliato completamente calcolo, comunque guardando ora le tabelle 8 ore non è sotto il 98%, è pari al 99,9%. Credo che Amazon si posizioni tra il 99,5 ed il 99,9 per cento.
  12. Però vi chiedo, in termini di livelli di servizio su cosa stiamo dibattendo? Io vedo quasi quotidianamente discussioni su provider italiani per esempio che provocano problematiche di tutt'altro tipo. Un SLA del 99,999% per esempio quanto permette di downtime all'anno, 8-9 ore? Non mi sembra ci si vada lontano su AWS, magari sto sbagliando qualche calcolo. Chiedo eh, è vero che queste interruzioni di Amazon fanno molto rumore, ma anche vero che bisogna riportare il problema alla sua dimensione reale, e a quanto spendono i siti che sono caduti lunedì su Amazon.
  13. "11:06 AM PDT We are currently experiencing elevated API failures and delays launching, updating and deleting Elastic Beanstalk environments in the US-East-1 Region." Non proprio saltate, ma quasi.
  14. Dell'utilizzo delle flash Ne ha parlato Jay Parikh all'evento organizzato da GigaOM, Structure Europe: DATA CENTER STRATEGIES FOR ... on GigaOM Structure: Europe Day 2 ... diverse testate hanno citato il termine cold storage tra le nuove strategie di gestione di dati: Facebook to use 'cold storage' to deal with vast amounts of data | Cloud Computing - InfoWorld E' vero che le flash sono poco affidabili, ma in questo caso i fattori che entrano in gioco sono: - risparmio energetico - velocità di accesso - semplificazione nelle procedure di accesso - grado statistico di affidabilità di memoria. Tutta la chiave del vantaggio sta in quel software di gestione dello storage e dell'archiviazione di contenuti che deve essere fatto molto bene, e nella comparazione che facebook ha svolto tra i costi dell'utilizzo di HDD e quelli dell'utilizzo di flash. E sappiamo che anche un vantaggio delle flash esiziale, se moltiplicato per le tonnellate di petabyte che deve gestire arriva a fare una bella cifra. Il motivo per cui poi tutto ciò può sembrare strano è che ovviamente una compagnia come Facebook non può vuotare tutto il sacco, l'aspetto davvero core di quest'innovazione probabilmente non l'ha neanche citato di striscio. Non si dicono queste cose, un po' come Google che la settimana scorsa ha pubblicato foto e Google Street View dei suoi data center, e ha parlato dei suoi metodi di raffreddamento dell'hardware: ne ho scritto anch'io, mentre lo facevo ero ben conscio che se fosse stato davvero l'ultimo livello di innovazione nel data center di Google non l'avrebbero mai fatto pubblicare. Anche la storia delle foto che dopo un po' di tempo passerebbero al cold storage è fumosa, dipende dall'utilizzo che ne fa l'utente. Ci sono utenti con foto del 2009 ma che hanno l'album di quelle foto in bella vista nella pagina delle foto, e ci sono utenti che hanno talmente tanti album che quello di tre anni fa non arriverà a vederlo mai nessuno, o giù di lì. Quindi sicuramente oltre al tempo di archiviazione conteranno il numero di accessi, e magari anche il numero di tag e così via.
  15. Hai ragione, precisazione giusta, diciamo che il nome cold storage è improprio per questo tipo di utilizzo, potremmo chiamarlo un livello di storage intermedio "tiepido". :asd: Per quanto riguarda l'affidabilità, tutto dipende da quello che farebbe questo fantomatico software di gestione degli array di flash, che si dice possa controllare l'affidabilità di questo tipo di memoria. Probabilmente nel momento in cui deve essere archiviata un'immagine il software controlla la bontà della memorizzazione, se va male fa rieffettuare la stessa operazione in un'altra porzione di memoria. Per capire se sia davvero utile bisognerebbe avere sotto mano i benchmark di Facebook che comparano questo utilizzo a quello su hard drive, oltre ad avere una visuale un po' più ampia dell'architettura di storage della compagnia. Ed io non credo che facebook abbia voglia di fornire questi dati.
  16. VMware non so che intenzioni abbia, ma credo se ne sia accorta con largo anticipo visto che ha richiesto (e ottenuto) l'accesso all'OpenStack Foundation come gold member ed ha acquisito Nicira quest'estate, non credo che si farà trovare impreparata di fronte alla diffusione di OpenStack. Guadagnerà meno degli anni scorsi, questo sì.
  17. E' sicuramente un'altra possibilità, anche se non so quanto possa combaciare con l'idea di Microsoft di approvvigionamento centrale fornito internamente con elettricità pubblica presa solo come backup energetico, ovvero basterebbe il biodiesel? Per i generatori di backup forse sì, ma se ci si vuole progressivamente staccare dalla rete pubblica no. Che io sappia poi anche per il biodiesel bisogna affrontare spese, per la riconversione degli impianti dei generatori diesel tradizionali, e poi di monitoraggio costante per evitare che ristagni all'interno dei contenitori. E' sempre una questione economica. :asd:
  18. Scusate, ho dovuto metterlo non pubblicato all'inizio perché era anche scomparso il post di Seeweb (l'hanno rifatto).
  19. Lorenzo Monni

    Server Cloud e limiti di spesa

    Non è stato fatto apposta per gli accessi indesiderati, ma credo possa essere utile ad accorgersi di un utilizzo indesiderato: Amazon Cloud Watch, ma in generale strumenti di monitoraggio cloud credo ne trovi a camionate, c'è questo per esempio: uptimeCloud | the simple way to manage the cost of cloud Ti mandano subito un'allerta se supera una certa soglia.
  20. Dove starebbe scritto nell'articolo che "noi virtualizziamo iOS"? Ma soprattutto, dove diavolo leggi che si parla di virtualizzazione di iOS?
  21. Lorenzo Monni

    Anche la NASA usa Amazon Web Services

    Diobono. Dove l'hai letto?
  22. Ho appena modificato il titolo.
  23. *La nuova versione del protocollo IP, che con l'aria che tira rischio di dover subire una nuova pleonastica precisazione. :asd:
  24. Ragazzi, è un titolo, è fatto così perché deve avere una lunghezza limitata contenente delle parole chiave e deve dare un'idea immediata dell'argomento, comunque grazie per aver chiarito che non è l'IPv6 ad essere dismesso, mi scuso con chi avesse interpretato male l'argomento. Per quanto riguarda "il futuro" dell'IPv4, l'obiettivo dichiarato di tutti è quello di dismetterlo entro il 2024. Quindi, ricapitolando: - Switch off: è ufficiale, le intenzioni sono di fare uno switch off; - IPv6: è il nuovo protocollo, non quello da dismettere; - Italia impreparata: un po' indietro nella preparazione, soprattutto rispetto ad Asia e USA. Spero di aver riparato.
×