Forum: Italian Ruby user group [OT] Paas semplice per ruby, rails, sinatra

Scusate per l'off topic (e la premessa un po' lunga) ma ho una curiosit 
:)

Leggo spesso richieste su hosting per rails.
Con Heroku  facile ma appena si supera la soglia free (1 web-worker 
dyno)
 un attimo salire con i costi (ed arrivare tranquillamente ai 100 $ al
mese)
Quindi si direbbe che  perfetto per fare test veloci di
un'idea-prodotto-servizio nella fase iniziale.
Ma se l'idea piace ed il traffico aumenta (molto) forse bisogna pensare
velocemente a soluzione alternativa.
E se l'idea piace nel mondo con i numeri attuali di persone su internet
magari passare da 1k visitatori al mese a 1k-10k visitatori al giorno pu
essere un attimo (pochi mesi, poche settimane ... o pochi giorni per i 
pi
fortunati :)
Ed a quel punto immagino che se l'azienda-startup non ha un budget
consistente in attesa di trovare finanziatori bisogna "aggiustare" il 
tiro
per cercare di tenere sotto controllo i costi dell'infrastruttura.
Specie considerando che i costi per sistemi online sono solo una delle 
voci
del bilancio aziendale.

Motivo per cui molti usano il classico server linux (vps, dedicato) e si
appoggiano a cloud service per esigenze particolari dell'applicazione.
Vedi amazon s3 (e simili) per storage immagini, audio, video (ed altro).
Oppure gestiscono direttamente istanza su amazon ec2, engineyard, 
rackspace
(e simili).
Per essere pronti nel caso aumentando le istanze nel cloud.

Molti poi lavorano su siti che probabilmente non avranno mai crescita
esponenziale (ed improvvisa) di traffico.
Per cui la soluzione classica con server linux basta ed avanza.

Detto ci ... potrebbe essere interessante una soluzione "paas
semplice" come heroku, https://www.appfog.com/,
https://www.dotcloud.com/ magari
free per i livelli iniziali ?
Tipo i 3 gears di openshift
https://openshift.redhat.com/community/developers/...
Ed a pagamento (con supporto full) per livelli successivi.

S.

E` tanto tempo che sto pensando di farne uno. Secondo me ci sono molte 
app/siti che non avranno mai un incremento esponenziale, oppure la cosa 
avvera` lentamente. L'idea sarebbe si usare server economici della 
Germania e/o della Francia e creare una infrastruttura li. Conoscendo 
Chef e Puppet la cosa non e` difficilissima. Il problema e` che su AWS 
ci sono cosi tanti servizi aggiuntivi, sia Amazon che di terze parti. La 
cosa che ho trovato piu` difficile e stata quella di avere un MySql 
load-balancer e highly available, ma da pochi giorni ho messo in 
produzione un cluster mysql, multimaster con il load balancer fatto da 
me e funziona bene, dopo qualche peripezia iniziale.

Secondo me un PaaS come dici te e` possibile, ma sembra che tutti usino 
solamente Amazon o Linode.

Guardando dotcloud sembra che si avvicini all'idea che avevo, non sembra 
male. appfog e` sempre basato su EC2 e non mi sembra tanto piu` 
conveniente piu` di Heroku

Il giorno 23 ottobre 2012 11:09, Riccardo Tacconi <rtacconi@gmail.com> 
ha
scritto:

> E` tanto tempo che sto pensando di farne uno. Secondo me ci sono molte
> app/siti che non avranno mai un incremento esponenziale, oppure la cosa
> avvera` lentamente. L'idea sarebbe si usare server economici della
> Germania e/o della Francia e creare una infrastruttura li. Conoscendo
> Chef e Puppet la cosa non e` difficilissima.


:-)
Per esempio http://www.hetzner.de/en/ oppure 
http://www.ovh.com/fr/index.xml
Why not ;)


> Il problema e` che su AWS
> ci sono cosi tanti servizi aggiuntivi, sia Amazon che di terze parti.


Decisamente.
Gli stessi che usano (con profitto) heroku ed engineyard.

La cosa che ho trovato piu` difficile e stata quella di avere un MySql
> load-balancer e highly available, ma da pochi giorni ho messo in
> produzione un cluster mysql, multimaster con il load balancer fatto da
> me e funziona bene, dopo qualche peripezia iniziale.


