All Posts in DevOps

marzo 8, 2017 - No Comments!

Training e Affiancamento su Microservizi

formazione microservicesIn occasione di Incontro DevOps lanciamo una nuova offerta di per l'adozione di microservizi.
I corsi, erogati a Milano, Roma e presso le aziende, sono pensati per far intraprendere il percorso di adozione sia dal punto di vista metodologico sia per realizzare la propria architettura utilizzando i servizi cloud di AWS e i meccanismi di containerizzazione di Docker.
Il valore aggiunto consiste in un pacchetto kickstart per calare i concetti appresi nel contesto del dominio aziendale. Una serie di attività di affiancamento per raggiungere i risultati in minor tempo.

Pagina di dettaglio >

 

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.

aprile 27, 2016 - No Comments!

Network e infrastrutture resilienti con il DevOps e la Continuous Delivery

Tutti dovrebbero sentire la responsabilità di portare miglioramento, nuove tecniche, prodotti e strumenti che guidano uno spirito innovativo in tutta l'azienda. Il nostro obiettivo non è solo sul "fare il lavoro", ma fare in modo che ognuno stia contribuendo in maniera significativa e coinvolgente all'interno del team.

 

Su questo argomento che ci sta molto a cuore stiamo organizzando una nuova edizione di DevOps e Continuous Delivery. Una opportunità da non perdere per migliorare le tue skills.

devops benefits

Con questo corso imparerai a creare una deployment pipeline con Vagrant e Chef ed utilizzeremo Jenkins come server di Continuous Integration. Costruiremo in modo automatico un intero stack infrastrutturale in cloud con AWS, Packer e Terraform.
Vedremo anche gli aspetti legati alla metodologia e di come puoi avere il controllo sul processo di rilascio, di automatizzarlo e renderlo efficiente per ridurre tempi, costi e rischi.

Vedi il programma completo

 

devops aws

Se la tua infrastruttura si avvale dei servizi di Amazon Web Services, il corso DevOps Engineering on AWS che eroghiamo come Authorized Training Partner AWS è quello che fa per te.
DevOps Engineering on AWS dimostra l'utilizzo dei modelli DevOps più comuni al fine di sviluppare, distribuire e mantenere le applicazioni in AWS. Il corso illustra i principi fondamentali della metodologia DevOps e prende in esame vari casi d'uso applicabili a scenari di sviluppo di startup, piccole e medie imprese ed enterprise.

Scopri la scheda del corso

 

 

Contattaci per maggiori informazioni e offerte di acquisto in bundle.

febbraio 15, 2016 - No Comments!

FOSDEM 2016 a Bruxelles

by Christian FeiTiago Martinho

Anche quest'anno XPeppers ha partecipato alla conferenza FOSDEM il 30 e 31 gennaio a Bruxelles!

FOSDEM è una conferenza gratuita dedicata a sviluppatori ed ormai è diventata il punto d'incontro in Europa che ogni anno ospita più di 7000 persone, presso l’università ULB di Bruxelles.

Da tutto il mondo sviluppatori appassionati di open-source vengono per discutere e condividere le loro esperienze.

Ci sono innumerevoli stanze dedicate a linguaggi di programmazione, tecnologie e pratiche come virtualizzazione, testing e automazione, fino al mondo open-source in generale.

Abbiamo seguito talk soprattutto legati ai temi Testing and Automation, Virtualisation, Configuration Management, Containers and Process Isolation e IoT.

Nel talk Jenkins as Code abbiamo conosciuto il plugin per Jenkins Job DSL, che rende programmabile la creazione di job Jenkins. Il presentatore ha mostrato come l'infrastruttura di Uber ha sfruttato questo strumento per scalare e automatizzare molti processi che prima richiedevano un intervento manuale.

Per rimanere nel contesto testing e automazione, abbiamo seguito la presentazione "Beyond config management", in cui l'autore ci ha esposto le sue considerazioni su DSL (scritti in Groovy) per modellare e definire l'infrastruttura in modo programmatico. Potendo compilare questo codice, abbiamo la possibilità di avere un'analisi statica sul codice dell'infrastruttura, oltre alla sua testabilità.

Secondo l'autore, e anche secondo noi, l'approccio di modellare l'infrastruttura tramite codice, cioè "Infrastructure as code", è una pratica essenziale per creare architetture affidabili e resilienti.

