Approccio ad una infrastruttura per MicroserviceDaniele Mondello
Preentazione effettuata al Cnu Linux Meeting 2016 nel quale vine descritto un "approccio ad una infrastruttura per Microservices".Vengono descritte diverse tecnologie a supporto come RabbitMQ, Jenkins, Doickers.
Presentazione alla Google Dev Fest Mediterranean 2016 di Catania con presentazione sulle metodologie di utilizzo di microservices e sui sistemi per monitorare le infrastrutture
- MicroServices, le dimensioni non contano
- Wildfly Swarm, Spring Boot & Vertx.io: il nuovo che avanza
- Microservices con JBoss EAP 7: innovare in continuità
- Microregole per grandi progetti con il BRMS
- Integrazione e microservizi: come un cammello può passare dalla cruna di un ago
- API Management con 3Scale nell’era dei microservizi
Approccio ad una infrastruttura per MicroserviceDaniele Mondello
Preentazione effettuata al Cnu Linux Meeting 2016 nel quale vine descritto un "approccio ad una infrastruttura per Microservices".Vengono descritte diverse tecnologie a supporto come RabbitMQ, Jenkins, Doickers.
Presentazione alla Google Dev Fest Mediterranean 2016 di Catania con presentazione sulle metodologie di utilizzo di microservices e sui sistemi per monitorare le infrastrutture
- MicroServices, le dimensioni non contano
- Wildfly Swarm, Spring Boot & Vertx.io: il nuovo che avanza
- Microservices con JBoss EAP 7: innovare in continuità
- Microregole per grandi progetti con il BRMS
- Integrazione e microservizi: come un cammello può passare dalla cruna di un ago
- API Management con 3Scale nell’era dei microservizi
A Framework for Rule-Based Dynamic AdaptationIMDS2014
A framework is proposed for rule-based dynamic adaptation of applications at runtime. Adaptation rules can be developed and updated separately from applications to modify application behavior based on changing goals or environments. Rules specify applicability conditions and can replace application activities with new code while preserving application state. The adaptation manager applies rules non-deterministically or by priority to adapt applications without stopping them. This framework allows flexible, dynamic adaptation using rules developed independently from applications.
MySQL Day Milano 2018 - Le architetture a microserviziPar-Tec S.p.A.
In occasione del MySQL Day 2018 di Milano il TechAdvisor Michelangelo Uberti ha fornito una panoramica sui concetti chiave, sui benefici e sulle opportunità offerte dalle architetture a microservizi.
I punti trattati durante la presentazione sono:
- Presentazione dell’offerta Par-Tec dedicata a MySQL Enterprise Edition
- Dai monoliti ai microservizi
- Un esempio concreto: Netflix
- Architetture a microservizi: vantaggi e punti di attenzione
- Dalla virtualizzazione ai container
- Containerizzazione: vantaggi e punti di attenzione
- Come superare i limiti dei container
- Introduzione al paradigma DevOps
Per saperne di più, scaricate le slide e guardate il video della presentazione del nostro TechAdvisor su https://www.par-tec.it/le-architetture-a-microservizi
[AxonIQ Italia Community] Architetture distribuite a eventi: sono adatte al m...Corrado Musumeci
Architetture distribuite a eventi: sono adatte al mio progetto?
Una rapida introduzione ai vantaggi che possiamo ottenere dall'adozione di una architettura a microservizi guidata dagli eventi.
Quali sono i problemi che tipicamente affliggono i sistemi software complessi?
Quali di questi problemi possono risolti adottando un approccio distribuito?
Che complessità dobbiamo affrontare nello sviluppo di applicazioni distribuite?
Cercheremo di sviscerare questi e altri dubbi relativi all'implementazione di sistemi event-driven distribuiti.
A Framework for Rule-Based Dynamic AdaptationIMDS2014
A framework is proposed for rule-based dynamic adaptation of applications at runtime. Adaptation rules can be developed and updated separately from applications to modify application behavior based on changing goals or environments. Rules specify applicability conditions and can replace application activities with new code while preserving application state. The adaptation manager applies rules non-deterministically or by priority to adapt applications without stopping them. This framework allows flexible, dynamic adaptation using rules developed independently from applications.
MySQL Day Milano 2018 - Le architetture a microserviziPar-Tec S.p.A.
In occasione del MySQL Day 2018 di Milano il TechAdvisor Michelangelo Uberti ha fornito una panoramica sui concetti chiave, sui benefici e sulle opportunità offerte dalle architetture a microservizi.
I punti trattati durante la presentazione sono:
- Presentazione dell’offerta Par-Tec dedicata a MySQL Enterprise Edition
- Dai monoliti ai microservizi
- Un esempio concreto: Netflix
- Architetture a microservizi: vantaggi e punti di attenzione
- Dalla virtualizzazione ai container
- Containerizzazione: vantaggi e punti di attenzione
- Come superare i limiti dei container
- Introduzione al paradigma DevOps
Per saperne di più, scaricate le slide e guardate il video della presentazione del nostro TechAdvisor su https://www.par-tec.it/le-architetture-a-microservizi
[AxonIQ Italia Community] Architetture distribuite a eventi: sono adatte al m...Corrado Musumeci
Architetture distribuite a eventi: sono adatte al mio progetto?
Una rapida introduzione ai vantaggi che possiamo ottenere dall'adozione di una architettura a microservizi guidata dagli eventi.
Quali sono i problemi che tipicamente affliggono i sistemi software complessi?
Quali di questi problemi possono risolti adottando un approccio distribuito?
Che complessità dobbiamo affrontare nello sviluppo di applicazioni distribuite?
Cercheremo di sviscerare questi e altri dubbi relativi all'implementazione di sistemi event-driven distribuiti.
MySQL Day Roma 2019 - Le architetture a microservizi e MySQLPar-Tec S.p.A.
In occasione del MySQL Day 2019 di Roma il TechAdvisor Michelangelo Uberti e Marco Carlessi - MySQL Principal Sales Consultant di Oracle - hanno fornito una panoramica sui concetti chiave, sui benefici e sulle opportunità offerte dalle architetture a microservizi.
I punti trattati durante la presentazione sono:
- Le architetture a microservizi
- Dai monoliti ai microservizi
- Un esempio concreto: Netflix
- Architetture a microservizi: vantaggi e punti di attenzione
- Dalla virtualizzazione ai container
- Containerizzazione: vantaggi e punti di attenzione
- Come superare i limiti dei container
- MySQL e le architetture a microservizi
- Microservizi e i dati
- Microservizi e database: due approcci
- MySQL può girare dentro i container
- Deploy MySQL 8.0 con Docker
- Oracle MySQL Operator for Kubernetes (Alpha)
- MySQL 8.0: un multi-model DB
- MySQL Enterprise licensing
Per saperne di più, scaricate le slide e guardate il video della presentazione del nostro TechAdvisor su https://www.par-tec.it/le-architetture-a-microservizi-e-mysql
Rich client application: MVC4 + MVVM = Knockout.jsGiorgio Di Nardo
La sempre maggiore diffusione di device diversificati (PC, Notebook, Tablet, Smartphone, ecc.) su piattaforme diverse, rilancia l'utilizzo delle Web Application come strumento per raggiungere il maggior numero di potenziali clienti con il minimo sforzo. Le capacità avanzate dei nuovi device e le ultime tecnologie ci consentono però di evolvere il concetto classico di applicazione Web in una declinazione più veloce, più responsiva, più accattivante: vediamo come.
MySQL Day Milano 2017 - Dalla replica a InnoDB Cluster: l’HA secondo MySQLPar-Tec S.p.A.
In occasione del MySQL Day 2017 di Milano il TechAdvisor Michelangelo Uberti ha fornito una panoramica delle soluzioni native di alta disponibilità di MySQL.
I punti trattati durante la presentazione sono:
- Presentazione dell’offerta Par-Tec dedicata a MySQL Enterprise
- High Availability: cause, esigenze, aspettative
- Funzionamento, benefici e limiti dei principali approcci:
- Replica tradizionale
- MySQL Cluster
- MySQL Group Replication
- La novità: MySQL InnoDB Cluster
Per saperne di più, scaricate le slide e guardate il video della presentazione del nostro TechAdvisor su https://www.par-tec.it/dalla-replica-a-innodb-cluster-l-ha-secondo-mysql-milano
Marty dives into the complex process of business transformation, highlighting both its anti-patterns and valuable lessons from successes.
The talk underscores the shift from mere ‘Agile’ labels to profound changes in building, problem-solving, and decision-making. He emphasizes transitioning from big releases to consistent cadences, evolving from stakeholder-driven roadmaps to empowered product teams, and redefining how companies prioritize threats and opportunities.
At its core, the transformation journey seeks to tap into the talent of your people to provide a machine for consistent innovation. This talk promises to provide a holistic view of company transformation, guiding product leaders on where they stand and where they need to head.
The document summarizes the outcomes of Facile.it Partner's 2023 hackathon. Some key points:
- The hackathon aimed to break down silos, foster collaboration, and promote a culture of sharing, creativity, and innovation.
- Activities included shadowing, brainstorming sessions, coding, prototyping, and team building. These resulted in ideas generated, issues solved, and code deployed.
- A rubber duck was used as the hackathon mascot to represent debugging techniques. Homemade gadgets with the company logo were also produced.
- The hackathon scope was expanded to ensure knowledge sharing and collaboration by involving sales accounts throughout the process.
- The
This document provides guidance on delivering effective feedback in 3 sentences or less:
The document defines feedback as helpful information or criticism given to improve performance and outlines key components of effective feedback, including asking permission, being specific, kind, empathetic, and timely. It also recommends using a feedback equation of observing a behavior, describing its impact, and asking a question to make feedback actionable. The overall message is that feedback should be a two-way dialogue to understand different perspectives and help the recipient improve.
No Silver Bullet - Essence and Accident in Software EngineeringSalvatore Cordiano
Frederick P. Brooks, Jr.
University of North Carolina at Chapel Hill
There is no single development, in either technology or management
technique, which by itself promises even one order-of-magnitude
improvement within a decade in productivity, in reliability, in simplicity.
The document summarizes a recent hackathon held by Facile.it Partner from May 9-12, 2022. It discusses the vision for the hackathon as an opportunity for cross-functional teams to solve problems in a new way. The hackathon utilized a new format of separating the problem and solution spaces. It involved 30 participants across 5 cross-functional teams who worked to identify issues, present solutions, and code implementations. The "Doctor Shark" team won the competition with 61 points by identifying issues, giving pitches, participating in team-building, and implementing the most story points worth of solutions. The hackathon aimed to foster a mindset of continuous problem solving across teams.
The document summarizes an FP Hackathon that took place from 9-12 May 2022. It discusses improvements from the 2021 to 2022 event, including an increase in participants from 30 to 55 and the use of a Miro board instead of a wall board. The top three winning teams were announced, with Doctor Shark taking first place. The hackathon aimed to develop solutions to reduce inbound calls, increase autonomy, and improve user experience for collaborators.
Today we started our 2nd internal #hackathon, introducing new approaches to complexity dealing. We propose to adopt the "Manifesto for Slow Thinking", even if we are in a time-bound competition.
According to my perspective, a #SlowThinking mindset enables empathy, critical thinking, humbleness, feedback, and emotional intelligence.
Ownership is about taking the initiative to do the right thing. It’s about taking the bull by the horns, driving the process and not assuming it is someone else’s responsibility.
The Eisenhower Matrix is a time management tool based on strategies used by Dwight D. Eisenhower to prioritize tasks. It divides tasks into four quadrants based on their urgency and importance: tasks that are both urgent and important should be completed immediately; important non-urgent tasks can be scheduled; unimportant tasks should be avoided or delegated; and urgent but unimportant tasks can be delegated to others. The matrix provides a simple framework to evaluate tasks and determine the best way to manage workload and priorities.
The Blake Mouton Managerial Grid assesses leadership styles based on two dimensions: concern for people and concern for results. The grid defines five styles ranging from low concern in both areas ("Nightmare") to high concern in both ("Heaven"). Leaders are evaluated based on how they balance accomplishing tasks while considering employees' needs, interests, and development.
The document announces a hackathon being held by Facile.it on June 7th. It lists the company's core values such as easiness, courage, concreteness, passion, and relationship. It also lists shared principles for the hackathon such as being against standardization, connecting people, and ensuring programs meet user expectations rather than creator expectations. The document defines empathy and its four key attributes. It wishes attendees a happy hackathon.
1. Che cosa sono i microservizi?
di Salvatore Cordiano
Milano, 21/03/2015
Contesto
Dagli anni ‘90 il modello multistrato (multitier architecture) è stato considerato un pattern
architetturale fondamentale per costruire un sistema software. Secondo tale modello le varie
funzionalità software sono logicamente separate su più strati che comunicano tra di loro. Ogni
strato comunica con gli strati adiacenti in modo diretto richiedendo ed offrendo servizi. In
effetti in questa architettura il sistema software, sia pure se logicamente suddiviso in strati,
risulta essere un unico sistema monolitico.
L’avvento e la diffusione del cloud computing, le pratiche di continuous delivery, l’approccio
alla gestione della complessità del software basato sul DDD (DomainDriven Design),
l’organizzazione agile delle aziende in team di sviluppo piccoli ed autonomi (37 persone)
sono il contesto in cui è emerso il modello dell’architettura a microservizi.
Che cosa sono i microservizi?
In breve i microservizi sono dei servizi “piccoli” ed autonomi che interagiscono tra di loro e
che hanno come finalità quella di fare una cosa e di farla bene; sono a tutti gli effetti dei
sistemi distribuiti.
Per dare una definizione più precisa possiamo riprendere le parole di Martin Fowler che
afferma: ≪Lo stile architetturale a microservizi è un approccio allo sviluppo di una singola
applicazione come insieme di piccoli servizi, ciascuno dei quali viene eseguito da un proprio
processo e comunica con un meccanismo snello, spesso una HTTP API≫.
Ma quanto devono essere piccoli i microservizi?
Non è facile rispondere a questa domanda. Infatti non è possibile fornire una risposta, ad
esempio, in termini di numero di righe di codice che definiscono la giusta taglia: alcuni
linguaggi di programmazione sono più concisi di altri, riuscendo ad esprimere molto senza
essere verbosi, per non parlare poi di librerie e dipendenze o della complessità del dominio
del software in oggetto.
2.
Secondo Jon Eaves, famoso autore di testi del mondo Java, un microservizio deve essere
tale da poter essere riscritto in due settimane. Ovviamente va considerato che tale risposta ha
validità nel contesto lavorativo di Real Estate Australia dove Eaves lavora. In sostanza la
taglia corretta deve essere identificata in accordo alla struttura organizzativa aziendale.
Teniamo sempre in mente che man mano che la dimensione di un servizio decresce,
aumentano i benefici relativi all’indipendenza tra le parti, ma cresce anche la complessità di
gestire un numero elevato di parti.
Autonomia
Ogni microservizio è un’entità separata che viene generalmente pubblicata su una
piattaforma PaaS oppure eseguita da uno processo di sistema ad hoc.
La comunicazione tra i servizi avviene attraverso la rete al fine di garantire l’indipendenza tra i
servizi ed evitare ogni forma di accoppiamento.
Ogni microservizio si propone all’esterno come una blackbox, infatti espone solo un
Application Programming Interface (API), astraendo rispetto al dettaglio di come le
funzionalità sono implementate e dallo specifico linguaggio o tecnologia utilizzati. Ciò mira a
far si che il cambiamento di ciascun microservizio non abbia impatto sugli altri.
Vantaggi
L’utilizzo dell’architettura a microservizi ha indubbiamente dei vantaggi:
● Velocizzare i tempi di rilascio del software e reagire velocemente alle esigenze del
mercato
In generale, nell’architettura a microservizi, ogni singolo servizio è autonomo rispetto
agli altri, di coseguenza può raggiungere l’ambiente di produzione in modo
indipendente dagli altri, senza che tale attività abbia effetti drammatici sul resto del
sistema. Disporre di un processo di deployment snello e veloce consente di poter
aggiungere o modificare funzionalità di un sistema software in modo efficace ed
efficiente, rispondendo alle necessità di mercato e utenti sempre più esigenti.
● Sperimentare più facilmente nuove tecnologie
Molto spesso, la principale barriera per adottare una nuova tecnologia risiede nel
rischio associato all’utilizzo di qualcosa di nuovo e con il quale si ha poca esperienza.
3. Confinando questo rischio ad una piccola porzione di un sistema software, che è
possibile riscrivere in appena due settimane di lavoro, il rischio risulta molto contenuto
e quindi è una sfida da accettare.
● Migliori performance grazie all’utilizzo di tecnologie ad hoc
L’utilizzo di linguaggi e tecnologie eterogenee consente di poter utilizzare gli stack più
performanti per implementare specifiche funzionalità: ad esempio è possibile introdurre
una particolare tipologia di base dati che risulta naturale per mappare un determinato
dato, oppure eseguire un calcolo in un modo particolarmente efficiente.
● Resilienza
In un’architettura a microservizi, quando una componente non funziona non è
automatico che tutto il sistema software smetta di funzionare. In molti casi è possibile
isolare il problema ed intervenire mentre il resto del sistema continua a funzionare,
cosa non possibile in un’architettura monolitica. Va però sottolineato che l’architettura
a microservizi, essendo un insieme di sistemi distribuiti, espone ad una nuova fonte di
problemi legati ai disservizi di rete.
● Scalabilità
In generale risulta molto più semplice ed economico scalare un microservizio rispetto
ad un sistema software monolitico di grandi dimensioni. Il modello a microservizi
consente di poter effettuare provisioning delle parti del sistema software in modo
dinamico ed intelligente.
● Facilità di deployment
Modificare poche righe di codice su un sistema software monolitico di grandi
dimensioni ed effettuarne il deploy è generalmente un’attività non banale, che espone
a rischi significativi considerando anche l’impatto che tali modifiche possono avere.
Questa paura generalmente porta a raccogliere un certo numero di modifiche prima di
avviare un’attività così onerosa e rischiosa.
Con l’approccio a microservizi ogni singolo servizio può raggiungere l’ambiente di
produzione in modo indipendente, sicché se si verifica un problema esso è facilmente
isolato e possono essere intraprese azioni di rollback più velocemente.
● Componibilità
Tra le opportunità più interessanti dell’architettura a microservizi vi è la possibilità di
riusare le funzionalità. Infatti è possibile che una stesso servizio venga utilizzato in
modi differenti e per scopi diversi. Si pensi ad esempio ad un sistema software che
4. deve poter dialogare non solo col mondo web ma anche con applicazioni mobile e
dispositivi wearable, etc.
● Sostituibilità
Quando un sistema software è organizzato a microservizi, il costo di sostituire un
servizio con un altro più efficiente e migliore è limitato a circa due settimane di
sviluppo, così come banale è il costo di rimuovere un servizio inutile.
Svantaggi
Da quanto fin qui trattato, potrebbe sembrare che l’architettura a microservizi risulti essere la
manna dal cielo, non è così. Infatti non possiamo dimenticare di ribadire che utilizzare tanti
servizi che dialogano tra di loro attraverso la rete, vuol dire di fatto avere a che fare con un
sistema distribuito, con tutti i problemi dal caso.
Si pensi, ad esempio, a cosa vuol dire autenticare un utente su un’architettura distribuita
volendo garantire il single signon, oppure a come gestire la mutua autenticazione tra i servizi
che compongono il sistema software. E ancora: cosa vuol dire testare un sistema software di
questo tipo?
Infine, vengono fuori altre tematiche tipiche dei sistemi distribuiti come la gestione di
situazioni in cui è necessario che il sistema software sia in grado di riconfigurarsi al volo
quando una nuova istanza di un servizio viene creata e il resto della rete può
automaticamente trovare essa ed iniziare a comunicare con essa. Questo processo è
chiamato service discovery.
Bibliografia
● Appunti della CloudConf 2015 di Torino
● Building Microservices, Sam Newman, O’Relly
● Micro services, what even are they? Jon Eaves,
http://techblog.realestate.com.au/microserviceswhatevenarethey/
● Microservices, Martin Fowler, http://martinfowler.com/articles/microservices.html