Incontro DevOps Italia 2018
8 - 9 Mar 2018 at SAVOIA HOTEL REGENCY

It’s time again for the Dull Stack Engineer, the Engineer who knows what’s running on his platform, focusses on servicing the business and not just his need of new and fancy tooling, the engineer who collaborates with his peers rather than running Docker because it’s the cool thing to do. Over the past 8 years, the DevOps movement was the stimulant to create a large number of new tools, lots of them open source, some not. A large number of those tools got announced as the ultimate #devops tool, think about Puppet, Chef, Vagrant, Docker, Kubernetes etc. and a lot of the developers and operations folks jumped on these tools. Often, even to a point where the tool was more important than the goal. Then came the idea of the Full Stack engineer … like the person who does kernel development, front-end development and everything in between. But now it’s time for the Dull Stack Engineer, the Engineer who knows what’s running on his platform, focusses on servicing the business and not just his need of new and fancy tooling, the engineer who collaborates with his peers rather than running Docker because it’s the cool thing to do.

While DevOps continue to mean a lot of things to a lot of people, containers continue to deliver lots of goodness in the DevOps space. Containers are becoming more and more the center of gravity of how software is packaged, life-cycled and executed in development and production environments. In this session we are going to cover a brief overview of the various compute abstractions available on the Amazon Web Services platform with a particular focus on container related services such as Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Container Service for Kubernetes (Amazon EKS) as well as AWS Fargate. In this session we are going to introduce these services and the idea behind them with a focus on educating the audience on the problems AWS is trying to solve with these technologies.

Come si è evoluto, e come continua ad evolversi il processo di sviluppo della piattaforma cloudesire, dal codice all’integrazione continua, analisi statica del codice, processi di code review e provisioning automatico in produzione.

Siamo un team che lavora all’interno di una grande realtà aziendale Italiana. Negli ultimi tempi abbiamo accettato la sfida di passare da un approccio monolitico ad uno orientato ai microservizi, da un approccio di delivery lento all’adozione della Continuous Delivery. In questo talk vogliamo raccontarvi la nostra esperienza: da dove siamo partiti, come ci stiamo muovendo e dove vogliamo arrivare.

Il talk sarà un case study del processo di trasformazione digitale, denominato Change Up: attraverso un’unico punto di controllo è stato reso possibile il deploy agnostico di applicativi su più orchestratori e piattaforme, applicando la vera metodologia DevOps tra il team di Developer e quello di Operations in concomitanza ai principi di interfaccia/contratto e composizione, principi che in questo caso non sono esclusivamente relegati alle buone pratiche di sviluppo ma hanno permesso un elevato grado di personalizzazione dei processi di CI/CD.

There are many use-cases for running databases in containers – this presentation will focus on pragmatic examples of using Kubernetes to orchestrate Postgres streaming replicas for on-demand disaster recovery and horizontal scaling. Containers are big news – they are the latest evolution in infrastructure technology and are poised to represent the next major shift in database workflows. As they are rapidly becoming an essential weapon in every DBA’s arsenal – so let’s take a look at what a Docker container represents to the RDBMS world, the relevant portions of the Kubernetes architecture, and a live demonstration of Postgres in action with Docker/Kubernetes.

Microservices are usually considered the be technology agnostic, thus they are approached in terms of architectures or models to be applied on distributed systems. Nevertheless, their basic mechanisms can be crystallized within a unique programming language by offering a new mindset for developers and engineers, In the past years we dealt with such an objective starting from the theoretical foundations of service oriented computing. In this presentation I’ll show our experience and our results in approaching microservices with a specific programming language called Jolie.

Applying Microservices patterns could be useful even in big companies, with big teams and lots of monoliths. How can we cope with the coexistence of several architectural styles in a big organization? Is it possible to let the monoliths coexist with SOA, microservices and DevOps? In our opinion, yes. This presentation will show you how to start evolving towards a better system architecture, without requiring you to perform risky “Big Bang” refactorings. This is the only way to succeed in digital transformation programs. The presentation will not only give you principles of good systems design: we will show you how we solved effectively some issues, such as avoiding distributed transactions in favor of compensation and idempotence; or how we managed to effectively correlate transactions in distributed systems by using ELK stack. We will show you how simple it is to build a monitoring dashboard for a highly distributed and heterogeneous architecture, built on SOA and microservices by leveraging cleverly built application logs, and integrating monitoring information coming from APM systems, in order to ease your transition to a more distributed system implementation. Real use cases from real projects alongside good architectural design principles.

