All Posts in Blog

febbraio 20, 2017 - No Comments!

Hiring Great People – come abbiamo migliorato il nostro processo di recruitment

hiring

Attirare e selezionare le persone giuste consente di costruire un grande team, di farlo crescere in salute, mantenendo e consolidando la propria cultura aziendale.
Eppure troppo spesso il processo di recruitment è sottovalutato o demandato quasi interamente al reparto HR o a società esterne.

Nella sessione dell'agile day del 2015 Pietro di Bello ha raccontato il processo di recruitment che nel corso degli anni abbiamo messo a punto, di quali siano gli aspetti che valutiamo più importanti, dell’importanza di coinvolgere pienamente il team in questo percorso, facendo anche un confronto con i metodi di selezione “tradizionali”.

Si tratta ovviamente di un percorso mai fisso: il processo di recruitment può e deve cambiare ed adattarsi al crescere dell’azienda. E come tale pone sempre nuove sfide, che vorrei raccontarvi, sia di quelle vinte che di quelle perse.

Le slides della presentazione

 

Se vuoi provare dal vivo il nostro processo di recruitment, invia la tua candidatura dalla pagina di carriere.

febbraio 13, 2017 - No Comments!

Case Study PhotoVogue

Photovogue

Nata come società di stampa, al giorno d'oggi la maggior parte dei contenuti di Condé Nast è distribuita attraverso canali digitali, per cui sono necessari la stabilità delle piattaforme di distribuzione e la flessibilità della tecnologia.

PhotoVogue, parte del marchio Vogue, è una piattaforma per i fotografi che vogliono mostrare il loro talento con la possibilità di partecipare a mostre internazionali e iniziative e la possibilità di essere rappresentato da un'agenzia di New York Art + Commerce, una delle più prestigiose al mondo.
La piattaforma, lanciata nel 2011, aveva bisogno di un importante aggiornamento della tecnologia per supportare la crescita costante. Nel corso del kickoff del progetto il team ha deciso di sfruttare tutte le tecnologie all'avanguardia fornite da Amazon.

Abbiamo partecipato all’implementazione nel corso di un periodo di tempo di tre mesi, portando l'adozione di metodologie agili e le operazioni automation di infrastruttura. Amazon ha realizzato un case study sul progetto.

La soluzione

serverless architecture

  • AWS Lambda abilita la scalabilità automatica in base al traffico di PhotoVogue to scale.
  • Il Web Client di PhotoVogue utilizza le API REST costruite con AWS Lambda e AWS API Gateway.
  • Gli utenti possono caricare le loro foto utilizzando la funzionalità delle S3 Pre-Signed URLs.
  • AWS S3 scatena una AWS Lambda function che converte la foto caricata dall'utente in vari formati.
  • AWS RDS con MySQL sono usati come servizio di database.
  • AWS CloudFront è usata come content delivery network per i contenuti.
  • AWS API Gateway è usato come layer di caching per le API rest.

Leggi il case study: https://aws.amazon.com/solutions/case-studies/photovogue/

febbraio 2, 2017 - No Comments!

Nuovo Workshop – Build, test and run a microservice, in AWS Elastic Container Services

Un nuovo workshop si aggiunge al nostro catalogo, la prima edizione sarà il 9 marzo a Bologna in occasione di Incontro DevOps.

tweet workshop

Le sfide che portano ad un sistema distribuito basato su micro-servizi sono molte. Le aziende devono spesso modificare il loro modo di sviluppare, il loro modello organizzativo deve adattarsi ai processi DevOps e le scelte tecniche devono essere orientate a disaccoppiare il più possibile i componenti. Amazon Web Services sta rapidamente abbracciando architetture basate su micro-servizi cloud-native. Per velocizzare l’adozione dei micro-servizi AWS ha introdotto Docker come sistema per “containerizzare” i carichi di lavoro di applicazioni esistenti o nuove. In particolare AWS ha lanciato il servizio ECS (Amazon Container Service) per gestire in maniera semplice ed efficiente un cluster di tali container e ECR (Elastic Container Registry) come registro di contenitori Docker completamente gestito.

