Don’t buy servers.

Don’t buy servers.

No, please don’t. Not even for personal use.

Let me start from the beginning: during my relocation last year, I left my desktop computer behind. It hadn’t been my primary machine for a while and I was probably powering it on only once a month, but it was still my core repository for backups and long term storage.

As I went 100% cloud years ago (no USB drives, no external HDDs, etc) my “current” dataset is now online, synchronised with my laptop(s). Still, there are some hundreds of GBs of “cold” (as in: I will probably never need them again) pictures/docs/archives that I want to be able to access, even remotely, at any time. After exploring some mid-range NAS solutions, I ended up realising that despite having a reliable internet connection, my flat was not the best location for hosting it, so started looking around for a decent colocation space.

It didn’t take much time to figure out that space and power in a datacenter are so expensive that a NAS isn’t suitable nor effective for this purpose.

As a consequence…


…meet MY-ZA*.

MY-ZA is an HP DL320e Gen8 server, equipped with an E3-1240 v2 CPU, 32 GB of RAM, and 2×250 GB SSD + 4x1TB SATA drives. Dual PSU, P420i hardware RAID controller, iLO4, etc… …yes: a real server.

I’m sure you’re now wondering what the hell I am doing here. The answer is easy, and anybody with an engineering mindset can probably confirm: sometimes we need to spend time and energy in experiments even if we know they will fail, because what we want to figure out is how exactly they will fail.

To be honest, even if I knew this choice was sub-optimal at the very least, I was like: “Hey, what could go wrong? It’s just a server”.

Well, now I know the answer: anything – (and if you cross this with Murphy’s law…).

My background is in traditional IT, but looks like I quickly forgot about the pain of having to deal with bare metal. To make sure this doesn’t happen again, here’s a quick reminder that might also help you all:

  • Servers are expensive: this is a $2800 machine (I’ve paid roughly 50% of that), that will cost around 70/80$ per month just by colocation and bandwidth. Moreover, in 2 years time it will be obsolete.
  • Bare metal servers are… …heavy: arranging shipping back and forth costs time. And money, of course.
  • They’re slow, reaaaaaaalllllly slooooooww. This thing wastes 10+ minutes just to get to the operating system boot. Don’t forget this if you’re doing something that requires a lot of reboots (like trying different RAID configurations, updating a newly installed Windows, etc). We’re now in an era where the boot time of an instance is shorter than what it takes to you, slow and inefficient human, to copy and paste connection details in your SSH client.
  • What about the risk? Well, it’s huge. I have onsite support, but no spare parts. So, should something bad happen, the downtime will be counted in hours, at least.
  • They don’t scale. This “thing” has already reached the maximum amount of RAM it can hold. What if I need more? I have two options, double the colocation space (and thus cost) and buy a similar second server, or buy a larger one to replace it and begin a slow, complex and painful migration.
  • Agility? What? – You must manage it as you would do with a pet. If something breaks, repair it, if the OS is out of date, upgrade it. Well, in a world where if an instance is broken you immediately spin up a new one, having to fix an OS doesn’t seem appropriate.
  • SSDs do have a well defined lifespan. This is not something you care about if you’re using a cloud hosting service, but here you should keep it in mind, as they will eventually die. Both at the same time, as their load will be similar.

After having spent the last 7 days (evenings to be fair, as I have a job during the day) on this project, I think I have definitely debunked the theory about cloud not being effective for personal workloads.

Project failed, time to terminat…

…no, wait, you can’t terminate a bare metal server: it’s an investment, it’s a long term decision, you can’t just roll back as you would do with a cloud instance.

Oh, God.

 

* don’t even try to understand my host naming convention. There are no standards, names are just random letters. Servers are cattle, not pets, right?

Going Cloud: the 8 don’ts

Going Cloud: the 8 don’ts

Okay, let’s face it: the world is finally 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 new adopters there are still many misconceptions and wrong expectations.

Wrong expectations are probably the most common reason for failure, because they usually lead to disasters that leave moving back to a legacy infrastructure design as the only option left.

datacenter_scale

(Image Source: XKCD)

But, turns out, it’s easier than you would expect. There is a basic set of rules and guidelines, and if you follow them you can easily be successful.

