Speakers

Talks

22nd October 2020

Vittorio Bertola
Keynote

Inside Hotel California: how the Internet giants dominate through culture and technology

If you want to know what really drives the world, just follow the money. This talk will offer a different view on common cultural mantras and technical trends of the Internet, such as "the Internet should not be regulated", "there should not be national borders online", "let's encrypt everything" and "the Web is the Internet", showing how in today's economy they suit the business and political interests of the big Internet giants and of surveillance capitalism in general. It will start by looking at where the revenues of these companies actually come from, and show how regulation and personal/national points of network control, like ad blockers and content filters, represent a big strategic risk for these companies, explaining their efforts to make those practices culturally unpopular. As a case study, the new DNS-over-HTTPS protocol will be examined in technical and policy terms, showing how, while providing better privacy and security in some use cases, it also addresses that strategic risk for those companies. To end on a positive note, regulatory efforts for a European political response will be summarized, and the open, cooperative, interoperable model based on free software and open standards will be presented as the possible way forward for the European Internet community.

Marco Abis

It takes two to DevOps

In common parlance (and marketing/recruitment speak) DevOps has transformed into a noun but that's misleading as you cannot be "a DevOps". Some say it's an adjective and a ‘DevOps person’ is someone who cares about and supports the DevOps principles while others suggest it's an adverb, so we can use it to describe how we do things rather than to describe ourselves. Either way DevOps itself was never meant to be the goal but rather a mean to an end and we will argue the its key goal is to ensure that software runs well in Production, especially in the context of regular changes (deployments). If you lead a team and want to understand why and how to make your software systems work better, then this talk is for you.

Rigel Di Scala

Write your own Kubernetes Operator using Ansible

This "talkshop" introduces the concept of Kubernetes Operators and guides the attendee in writing a simple one on OpenShift using the Ansible automation framework. Level: Intermediate, for developers and system admins, no programming knowledge needed.

Anton Babenko

Hacking Terraform for fun and profit

If you’ve been using Terraform just by following the official documentation, you are not getting all from it. As soon as one cloud provider announces a new service or a feature, you dream that Terraform has zero-day support for it. Well, it is not always like this, and I will show what we can do about it. Are you using Terraform and keep asking yourself why I should copy-paste so much? What if you need to manage more than a dozen resources with Terraform (e.g., hundreds of GitHub repositories with permissions, or hundreds of IAM users and their permissions)? How can I use Terraform to manage absolutely ANY type of resource? What is beyond Terraform modules? What is a really dynamic module and what Terraform 0.12 will help us with? Let's see the advanced and very unusual solutions of how Terraform can be extended, integrated, executed, or merely hacked to get the job done with the help of external open-source services and integrations.

Gabriella Castelli

The Road to DevOps

Si può fare DevOps in una banca commerciale tradizionale? Nel talk illustreremo l'approccio che abbiamo seguito per introdurre i primi elementi di DevOps mostrando come è possibile cambiare anche in un mondo caratterizzato da forti vincoli normativi, software legacy e un contesto culturale di stampo tradizionale. Discuteremo anche cosa stiamo imparando durante questo viaggio e come il percorso sta evolvendo man mano che lo percorriamo. In particolare stiamo vedendo davvero ""sulla nostra pelle"" quanto il DevOps sia un cambiamento culturale e di metodo e non solo di tecnologia. 

Francesco Degrassi

Surviving microservices

Challenges and risks during adoption, and what to look for beyond. With microservices becoming mainstream a few years ago, many organizations have now adopted them; even though all are paying the price in terms of training, solution complexity and operational costs, few are reaping the promised benefits. Lower velocity, quality and performance issues, along with an overall lack of visibility are what we hear about most often. In this session, working from our experience as advisors to software development teams, we’ll walk you through some of the symptoms you might experience, their possible causes and some potential solutions. Furthermore we outline a pragmatic adoption framework to guide the technology choices in terms of your specific domain, goals and constraints.