La sfida di chi deve garantire l’esercizio degli applicativi legacy, definendo anche una strategia per l’adozione di architetture a micro-servizi, è piena di ostacoli. Verranno presentate le diverse soluzioni, le scelte possibili e il ruolo della Cloud Native Computing Foundation anche per le aziende che hanno l’obiettivo nel medio termine di abilitarsi per l’infrastruttura al cloud pubblico.

The emergence of large-scale IT architectures, deployed on multiple federated (and possibly hybrid) Cloud data centers and serving a worldwide customer base, suggests the adoption of smart and business-driven autoscaling solutions that could bring valuable cost saving opportunities to service providers. More specifically, dynamically reconfiguring IT service components placement, in order to respond to VM pricing changes and to control and guarantee the SLOs defined by service providers, has the potential of significantly reducing IT costs. However, that requires next-generation management solutions capable of evaluating the performance of complex IT services deployments over large-scale Cloud systems in a wide range of alternative configurations. This talk discusses the potential and challenges in this research area and presents BDMaaS, a novel JRuby-based open source solution for adaptive business-driven IT service component reconfiguration.

Modern organizations invest vastly on designing top-notch visual user interfaces that improve their credibility, strengthen their brand and help them win new customers, but how do they ensure that they look flawless when delivered to the end users? How do they prevent regressions and visual defects given all the possible combinations of devices, platforms, browsers, screen sizes and resolution that proliferate from day to day? Those who care enough often use dedicated, manual QA stages that inevitably introduce delays in the deployment pipelines and cost a great deal of resources and time. Those who, on the other hand, leave this aspect unaddressed, incur the risk of exposing defective interfaces that negatively impress their audience, often times losing them to competitors. We present an approach to visual testing that is completely automated and integrated into a continuous deployment pipeline, capable of blocking visual regressions and defects at early development stages thus saving resources, costs and reducing the time needed to deliver impeccable user interfaces. A live demo will highlight all the steps involved, from design to deployment, using Python, Selenium, GitLab and Docker.

ZFS is a filesystem, originally developed for Solaris, that finally brings advanced filesystem features (compression, snapshots, and checksums, among others) to Linux. I selected the ZFS-on-Linux port as the key component of an internal tool created with the purpose of better supporting the team in all those scenarios where a replica of the production Postgres database might be required: testing query optimizations, database migrations, etc. While it was a lot of fun for me to work on it, the tool proved, most importantly, to be extremely useful to the whole team. The presentation dives into the technical details of the tool, introduces ZFS key features, why one would want to use it, and then explores some other interesting ZFS use cases.

Apache Hadoop è uno dei framework opensource più utilizzati nell’ambito del data processing distribuito su grande scala. La presentazione illustrerà la storia di Hadoop, l’architettura, i suoi utilizzi e l’ecosistema di applicazioni nate attorno ad esso. Verranno presentate anche le features della nuove release 3.0.

Development boxes and modern software lifecycle development techniques. How our development team grew up and how we evolved our development stack: our use case, based on our experience in Fazland.com