:-)


> Secondo me un PaaS come dici te e` possibile, ma sembra che tutti usino
> solamente Amazon o Linode.
>
> Guardando dotcloud sembra che si avvicini all'idea che avevo, non sembra
> male. appfog e` sempre basato su EC2 e non mi sembra tanto piu`
> conveniente piu` di Heroku


Anche dotcloud ( basato su EC2)
http://docs.dotcloud.com/0.4/faq/
>>> DotCloud runs on Amazon EC2. More specifically, we run
>>> on the us-east-1 region, across multiple availability zones
Come prezzi alla fine mi sa che si avvicina anche lui ad heroku (
https://www.dotcloud.com/pricing.html basta aggiungere istanza ruby, 
mongo
e sei gi sui 17 $ al mese)

Appfog forse  interessante per l'approccio easy (come dotcloud) e perch
offrono un plan free.
Dal loro blog
http://blog.appfog.com/if-paas-is-expensive-and-sl... 
dicono
che pensano di reggere l'offerta free (che non  poco, fino a 2GB ram e 
db
fino a 1 GB) vendendo soluzioni enterprise.
>>> AppFog is able to give away more free than any other PaaS
>>> because we have our own alternate monetization strategy:
>>> running dedicated PaaS platforms for our enterprise customers

Io cmq pensavo di usare http://www.cloudfoundry.org/ in modo da potersi
connettere con amazon, rackspace, azure, hp.
Volendo anche con l'acerrimo nemico openshift (chiamando api ... o 
facendo
un connector-adapter per cloudfoundry :)
Poi le istanze potrebbero essere su ovh o hetzner.

Se vuoi ne parliamo (in privato, via mail)

S.

Ci stavo pensando anche io, l'argomento mi interessa e secondo me 
ponendo dei paletti
ben rigidi gli sviluppatori non hanno problemi ad adeguarsi se il 
servizio  efficiente ed
economico.

Per paletti rigidi intendo dire cose come la versione di ruby 
supportata, la struttura dell'applicazione che ti aspetti di trovare 
etc.

Effettivamente con chef o puppet il modeling dell'infrastruttura 
diventato abbastanza facile.
(Tra l'altro puppet  in giro da diversi anni non  che prima fosse pi 
difficile.).

E secondo me se ti capita di avere dei server liberi, con il supporto 
per openstack che c' ora in ubuntu non
neanche troppo malsana l'idea di mantenere i server in Italia, 
potrebbero esserci notevoli vantaggi.

Ho fatti dei ragionamenti. Se la discussione non  troppo privata mi 
unisco volentieri.

-f

Si io ho usato OVH per delle prove, all'inizio con i server nel virtual 
rack poi mi son reso conto che nel caso che il load balancer andasse 
giu`, e` possibile cambiare l'IP virtuale con una semplice chiamata 
SOAP. per esempio anche su EC2 non puoi usare due server on heartbeat 
perche` l'IP deve essere assegnato ad un server.

Ho visto che cloud foundry e` stato rilasciato da poco ed e` molto 
interessante, anche openstack e` ottimo.

Mi son reso conto che e` possibile creare l'infrastruttura senza 
utilizzare la virtualizzazione, per esempio un server con 24GB di RAM 
potrebbe ospitare diciamo 20 istanze di Thin, se utilizzi tre server 
diventano 60. Una applicazione su Heroku, se no erro, ne ha al massimo 
48, quindi aggiungendo abbastanza in tempo i server, non sarebbe lontano 
da un cloud hosting ala heroku. Alla fine tutti i progetti a cui ho 
lavorato avrebbero piu` benefici da un hosting economico su OVH, ma 
bilanciato ed ad alta disponibilita`, magari con la possibilita` di 
aumentare un po` le risorse in caso che gli utenti diventino di piu`.

Sono disponibile a parlarne in privato.

Il giorno 23 ottobre 2012 14:09, Fabrizio Regini <freegenie@gmail.com> 
ha
scritto:

> E secondo me se ti capita di avere dei server liberi, con il supporto per
> openstack che c' ora in ubuntu non  neanche troppo malsana l'idea di
> mantenere i server in Italia, potrebbero esserci notevoli vantaggi
>

