On containers and orchestration

I don’t know what do you think about containers and orchestration tools, but for me it’s been a while since I started discussing on those topics on forum and various platforms, and I can’t say It’s an easy discussion.
To be honest I’m quite tired of repeating the same concepts so I thought this blog could be help me to express my point of view, at least in future I only have to copy and paste this post url and not waste time anymore :)

For someone my point of view on containers and microservices could sound a bit grumpy, but I can assure that I’m not against them, or think they are bad or simply some nasty trend.

First of all It’s imperative to distinguish between two main scenarios: development/test and production environment.

For the first one containers are wonderful, they are the Nirvana and Shangri-La all together, they give developers the opportunity to setup dev environment in no time, no setups, no hard requirements, everything is perfectly consistent and works in the same way as the tools they are familiar with (think about git or other versioning softwares), everything is perfectly reproducible on whatever platform, their work pc, home pc, a server, a laptor, everything.

For production… well It’s not the same.
First of all: the most important requirement for a production environment is reliability, then comes security, then everything else.
Literature, research, experience and logic taught us that these two basic requirements could be reached only following the KISS principle (Keep It Simple Stupid) which is not a joke, It’s real, It’s true and It works, period.
Second, when your application moves from development to production It moves from developers to sysadmins, It’s the sysadmin the guy which must maintain It, that must provide resources and guarantee that the application (and all its requirements) are working, are reliable and kept secure.
Third: if you think about the lifecycle of an application most of It is in production, an application could require a few months of development but will remain online for years, and usually the more It will require for the development the more It will remain in production.

Following the KISS principle means REDUCE COMPLEXITY, containers ADD COMPLEXITY :\
This may sound strange to containers users because “well it’s a piace of cake, launch a couple of commands and you’re ready to go”, well stop for a moment and think about it.

  • On a “legacy” environment you have, applications (your site, your database, etc etc) on top of services (webservers, application servers, rdbms, etc etc shared by several applications) on top of an OS (shared by several services) on top of some sort of hardware (which could be very complex in production, and could be shared between several OSs if you’re using virtual machines).
  • With containers and orchestrators (like Kubernetes or Openshift) you have a LOT more complexity, you still have your applications, on top of services (which are the same as before for instance…), on top of containers, on top of a container environment (for example Docker), on top of orchestrators, on top of a OS (usually installed on a vm, so add also the hypervisor complexity) on top of hardware.

More complexity means less reliability and less security, or a least a lot more work and variables to manage to reach the same level of those requirements.

Like everything there are pros and cons, and someone could argue that beside that added complexity containers and orchestrators give you a lot of benefits, mainly:

  1. reproducibility
  2. horizontal scalability (adding more “nodes” and distribute load across them).

We already talked about the first before, It’s awsome for a developer, but for a sysadmin on a production environment?
Well, not really, simply we don’t need it because move an application between different environments is really rare (in 20+ years of IT consultant work It happened to me only one time, moving and Oracle 10g rdbms from Windows Server 2003 to RHEL) and usually any service have its own backup and restore procedures to accomplish this goal.

Scalability is another story, in theory it’s an awsome thing, in real world it’s not a big deal in 99% of companies or services.
The idea of having some black magic that will add more and more instances of your application and distribute the load on those is good and managers love it, they simply think this is the solution for every problem because, let’s be honest, they don’t understand the complexity behind an application and they think that all the problems come from lack of resources.

In the real world any experienced sysadmin can confirm that usually resources are enough and when an application have problems it’s all about some bug, exception, unmanaged situations (for example the application use a third party service which doesn’t work and the application does not manage it), all those things can lead to a slow or unresponsive application even if you have a lot of resources available.
Adding more and more application instances and balance load across them will lead to a simple result: more and more exceptions.

Ok, let’s ride our fantasy horse and think about a bug free application, can we scale up with containers with no worries?
Sure you can, but do you really need it?
For 99% of companies nowadays it’s really rare that an application don’t have enough resources, or have such a huge amount of requests to run out of resources.
If you are Google, Facebook, Netflix, Amazon or any other global huge company maybe you really need horizontal scalability, so orchestrators and containers are very useful (it’s not surprising that one of the most popular orchestrators, Kubernetes, came from Google), otherwise… well no, you don’t need it.