In the era of cloud-native distributed applications and micro-services, ensuring the robustness and reliability of services is hard. Our applications make use of ephemeral compute resources (e.g. Containers / Cloud Infrastructures) and rely on network-based communication to coordinate and distribute information. In such context, designing applications for robustness and reliability is definitely an hard task. The culture and engineering approach promoted by tech giants like Netflix, AWS, etc to deal with such complex systems is called Chaos Engineering. Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production. (http://principlesofchaos.org/). In this talk we will introduce the audience to Chaos Engineering providing concrete examples of the motivations behind this engineering approach and tools that can be used to apply this methodology in practice.

La produttività data dall’utilizzo dei container raggiunge l’apice quando si arriva all’elasticità di un cloud. Dai container, al Container as a Service al Container Less in questa sessione offriamo una panoramica della tecnologia Azure Container per il mondo DevOps, e un deep dive sugli strumenti di produttività basati su Kubernetes quali Helm/Brigade/Draft. Ma la potenza è nulla senza controllo, quindi vedremo come è possibile tenere sotto stretta governance il consumo di questi servizi e domarli attraverso strumenti di CI/CD in Azure.

I will talk about how I applied Promise Theory to managing a loose team of people to most of whom I don’t have a line of command. Promise Theory was born in 2004 as Mark Burgess was looking for a model to describe CFEngine 3, the third major version of his Configuration Management system. It didn’t take long to Mark to realise that Promise Theory was suited to model any complex system, no matter of the nature of its parts (software, hardware, people, companies…) and that expressing complex systems in terms of “agents” and “promises” provided an insight in their complexity, helped design them for scalability, set realistic expectations for the outcomes. I had used CFEngine a lot when I became the Head of IT in Telenor Digital, and thus the principles of the theory were quite clear to me. In my new role I had a lot of both operational and managerial tasks and an initial team size of one and then two. The challenge was big and borrowing help from other functions in the company was a necessity. A traditional management style was not going to work, so I decided to shape my own management style by using Promise Theory. This talk is the report of the first year. It will introduce the audience to promise theory and the context where the idea of promise-based leadership was born, and then describe how those principles were used with a few practical, real-world examples. We’ll also talk about where our knowledge falls short and where this approach is not applicable.

Con DevOps si intende in genere l’abbattimento di tutte le barriere tra sviluppatori ed addetti alle operazioni. In un mondo in continua evoluzione tecnologica dove oggi si parla di “Serverless” e “NoOps”, ha ancora senso parlare di DevOps? La metodologia DevOps è da ritenersi superata? Presenteremo alcune delle nostre esperienze in contesti moderni, spaziando dalla collaborazione tra team differenti, alla gestione di infrastrutture cloud composte di tecnologie serverless o PaaS. In questo modo vogliamo mostrare delle possibili evoluzioni dei lavori del team di operazioni o aspetti che ogni sviluppatore dovrebbe tenere presente nella progettazione e realizzazione di nuovi servizi. Il talk sarà più a carattere divulgativo che tecnico sulle metodologie e modalità di lavoro per un “devops 2.0”, non mancheranno comunque esempi e riferimenti a strumenti e servizi che usiamo nelle nostre attività.

Bash is a fundamental scripting shell and language tied to the core of standard Unix process launching and composition (execve(2), fork(2), and pipe(2)). As being omnipresent, reliable, stable and straightforward to start working with Bash is often used for writing the first version of simple provisioning script. Those initially simple scripts soon can become awkward to maintain mostly due to the language unique idiosyncrasies. Test-Driven Development is a engineering practice that, among other things, leverages automatic testing to develop confidence with unknown systems and languages. Mixing Bash and TDD I’ll demonstrate you how you can discover and deal with Bash quirks and features in order getting a task done. The talk will be delivered as #noslides performance (a talk where the speaker casts its computer screen while performing the work and explaining what is doing and why). I will develop a Bash script incrementally using TDD but without using any pre-existent xUnit framework: during this session a mini-framework will be developed from scratch using only out-of-the-box system features and tools.

How AWS Lambda Functions can help you keeping clean your infrastructure. If you have ever used a cloud service like AWS EC2, you already know how much AutoScaling Groups rock. It’s a honeymoon until you deploy a service that, before being shut down, must perform some cleanup. These systems terribly suffer when a scale-in event abruptly kills servers without notice. In this talk we show a very simple and practical example of leveraging FaaS to cleanly shutdown a pool of workers that execute jobs off a queue.

The presentation is about PSICK a Puppet module and the companion control-repo, which can be used to build a modern, flexible, expandable and full featured IT infrastructure with Puppet in an amazingly quick way. We will review the unique features of PSICK and how we can configured everything entirely via Hiera data, without the need of an excessive number of external modules.

Il processo di migrazione di ambienti IT nel cloud è diventato un trend ricorrente negli ultimi anni. I motivi che spingono le aziende a migrare sono diversi: aumentare l’agilità, incrementare la produttività, utilizzo di tecnologie più moderne, riduzione dei costi. Sebbene ci siano dei fattori che accomunano le strategie di migrazione, non esiste una soluzione unica per tutti. In questo talk vi mostreremo la nostra esperienza nella migrazione partendo dagli scenari più legacy fino a passare a quelli elaborati con ciclo continuo di deployment e delivery dell’infrastruttura. Il talk darà la possibilità di comprendere le differenze tra differenti livelli di automazione e/o sfruttamento del Cloud analizzando dei casi d’uso che si adattano a specifiche situazioni.

Finding a well written API is a rare pleasure; we often stumble upon horrors that make us pull our hair out, mostly due to a basic lack of common sense. To help make common sense actually common, in this talk we would like to go over the most frequent mistakes and how to avoid them. The session is mostly technology-agnostic, and is suitable to anyone with a programming background. Some of the issues we’ll cover are: Consistency: the refuge of the weakly minded. One DTO to rule them all: is designing requests and responses so hard? Dates: in how many different ways can you say “next tuesday at noon”? The often forgotten link between request parameters and response data. The Promise of a Future that has been broken. Correlating entities across different API methods. Authentication, Authorization and Accounting, reinvented. Again. Dumping your C memory structs and calling it an API – why not. The bicycle that became a motorcycle upon deletion. The lost art of paging lists of entities correctly. Or at all. Ever felt the pain of trying to integrate with an API which was clearly not meant to be used by humans? We did! Come hear some war stories and what could have been done to avoid some of the pain.

Come sfruttare la tool chain Atlassian per interagire con l’infrastruttura Openstack Docker Kubernates.

There is a lot of discussion nowadays on how to use containers in production, are you there already? When operating a production platform we should prepare for failure and in addition to monitoring working metrics, we cannot forget about the most common failure points. From monitoring solution agnostic perspective, and following a use-case driven approach, we will learn the most common failure points in a Kubernetes infrastructure and how to detect them (metrics, events, checks, etc).

Uno stagionato stack LAMP come WordPress mixato all’avvento del Cloud Computing e di Docker ha permesso di ottenere un cocktail dalle massime prestazioni, massima facilità di manutenzione e massima scalabilità ed ottimizzazione dei costi, senza rinunciare ad un comodo ambiente di sviluppo locale. Sull’esigenza di poter avere un unica piattaforma capace di ospitare tante testate giornalistiche locali è nato QNlocal: Un sistema editoriale con un codice unico (WordPress + tema sviluppato ad Hoc) che gira in un container, orchestrato dal progetto Praxis di Convox su AWS. Parleremo del setup che permette di creare base dati, distribuzioni cloudfront e S3 buckets per gli asset statici e per il backup. Il tutto con un paio di comandi. Un sistema di continuous integration che permette un ciclo di testing e sviluppo. Verranno illustrati gli aspetti tecnici, quelli di automazione, di manutenzione e di setup di una testata locale. Verrà inoltre mostrata l’evoluzione della piattaforma che si sta attuando basata sull’esperienza acquisita dopo un anno dalla messa in produzione.

Reacting to threats “just” in real-time is no longer enough to stay on top of the security game. Threats escalate within minutes, requiring you to be ready, when they hit. In this talk we will look at how you can be able to accurately predict attacks weeks in advance. Learn how you can discover how to protect against tomorrow’s threats – today using machine learning.

Come passare dal Centro Elaborazione Dati al cloud? L’IT del settore pubblico parte da una situazione estremamente frammentata con oltre 10000 piccole installazioni, spesso singoli rack nel sottoscala dell’ufficio locale, e sta vivendo un momento di trasformazione importante, in cui la governance deve cercare di bilanciare richieste essenziali e spesso conflittuali come: offrire servizi pubblici migliori e più pertinenti incentrati sui bisogni dei cittadini e delle imprese; ridurre i costi e migliorare l’efficienza delle loro operazioni; e reinventare le catene di approvvigionamento e delivery per fornire servizi più rapidamente, a basso costo ed efficacemente. Il Piano Triennale approvato nel 2017 lancia una gigantesca sfida tecnologica che richiederá un cambiamento totale delle infrastrutture pubbliche. Related

We don’t need to convince you that Continuous Delivery/Deployment (CoDe) will be like Paradise on Earth – you already bought into the idea. However, you haven’t arrived yet – otherwise you should have done your own presentation. Therefore, you are probably struggling to find the right way to get there, and you have come to this presentation to be warned about what to expect and prepare yourself for what to do. Let us show you how you can go to CoDe Paradise before others spending less time and effort. Many are the roads that lead to CoDe Paradise – some are more bumpy than others and some have pitfalls that you should look out for. So how can you address these problems – or avoid them? Fortunately, others have already gone down the CoDe roads and made some experience. This presentation is an experience report based on interviews with 1-3 persons in each of 4 Danish companies of different sizes and at various stages of their CoDe journey. In addition, the presentation integrates results from interviews done with 2 persons from Denmark’s leading CoDe consultancy company about their customers’ experience. We will present a selection of the challenges, pitfalls, and bumps that we found and reflect on the approaches used to either address or avoid them. Like in all fairy tales, we will end by showing you a glimpse of CoDe Paradise from a company that has already arrived there and some of the lessons of excellence that can be learned from them. At the end of this presentation, you will be more informed regarding the kind of bumps and pitfalls that others have experienced on their journey towards CoDe Paradise. You will know what they have done to address such challenges; why those approaches worked and, in some cases, did not; what they did to avoid some; and, what are the general lessons learned (guiding principles) we can draw from their experience.

Supporting non-cloudnative or stateful applications it’s always been hard. Every time there was an effort to automate these kind of applications, we had to reinvent the wheel over and over again, with no patterns, no best-practices, no standardization. In this talk will see how we can leverage kubernetes’s primitives to automate us out of a job. Kubernetes is able to adapt to the environment in which is installed thanks to its pluggability: we’ll see a bit of theory and a bit of how we can write only the business logic reducing bootstrapping to a minimum.