Let’s begin in this article with the 8 don’ts:

  1. Never, ever trust a single instance of a given service. Don’t rely on redundant database platforms, replicated block devices, and so forth. They can still fail: accounting for this kind of failure at the application layer is the way to go.
  2. Don’t put all your eggs in a bucket: cloud platforms are available in different geographical locations by nature, so you should really leverage this. True geographical redundancy can be hard to achieve at the beginning, but try at least to have read replicas spread over the world, so that in case of downtime in the main region you’re using your service would just be degraded and not completely unreachable.
  3. Never 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 when needed, you won’t have to worry about later.
  4. Don’t design complex software platforms: micro services are the way to go. Keep them simple and easy to maintain. It will be easier to scale them, and 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 small number of users, but is going to be an issue when your platform grows. Make your application as efficient as possible, even when it doesn’t seem needed.
  6. Don’t forget that everything could break, at any time. Keep your instances as simple as possible, so that they are easy to operate. If one fails or starts misbehaving, just respawn it, don’t waste your time trying to fix or debug it. In an ideal world, they should all be stateless.
  7. Vertical scaling is a no go. Choose the size of your instances based on the performance you want a single request to have, but always spread multiple requests horizontally. This pattern will help a lot with 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 efficienty, and new versions of the services your cloud provider is offering you usually improve a number of items, cost being usually the main one. Running a legacy instance type just because your platform is too hard to upgrade to a newer operating system makes no sense and will kill your business in the long term.

Here we are. Now go and build!

La Generation Y e l’Analfabetismo Funzionale

La Generation Y e l’Analfabetismo Funzionale

Ho 24 anni compiuti da poco e ho la fortuna di vivere e lavorare in un contesto aperto, globale, di quelli in cui non si smette mai di crescere: lavoro ogni giorno a fianco di inglesi, israeliani, americani, argentini, malesiani e molti ancora, e ho relazioni personali con ragazzi/e di una gamma ancora piu’ vasta di nazionalita’.

millennial

Si tratta di persone che hanno girato il mondo, che vivono in ambienti altamente competitivi, persone che per seguire i propri sogni e obiettivi si sono trasferite anche a decine di ore di volo dai posti dove sono cresciute e dove hanno famiglie, amici e legami. Persone che si sono spinte sempre oltre i propri limiti, dal collega argentino seduto di fronte a me, alla mia (ex?) ragazza siberiana, che, cascasse il mondo, ogni 3 mesi torna a casa dalla mamma almeno per un weekend.

Persone che attraverso percorsi differenti sono arrivate a sedere di fianco a me o a far parte della mia vita, persone come me che sanno di essere solo ad uno step intermedio, perche’ non bisogna mai smettere di crescere e di alzare la barra. Persone che hanno sempre fatto scelte forti sapendo benissimo che avrebbero dovuto pagarne prezzo e conseguenze molto prima di vederne, in lontananza, i risultati.

Faccio parte di quell’ala della Generation Y che non smette mai di correre, che pretende di far girare il mondo a suo piacimento ma che ha anche imparato a viverci, quell’ala della Generation Y che prova, instancabile, a dare un senso a tutto il resto.

Siamo quell’ala che mai si ferma, che fa della crescita e del miglioramento continuo lo scopo della sua esistenza, la GenY che sposta sempre la linea del traguardo qualche metro piu’ in avanti rispetto a dove deve arrivare, la Generation Y che cerca dei miti e degli esempi di vita non per poterli seguire e venerare ma solo per poterli superare.

Siamo i Millennials mai contenti, siamo quelli che anche quando raggiungono una meta non sentono di essere arrivati, perche’ ancora prima di raggiungerla iniziamo a pensare a quella successiva. Siamo quelli che non puoi chiudere in una stanza, un paese o in uno stato, perche’ le barriere ci fanno stare male, e perche’ vogliamo sempre andare oltre quello che abbiamo.

Il viaggio e la distanza sono fondamentali. Sono circondato da persone che non hanno mai dato importanza al proprio “orticello”, che se ne sono andate e che magari poi sono anche tornate, ma che comunque hanno avuto la forza, o forse il coraggio, di staccarsi da quello che avevano e in cui, tutto sommato, stavano bene.

Ognuno di questi a modo proprio si e’ scontrato con il mondo: chi lavora in un mercato globale dove per sopravvivere non basta essere tra i migliori del quartiere, bisogna essere tra i migliori del mondo, chi ha superato test di ingresso e graduatorie allucinanti contro ragazzi provenienti da ogni parte del pianeta per entrare in una universita’, chi semplicemente ha preso e se ne e’ andato, cercando una vita nuova.