workshop

Durante il workshop metteremo in piedi una pipeline attraverso il servizio AWS CodePipeline che ci permetterà di automatizzare il flusso che va dalla creazione dell’intera infrastruttura, utilizzando AWS Cloudformation, fino all’esecuzione del servizio sul cluster Amazon ECS.
Vedremo poi come Amazon Blox (progetto open-source) ci fornisce una serie di API per creare orchestratori personalizzati.

Argomenti

- Deployment on AWS (CLoudformation, Opsworks, Beanstalk)
- CI&CD on AWS (CodeDeploy, CodeBuild, CodePipeline)
- Container on AWS (Elastic Container Services)
- All together: build, test and run a microservices

Cosa Impareremo

Impareremo a creare una Pipeline di CI&CD che va dal test di un micro servizio fino al deploy su un cluster di container docker passando per la creazione automatica dell’infrastruttura (Infrastruttura come codice).

A chi è rivolto

DevOps Engineer, Systems Engineer, Developer

Requisiti

Notebook con:
- Docker
- Apache Maven
- Editor (Atom, Sublime, etc)
- AWS Command Line

Docente

Paolo Latella

Prendi il biglietto per il workshop:

Eventbrite - Incontro DevOps Italia 2017
Non riesci a partecipare o vuoi offrire questo workshop al tuo team? contattaci per un'offerta onsite

gennaio 13, 2017 - No Comments!

I prossimi eventi

Save the date, tanti eventi in cui saremo presenti come organizzatori o tra il pubblico ad ascoltare.

25 gennaio - AWS business essentials & Re(Play):Invent + AWS User Group Ticino

aws

Il nostro primo evento in Ticino in collaborazione con AWS, un evento gratuito rivolto a coloro per cui il lavoro con AWS rappresenta una novità e per chi invece ha già
dimestichezza con il cloud computing e vuole scoprire le ultime novità presentate all’AWS re:Invent di Las Vegas.
A seguire, il meetup AWS User Group Ticino con ospite speciale il Technical Evangelist AWS Danilo Poccia.

Registrati qui

27 gennaio - Incontro Community 4DevOps + Docker Italia

i4di 2

Un incontro super a Roma, in cui si susseguiranno talk interessanti su Serverless, containers, orchestrazione e molto altro legato al mondo DevOps.

Vedi l'agenda

4-5 febbraio - Fosdem

fosdem

L'appuntamento da non perdere per gli amanti dell'open source, e della buona birra artigianale 🍻

Sito dell'evento

11 febbraio - mini iad Vimercate

mini iad

L'Italian Agile Days si fa piccolo e va in tournée, il keynote di Ran Nyman ci parlerà di casi di successo di un'implementazione del framework LeSS in aziende di grandi dimensioni

L'evento è già sold out 😢

 

Pronti a partire? ci vediamo li, o seguici su twitter

gennaio 13, 2017 - No Comments!

Mobile Development the XP way

XP mobile

Lo sviluppo di applicazioni mobile comporta nuove sfide rispetto allo sviluppo web tradizionale, come, ad esempio, testare l’applicazione su dispositivi in continua evoluzione o automatizzare i processi manuali ripetitivi e soggetti ad errori per il rilascio sui vari store e piattaforme di distribuzione.
All’ultimo Agile Days, Tiago ha raccontato la nostra esperienza e le soluzioni implementate per arrivare ad un processo di mobile continuous integration con compilazione automatica e rilasci per i tester. In una comunità non molto test infected non è stato facile applicare TDD, ma i risultati ottenuti in termini di stabilità e pulizia del codice giustificano l’investimento.

Slides della presentazione

Link utili

Tiago è anche il trainer del corso “Continuous Delivery su progetti iOS”  in cui vengono spiegate a livello teorico e pratico i principi e le tecniche che permettono di automatizzare il processo di rilascio su App Store. Contattaci per organizzare una sessione on-site per il tuo team.