So that’s all?
No, there are a lot of smaller pros and cons (most cons to be honest imho…) on this topic, like security, access on third party resources, logging, service redundancy vs consolidation and many more.
Most of these are huge problems with containers (and most of the times they are ignored) while with a traditional architecture they simply aren’t, even a simple stdout append on a log is a pain in the ass with containers, and require to add a lot of complexity to reach this simple goal (remember KISS principle).

Let me add a small personal thought on this subject that can be extended in many other areas of the IT universe.
As you probably understood I think that containers are a really good tool for developers and not a good one for sysadmins, containers are born from developers for developers.
Why people always think that a development tool should work for production?
Why people don’t think from a production perspective when they develope tools for production?

If you are a developer and you’re working on a tool that will be used in production, please ask your sysadmin what does he think about it, what’s its requirements, what are the problems that he usually have in production and he need to fix.
Maybe if we start to develope tools from the right perspective we’ll have better results, otherwise we will continue to have always the same problems.



Wind Infostrada FTTC

Dopo tanto tempo ho deciso di scrivere uno post in italiano sperando che possa agevolarne la diffusione tra gli utenti del nostro Paese che si accingono ad aderire alle varie offerte di connettività propinate dai diversi operatori tlc.

Nel mio caso si tratta di Wind, operatore con il quale ho iniziato ad avere rapporti nel 2007 dopo una iniziale esperienza con NGI.
A onor del vero devo confessare di non aver mai avuto problemi catastrofici, la mia vecchia linea ADSL (seppur limitata a 4Mbps in downstream) si è sempre dimostrata stabile, affidabile e con una latenza decisamente superiore alla media.
A parte il feedback tecnico (variabile da zona a zona a causa dell’infrastruttura spesso in stato di abbandono) quello che mi ha favorevolmente impressionato è la flessibilità di Wind nell’applicare profili di connettività differenti da quelli proposti come standard, nel mio caso alzando la banda di upstream da 128Kbps a 512Kbps.

Poco meno di un anno fa scopro di avere copertura FTTC, viste la tariffe vantaggiose e il buon rapporto maturato decido di rimanere con questo operatore, tutto perfetto fino allo scorso agosto, quando noto un sensibile rallentamento nel downstream e un drastico aumento nella latenza.
Provo a lanciare qualche test con Speedtest.net utilizzando il server per me più affidabile (Fastweb Milano) e ottengo un ping aumentato da 5/6 a 25 ms e una banda in downstream diminuita da 60/70Mbps a 15/20Mbps.

Ripeto il test ogni giorno e ottengo lo stesso risultato, schedulo un test ogni 15 minuti utilizzando l’ottimo speedtest-cli da cui emerge un evidente problema di saturazione nelle ore serali, con qualche anticipo pomeridiano nel week end,  questo è il risultato, giudicate voi.




Riattivazione fallback https su Firefox

Di recente il protocollo HTTPS è al centro di attenzioni di cui purtroppo fin’ora non aveva mai goduto, per questo stanno emergendo una serie di vulnerabilità che fino ad oggi sono state sottovalutate dalla gran parte degli utenti e degli addetti ai lavori.

Per adeguarsi alle nuove best practice i browser si sono evoluti inserendo configurazioni sempre più restrittive nell’accesso https ai siti.
Tutto bene, tutto bello (e ci mancherebbe), purtroppo però come sappiamo il mondo dell’IT è tutt’altro che uniforme o allineato alle ultime versioni di ogni tecnologia; specialmente in ambito lavorativo capita di trovare prodotti vetusti, interfacce web per la gestione di dispositivi hardware, piuttosto che architetture che per mille motivi non possono essere aggiornate, e quindi utilizzano il vecchio e insicuro protocollo SSL2 o SSL3.
Sia chiaro, si tratta di servizi non esposti sul web, dove quindi il rischio di attacco è estremamente basso o comunque gestito mediante opportune politiche di accesso perimetrali (anche su più livelli).

Che fare quindi per riattivare la compatibilità con il vecchio protocollo e accedere in https a questi servizi ritenuti insicuri dai browser?
Firefox ci viene incontro dando la possibilità di riattivare manualmente la considetta fallback ssl3.