Paolo Melchiorre

A Django project template with CI/CD pipelines and k8s orchestration

Illustro il nostro template di sviluppo open-source per lo sviluppo, il test ed il delivery di progetti principalmente basati su Python, Django, PostgreSQL, uWSGI e React che usiamo in produzione di progetti di medie e grandi dimensioni, per fornire servizi web o mobile. In questo talk il pubblico potrà vedere come noi mettiamo in pratica le regole dello sviluppo agile in ambito web usando il linguaggio ed il framework web che preferiamo con l'utilizzo di tecnologie di orchestrazione e CI/CD il tutto racchiuso nel nostro template open-source e riutilizzabile da tutti così com'è o adattabile anche con altri linguaggi di programmazione o framework. In definitiva vorremo portare l'esempio della nostra azienda dove, pur non avendo una figura dedicata esclusivamente ai processi specifici del DevOps ne usiamo l'approccio coordinandoci tramite il nostro template.

Raffaele Colace

A Django project template with CI/CD pipelines and k8s orchestration

Illustro il nostro template di sviluppo open-source per lo sviluppo, il test ed il delivery di progetti principalmente basati su Python, Django, PostgreSQL, uWSGI e React che usiamo in produzione di progetti di medie e grandi dimensioni, per fornire servizi web o mobile. In questo talk il pubblico potrà vedere come noi mettiamo in pratica le regole dello sviluppo agile in ambito web usando il linguaggio ed il framework web che preferiamo con l'utilizzo di tecnologie di orchestrazione e CI/CD il tutto racchiuso nel nostro template open-source e riutilizzabile da tutti così com'è o adattabile anche con altri linguaggi di programmazione o framework. In definitiva vorremo portare l'esempio della nostra azienda dove, pur non avendo una figura dedicata esclusivamente ai processi specifici del DevOps ne usiamo l'approccio coordinandoci tramite il nostro template.

Marco Pracucci

Scaling Prometheus with Cortex, one time series at a time

Cortex is a scalable, highly available, multi-tenant, long term storage for Prometheus. It is designed to reliably ingest and query millions of time series per second, while keeping the operational cost low. But if you try to get started, it is easy to get lost in the tens of different components and config options. In this talk, we will introduce Cortex and its architecture in an approachable way. We’ll start from the minimum setup required and we’ll iteratively cover the Cortex core design principles, sharding, replication, failure modes and a series of techniques employed by Cortex for accelerating PromQL queries. Finally, we’ll look at what the future holds for us and the upcoming features and improvements in Cortex. Cortex is an open source project, released under the Apache 2.0 license, and in the CNCF sandbox stage.

Massimo Re Ferrè

Serverless and containers are coming together: an AWS perspective

Containers have been a driving force in this industry for the last 5+ years. In the meanwhile we have seen the raise of other compute patterns, such as serverless. 2020 seems to be the year where the line between containers and serverless starts to blurry. We are seeing the raise of container serverless platforms (e.g. AWS Fargate) as well as the raise of higher order abstractions above container platforms (e.g. OpenFaaS, ECS CLI v2, …) that allows developers to focus on their code instead of managing containers. In this session we will discuss how the serverless benefits are starting to permeate into the container ecosystem and we will provide real life examples of how some AWS and OSS technologies can be used to abstract and remove part of the undifferentiated heavy lifting developers often need to take care of.

Alessandro Proscia

Da DevSecOps a SecDevOps: Security is not a matter of doors (and sometimes windows are broken)