C’e’ una barra tra questo tipo di persona e tutto il resto: riflettendoci, nella mia vita questa barra credo di averla superata all’inizio del liceo. Ho frequentato un istituto che ci era stato presentato come l’inferno, dove bisognava correre e studiare o si rischiava di rimanere fuori dai giochi, e forse questa e’ stata la chiave: chi si e’ ritrovato li’ con me aveva gia’ fatto una scelta, si era gia’ spinto oltre. Aveva rischiato.

Vi assicuro che ne stiamo raccogliendo risultati, dal primo all’ultimo. Chi li raccoglie gia’, chi sta per iniziare a farlo, chi deve forse ancora convincersi e aprire gli occhi per vederli.

Sotto questa barra non ci sono mai piu’ voluto tornare, nemmeno come turista, perche’ c’e’ anche la parte che e’ rimasta sotto. Quelli che hanno fatto scelte a breve termine, quelli per cui essere liberi tutti i pomeriggi era piu’ importante di ogni altra cosa. Quelli che non si staccano dal loro contesto locale, perche’ e’ li’ che spadroneggiano e sanno benissimo di non essere in grado di spostarsi, perche’ per raggiungere la stessa posizione in qualunque altro posto dovrebbero confrontarsi con il mondo intero.

Sono anche quelli che alle elementari hanno imparato a leggere dopo tutti gli altri, e che in terza media ancora non sapevano leggere una pagina senza incastrarsi o balbettare. Quelli che, insomma, si sono accontentati e che continuano a farlo, guardando con disprezzo chi e’ andato oltre, nella convinzione che se loro non ci possono arrivare, allora non puo’ farlo nessuno e deve sicuramente esserci un trucco da qualche parte.

Il problema, e’ sociale e non personale: perche’ chi rimane sotto non sviluppa capacita’ di giudizio, di analisi, e spesso manca anche delle capacita’ basilari di comprensione necessarie a vivere in questo periodo storico. Vive da schiavo facilmente controllabile in un periodo dove le idee sbagliate uccidono (gli altri), periodo dove ci sono persone, e macchine, che stanno imparando ad usare le folle di ignoranti a loro favore. Non riuscire a giudicare quello che succede nella vita quotidiana diventa in breve tempo un grave rischio: i mezzi che oggi sono disponibili a chiunque permettono di esprimere opinioni troppo alla leggera, e rendono molto semplice la raccolta di adepti e di schiavi degli schiavi. Creando nuovi branchi.

Si chiama Analfabetismo Funzionale. I sociologi lo hanno correlato a crimine, uso di droghe, basso reddito e in generale basso livello di soddisfazione. L’analfabetismo funzionale crea masse, masse facili da controllare e da usare a piacere. Dobbiamo di nuovo imparare a difenderci dai branchi.

Fortunatamente, c’e’ una gran parte della generazione che ne sta portando alto il nome nel mondo.

Non guardate sotto la barra, guardate sopra.

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

Time to clean things up.

Time to clean things up.

It was largely unexpected, but yesterday’s post had an enormous success. Okay, nothing compared to The Blonde Salad‘s posts, but I wasn’t expecting at all to get 500 visits in a couple of hours on a blog that I was considering as dead & forgotten.

This means it’s time to focus on improving your experience on this website. The weather in Ireland, where I currently am, is really helping me focus on my blog:

img_2570

What I’ve done so far, in detail:

  • HTTPS: I finally completed the SSL integration. All static links have been modified to use HTTPS, and any HTTP URL is now redirecting to its SSL version.
  • Categories & Tags: I wasn’t using categories and relied on tags to categorize my posts. After a few years the tag cloud had become a real mess, so I spent a few hours in cleaning it up and reducing the number of tags per article. From now on, every post won’t have more than 5 tags and will belong to 2 categories: the real category, and a second one (English, Italian) based on its language.
  • Caching: WordPress wasn’t performing at its best, so I tuned W3 Total Cache and switched to Memcache as its backend. It’s much better now.
  • Permalinks: Sounds like my permalinks are not so permanent. I’ve modified some titles and URLs, so you should expect to incur in 404 errors for the next few days if you’re getting here via Google or old links.
  • MySQL: Yes, believe it or not, I was still using MySQL 5.5. Switched to MariaDB 10.1, and I’m in the process of tuning it: you should expect some brief downtimes in the next few hours, while I restart services.

That’s it, for now at least.

Stay tuned!