gennaio 5, 2017 - No Comments!

Serverless Test Driven Development

serverless tdd

Il paradigma serverless permette di dimenticarci della gestione dei server per poterci concentrare sulla realizzazione di funzionalità. Insieme a Filippo Liverani all'Italian Agile Day abbiamo visto come creare funzioni Lambda mantenendo alta la qualità del codice, con l'utilizzo del test driven development e ambienti locali di sviluppo e di produzione quanto più simili possibili con Docker.

Durante il talk, Filippo ha mostrato in un'applicazione di test come scrivere il primo test di accettazione in locale, un microciclo red, green, refactor e il deploy su Amazon Web Services con il framework Serverless, per poi eseguire con successo il test di accettazione direttamente sull'endpoint creato su AWS.

Repository del progetto: https://github.com/xpeppers/serverless-tdd

Slides della presentazione

Contattaci per maggiori informazioni su come adottare Serverless in azienda e se l'argomento test driven development ti interessa non perdere la prossima edizione del corso TDD explained.

dicembre 20, 2016 - No Comments!

La pratica del daily journal

daily journal

All'ultimo Agile Day, Pietro di Bello ci ha raccontato la pratica del daily journal: un diario di bordo, da scrivere a fine giornata, per raccontare come è andata, le cose apprese, cosa manca per chiudere il task in lavorazione e quali ostacoli si sono incontrati.

Le slides della presentazione:

dicembre 15, 2016 - No Comments!

re:Invent le novità Amazon per il cloud e l’IoT

brand-og

Un re:Invent impegnativo: tantissime sessioni, tra cui quella del nostro community hero Paolo Latella, distribuite su più hotels e eventi della community da non perdere. Per non farci mancare niente abbiamo approfittato dell’occasione per l’ottenimento delle certificazioni AWS.

Screenshot 2016-12-15 10.23.37

Un re:Invent sempre più grande con più di 25000 partecipanti e l’annuncio di nuovi servizi interessanti e miglioramenti dei precedenti.
Il trend più evidente al re:Invent è quello dei servizi per IOT, Machine Learning, Big Data e molto Alexa-centric.

CyjYdxnVEAAYYIl

Day 1 - Partner Summit Keynote - Terry Wise

Terry Wise (Business Developer Manager) ha iniziato con la partnership VmWare. E poi ha introdotto i seguenti programmi interessanti:

  • VmWare Partner Program
  • Public Sector Partner Program
  • AWS Service Delivery Program
  • Alexa Service Delivery Program
  • Iot Competency
  • Finance Competency
  • Marketplace API gateway Competency
  • Partner Finder Portal

Come sapevamo i programmi sono importanti, ma dal prossimo anno lo saranno molto di più. Il Partner Finder Program dovrebbe visualizzare i partner secondo le certificazioni, i case public e le competenze.

Day 2 - Keynote - Andy Jassy

Amazon Lightsail
Un VPS che gira su tecnologia EC2, si possono scegliere 5 tipi di configurazione che è un mix di computazione, storage e traffico. Le configurazioni vanno da 5 a 80 dollari e supportano i maggiori CMS come Drupal, Joomla e WordPress.

Amazon Athena
E’ un servizio che permette di analizzare grosse quantità di dati (strutturati e non) direttamente da S3. Amazon Athena è basato su presto e quindi permette di analizzare in maniera distribuita, utilizzando delle query SQL, i nostri file in JSON, CSV o TXT con delimitatori. Le quei possono effettuate attraverso un qualsiasi client JDBC, proprio come un normale database, infatti un database Athena è una composto da una o più tabelle e ogni tabella è collazione di uno più oggetti S3. Il risultato di una query può poi essere salvato nuovamente su S3. Anche le query stesse possono essere salvate. La creazione di una tabella e le operazioni fatte su quella tabella non vanno ad impattare i dati originali su S3 in quanto Athena usa l’approccio schema-on-read. Al momento Athena è disponibile sono in US-East e US-West. Ovviamente Amazon Athena si basa sul paradigma serverless. Molti si chiederanno qual’è la differenza rispetto ad EMR, la differenza sta nella maggiore flessibilità di EMR in termini di Framework e applicazioni che possiamo farci girare sopra. Ovviamente non può essere comparato a Redshift essendo il secondo un Datawarehouse per definizione. Dal punto di vista del pricing si pagano i dati estratti da S3 e analizzati dalle query.