Se per decenni il mantra nel mondo dell'IT è stato _Prima il software poi i sistemi_, altrettanto lo è ancora la Sicurezza: questa ancora oggi è vista come un aspetto perimetrale di un infrastruttura e spesso relegata alla sola componente Ops. Nel mondo DevOps l'infrastruttura è diventata parte integrante dello sviluppo e la visione della Sicurezza è mutuata nel concetto moderno di DevSecOps. Tuttavia l'infrastruttura è solo un aspetto di cui preoccuparsi: la Sicurezza è anche una questione di software, persone e processi. Ad oggi la Sicurezza è un fattore decisivo ed abilitante per il business: è necessaria pertanto un evoluzione dalla sua visione tradizionale ad un approccio più organico. La Sicurezza pertanto deve seguire la stessa evoluzione del mondo Ops: essere presa in considerazione _By design_ in ogni aspetto del ciclo di vita del software. Nell'incontro saranno presentate le differenze tra gli approcci tradizionali e DevSecOps fino ad arrivare alla sua evoluzione in SecDevOps: verrà in particolare delineato un percorso in cui il punto finale sarà la Sicurezza come parte integrante della metodologia DevOps.

Alessandro Molari

Da DevSecOps a SecDevOps: Security is not a matter of doors (and sometimes windows are broken)

Se per decenni il mantra nel mondo dell'IT è stato _Prima il software poi i sistemi_, altrettanto lo è ancora la Sicurezza: questa ancora oggi è vista come un aspetto perimetrale di un infrastruttura e spesso relegata alla sola componente Ops. Nel mondo DevOps l'infrastruttura è diventata parte integrante dello sviluppo e la visione della Sicurezza è mutuata nel concetto moderno di DevSecOps. Tuttavia l'infrastruttura è solo un aspetto di cui preoccuparsi: la Sicurezza è anche una questione di software, persone e processi. Ad oggi la Sicurezza è un fattore decisivo ed abilitante per il business: è necessaria pertanto un evoluzione dalla sua visione tradizionale ad un approccio più organico. La Sicurezza pertanto deve seguire la stessa evoluzione del mondo Ops: essere presa in considerazione _By design_ in ogni aspetto del ciclo di vita del software. Nell'incontro saranno presentate le differenze tra gli approcci tradizionali e DevSecOps fino ad arrivare alla sua evoluzione in SecDevOps: verrà in particolare delineato un percorso in cui il punto finale sarà la Sicurezza come parte integrante della metodologia DevOps.

Giuseppe Lavagetto

Testing in production for fun and profit

While it's common wisdom that testing in production is a bad thing, it's actually a fundamental part of the work of most deployments in a fast-paced environment. In this talk, starting from my experience managing difficult transitions/rollouts for Wikipedia, I will underline what and how is worth testing in production, and some recommended patterns for doing so, both at large and small scale.

Emanuel Mazzilli

Rousseau Platform: What does it mean to run a high-load critical platform on Kubernetes, while half of the country and national tv is watching you

On Sept. 3rd, 2019, the M5S held a vote on the Rousseau Platform from which was depending the whole country's political system and the current government. The vote ended with over 100.000+ preferences, millions of visiting users, tens of malevolent players reverse engineering your stack, and all principal press offices closely observing the platform behaviors. In this talk, we will dive deep into the technical architecture behind the new Rousseau Platform, based on AWS, Kubernetes Fury and upstream Open Source Cloud Native components. We will also discuss and share our journey and lessons learned as operators working in a high-pressure environment and national scrutiny.

Jacopo Nardiello

Rousseau Platform: What does it mean to run a high-load critical platform on Kubernetes, while half of the country and national tv is watching you

On Sept. 3rd, 2019, the M5S held a vote on the Rousseau Platform from which was depending the whole country's political system and the current government. The vote ended with over 100.000+ preferences, millions of visiting users, tens of malevolent players reverse engineering your stack, and all principal press offices closely observing the platform behaviors. In this talk, we will dive deep into the technical architecture behind the new Rousseau Platform, based on AWS, Kubernetes Fury and upstream Open Source Cloud Native components. We will also discuss and share our journey and lessons learned as operators working in a high-pressure environment and national scrutiny.

Rousseau Platform: What does it mean to run a high-load critical platform on Kubernetes, while half of the country and national tv is watching you

