Simon Sinek lo ha scelto come titolo del suo libro, noi in evoseed ne abbiamo fatto il nostro mantra: “Start from why”.

In evoseed partiamo dai bisogni dei nostri clienti. E’ inutile realizzare un software, un hardware, un servizio bellissimo e super funzionale che però non serve a nessuno; preferiamo partire dai e sviluppare iterativamente una soluzione che risponde a delle reali necessità di mercato.

La prima cosa che facciamo quando partiamo con un nuovo progetto è farci delle domande; e le prime domande sono proprio: Perché sviluppare questo servizio? A quale bisogno va incontro?

Quanto è sentito ? A chi possiamo “dare più sollievo?“

In questo articolo vogliamo quindi condividere con voi le risposte che ci siamo dati prima di appoggiare le dita sulla tastiera ed iniziare a scrivere il codice di CloudTik.

Chi ha partecipato al webinar del 16/06 ha ricevuto già qualche spoiler, se invece non sei riuscito a partecipare al webinar puoi rivedere la registrazione qui

Perché è nato CloudTik.

• una significativa semplificazione nella gestione dei MikroTik, senza pagare la loro complessità
• una necessità di automazione al fine di ridurre i tempi e costi e soprattutto gli errori umani in un’attività “meccanica” e ripetitiva come la configurazione in serie di apparati standard da spedire ai clienti.

Abbiamo definito i MikroTik “Croce & delizia”.

Sono una delizia per il basso costo, per la loro resistenza costruttiva (in 10 anni di utilizzo di parecchie migliaia di apparati pochissime volte ci è capitato che si rompesse l’hardware) e perché c’è una vastissima gamma di modelli adatti ad ogni uso.

Montano a bordo un Sistema Operativo il RouterOS che è potentissimo, completo e ricco di funzionalità e la stessa versione è installata su qualsiasi hardware MikroTik , dalla RouterBoard più piccola alla RouterBoard più grande e potente.

I MikroTik hanno così tante funzionalità e possibilità che possono assumere la funzione di un oggetto diverso a seconda delle necessità. Il loro SO, che è il suo punto di forza, è programmabile, ci permette di creare degli script personalizzati, mette a disposizione uno scheduler per farli eseguire in automatico con cadenza temporale.

Qui di seguito solo alcuni esempi di come abbiamo utilizzato negli anni questi apparati:

- VPN multi sede con Routing dinamico (sia bgp che ospf)

- MultiWAN router con load balancing e failover automatico

- Virtualizzazione di LAN ufficio / data center grazie a EoIP (Ethernet over ip)

- Implementazione di sistemi di secure mobile office

- Sistemi di Routing e autenticazione di wireless POP su punti bras

- BGP router con full Routing table (ad oggi siamo a circa 725000 prefix da tenersi in memoria)

- Firewall perimetrale per cluster di VM

- Reti MPLS

- Sistemi di prioritizzazione del traffico e di taglio banda per servizio

lo scotto da pagare, la nostra croce è la gestione della complessità.

Come disse Ben Parker a suo nipote in Spider-Man “da grandi poteri derivano grandi responsabilità“. Noi in questi anni ci siamo imbattuti in quella che possiamo definire l’altra faccia della medaglia di un sistema che ti permette di fare veramente tante cose e in modi diversi, un sistema appunto complesso.

Abbiamo ripensato alle situazioni più “fastidiose” in cui ci siamo trovati ed abbiamo pensato a come sarebbe andata quella situazione completando la frase “... se avessi avuto…”

Abbiamo ripensato alle prime esperienze coi MikroTik:

• 2 ore per configurare la cpe, non salvi la configurazione, arrivi dal cliente e ti chiede di cambiare la configurazione, aggiorni la configurazione e nuovamente ti dimentichi di fare backup. Una settimana dopo un fulmine brucia l’apparato.

Se avessi avuto il backup aggiornato da qualche parte, avresti ripristinato al volo la configurazione su un nuovo apparato e avresti riattivato l’operatività della rete del cliente in tempo 0.

• Cliente multisede, tre connettività per ogni sede, VPN per ogni connettività e OSPF come sistema di Routing dinamico. Una configurazione non rocket science ma bella complessa.

Ovviamente 0 documentazione, 0 commenti sulla configurazione dei MikroTik, 0 diagrammi (o peggio, diagrammi vecchi e quindi sbagliati), e chi ha configurato il tutto nel frattempo ha cambiato azienda. L’unica strada diventa il reverse engineering.

Se avessi avuto un template standard di configurazione e un sistema di backup con le diff sarebbe stata molta meno fatica e saresti stato molto meno tempo per fare qualsiasi debug o integrare nuove configurazioni.

• Cliente con connettività di backup su chiavetta mobile, assenza completa di sistema di monitoraggio con allarme pro-attivo, scopri che la connettività principale era guasta da più di una settimana. Ovviamente non te ne sei accorto, anzi se n'è accorto il cliente, quando la chiavetta ha smesso di funzionare perché aveva finito il plafond.

Quindi il sistema di doppia-connettività e switch automatico aveva funzionato benissimo, il cliente non si è accorto di nulla quando la connettività principale si è guastata ed è stata attivata la connettività di backup sulla chiavetta mobile.

Se avessi avuto un sistema di monitoraggio e allerta proattivo avresti scoperto immediatamente quando la connettività principale sarebbe andata in errore e quindi saresti potuto intervenire senza dare disservizio al cliente.

• Quante volte ti è successo di configurare una CPE da mandare al cliente e scoprire durante l’installazione di aver dimenticato quel pezzo di configurazione.

E quanto tempo in media ci vuole per configurare un apparato da spedire al cliente? È un’azione “meccanica” e ripetitiva, è assolutamente automatizzabile.

Se avessi avuto un sistema di auto-provisioning non solo ti avrebbe fatto risparmiare una quantità di tempo indescrivibile, avrebbe ridotto gli errori di configurazione al minimo.

• Quanto tempo investi per fare debug quando “non va l’internet” per poi scoprire , grazie al torch, che “iphone di Giorgio” sta caricando i video della vacanza sul cloud ? O che la connettività principale perde pacchetti ?

Se avessi avuto un sistema di autodiagnosi in grado di fare torch, Speedtest, analisi stato connettività , ping e traceroute con un click e un report di risultato ti avrebbe non solo permesso di risparmiare un sacco di tempo, ma anche di dare un’immagine più professionale del servizio di assistenza !

Questo è stato il punto di partenza per elencare le possibili funzionalità da sviluppare in CloudTik.