Aprire il browser e digitare nella barra degli indirizzi about:config, nel caso vi comparisse un warning di sicurezza come questo confermate premendo l’apposito pulsante.


Inserite nella campo cerca la stringa security.tls.version.min e settatene il valore a zero.


Fate lo stesso per il campo security.tls.version.fallback-limit settandone il valore a zero.


A questo punto non vi resta che riavviare il browser per rendere effettiva la modifica.

Ricordate di ripristinare il valori di questi due parametri di configurazione al termine dell’attività o comunque prima di accedere a siti web.


Redhat Network… WTF?!??!

Ecco un piccolo esempio del perchè è sempre utile usare estensioni per modificare la lingua del proprio browser.




Hatred e la violenza nei videogiochi

Sta facendo un gran parlare di se il trailer di Hatred, ovvero questo simpatico sparattutto in terza persona dove l’obbiettivo sembra essere semplicemente quello di sterminare ogni forma di vita.
Giusto ieri stavo leggendo un post sull’Angolo di Farenz intitolato appunto “Hatred e il senso di giocare“, volevo inserire un commento, ma visto che non ho tempo ne voglia di attendere che qualcuno mi attivi l’account ho deciso di scrivere qui quello che penso di quel post e di quel poco che si sa del gioco.

Iniziamo col dire che anch’io come l’autore del post non sono particolarmente disturbato dal ruolo che il giocatore dovrà ricoprire nel titolo in questione, insomma anche per me non fa ne caldo ne freddo andare in giro a freddare innocenti in un videogioco.
Quello che non condivido è quanto viene detto dopo, io non trovo ridicolo proporre titoli del genere, non trovo che siano scandalosi, e francamente non me ne può fregare nulla del loro presunto valore educativo o diseducativo (ogni adulto è responsabile per se stesso, i minori non sono un mio problema ma dei genitori).

Trovo questo atteggiamento decisamente ipocrita, l’autore non vuol dire che il gioco è scadaloso o sconvenientemente violento perchè sarebbe troppo “matusa” (o simile ai soliti giudizi dei media tradizionali), così mena il can per l’aia pur di demolirlo senza sapere nulla (perchè dal trailer non si deduce nulla dei mille aspetti con cui valutare un videogioco); semplicemente si limita a demolire un titolo sconosciuto dicendo che il massacro è fatto “così a cazzo”, senza motivo.
Ma scusate cari compari dell’Angolo, che mi dite delle migliaia di titoli più o meno acclamati dove il giocatore è costretto a fare cose “a cazzo”?

La ragione vera è che questo gioco si basa su una violenza gratuita e inspiegabile, violenza come fine e non come mezzo che spaventa e innorridisce l’autore e tanti che hanno commentato negativamente, smontando in anticipo un gioco che fin’ora nessuna ha avuto modo di provare.
Io in questo ci vedo molta ipocrisia (o per dirla alla Farenz, “faccia di culo”), per anni si è giustamente risposto  alle accuse di violenza nei videogiochi ripetendo che il mondo dei videogiochi e quello reale sono due cose distinte, ora che un videogioco non solo propone la violenza ma nel modo più crudo e spaventevole (per il semplice fatto che è senza motivo) si accampano scuse e si cerca un “non motivo” per screditare il videogioco.

La realtà è che la violenza gratuita e ingiustificata nel mondo esiste, la troviamo nella storia come nella cronaca, e proprio perchè ingiustificata ci spaventa e rappresenta un tabù.
Io non trovo nulla di scandaloso nel proporla in un videogioco, anzi nel costruirci un videogioco attorno, anzi trovo che sia una operazione normale (visto che è già stata fatta per tantissime altre forme artistiche) che può aiutare ad esorcizzare questa paura e forse a superare questo tabù.

Forse i media dovrebbero riflettere un po’ più sul perchè questo tipo di violenza ci spaventa così tanto, perchè genera risposte così violente (questa si violenza reale, anche se solo scritta) ogni volta che viene inserita in una forma artistica (videogioco, film, libro, musica  o altro), penso sarebbe una discussione ben più matura e utile rispetto allo starnazzare dietro a un videogioco.

« Post precedenti