Archives for ottobre 2016

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.

ottobre 13, 2016 - No Comments!

La crescita passa dalle persone

Ottobre procede alla grande con presentazioni, onboarding, percorsi di studio e moving motivators.
La qualità dei servizi che offriamo è frutto dalla qualità delle nostre persone e di una cultura fondata sul continuous learning, per questo siamo entusiasti delle ben quattro nuove persone nel grande team di XPeppers a Trento, Milano e Roma.

persone2

Gli abbiamo chiesto di raccontarsi in poche parole su di loro e sul loro ruolo in XPeppers

Giulio De Donato: Ciao sono Giulio De Donato, ho sempre orbitato nell'ecosistema opensource, ho co-fondato la community GoLang e Docker in italia, alcune librerie OS sul monitoring sono usate da Wikipedia e altre aziende, ho lavorato fuori dall'Italia per un piccolo periodo, ma sono tornato per portare un po' di passione, nel mio storico ci sono alcune aziende Italiane, il mio ruolo in XPeppers è quello di Tech Evangelist e Docker advocate, punto molto a metodologie di microservizi devops e buone pratiche.
Ho scelto XPeppers perchè mi da la possibilità di fondere lavoro e passione, mi aspetto che nel prossimo anno tutte le aziende Europee lascino il lato oscuro della forza per unirsi alle nostra unione fatta di buone pratiche e metodologie.

Giuseppe Cossu: Mi chiamo Giuseppe Cossu e mi sono avvicinato al Cloud Computing lavorando su OpenStack a partire dal 2013. Mi sono occupato dell'installazione e amministrazione di OpenStack con particolar interesse sul lato Networking (NaaS) partecipando ai progetti europei XIFI e FIWARE/FICORE. Nello stesso tempo ho coltivato l'interesse per l'architettura di applicazioni cloud-aware e per le recenti innovazioni sulla conteinerizzazione e la loro orchestrazione.
Il mio ruolo XPeppers e' DevOps & Cloud Engineer. La mia figura da un lato mira a creare, gestire e automatizzare il deployment di infrastrutture sul cloud, dall'altro a favorire l'integrazione tra le attività degli sviluppatori e dei sistemisti, assicurando un miglior processo per la messa in produzione del software.

Matteo Foccoli: Ciao, sono Matteo!
Ho cominciato da circa due settimane la mia nuova collaborazione con XPeppers. Dico nuova perché in realtà ho già avuto modo di lavorare, in maniera più o meno diretta, con voi: per alcuni sono infatti un ex collega e con la mia precedente società sono stato vostro fornitore.
Sono uno sviluppatore che negli anni è saltato da una tecnologia all'altra (da Java a Ruby passando per Javascript e altro...), conquistato fin dai primi anni 2000 dall'XP e dall'agile.
Ciò che mi piace di più della nostra professione è la possibilità di lavorare in team e condividere i risultati, motivo per cui negli anni ho voluto fare esperienza come Scrum Master e coach.
Per ora ho lavorato solo con i ragazzi qua a Milano, non vedo l'ora di conoscervi tutti! A presto!

Nicola Pedot: Ciao sono Nicola, sono uno sviluppatore affascinato dalla creatività ed eleganza di soluzioni pratiche che rendono l'informatica uno strumento in grado di eliminare le complicazioni in modo accessibile. Alla eterna ricerca di una definizione, sono in viaggio da programmazione procedurale, oggetti, funzionale ad agenti. Cerco di applicare in ogni cosa le tre regole dello spirito hacker-space: impara, insegna e condividi con quante più persone.

Vuoi far parte di questa squadra? consulta le nostre posizioni aperte

ottobre 12, 2016 - No Comments!

ReactJS Day 2016 Verona

by Christian Fei

Venerdì, 7 ottobre 2016, ho partecipato alla seconda edizione dell'evento "ReactJS Day 2016" a Verona.

La conferenza è iniziata con la presentazione dell'associazione GrUSP e di Frontenders Verona (FEVR).
Dopodiché in lineup c'erano due presentazioni sui temi "Individual paint for your React components" e "CSS is dead, long live CSS (but in modules, please)!", quindi entrambi riguardanti lo stilyng di componenti React.
Johannes Stein (@frostney) ci ha condiviso la sua esperienza con le varie tecniche per stilizzare componenti con React, dai famigerati inline-styles, da Aphrodite, da react-with-styles a una marea di webpack-modules. Adesso bisogna solo scegliere..

Dopo una breve pausa, Emanuele Rampichini (@emanuele_r) ha parlato dei vari tipi di testing di applicazioni di React. Partendo da una filosofia "PnP (Push-and-Pray)", come si crea un' applicazione che è in linea con il titolo della sua presentazione "How to push a ReactJS application in production and sleep better"? Non nuoce avere conoscenza della libreria react-test-utils e react-shallow-testutils per testare componenti React unitariamente o integrazione. Per una soluzione all-in-one di Airbnb, consiglia(mo) enzyme.

Con Massimiliano Mantione sul palco non c'era altro che aspettarsi una sbalorditiva demo con live-coding.
Ci ha lasciato tutti a bocca aperta con la dimostrazione di un suo esperimento dell'uso di React per lo shallow rendering della view, Redux per la gestione dello stato dell'applicazioni e tre varianti di "view" a la "TodoMVC":

  • una parte renderizzata con componenti HTML
  • un canvas 2D
  • un canvas 3D renderizzato con WebGL


*Modificando la todolist in una view, cambiava in tutte e tre 😎*

Francesco Strazzullo ci ha raccontato dello sua esperienza con la libreria MobX per lo state management in applicazione web JavaScript.

Nella presentazione "Building Modular Redux Applications" Gian Marco Toso presenta l'attuale stato dell'arte per l'organizzazione di progetti e del codice di applicazione modulari scritte con Redux.js.

Scrivere applicazione con una codebase "ridotta" (in termini di logica di business, linee di codice, complessità etc.) è veramente un gioco da ragazzi, ammettiamolo. Ma cosa succede in una codebase di grande scala? Il codice si riduce a codice illegibile e inutilmente complesso (aka "Spaghetti Code"), o è comprensibile e mantenibile?
Erik Wendel parla della sua esperienza ormai di quasi 5 anni in Bekk Consulting, insomma in una organizzazione a larga scala, in cui sono state adottate le librerie React e Redux. Wow!

Hoti Fatos ci introduce nel mondo GraphQL, e con una dimostrazione live ci spiega concetti del nuovo Query Language "GraphQL" (di Facebook).

La fantastica giornata al ReactJS Day 2016 finisce con la presentazione del carismatico Michele Bertoli su "Proper Error Handling with React/Redux".

seguita dall'invito al Node.JS Conf, il 22 Ottobre a Desenzano. Ci vediamo lì!