AWS Glue
E’ un servizio di ETL fully managed che semplifica i workflow di ETL tra i servizi di AWS e non. Per esempio da S3 a RDS oppure da S3 a Redshift oppure da un qualsiasi Datastore JDBC a RDS. Infatti AWS Glue non fa altro che il crawling dei dati sorgente, suggerisce delle trasformazioni e poi li carica sulla destinazione scelta. Glue genera infatti uno script Python che possiamo sempre modificare a piacimento e farlo poi eseguire ad una determinata ora del giorno oppure in risposta a degli eventi. I jobs di ETL sono distribuiti su Apache Spark quindi eseguiti in parallelo in maniera rapida.

Snowball Edge
E’ uno Snowball con delle funzionalità in più. Per esempio può essere collegato in Cluster, supporta il protocollo NFS e soprattutto può eseguire delle funzioni lambda localmente. Con questa ultima funzionalità le operazioni di backup & restore diventano intelligenti.

Amazon Lex
E’ un sistema ASR – Automatic Speech Recognition NLU – Natural Language Understanding, lo stesso che sta alla base di Amazon Alexa. Possiamo costruire dei BOT che si interfacciano con AWS Lambda. I componenti del BOT sono: intent (l’obiettivo da far raggiungere al BOT), Utterance (E’ la frase che fa partire un intent, per esempio voglio comprare una pizza), slot (sono informazioni ulteriori che servono al BOT, per esempio il gusto della pizza), gli slot vengono popolati attraverso i prompt (la domanda che chiede maggiori informazioni, per esempio pizza Margherita ?) e infine i fulfillment che che è la logica di business con la quale raggiungere l’obiettivo del BOT. Amazon Lex usa Lambda per la logica e Polly per il Text-To-Speech.

Amazon Polly
Text to Speech fully managed con oltre 24 lingue. Noi inviamo un testo a Polly e Polly trasforma il testo in parole via streaming o salvando il file in MP3.

Amazon Rekognition
Il nome dice tutto. Anche se oltre a fare il riconoscimento aggiunge dei dettagli interessanti, per esempio E’ una donna, sta sorridendo, è all’aperto in una giornata di sole.

AWS Greengrass
Greengrass è un Software pensato per girare su dispositivi con capacità di calcolo ridotte, autonomia limitata e possibilità di perdere la connessione a internet. Greengrass permette infatti di eseguire delle funzioni lambda sui dispositivi che supportano Greengrass Core (SDK che gira su Linux con Kernel 4.4) con 1 GHz minimo di processore e 128 MB di RAM.

AWS e VmWare
La novità maggiore riguarda il fatto di poter eseguire VM VmWare su infrastruttura AWS (già anticipato al VmWare forum). Questo significa permettere a VM VmWare di sfruttare l’infrastruttura (in termini di availability e reliability) di AWS ma anche poter utilizzare i servizi al contorno come ELB, RDS, S3, SQS, SNS etc.

Day 3 - Keynote - Werner Vogel

CynLY8DUsAAsgXk