Nel talk PostgreSQL features for IoT da Simon Riggs abbiamo visto le nuove funzionalità di PostgreSQL dove la vision è avere un database che permette la creazione di applicazione dove l'ambulanza arriva prima del incidente perché la misurazione del battito cardiaco ha rilevato che la persone sta per avere un infarto. Questo database può registrare una grande quantità di dati in poco tempo in continuo, l'esempio fatto è quello di registrare le misurazione di glucose ogni minuto di ogni cittadino del europa.

Nel talk Build an IoT platform on Matrix da Matthew Hodgson è stata presentata una introduzione al framework Matrix. Questo framework permette di create una piattaforme aperta e decentralizzata dove vari dispositivi IoT riescono a comunicare tra di loro in una forma semplice e affidabile.

Puoi trovare i video di tutti talk qui FOSDEM 2016


 

Ogni anno viene organizzata una serata dedicata al FOSDEM, al Delirium Café vicino al Grand Place, la piazza centrale di Bruxelles. Non potevamo perderci questo evento per conoscere nuove persone, per fare networking e per goderci delle ottime birre belghe (la scelta è molto vasta; parliamo di oltre 25 birre)!

Come potete vedere non abbiamo resistito agli sticker che venivano distribuiti ai vari stand:

FOSDEM stickers!

dicembre 29, 2015 - No Comments!

Agile@Work – Bolzano 2015

Conferenza Agile, Cloud, Devops

Il 4 Dicembre 2015 si è tenuto a Bolzano l'evento “Agile@Work”, una conferenza su Agile, Cloud e Devops.

La collaborazione tra XPeppers, TIS e Red Oddity è stata un fattore determinante per la buona riuscita della conferenza come dimostrato dal numero dei partecipanti e dalla velocità con cui sono stati prenotati i posti disponibili. A questa prima edizione hanno partecipato infatti circa 100 persone provenienti principalmente del Trentino Alto Adige e dalle altre regioni del nord Italia.

Agile@Work Bolzano 2015

Agile@Work Bolzano 2015

Tematiche

La giornata è iniziata con l’introduzione di Roberto Bettazzoni in sessione plenaria che ha catalizzato l’attenzione facendo una panoramica generale su come utilizzare il Framework Cynefin per identificare ed affrontare situazioni semplici, complicate, complesse e caotiche e sul ruolo centrale delle retrospettive per adattare il modo di affrontare i problemi in base alla situazione esistente.

La giornata è continuata poi su tre track parallele dove sono stati presentati talk e workshop che hanno riscosso tutti un grande successo. Di seguito potete trovare i link ai video ed ai materiali resi disponibili dagli speaker.

Ha riscosso particolare interesse anche l’idea di rendere disponibile un aula dove le persone hanno potuto continuare a discutere degli argomenti presentati nei talk.

Riepilogo delle sessioni

Si riporta di seguito l’elenco delle sessioni presentate (talk e workshop), i link ai materiali presentati ed alla play-list dei video.

Why you need to change your way of working - Roberto Bettazzoni

Some of the most advanced technical practices allow to get sustainable and effective benefits only if you use them properly. Unfortunately the inertia in adapting the way of working to the changing needs can thwart any technological advantage.
In this talk I discuss the reason why an appropriate change of the way of working is a non postponable need. I also present some methods and indicators to help you adapting your way of working to the product’s needs, your company's culture and the technical practices.

Visualizza presentazione su SlideShare

What is Agile? - Marco Trincardi

Most of the times Agile is described as a set of practices. In this presentation I will give a different point of view of Agile, where practices are just a means to build an effective working culture.

Visualizza presentazione su SlideShare

Continuous Delivery on Java projects - Paolo D'Incau

We will talk about real life examples where we apply Continuous Delivery practices and principles. We will tell how you can evolve in an iterative way a CD pipeline starting from simple tasks (build and deploy on a single environment) to a multi-environment pipeline inspired by what we learned by hurting ourselves. We will give concrete examples, keeping the focus on the code, the infrastructure and the relationship with the different stakeholders.

Visualizza presentazione su SlideShare

Hiring Great People - Pietro Di Bello