Per il discorso latenza e siti, app, servizi di potenziali clienti che 
si
rivolgono a users in Italia ?
Tra l'altro forse conosco persone che potrebbero offrire hosting in 
Italia
a prezzi di favore a fronte di progetto interessante (vedi
http://www.servizi-internet.eu/ e forse, con un po' di fatica
http://www.seeweb.it/ :-)

Cmq server in Francia (Germania) ed Italia ci starebbero in ottica di 
paas
provider che si rivolge per esempio a clienti europei.


> Ho fatti dei ragionamenti. Se la discussione non  troppo privata mi
> unisco volentieri.
>

Volentieri, per idee e ragionamenti in dettaglio passiamo in privato.
Cos non disturbiamo persone in lista.

S.

Il giorno 23 ottobre 2012 14:22, Riccardo Tacconi <rtacconi@gmail.com> 
ha
scritto:

> Ho visto che cloud foundry e` stato rilasciato da poco ed e` molto
> interessante, anche openstack e` ottimo
>

Si, da quanto ho capito leggendo un po' di doc (e guardando sorgenti
:) cloudfoundry ti permette di gestire-coordinare un po' tutta
l'infrastruttura (comprese app deployate)
(vedi http://apidocs.cloudfoundry.com/cloud-controller, dea, ecc..)

Poi c' chi come vmware lo usa per gestire istanze su vsphere
http://www.cloudfoundry.com/faq#whatis.com
Ma quella  pi una scelta di architettura-infrastruttura legata ai loro
prodotti.
E cloudfoundry.com (in beta) gli fa un po' da test sul campo :)


> Mi son reso conto che e` possibile creare l'infrastruttura senza
> utilizzare la virtualizzazione, per esempio un server con 24GB di RAM
> potrebbe ospitare diciamo 20 istanze di Thin, se utilizzi tre server
> diventano 60. Una applicazione su Heroku, se no erro, ne ha al massimo
> 48, quindi aggiungendo abbastanza in tempo i server, non sarebbe lontano
> da un cloud hosting ala heroku. Alla fine tutti i progetti a cui ho
> lavorato avrebbero piu` benefici da un hosting economico su OVH, ma
> bilanciato ed ad alta disponibilita`, magari con la possibilita` di
> aumentare un po` le risorse in caso che gli utenti diventino di piu`


Si, poi dipende da come gestisci e vuoi far crescere infrastruttura del
paas provider che stai costruendo.
In fase iniziale magari te la cavi con un po' di server dedicati (tipo
http://www.ovh.it/server_dedicati/,
http://www.hetzner.de/en/hosting/produktmatrix/roo...)
con su linux ed openstack.
Diciamo finch prodotto-servizio  in beta, aperto ad un numero massimo di
clienti.
Dopo forse virtualizzare per gestire tanti server diventa quasi un 
obbligo.
Ma non  detto: d'altronde prima del trend "tutti i datacenter con
virtualization technology" si gestivano anche datacenter non piccoli con 
le
solite vecchie pratiche del buon sysadmin :-)

S.

>
> Secondo me un PaaS come dici te e` possibile, ma sembra che tutti usino
> solamente Amazon o Linode.
>
> Guardando dotcloud sembra che si avvicini all'idea che avevo, non sembra
> male. appfog e` sempre basato su EC2 e non mi sembra tanto piu`
> conveniente piu` di Heroku
>


Non partecipo alla discussione perche' lavoro/collaboro con almeno 3 dei
servizi citati e quindi sono in conflitto di interessi :)

Pero' Ti/vi do' qualche dritta/consiglio:

- Heroku e DotCloud hanno gia' ridotto i costi ai minimi possibili, fare
di meglio e sperare di guadagnarci e' dura (vedere ep.io e djangozoom 
che
sono morti prima di fare i soldi)

- fornire servizi non e' solo una questione tecnica, implica conoscere
ogni singolo aspetto dell'infrastruttura che offri, per capirci se basi 
il
tuo lavoro su chef e puppet non farai meglio dei provider di inizio 
2mila
che pensavano di mettere su un servizio a colpi di cpanel (sono morti
tutti...)

Se c'e' un problema (dal kernel, all'immagine del cavolo che non si
visualizza) devi saper individuare TU il problema, non il cliente. 
Questo
e' ancora piu' amplificato quando offri servizi ad utenti 'amatoriali' 
che
non hanno la minima idea di quello che stanno facendo (ma che possono
farti cattiva pubblicita' con estrema competenza :P)

- l'assistenza e' la chiave, l'helpdesk deve essere fatto da 
sviluppatori
che conoscono (o usano) i prodotti che offrite, e deve coprire una 
fascia
oraria il piu' ampia possibile (ad esempio con Unbit che opera solo in
Italia e con clienti business il 30% delle richieste arrivano tra le 2 e
le 5 del mattino). Da Dotcloud che ne sono di continuo :) Heroku non lo
so, ma presumo sia un bombardamento totale ;)

- la sicurezza E' TUTTO, prendete in considerazione di pagare un'esperto
sia di sicurezza reti che di isolamento account. E' quello su cui Heroku
(ad esempio) continua ad investire (la nuova piattaforma ceddar e' 
basata
su cgroup/namespace). Se un cliente ne danneggia un altro siete finiti
(basta un blog post del bimbominkia di turno e dite addio ai vostri 
sogni)

- L'hardware si rompe, e' il motivo per cui tutti virtualizzano (anche 
se
hanno hardware a disposizione). Dopo un po' di tempo diventera' piu' 
utile
perdere performance piuttosto che dover gestire hardware (o aspettare 
che
l'omino di turno vada in server farm a fare la sostituzione o l'aggiunta
di un nodo).

- la meta' delle volte non e' disponibile software per quello che vi 
serve
(i fornitori di servizi e' rarissimo che rilascino i sorgenti di 
qualcosa
visto che e' la parte che li rende competitivi), quindi preparatevi a
scrivere tonnellate di codice. (a partire dagli application server...)

- il single system image e' ancora un sacro graal, se ci riesci diventi
ricco o finisci a insegnare al MIT

- dite addio alla vostra vita privata e preparatevi a spendere una marea
di soldi ;)

Per il resto io approvo qualsiasi iniziativa imprenditoriale in ambito 
IT,
soprattutto in Italia e soprattutto quando prova a fare concorrenza ai
colossi, quindi in bocca al lupo :)

a parte lodare Unbit (sempre disponibile il servizio e l'assistenza), 
dal basso della mia ignoranza, Loris ha dato un quadro pessimistico ma 
realistico.
Molto interessante il fatto che Unbit abbia messo a disposizione parte 
del loro codice open source (uwsgi).

2012/10/24 Roberto De Ioris <roberto@unbit.it>

> - il single system image e' ancora un sacro graal


http://en.wikipedia.org/wiki/Single_system_image

figo :-)

Il giorno 24/ott/2012, alle ore 09:29, Michele Casari 
<lablinux@gmail.com> ha scritto:

> a parte lodare Unbit (sempre disponibile il servizio e l'assistenza),
> dal basso della mia ignoranza, Loris ha dato un quadro pessimistico ma
> realistico.
> Molto interessante il fatto che Unbit abbia messo a disposizione parte
> del loro codice open source (uwsgi).
>

In tutta onesta', se i colossi non ci "sponsorizzavano", col caXXX che 
lo rilasciavo :P

Alla fine siamo riusciti a costruire un business su un prodotto 
opensource, ma capita una volta su mille :(

--
Roberto De Ioris
http://unbit.it
JID: roberto@jabber.unbit.it

Michele Casari wrote in post #1080885:
> a parte lodare Unbit (sempre disponibile il servizio e l'assistenza),
> dal basso della mia ignoranza, Loris ha dato un quadro pessimistico ma
> realistico.
> Molto interessante il fatto che Unbit abbia messo a disposizione parte
> del loro codice open source (uwsgi).

Mi sembra piu` realistico che pessimistico. Chi fa hosting come lavoro 
ha sicuramente incontrato tante difficolta`, ne ho sentiti tanti di 
esperienze simili.

Sono d'accordo su tutto. Adam Wiggins e` entusiasta di EC2 proprio 
perche` permette rimuovere il problema dei guasti hardware e da la 
possibilita` di scalare immediatamente senza dover ordinare nuovi server 
ed attendere ore? Purtroppo questo gioco e` costoso e la qualita` si 
paga.

Mi rendo conto pero` che alcuni siti su EC2 o Linode hanno dei costi 
elevati solamente per avere un po` di HA e che non cresceranno in modo 
esponenziale. Quindi credo che ci sia un po` di posto per un servizio 
dove sia la app che il DB siano HA e bilanciati e magari che siano un 
po` scalabili.

Per esempio gestisco un sito Rails che usa il load balancer di Linode, e 
tre nodi da 2GB, in piu` usa S3. I tre nodi hanno il server web, un 
bilanciatore per il cluster mysql, ed una istanza del cluster mysql per 
nodo. Tutto questo per diminuire la possibilita` di avere downtimes. Il 
costo? $79.95 x 3 piu` $19.99 per il load-balancer. Credo che avendo una 
infrastruttura simile su OVH costerebbe circa 50 euro, ovviamente con 
una soluzione condivisa, tipo shared hosting.

Pensare di competere con heroku e` assurdo, sono molto bravi ed hanno 
tante risorse.

Il giorno 24 ottobre 2012 06:48, Roberto De Ioris <roberto@unbit.it> ha
scritto:

> Non partecipo alla discussione perche' lavoro/collaboro con almeno 3 dei
> servizi citati e quindi sono in conflitto di interessi :)
>