AWS Step Function
Il Servizio AWS Step Function permette di creare un workflow di lavoro (diciamo una macchina a stati finiti) partendo da alcuni semplici passi: start, pausa, parallelizza, scegli, stop, Work. Nello stato di Work possiamo invocare una funzione Lambda oppure un processo a lungo termine. Nel caso di processo a lungo termine Step function attende che qualcuno (EC2 oppure VM interna al nostro datacenter) prenda in carico il lavoro da fare e segnali OK/KO. Con questo servizio si possono mettere in piedi processi logici che mappino dei processi aziendali complessi. Molti di voi si ricorderanno il famoso servizio AWS Simple Workflow (appunto simple). AWS Step function può essere ritenuto una evoluzione di questo servizio anche se nel primo avevamo libertà di scelta sul linguaggio di programmazione con cui implementare il flusso (i decider) e i task (i worker). Qui il processo è descritto in JSON (usano Amazon State Language9 e i worker sono funzioni lambda o processi esterni. Step Function è disponibile in US East (Northern Virginia), US East (Ohio), US West (Oregon), EU (Ireland), and Asia Pacific (Tokyo) Regions. Dal punto di vista del pricing paghiamo solo i cambiamenti di stato più eventuali servizi accessori come Lambda o EC2.

Amazon EC2 Systems Manager
E’ un servizio centralizzato per la gestione delle istanze EC2 (e i server on-premise). Il suo funzionamento si basa sull’installazione di un agent (supporta sia Linux che Windows) che è in grado di ricevere dalla console di AWS i task di gestione. I task possono essere avviati in maniera automatica oppure dietro un evento di Cloudwatch. Systems Manager compre i task “Run Command” per l’esecuzione di script bash o power shell da remoto, “Update Manager” o “Patch Manager” per gestire gli aggiornamenti di sistema, di sicurezza o delle applicazioni installate sul sistema, “Inventory” per avere informazioni sullo stato di tutte le istanze EC2 e “Automation” che permette di eseguire dei task basati sulle API di EC2, per esempio avviare una Istanza da una AMI versione 1.o, installare software e creare nuovamente la AMI per una versione 2.0 e “Parameter Store” che permette di memorizzare parametri di configurazione in un posto sicuro (usa KMS) e centralizzato.

AWS Personal Health Dashboard
E’ semplicemente una Dashboard che permette di tenere sotto controllo lo stato delle nostre risorse. Per esempio un’attività di manutenzione sull’hardware in cui risiede una nostra VM verrà segnalato dalla dashboard. Ovviamente possiamo costruire la dashboard in modo che catturi allarmi da Cloudwatch e avvii una funzione Lambda per delle operazioni di fail-recovery complesse. Per chi ha il supporto business può usare questa console per raccogliere informazioni dal proprio tools e inviarli (via API) alla dashboard di AWS.

OpsWorks for Chef
AWS Opsworks for Chef è uno Chef Master fully managed. Con AWS OpsWorks for Chef AWS ci da accesso alla full Chef Automate platform che contiene tools come Chef Workflow, Chef Visibility, and Chef Compliance.

AWS Shield
E’ un servizio che protegge i clienti dagli attacchi DDoS e si aggancia a ELB, Route53 o Cloudfront. E’ in grado di intercettare attacchi a livello di rete (UDP, TCP) e a livello 7 integrandosi con il WAF di Amazon Web Service. Esiste in due versioni la versione standard attiva per tutti i clienti AWS e la versione Advanced in cui si ha un sistema di reportistica in tempo reale, sistemi di Mitigation più evoluti (Volumetrici, Credit scoring, etc) protezione dei costi nei confronti di servizi come Route53, ELB e CLoudfront.

AWS Batch
Anche questo sistema sembra l’evoluzione di SWF o di una coppia SQS+Autoscaling+SNS. In ogni caso il servizio nasce per creare dei processi batch distribuiti su istanze EC2 senza preoccuparsi della gestione, dei fail e dell’ottimizzazione delle risorse/costi. L’unità di lavoro di AWS Batch è il Work, un’applicazione da lanciare su EC2. Come il job debba essere lanciato e con quale computazione lo possiamo definire attraverso un job definition. Più Job vengono messi in una coda e poi lo scheduler si occuperà di prenderli e inviarli a un environment in modalità FIFO. L’environment è un cluster di macchine EC2, la cui dimensione può essere fissa o variabile (scale-in e scale-out).

Lambda@Edge
E’ un servizio molto interessante perché consente di eseguire delle funzioni Lambda sui POP di Cloudfront. Quindi si possono intercettare e manipolare le chiamate HTTP in prossimità dell’utente (appena inviate dal client e/o poco prima di rispondere al client). In una demo è stata utilizzato per prendere delle decisioni, come una immagine da visualizzare, sulla base delle URL che arrivava all’edge. Oppure se l’utente aveva un cookie che lo abilitava a vedere determinate pagine allora ok altrimenti veniva rimandato ad un sito ombra.

AWS Codebuild
E’ il componente che mancava dopo CodeDeploy e CodePipeline. E’ un server per le Build fully managed che si integra con Codepipeline per la pipeline e CodeDeploy per il delivery. Come repository si integra a Git, S3 e Codecommit. Come environment supporta Android, Java, Python, Ruby, Go, Node.js, o Docker e come tools per la build supporta Maven, Gradle e NPM. In ogni caso l’environment può essere personalizzando creando un Dockerfile. Come capacità di calcolo arriva fino a 15GB di RAM e 8 vCPU. Per le Build usa dei container che vengono creati e distrutti all’occorrenza. Si integra con CLoudwatchLogs per i blog delle build e ha una sua console di gestione e monitoraggio delle build.

AWS X-Ray
X-Ray è un servizio che analizza le informazioni di applicazioni in esecuzione su EC2, su ECS, su Beanstalk ed anche API Gateway. Per le applicazioni si aspetta di inserire nel codice un message handler che catturi tutte le richieste in arrivo e le giri a X-Ray, per quanto riguarda invece gli SDK è necessario installare un agent sulle macchine. X-Ray è in grado di disegnare una mappa del servizio end-to-end (per esempio client->Application->Database) dando informazioni sulla availability di ogni singolo servizio. AWS X-Ray supporta tracing per applicazioni Node.js, Java, and .NET. e per chiamate a servizi come RDS, Dinamo, SQS e SNS.

 

CyZz0VlVQAEoGai

Come sempre è un'esperienza fantastica quella offerta da Amazon, ci rivediamo il prossimo anno, sempre a Las Vegas 🎰

A breve annunceremo un nuovo evento in cui andremo a provare con mano i servizi annunciati durante questo re:Invent, seguici su twitter.

dicembre 5, 2016 - No Comments!

Ruby Day 2016 – La nostra esperienza a Firenze

by Alessio Coser, Christian Fei, Matteo Pierro

Sabato, 26 Novembre 2016, abbiamo partecipato al Ruby Day 2016 a Firenze (programma).

Presentazione del Ruby Day 2016

Presentazione del Ruby Day 2016

La conferenza è iniziata con l'intervento di Xavier Noria che ha proposto alcuni concetti di codice leggibile, corretto e conciso.

Abbiamo visto alcune porzioni di codice scritte in modi diversi: alcuni più concisi, altri più leggibili e ci ha fatto notare che la scelta di come scrivere il codice è molto soggettiva, ma che dovrebbe comunque essere condivisa interamente dal team in cui ci si trova.

Successivamente abbiamo deciso di seguire una presentazione improntata su Integration testing, di Piotr Szotkowski. Il ragionamento di Piotr è partito dalle problematiche emerse in questi anni su integration testing ed ha preso come esempio l'articolo di J.B. Rainsberger intitolato "Integrated Tests Are A Scam!".
E' partito con un'introduzione sui test doubles, come e quando vengono usati, ma soprattutto quali sono le loro limitazioni. Ci ha spiegato come Bogus (un tool per il testing) affronta questi problemi in modo diverso e ci aiuta nel tdd-outside-in.

Prima di pranzo Devon Estes ci spiega come applicare concetti funzionali ad applicazioni Ruby. Ci ha invitato a ripensare il modo in cui scriviamo il codice sfruttando concetti del paradigma funzionale mostrandoci alcuni esempi di come sia possibile scrivere codice testabile e mantenibile.

Ruby Refinements - Paolo Perrotta

Refinements the worst feature you ever loved - Paolo Perrotta - Ruby Day 2016

Nel pomeriggio Paolo Perrotta ci ha raccontato di una fantastica feature poco conosciuta utilizzata di Ruby chiamata "Refinements". Ci ha parlato di come questa feature sia un'arma a doppio taglio e del motivo per il quale è stata introdotta: cercare un'alternativa sostenibile al monkey patching.

In seguito Simone Carletti ci racconta come la sua curiosità verso altri linguaggi di programmazione (Elixir, GO, Crystal e Java in particolare) lo abbiano portato ad evolvere il modo con cui scrive codice in Ruby.

Il talk successivo, proposto da Benjamin Roth, era incentrato sul tema dei ServiceObject e su come comporli per creare quello che lui chiama realistic context. Ha sottolineato come un approccio del genere porti ad avere dei Controller più light e con meno codice ripetuto. A supporto della presentazione ha introdotto una serie di gemme che "facilitano" -l'applicazione di questa pratica. Tra queste quella che ci ha colpito di più è stata Waterfall.

Nel tardo pomeriggio abbiamo partecipato al talk Lessons learned while building Hanami di Luca Guidi.
Ha parlato di tutti gli aspetti che si celano dietro lo sviluppo e il mantenimento di un progetto Open Source, di come la comunicazione e la collaborazione siano aspetti molto importanti nella buona riuscita di progetti di questo tipo.

Secondo la sua esperienza la scrittura di codice arriva alla fine di tutte quelle azioni che permettono la crescita della comunità intorno al progetto come la comunicazione che deve essere “inclusiva“ e propositiva in modo da aiutare, chi lo desidera, a collaborare al progetto.

Inoltre ha toccato un aspetto molto importante: la gestione del tempo. Consiglia di dedicasi al progetto ogni giorno anche per poche ore. Però non proprio ogni giorno, infatti si dovrebbe riuscire a ritagliarsi del tempo (come il week-end) per la propria vita privata e non permettere che questa attività, anche se è appassionante, assorba tutto il tempo libero.

Can we still innovate? - Piotr Solnica - Ruby Day 2016

Can we still innovate? - Piotr Solnica - Ruby Day 2016

Piotr Solnica ha concluso la giornata parlando della sua esperienza nello sviluppo di progetti OpenSource e di come la comunità cerca di migliorare l'ecosistema Ruby.

E' stata veramente una bella esperienza che ci ha permesso di confrontarci con la comunità Ruby e di passare una giornata divertente e stimolante.

ottobre 25, 2016 - No Comments!

Reasons to adopt a microservices architecture

by Paolo D'incau

microservices

Microservices based architecture is a trending topic in these days: more and more companies try to take a big step and shape their software and internal organisation following the examples of well-established realities such as Spotify, Netflix and Zalando. Even though it's always positive to keep an eye on new technologies, languages and frameworks available in the market, it wouldn't be wise to blindly embrace them. In this article we will discuss with concrete examples three different reasons that should trigger your interest in knowing more about microservices.

1) Faster Deployment

