Dopo Amazon, Google  e Azure, anche Oracle è entrata nel mercato Cloud. Nell’ultimo periodo Oracle Cloud propone in modo aggressivo con lo slogan “Always Free” una serie di risorse che saranno sempre disponibili senza accrediti ulteriori. Ovviamente non è tutto oro quello che luccica ma…abbiamo fatto un paio di prove per saggiare questo servizio.

Read More

Bill Gates ha detto che tendiamo a sovrastimare gli avanzamenti tecnologici dei prossimi due anni e a sottostimare quelle dei prossimi dieci.

Al momento ci sono due forze opposte nel mondo dell’IT:

• Da un lato i provider cloud, i container (=K8s per intenderci) sembrano portare verso un mondo di servizi agili e leggeri. In Java l'application server sta concettualmente morendo, se ne parla sempre meno e sa di "vecchio". Le mesh di reti coordinate con K8s possono fare tutto quello che faceva un application server, e scalare molto di più. I server in cloud non bruciano né si rompono, e la loro capacity può essere regolata  in modo elastico (entro certi limiti).
• Dall'altro lato AMD ha sdoganato nel mondo consumer una CPU da 64 processori e 128 thread, che benché sia sbilanciata sulla potenza computazionale pura renderà sempre più economico avere un server in casa piuttosto che affittarne uno sul cloud. Questo perché AMD sta tenendo il costo per thread intorno ai 30$.

Realisticamente un  Threadripper entry-level da 24 core (3960x) viene intorno ai 1600€ su Amazon. Possiamo supporre che questo costo scenda (o che il numero di CPU si alzi a parità di costo) anche senza che la legge di Moore ci supporti più di tanto. Il trend potrebbe essere leggermente più lento, ma sarà inesorabile. Non è ancora comparabile con una soluzione in Cloud, che è certamente troppo diversa e tendezialmente più flessibile come combinazione di memoria e CPU.

Il software però si trova stretto in una certezza: il numero di CPU aumenterà in modo significativo (nell’ordine delle decine, almeno) e quindi bisognerà adeguarsi sempre di più a questo nuovo contesto. Le soluzioni basate su micro-servizi promettono di poter scalare in ogni direzione, ma il peso sull’architettura software è immenso: in particolare le nuove architetture richiedono una serie di servizi infrastrutturali complessi come:

Read More

!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à.

Read More

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.

Read More

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

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:

Read More

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”!

Read More