Non avevo dubbi (sul fatto che collaborassi con dei big player, tipo 
amazon
o dotcloud)
Possibilit che unbit apra anche su mercato europeo, usa (mondiale) per 
il
segmento business ?
:-)


> - Heroku e DotCloud hanno gia' ridotto i costi ai minimi possibili, fare
> di meglio e sperare di guadagnarci e' dura (vedere ep.io e djangozoom che
> sono morti prima di fare i soldi)
>

Si, competere solo su prezzo probabilmente porta al fallimento.

- fornire servizi non e' solo una questione tecnica, implica conoscere
> ogni singolo aspetto dell'infrastruttura che offri, per capirci se basi il
> tuo lavoro su chef e puppet non farai meglio dei provider di inizio 2mila
> che pensavano di mettere su un servizio a colpi di cpanel (sono morti
> tutti...)
>

+100


> Se c'e' un problema (dal kernel, all'immagine del cavolo che non si
> visualizza) devi saper individuare TU il problema, non il cliente. Questo
> e' ancora piu' amplificato quando offri servizi ad utenti 'amatoriali' che
> non hanno la minima idea di quello che stanno facendo (ma che possono
> farti cattiva pubblicita' con estrema competenza :P)
>

Verissimo.
Cmq bisogna avere la pelle dura.
Nonostante tutta la buona volont pu sempre capitare un errore.
Tipo non rispondere subito ad una richiesta di supporto, specie 
all'inizio
quando magari si  pochi e non ci sono i soldi per mettere su helpdesk di
10 persone.
Ed il cliente non perdona, mai (gi critiche, note negative, stroncature
... quando va bene, se non insulti)
Poi i clienti italiani devono essere particolarmente rognosi (in media
decisamente pi esigenti, poco comprensivi)
Probabilmente in parte dovuto alle tante frustrazioni che subiscono 
nella
vita quotidiana (lavoro, stress, problemi personali...)
Serve molta filosofia zen :-)