One of the things that I have noticed in the past years of work on monolithic architectures is that most of the times the process of deploying working features in productions becomes difficult and time consuming. Let me try to expand this point and explain why I believe that a microservices approach can ease these kinds of organizational issues.

When the products you are working on becomes somehow stable and is actively used by customers, the daily work of your team splits in three different activities, that are:

  • new features implementation
  • bug fixing
  • changes of the existing features (small ones, most of the time)

If your code is organized in a monolithic structure chances are very high that your Continuous Integration/Delivery/Deployment pipeline will reflect the same structure which means that it has a unique flow and therefore each and every change to the codebase will need to pass through tests or build steps that are totally unrelated to the change itself; this obviously means that you need more time to deploy your new code in production with all the costs that this implies.

When you need to push to production an urgent fix, but your continuous delivery pipeline remains blocked by non related broken user acceptance tests for hours (they can even be tests on features that are seldom used) your team can undergo frustration and and irritability. I have noticed the same frustation to arise when someone (probably the PO) asks to deploy a given feature to production without deploying other features that are still not ready and the team just can't satisfy the request because the deploy follows the motto "get everything or nothing".

Microservices obviously can help in tackling these kind of issues. If you separate your big project in smaller services built around features you can obviously decouple the related code, with the great benefit that your deployment strategy will follow. This means that you can decide to create a different pipeline for each microservice and therefore you will be able to deploy each component indipendently decreasing drastically the time your bug/feature/change takes to be released and used in production.