On Sept. 3rd, 2019, the M5S held a vote on the Rousseau Platform from which was depending the whole country's political system and the current government. The vote ended with over 100.000+ preferences, millions of visiting users, tens of malevolent players reverse engineering your stack, and all principal press offices closely observing the platform behaviors. In this talk, we will dive deep into the technical architecture behind the new Rousseau Platform, based on AWS, Kubernetes Fury and upstream Open Source Cloud Native components. We will also discuss and share our journey and lessons learned as operators working in a high-pressure environment and national scrutiny.

Michele Sacchetti

Tale of two cities, dark release in both REST and Message Driven ecosystem

In un ambiente di produzione a micro-servizi avere la possibilità di avere dei deploy ""dark"" per valutare gli impatti delle nuove funzionalità è un grossissimo vantaggio. L'introduzione del concetto di service mesh permette un maggiore controllo sulle chiamate REST/Http, ma in un ambiente misto in cui i servizi dialogano anche in con approccio asincrono message driven ci sono alcuni importanti criticità da affrontare per poter ottenere il risultato atteso. Lo speech illustra come abbiamo integrato l’utilizzo di Istio su Kubernetes all’interno della nostra pipeline di Continuous Delivery per gestire dei microservizi “dark” affiancati a quelli live sia in ambiente di integrazione per velocizzare e parallelizzare lo sviluppo, sia in produzione per poter fare rilasci a zero downtime e A/B Testing. La seconda parte illustra come siamo riusciti ad estendere lo stesso concetto anche alla parte di micro-servizi che dialoga non tramite chiamate REST ma via messaggistica Kafka, un ambito attualmente non coperto dal concetto di service mesh dove abbiamo dovuto implementare una nostra soluzione. Il tutto è stato integrato sul nostro sistema di ticketing Jira in modo da tenere traccia dello stato/ambiente di deploy per ciascuna funzionalità sviluppata.

Franco Torriani

Tale of two cities, dark release in both REST and Message Driven ecosystem

In un ambiente di produzione a micro-servizi avere la possibilità di avere dei deploy ""dark"" per valutare gli impatti delle nuove funzionalità è un grossissimo vantaggio. L'introduzione del concetto di service mesh permette un maggiore controllo sulle chiamate REST/Http, ma in un ambiente misto in cui i servizi dialogano anche in con approccio asincrono message driven ci sono alcuni importanti criticità da affrontare per poter ottenere il risultato atteso. Lo speech illustra come abbiamo integrato l’utilizzo di Istio su Kubernetes all’interno della nostra pipeline di Continuous Delivery per gestire dei microservizi “dark” affiancati a quelli live sia in ambiente di integrazione per velocizzare e parallelizzare lo sviluppo, sia in produzione per poter fare rilasci a zero downtime e A/B Testing. La seconda parte illustra come siamo riusciti ad estendere lo stesso concetto anche alla parte di micro-servizi che dialoga non tramite chiamate REST ma via messaggistica Kafka, un ambito attualmente non coperto dal concetto di service mesh dove abbiamo dovuto implementare una nostra soluzione. Il tutto è stato integrato sul nostro sistema di ticketing Jira in modo da tenere traccia dello stato/ambiente di deploy per ciascuna funzionalità sviluppata.

Marco Tozzi

Tale of two cities, dark release in both REST and Message Driven ecosystem