- l'assistenza e' la chiave, l'helpdesk deve essere fatto da 
sviluppatori
> che conoscono (o usano) i prodotti che offrite, e deve coprire una fascia
> oraria il piu' ampia possibile (ad esempio con Unbit che opera solo in
> Italia e con clienti business il 30% delle richieste arrivano tra le 2 e
> le 5 del mattino). Da Dotcloud che ne sono di continuo :) Heroku non lo
> so, ma presumo sia un bombardamento totale ;)
>

+100

- la sicurezza E' TUTTO, prendete in considerazione di pagare un'esperto
> sia di sicurezza reti che di isolamento account. E' quello su cui Heroku
> (ad esempio) continua ad investire (la nuova piattaforma ceddar e' basata
> su cgroup/namespace). Se un cliente ne danneggia un altro siete finiti
> (basta un blog post del bimbominkia di turno e dite addio ai vostri sogni)
>

Il cliente non perdona, mai
Anche se sta usando un servizio gratis :-)

- L'hardware si rompe, e' il motivo per cui tutti virtualizzano (anche 
se
> hanno hardware a disposizione). Dopo un po' di tempo diventera' piu' utile
> perdere performance piuttosto che dover gestire hardware (o aspettare che
> l'omino di turno vada in server farm a fare la sostituzione o l'aggiunta
> di un nodo).
>