2) Easier onboarding

So you develop and improve your software for quite a lot of time (can be years), but things change and some of your developers (I hope not all of them) decide to leave and seek their fortune away from your company. Your product is widely used in production and obviously it needs support and new features, so you decide to hire new developers.

For newcomers it can be really difficult to approach a monolithic codebase and to become productive in a few weeks. It is very reasonable if you reflect on it: your new developers have to understand not only the new business features that need to be added, but also the overall business domain and the way it was coded down by other people who left the project! A monolithic architecture is the main reason that made me hear during the last years things like: "To be productive on this codebase you need N months" or "A couple of years ago we decided that...", I bet you heard something like this during your career too!

If you hired new developers and you want them to be productive as soon as possible, you may consider switching to a microservices architecture. I strongly believe that with such approach new team members can develop all the new features you need in a faster way without the burden of a limited knowledge of what lies in the monolith. Also, I recommend that newcomers should practice work on these new features while pair programming with somebody with more experience on the project so that they can be thought about the business domain, monolith architecture and, why not, team/project history.

3) Smarter scaling

Scalability seems to be a big concern nowadays and it's very common to hear business people ask the dev team whether the system under development "will scale". With the advent of cloud and virtualization everything seems very easy: you just need to deploy your application to several machines and put some sort of load balancer in front of them (e.g. country based) and voilà: you get the scalability you desired almost for free.