In un ambiente di produzione a micro-servizi avere la possibilità di avere dei deploy ""dark"" per valutare gli impatti delle nuove funzionalità è un grossissimo vantaggio. L'introduzione del concetto di service mesh permette un maggiore controllo sulle chiamate REST/Http, ma in un ambiente misto in cui i servizi dialogano anche in con approccio asincrono message driven ci sono alcuni importanti criticità da affrontare per poter ottenere il risultato atteso. Lo speech illustra come abbiamo integrato l’utilizzo di Istio su Kubernetes all’interno della nostra pipeline di Continuous Delivery per gestire dei microservizi “dark” affiancati a quelli live sia in ambiente di integrazione per velocizzare e parallelizzare lo sviluppo, sia in produzione per poter fare rilasci a zero downtime e A/B Testing. La seconda parte illustra come siamo riusciti ad estendere lo stesso concetto anche alla parte di micro-servizi che dialoga non tramite chiamate REST ma via messaggistica Kafka, un ambito attualmente non coperto dal concetto di service mesh dove abbiamo dovuto implementare una nostra soluzione. Il tutto è stato integrato sul nostro sistema di ticketing Jira in modo da tenere traccia dello stato/ambiente di deploy per ciascuna funzionalità sviluppata.

Leonardo Di Donato

Cloud Native eBPF Instrumentation

In this talk we are going to see how in Cloud Native environments we have the common issue of having tools to instrument and comprehend the application behaviour at kernel level. To try to solve this problem I'll try to illustrate my opinions on how I used eBPF and eBPF based tools that are both the kernel and Kubernetes aware. In other words, Cloud Native.

Maurizio Caltabiano

IT Asset Management

Nel percorso DevOps di automazione e controllo dell'intera filiera di produzione del software, Banca Mediolanum sviluppa un Configuration Management System ovvero uno strumento di analisi degli asset tecnologici basandosi su Neo4j, Spark e Hadoop. La scelta di modellare il dominio come un insieme di relazioni tra entità diverse ma tra loro naturalmente connesse si rivela vincente nel consentire di fornire insight mirati ed efficaci ai differenti attori e processi. Il graph database diventa il supporto di analisi strumentale per gli Specialisti IT nelle operazioni quotidiane di analisi di impatto, disegno e governo degli asset tecnologici.

Giulio Vian

How to write cloud-agnostic Terraform code

Terraform is a beautiful tool we all love; it is multi-cloud, meaning you can write code to provision resources from all major and many minor cloud providers. Sadly the code you write is vendor specific as resource descriptions are not portable between providers. What if your boss or customer wants a cloud-agnostic solution? Do you need an external tool or Terraform language is rich enough to allow cloud-agnostic code? I stand that 0.12 is so powerful that you can create provider-agnostic modules and write code that works the same in GCP, AWS and Azure.

Floor Drees

Open at Microsoft: what do VS Code, .NET, TypeScript and Git have in common?

The first Microsoft project released under an open source license was WIX... in 2004! The technology behemoth has come a long way since then. Today, Microsoft’s engineers maintain TypeScript, .NET, Windows Terminal, Dapr, Helm, and more than a thousand other projects. Did you know that with over 19k contributors, Visual Studio Code is the number 1 open source project by contributors? How does Microsoft's Open Source Program Office (OSPO) manage and support all that activity, and what is their recipe for scale?

Andrea Tosatto

Effective GitOps with Ansible

"Initially advocated by WeaveWorks in the context of cloud native applications delivery, the GitOps approach promises to streamline applications and infrastructures delivery promoting a Git-centric approach to applications and configuration mangement. While GitOps is seeing a growing interest and adoption in the Kubernetes community with the help of tools such as Argo and Flux, there is a lack of tooling and literature describing how this approach can be extended to the broader configuration management environment and traditional infrastructures. The goal of this talk is to explore how GitOps relates to traditional configuration management and how this can be effectively implemented by DevOps teams to streamline the delivery of Ansible-managed infrastructures and applications."

Lars Bendix

What SCM is useful and necessary on DevOps projects?