In effetti

- la meta' delle volte non e' disponibile software per quello che vi 
serve
> (i fornitori di servizi e' rarissimo che rilascino i sorgenti di qualcosa
> visto che e' la parte che li rende competitivi), quindi preparatevi a
> scrivere tonnellate di codice. (a partire dagli application server...)
>

Immaginavo ... software house decisamente parte integrante (e core
business) del provider

- il single system image e' ancora un sacro graal, se ci riesci diventi
> ricco o finisci a insegnare al MIT
>

Improbabile (che si riesca a trovare il sacro graal :)

- dite addio alla vostra vita privata e preparatevi a spendere una marea
> di soldi ;)
>

Eh ... speriamo non troppo (addio a vita privata)
Per spendere una marea di soldi ... in Italia  pure peggio :)
Li chiamano investimenti per progetti aziendali.
E poi ritrovi i tuoi soldi spesi per auto, feste, consulenze, rimborsi
chilometrici ...
Anche qui serve filosofia zen :-)

S.

Il giorno 24 ottobre 2012 10:27, Riccardo Tacconi <rtacconi@gmail.com> 
ha
scritto:

> Per esempio gestisco un sito Rails che usa il load balancer di Linode, e
> tre nodi da 2GB, in piu` usa S3. I tre nodi hanno il server web, un
> bilanciatore per il cluster mysql, ed una istanza del cluster mysql per
> nodo. Tutto questo per diminuire la possibilita` di avere downtimes. Il
> costo? $79.95 x 3 piu` $19.99 per il load-balancer. Credo che avendo una
> infrastruttura simile su OVH costerebbe circa 50 euro, ovviamente con
> una soluzione condivisa, tipo shared hosting.
>

Probabilmente si (soluzione con un target un po' pi alto, che ha bisogno
di ha e fault tolerance)
Cmq tieni conto che nei 260 $ c' anche il "costo nascosto" di assistenza
tecnica super 24x7 (ossessiva alla engineyard :)

Pensare di competere con heroku e` assurdo, sono molto bravi ed hanno
> tante risorse


Si, competere subito pronti via con heroku (o engineyard) pu andar bene
come marketing slogan, nella vision all'americana, in un pitch o 
business
plan.
Ma pensare di farlo sul serio ... ;)
Non so heroku (molto bravi e con un dev center di tutto rispetto)
ma engineyard solo per assistenza tecnica quanti centri ha sparsi per il
mondo ?
E persone (in gamba) che ci lavorano
http://www.engineyard.com/company
>>> Were headquartered in San Francisco, California
>>> with offices in Portland, Oregon and Dublin, Ireland.
>>> We also have teams located across the United States
>>> and around the world.

No way :)

S.

Il giorno 24/ott/2012, alle ore 15:03, Sergio Berisso 
<sergio.berisso@gmail.com> ha scritto:

> segmento business ?
> :-)
>


A parte che violeremmo una 70ina di accordi di "non belligeranza", c'e' 
anche il fatto che i miei
soci ancora mi maltrattano per l'idea malsana (2006-2008) di aprire "a 
tutti" :(

Poi ormai sono "vecchio" e, cosa ancora piu' importante ho appena 
iniziato ad assaporare la bellezza di dormire la notte senza
qualche allarme che suona :)


>
> Cmq bisogna avere la pelle dura.
>

giusto, ho dimenticato di dirlo ma e' forse l'aspetto piu' importante.

Alla fine e' lo stesso meccanismo di difesa che devi costruirti quando 
rilasci il software, c'e' sempre qualche professore (tendenzialmente
che non ha mai rilasciato una sola linea di codice) che ti tira melma. 
Alla fine se vuoi sopravvivere cerchi di estrapolare il meglio dalle 
critiche
e provi a migliorarti (questo a parole, in realta' non conosco nessuno 
che ci riesca, forse solo chunk norris puo'...)

--
Roberto De Ioris
http://unbit.it
JID: roberto@jabber.unbit.it