While it's pretty obvious that today we have a lot of platforms and tool that comes to our help, it is worth to remember that the way we design and organize our architecture still plays a big role.

Suppose your application just became mainstream and day by day is used by more users: with a monolith, if you want to scale, you are forced to deploy everything to several "replica machines", without taking into consideration whether you need to scale all the features the application provides or just a small subset of them. This kind of approach introduces different business related issues in your organisation, not only technical ones: for example you will have to use several new machines that must provide the computational power needed by the entire application and obviously this will cost you more.

When talking about scalability, microservices seems to outperform many other architectural choices out there. Whenever you feel the urge to scale some part of the system (and I hope you are forced by real metrics and not by your gut) you can decide to spin new small machines that will host only the service that provides the needed feature and nothing more; so if you are running an online shop you will be able to scale only the part connected to searches, while keeping the parts that implement shipment tracking or products recommendation as they are.

With a microservices approach you will get another great benefit: you will be able to kill some of the instances with no mercy because you are confident that just by stopping one or more microservices you are not shutting down the entire system but only a part of it.

Conclusions

In this article we have looked at three good reasons that should address you towards a microservices based architecture when redesigning your legacy monolithic application or starting it from scratch. With microservices you can boost your team productivity, reduce your time to market and scale those parts of the systems that really need it.

It is worth noting that microservices are not the only way to achieve those results, so before embracing them you should evaluate different solutions and also consider the issues that this kind of architecture can bring into your organisation. Finally you should alway keep these words by Sam Newman in mind:

About me

I have a double identity: I code OOP by day and spread FP by night (and during the weekends). I love talking about Erlang, Continuous Delivery, refactoring and microservices. I fight for to the coding “made in Italy".
I've started collecting useful resources about microservices here.