Getting the right people will help create a great team, and will let it grow healthy. Moreover, it will keep it rooted in your company culture, and sustaining that same culture in turn. Nevertheless, too often recruiting is overlooked or completely delegated to HR or external recruiting agencies.
In this session I’ll share our experience in building our actual recruitment process, how we got to this recruitment workflow, what lessons we’ve learned and what are the key elements of a recruitment process. I’ll also examine some differences compared to a more “traditional” way of selecting and assessing people.

Visualizza presentazione su SlideShare

Event-driven (serverless) applications - Danilo Poccia

We built event-driven user interfaces for decades. What about bringing the same approach to mobile, web, and IoT backend applications? You have to understand how data flows and what is the propagation of changes, using reactive programming techniques. You can focus on the core functionalities to build and the relationships among the resources you use. Your application behaves similarly to a “spreadsheet”, where depending resources are updated automatically when something “happens”, and is decomposed into scalable microservices without having to manage the infrastructure. The resulting architecture is efficient and cost effective to run on AWS and managing availability, scalability and security becomes part of the implementation itself.

Visualizza presentazione su SlideShare

Agile banks, is it an oxymoron? - Marco Trincardi

Stated that Bank is an example of Control culture a Bank, Introducing Agile in a Bank is more working on existing culture than teaching practices.
In this talk I want to share my year experience on agile introduction in one of the most important Italian Bank.
I will cover the topic on how to be agile introducing agile, Scrum of scrum as the simple thing that could possible work, the compromises we accepted, the pitfall we faced; in essence how to instill an Agile Culture in a Control Culture environment.

Visualizza presentazione su SlideShare

Extreme Contracts - Turning negotiation into collaboration - Jacopo Romei

We care too much for contracts and too little for collaboration. We maximize contracts' value as safety devices and we never focus on their value as collaboration enabler. We want contracts that go fast towards a deadline instead of finding agreements which bring you and your counterpart to trust each other as soon as possible. We read in the Agile Manifesto: "[We value] customer collaboration over contract negotiation". How can we make the latter foster the former?

Test Driven Infrastructure - Filippo Liverani

Many IT operations teams are used to managing infrastructure manually or with simple one-off scripts. This manual work and lack of verifiable behavior results in many issues and in uncertainty. In software development, Test Driven Development (TDD) is well recognized for improving design, increasing code quality, and allowing refactoring and better knowledge sharing.
Similar benefits can be gained in infrastructure projects when infrastructure is treated as code, driving that code development with tests. Configuration management tools such as Chef and Puppet allow infrastructure to be easily described as code and provide a complete support to introduce and run tests. This can allow development and operations teams to collaborate and confidently deliver working infrastructure code.

Visualizza presentazione su SlideShare

Collective code ownership in Extreme Programming - Dario Coco

What can we do to improve communication and knowledge sharing in an Agile team? Collective Code Ownership is one of the most important rules in Extreme Programming: every member of the team is responsible for the architecture.
In this talk we'll explore the connection between CCO and the other XP rules, and we'll see some techniques that can help us in following this good practice.

Visualizza presentazione su SlideShare

Video


Approfondire gli argomenti

Per ricevere maggiori informazioni sui temi trattati, puoi contattare gli organizzatori ai seguenti indirizzi:

  • XPeppers: info@xpeppers.com
  • TIS Innovation Park: info@tis.bz.it
  • Red Oddity: info@redoddity.it

Il team XPeppers sta preparando il calendario corsi per il 2016. Visto il notevole interesse su queste tematiche riscontrato alla conferenza, sta pensando di proporre dei corsi anche a Trento e/o Bolzano. Se foste interessati a frequentare uno dei corsi disponibili vi invitiamo a compilare il modulo che abbiamo predisposto. Questo ci pemetterà di organizzare i corsi nelle sedi che risultano più comode per gli utenti interessati.

Ringraziamenti

Un ringraziamento particolare a:

  • XPeppers, TIS Innovation Park e Red Oddity per l’organizzazione dell’evento.
  • TIS Innovation Park per aver offerto la sede per l’evento e per il servizio.
  • Red Oddity e  TIS Innovation Park per aver promosso l’evento tra le aziende locali.
  • XPeppers per aver offerto il pranzo ed il coffee-break.
  • Tutti gli speaker per aver proposto talk e workshop che hanno riscosso grande interesse.
  • Tutte le persone che hanno partecipato per aver investito una giornata del loro tempo per confrontarsi sui temi trattati.