"Software Configuration Management (SCM) is an important foundation for any type of project to work in a smooth and successful way. So there is no reason that SCM shouldn't be useful and necessary also on DevOps projects However, all projects are not alike and there is no single “one size fits all” SCM that will work in all contexts and for all development methods. SCM has well-established practices for more traditional ways of development, but very little is known about what SCM is needed and how it should be carried out in a DevOps context. DevOps projects probably need SCM done in different ways than “traditional” projects - and operationally by different (non-SCM) people. The difficult thing is not the concepts and principles of SCM - but to figure out what part of them can be helpful in different situations and in which way they should be implemented. As SCM experts - with a DevOps interest - we decided to investigate more closely how to match up SCM with DevOps. There is already some knowledge about how to do SCM in DevOps contexts, but it is fragmented and scattered around - and it is incomplete. We have researched “prior art” to collect existing wisdom. We have also analysed DevOps and SCM to identify areas where we could complete the existing knowledge. In this presentation, we will present and discuss our findings so far."

Matteo Castellani

Un Castello di Carte (di Credito) tra le Nuvole

PCI-DSS è un acronimo che sta per “Payment Card Industry - Data Security Standard” ed in UK rappresenta il modello legale da soddisfare se si decide di gestire autonomamente il proprio sistema di pagamenti online. In questo talk racconterò le strategie che io ed il mio team abbiamo messo a punto per realizzare uno dei primi sistemi di pagamento, certificati PCI-DSS di primo livello, hostato interamente in AWS public cloud. Racconterò di come Dev ed Ops abbiano lavorato assieme, descriverò l’architettura dell’infrastruttura, il tipo di automazioni e quali gli accorgimenti utilizzati per la realizzazione della piattaforma.

Claudio Bartoli

Data science from lab to production

"Vorrei raccontare l’esperienza vissuta come Data Engineer in un team di data scientist, dove le competenze matematiche e statistiche sono molto elevate, ma non si può dire lo stesso per quella sistemistica e la cura (e replicabilità) degli ambienti. L’esperienza (in ambito python) ci ha permesso di eseguire l’ambiente in locale e CI (con docker) in produzione su cluster AWS EMR. Il taglio del talk sarebbe molto esperienziale, su quelle che sono le dinamiche su team MOLTO eterogenei e sulla replicabilità delle dipendenze python (tramite pyenv e pipenv) e di sistema (librerie native) per poter replicare gli ambienti sulle varie piattaforme."

Alessandro Scuderetti

Continuous Delivery su Database in contesto Enterprise: sfide tecniche e organizzative

Nel percorso DevOps di automazione e controllo dell'intera filiera di produzione del software, Banca Mediolanum sviluppa una pipeline di continuous delivery su database. L’intervento racconta l’esperienza vissuta in un progetto di automazione del processo di rilascio del software su database, problematiche e benefici ottenuti in termini di efficienza e sostenibilità di processi legati al governo dei dati quali “privacy by design”. Ecco i temi trattati: * Contesto organizzativo, di processo e tecnico di partenza * Definizione nuovo processo di design, sviluppo e rilascio * Soluzione tecnica: modello di branching, versionamento, Erwin, Flyway, Jenkins Pipeline, Git, Maven, Artifactory, Mattermost, Hashicorp Vault e Consul, custom tool * Mitigazione dei rischi di cambiamento: visibilità, collaborazione, condivisione * Gdpr e privacy by design * Benefici ottenuti, “lesson learned” e prossimi passi

Giacomo Tonucci

Introduzione alla Service Mesh per DevOps

Dopo aver adottato gli orchestratori di container, i microservizi e aver industrializzato i ltutto tramite le pipeline CI/CD, il prossimo collo di bottiglia potrebbe essere la pubblicazione dei servizi ed il controllo delle loro comunicazioni. Per superare questi limiti potrebbe essere necessario introdurre in azienda una Service Mesh. La Service Mesh offre osservabilità, resilienza, controllo del traffico e sicurezza per le comunicazioni tra servizi distribuiti, aggiungendo un disaccoppiamento tra il codice applicativo(Dev) e le preoccupazioni a livello di servizio e gestione delle sessioni (Ops)

Grazie
a

main
diamond
platinum
silver
bronze
Media partners
Become a Sponsor!
And help up make the conference great
Send us an email