Stateless all the thing, they say. In the last few years we’ve been brainwashed: design stateless systems, otherwise they cannot scale, they cannot be highly available, and they are hard to maintain and evolve. In a nutshell stateful is bad. However complex software systems need to do collaborative processing, that is stateful by definition. Stateless myth busted! Collaborative domains deal with long running business transactions and need to interact with distributed resources. The traditional distributed transactions approach, even if tempting, is a time bomb.
This is when Sagas come into play. Sagas allow to model complex collaborative domains without the need for distributed transactions and/or orchestration across multiple resources. Join Mauro on a journey that aims to disclose what sagas are, how they can be used to model a complex collaborative domain, and what role they play when it comes to designing systems with failure and eventual consistency in mind.
(It’s all right, I know where you’ve been)
Welcome to the (state) machine @ Xe One Day Enterprise ApplicationsMauro Servienti
Ultimamente ci hanno stressato come non mai che stateful è il male. Tutto deve essere stateless, altrimenti non scala, non può essere altamente disponibile, ed è complesso da manutenere ed evolvere. Nonostante questo i sistemi software complessi, essendo basati su processi collaborativi, sono per natura stateful. I processi collaborativi, noti anche come long running business transactions, necessitano di interagiscono con risorse distribuite. L’approccio tradizionale basato su transazioni distribuite, anche se allettante, è una bomba pronta ad esplodere.
Pane quotidiano per le Saghe. Le Saghe consentono di modellare sistemi complessi senza la necessità di transazioni distribuite e coordinamento esterno. Vedremo cosa sono le Saghe, come possono essere usate per modellare domini complessi, e che ruolo giocano quando progettiamo sistemi basati sui concetti di “design for failures” e “eventual consistency”
(It’s all right, I know where you’ve been)
Designing a ui for microservices @ .NET Day Switzerland 2019Mauro Servienti
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
All our aggregates are wrong @ NDC Copenhagen 2019Mauro Servienti
It always starts well. At first glance the requirements seem straightforward, and implementation proceeds without hiccups. Then the requirements start to get more complex, and you find yourself in a predicament, introducing technical shortcuts that smell for the sake of delivering the new feature on schedule.
In this talk, we’ll analyze what appears to be a straightforward e-commerce shopping cart. We’ll then go ahead and add a few more use-cases that make it more complex and see how it can negatively impact the overall design. Finally, we’ll focus our attention to the business needs of these requirements and see how it can shed light on the correct approach to designing the feature. Walk away with a new understanding on how to take requirements apart to build the right software.
Be like water, my friend @ Agile for Innovation 2019Mauro Servienti
L’acqua è quasi inarrestabile, basta un pertugio e si propaga. Basta un po’ di pressione e con facilità il pertugio diventa una voragine e lascia spazio ad una piena. La conoscenza e l’esperienza in un team possono essere come l’acqua. Il sapere deve poter scorrere senza freni, con solo degli argini che lo guidino al fine di evitare un’inondazione.
È possibile strutturare un’organizzazione al fine di garantire la diffusione del sapere? Quali sono i processi e gli strumenti che possiamo mettere in campo per essere certi che conoscenza ed esperienza siano diffuse, ma anche che non vi sia un’inondazione?
Lasciatevi trasportare da Mauro nei meandri di Particular Software, per scoprire come una realtà “dispersa” su 17 time zone gestisce collaborazione e condivisione del sapere. Analizzeremo sia i processi, che ci siamo creati, che gli strumenti digitali che usiamo quotidianamente.
Microservices architecture is it the right choice to design long-living syste...Mauro Servienti
Microservices all the thing! they say. Nowadays it seems that if architectures are not microservices based they are not worth the name. Is it really true? Do we really need a (micro)services based architecture?
We should design our systems with longevity, manutenability, and evolution simplicity in mind. Not hype. Long living systems are our primary goal. We'll analyze most common errors and we'll see how architecture can be a game changer in systems design.
Join Mauro in a journey that aims to disclose what it means to build a distributed system based on a (micro)services oriented architecture.
Titles, abstracts, and bio matter... oh my! @ Global Diversity CFP Day 2019Mauro Servienti
Sei uno studente che deve presentare una tesi? Un manager che deve presentare un report ai colleghi? Un esperto che deve presentare i risultati di uno studio ad una conferenza? O semplicemente avresti voglia di parlare al mondo di ciò che ti appassiona ma non sai da dove cominciare?
Living organizations, particular software @ do IT Better ParmaMauro Servienti
Siamo così abituati ad organizzazioni basate sul tradizionale organigramma che diamo per scontato che sia l'unica opzione.
Un approccio differente è possibile?
Quando sono entrato in Particular, era un'organizzazione tradizionale, sebbene distribuita. Avevamo manager e una gerarchia. Un anno dopo la decisione di rivoluzionare tutto. La miglior decisione di sempre. Intraprenderemo un viaggio che ci permetterà di scoprire che un modello organizzativo diverso è possibile, che un processo decisionale dall'alto verso il basso non è l'unica opzione e che possiamo organizzare la vita lavorativa intorno a quella privata in funzione di un ottimo life-work balance.
Welcome to the (state) machine @ Crafted SoftwareMauro Servienti
Stateless all the thing, they say. In the last few years we’ve been brainwashed: design stateless systems, otherwise they cannot scale, they cannot be highly available, and they are hard to maintain and evolve. In a nutshell stateful is bad. However complex software systems need to do collaborative processing, that is stateful by definition. Stateless myth busted! Collaborative domains deal with long business transactions and need to interact with distributed resources. The traditional distributed transactions approach, even if tempting, is a time bomb. This is when Sagas come into play. Sagas allow to model complex collaborative domains without the need for distributed transactions and/or orchestration across multiple resources. Join Mauro on a journey that aims to disclose what sagas are, how they can be used to model a complex collaborative domain, and what role they play when it comes to designing systems with failure and eventual consistency in mind. (It’s all right, I know we’re you’ve been)
Welcome to the (state) machine @ Xe One Day Enterprise ApplicationsMauro Servienti
Ultimamente ci hanno stressato come non mai che stateful è il male. Tutto deve essere stateless, altrimenti non scala, non può essere altamente disponibile, ed è complesso da manutenere ed evolvere. Nonostante questo i sistemi software complessi, essendo basati su processi collaborativi, sono per natura stateful. I processi collaborativi, noti anche come long running business transactions, necessitano di interagiscono con risorse distribuite. L’approccio tradizionale basato su transazioni distribuite, anche se allettante, è una bomba pronta ad esplodere.
Pane quotidiano per le Saghe. Le Saghe consentono di modellare sistemi complessi senza la necessità di transazioni distribuite e coordinamento esterno. Vedremo cosa sono le Saghe, come possono essere usate per modellare domini complessi, e che ruolo giocano quando progettiamo sistemi basati sui concetti di “design for failures” e “eventual consistency”
(It’s all right, I know where you’ve been)
Designing a ui for microservices @ .NET Day Switzerland 2019Mauro Servienti
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
All our aggregates are wrong @ NDC Copenhagen 2019Mauro Servienti
It always starts well. At first glance the requirements seem straightforward, and implementation proceeds without hiccups. Then the requirements start to get more complex, and you find yourself in a predicament, introducing technical shortcuts that smell for the sake of delivering the new feature on schedule.
In this talk, we’ll analyze what appears to be a straightforward e-commerce shopping cart. We’ll then go ahead and add a few more use-cases that make it more complex and see how it can negatively impact the overall design. Finally, we’ll focus our attention to the business needs of these requirements and see how it can shed light on the correct approach to designing the feature. Walk away with a new understanding on how to take requirements apart to build the right software.
Be like water, my friend @ Agile for Innovation 2019Mauro Servienti
L’acqua è quasi inarrestabile, basta un pertugio e si propaga. Basta un po’ di pressione e con facilità il pertugio diventa una voragine e lascia spazio ad una piena. La conoscenza e l’esperienza in un team possono essere come l’acqua. Il sapere deve poter scorrere senza freni, con solo degli argini che lo guidino al fine di evitare un’inondazione.
È possibile strutturare un’organizzazione al fine di garantire la diffusione del sapere? Quali sono i processi e gli strumenti che possiamo mettere in campo per essere certi che conoscenza ed esperienza siano diffuse, ma anche che non vi sia un’inondazione?
Lasciatevi trasportare da Mauro nei meandri di Particular Software, per scoprire come una realtà “dispersa” su 17 time zone gestisce collaborazione e condivisione del sapere. Analizzeremo sia i processi, che ci siamo creati, che gli strumenti digitali che usiamo quotidianamente.
Microservices architecture is it the right choice to design long-living syste...Mauro Servienti
Microservices all the thing! they say. Nowadays it seems that if architectures are not microservices based they are not worth the name. Is it really true? Do we really need a (micro)services based architecture?
We should design our systems with longevity, manutenability, and evolution simplicity in mind. Not hype. Long living systems are our primary goal. We'll analyze most common errors and we'll see how architecture can be a game changer in systems design.
Join Mauro in a journey that aims to disclose what it means to build a distributed system based on a (micro)services oriented architecture.
Titles, abstracts, and bio matter... oh my! @ Global Diversity CFP Day 2019Mauro Servienti
Sei uno studente che deve presentare una tesi? Un manager che deve presentare un report ai colleghi? Un esperto che deve presentare i risultati di uno studio ad una conferenza? O semplicemente avresti voglia di parlare al mondo di ciò che ti appassiona ma non sai da dove cominciare?
Living organizations, particular software @ do IT Better ParmaMauro Servienti
Siamo così abituati ad organizzazioni basate sul tradizionale organigramma che diamo per scontato che sia l'unica opzione.
Un approccio differente è possibile?
Quando sono entrato in Particular, era un'organizzazione tradizionale, sebbene distribuita. Avevamo manager e una gerarchia. Un anno dopo la decisione di rivoluzionare tutto. La miglior decisione di sempre. Intraprenderemo un viaggio che ci permetterà di scoprire che un modello organizzativo diverso è possibile, che un processo decisionale dall'alto verso il basso non è l'unica opzione e che possiamo organizzare la vita lavorativa intorno a quella privata in funzione di un ottimo life-work balance.
Welcome to the (state) machine @ Crafted SoftwareMauro Servienti
Stateless all the thing, they say. In the last few years we’ve been brainwashed: design stateless systems, otherwise they cannot scale, they cannot be highly available, and they are hard to maintain and evolve. In a nutshell stateful is bad. However complex software systems need to do collaborative processing, that is stateful by definition. Stateless myth busted! Collaborative domains deal with long business transactions and need to interact with distributed resources. The traditional distributed transactions approach, even if tempting, is a time bomb. This is when Sagas come into play. Sagas allow to model complex collaborative domains without the need for distributed transactions and/or orchestration across multiple resources. Join Mauro on a journey that aims to disclose what sagas are, how they can be used to model a complex collaborative domain, and what role they play when it comes to designing systems with failure and eventual consistency in mind. (It’s all right, I know we’re you’ve been)
PO is dead, long live the PO - Italian Agile Day 2018Mauro Servienti
Cosa succederebbe se i prodotti non fossero gestiti dai manager? O addirittura, cosa se i manager non ci fossero proprio? Chi si prenderebbe la responsabilità di definire la priorità nel backlog? In Particular Software non c’è una struttura gerarchica. La gestione dei prodotti, intesa come vera e propria product ownership, è responsabilità di tutti. Sembra quasi che gli internati siano anche i gestori del manicomio. Non è proprio distante dalla realtà. Oggigiorno sempre più aziende si stanno orientando verso strutture organizzative fluide. Che cosa si può fare per abilitare chiunque a prendere decisioni a qualsiasi livello? C’è un modo per condividere il processo decisionale? Guarderemo come è strutturata Particular Software al fine di abilitare tutto ciò. Analizzeremo come vengono risolti i problemi e quali processi e strumenti utilizziamo per prendere decisioni. Tutto senza infermieri, ooops, senza manager.
Design a UI for your Microservices @ Do IT BetterMauro Servienti
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Microservices and pineapple on pizza what do they have in common - dos and ...Mauro Servienti
Microservices è una delle buzzword del momento. Sembra quasi che un'architettura a microservices sia fondamentale. È veramente così? Faremo un tortuoso viaggio tra le buzzword del momento cercando di districarci tra cosa è bene e cosa è meno bene, ma soprattutto perché. Obiettivo è quello di comprendere quali sono i limiti di certe scelte architetturali e quali gli errori da non commettere. Il tutto nell'ottica di garantire ai nostri sistemi 'lunga vita e prosperità' (cit.)
All our aggregates are wrong (ExploreDDD 2018)Mauro Servienti
It always starts well. At first glance the requirements seem straightforward, and implementation proceeds without hiccups. Then the requirements start to get more complex, and you find yourself in a predicament, introducing technical shortcuts that smell for the sake of delivering the new feature on schedule. In this talk, we'll analyze what appears to be a straightforward e-commerce shopping cart. We'll then go ahead and add a few more use-cases that make it more complex and see how it can negatively impact the overall design. Finally, we'll focus our attention to the business needs of these requirements and see how it can shed light on the correct approach to designing the feature. Walk away with a new understanding on how to take requirements apart to build the right software.
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Cosa succederebbe se i prodotti non fossero gestiti dai manager? O addirittura, cosa se i manager non ci fossero proprio? Chi si prenderebbe la responsabilità di definire la priorità nel backlog? In Particular Software non c’è una struttura gerarchica. La gestione dei prodotti, intesa come vera e propria product ownership, è responsabilità di tutti. Sembra quasi che gli internati siano anche i gestori del manicomio. Non è proprio distante dalla realtà. Oggigiorno sempre più aziende si stanno orientando verso strutture organizzative fluide. Che cosa si può fare per abilitare chiunque a prendere decisioni a qualsiasi livello? C’è un modo per condividere il processo decisionale? Guarderemo come è strutturata Particular Software al fine di abilitare tutto ciò. Analizzeremo come vengono risolti i problemi e quali processi e strumenti utilizziamo per prendere decisioni. Tutto senza infermieri, ooops, senza manager.
Shipping code is not the problem, deciding what to ship it is!Mauro Servienti
This document discusses an organization's approach to prioritizing work and developing software. It emphasizes focusing on solving clear problems rather than executing on estimates or deadlines. Work is organized into buckets or strategies, each with a dedicated squad prioritizing issues. Issues go through an intake process to clearly define the problem before being selected for a cross-functional task force to implement a solution. The goal is for squads to proactively address problems rather than reactively execute work.
GraphQL - Where are you from? Where are you going?Mauro Servienti
GraphQL, inventato da Facebook per risolvere un problema molto specifico, è diventato uno standard. Le applicazioni client lo utilizzano per leggere e manipolare i dati esposti dai server back-end. È così flessibile che recentemente GitHub l'ha adottata per tutte le sue API. Il paradigma è semplice e tuttavia potente tale da consentire la manipolazione flessibile e la loro composizione da molte fonti diverse. Mauro offre in questo intervento un'introduzione a GraphQL, partendo da una breve storia e poi analizzando come GraphQL risolva i tipici problemi in cui i progettisti API e i loro consumer si possono imbattere.
Dall'idea al deploy un lungo viaggio che passa per git flow e semverMauro Servienti
Parliamo tanto di DevOps e ci concentriamo sui tool senza soffermarci a pensare che DevOps è principalmente una metodologia. Lo scopo è rendere l'intera filiera il più fluida e lineare possibile, rimuovendo impedimenti e cercando di prevenire e anticipare problemi.
Possiamo costruire tutto il processo di sviluppo, partendo dai vagiti iniziali del backlog per finire che il deploy fisico in ottica DevOps? Il processo ha impatto sulle scelte tecniche? Pratiche come SemVer e GitFlow hanno invece un impatto sul backlog?
Analizzeremo l'intero processo di sviluppo di Particular Software, dalla gestione del backlog al deploy automatico in produzione, con lo scopo di evidenziare come pratiche che sembrano disconnesse abbiano invece impatto su tutta la filiera.
This document discusses different approaches to designing a user interface for a microservices architecture. It begins by proposing a domain model decomposition with individual services owning pieces of product data. However, this poses issues for users who need an aggregated view. An alternative presented is to have individual services cache normalized data and compose a view model at the edge. Later approaches incorporate client-side messaging, hosting the composition engine in MVC, and using view components to give services more ownership over vertical slices of the UI. The key takeaways are that the UI structure can be defined at the edge while still keeping domain responsibilities clear across services.
The road to a Service Oriented Architecture is paved with messagesMauro Servienti
One of the options on the table when implementing a Service Oriented Architecture (SOA), or the communication style across multiple microservices, is based on messages and a service bus. This talk will drive you through the basic SOA building blocks, introduce message based architectures, and will connect the dots between technology and architectural principles through some samples using NServiceBus.
The document discusses how a service-oriented architecture is built on a message-based infrastructure and outlines some of the benefits of using messaging patterns between services rather than direct integration. Messages allow for loose coupling between services, autonomous components that respect boundaries, and easy scalability through asynchronous communication and competing consumers. Transaction handling becomes simpler with messages since each operation is independent rather than spanning multiple systems.
How we daily manage and work in a dispersed company: Particular SoftwareMauro Servienti
Working in Particular Software is awesome and challenging at the same time, working in what we call a "dispersed" company can introduce a lot of friction in your daily job. This session aims to disclose how we work internally, how we manage daily tasks, how we manage communication and long term goals in a company were nearly no one works in the same city as anyone else and were most of us are alone in their countries. Not to mention all the time zones issues on top.
Lavoro da remoto, come Solution Architect, per Particular Software; Il lavoro da remoto è fantastico, porta tanta autonomia nella mia vita quotidiana, il problema è che più il team dispersed cresce più la frizione quotidiana aumenta. Obiettivo di questa sessione è rivelare come lavoriamo internamente in Particular Software, come gestiamo la quotidianità, la comunicazione e gli obiettivi di lungo periodo in un'azienda i cui dipendenti sono dispersi su 17 time zone.
DevOps e scelte architetturali: tre scenari realiMauro Servienti
DevOps è principalmente cultura aziendale e di team, DevOps è una nuova visione in cui alcune di quelle che sono le barriere tra mondo dello sviluppo e mondo operations vengono abbattute al fine di generare sinergie inimmaginabili prima. Vorrei raccontare due esperienze vissute in due scenari molto diversi tra loro, due scenari in cui DevOps è stato da un lato il traguardo di un processo evolutivo dal monolite ingestibile a SOA/Microservices e dell'altro invece DevOps è stato il motivo scatenante finalizzato a superare tutta una serie di ostacoli amministrativi e burocratici che rendevano impossibile il deploy in produzione.
Lavoro da remoto, come Solution Architect, per Particular Software; Il lavoro da remoto è fantastico, porta tanta autonomia nella mia vita quotidiana, il problema è che più il team dispersed cresce più la frizione quotidiana aumenta. Obiettivo di questa sessione è rivelare come lavoriamo internamente in Particular Software, come gestiamo la quotidianità, la comunicazione e gli obiettivi di lungo periodo in un'azienda i cui dipendenti sono dispersi su 17 time zone.
Lavoro da remoto, come Solution Architect, per Particular Software; Il lavoro da remoto è fantastico, porta tanta autonomia nella mia vita quotidiana, il problema è che più il team dispersed cresce più la frizione quotidiana aumenta. Obiettivo di questa sessione è rivelare come lavoriamo internamente in Particular Software, come gestiamo la quotidianità, la comunicazione e gli obiettivi di lungo periodo in un'azienda i cui dipendenti sono dispersi su 17 time zone.
In molti scenari Pub/Sub è un approccio vincente anche quando lo caliamo in uno scenario di front-end basato su un pattern chiamato Composite UI; Partiremo con una breve introduzione a Pub/Sub e ai concetti base di SOA per poi buttarci in un'applicazione di esempio al fine di comprendere come applicare questi concetti a una SPA con AngularJs, vedremo che AngularJs non è un requisito e analizzeremo pro e contro di tale approccio dal punto di vista dello sviluppo, del mantenimento e del deploy.
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Superpower Your Apache Kafka Applications Development with Complementary Open...Paul Brebner
Kafka Summit talk (Bangalore, India, May 2, 2024, https://events.bizzabo.com/573863/agenda/session/1300469 )
Many Apache Kafka use cases take advantage of Kafka’s ability to integrate multiple heterogeneous systems for stream processing and real-time machine learning scenarios. But Kafka also exists in a rich ecosystem of related but complementary stream processing technologies and tools, particularly from the open-source community. In this talk, we’ll take you on a tour of a selection of complementary tools that can make Kafka even more powerful. We’ll focus on tools for stream processing and querying, streaming machine learning, stream visibility and observation, stream meta-data, stream visualisation, stream development including testing and the use of Generative AI and LLMs, and stream performance and scalability. By the end you will have a good idea of the types of Kafka “superhero” tools that exist, which are my favourites (and what superpowers they have), and how they combine to save your Kafka applications development universe from swamploads of data stagnation monsters!
In this infographic, we have explored cost-effective strategies for iOS app development, focusing on building high-quality apps within a budget. Key points covered include prioritizing essential features, leveraging existing tools and libraries, adopting cross-platform development approaches, optimizing for a Minimum Viable Product (MVP), and integrating with cloud services and third-party APIs. By implementing these strategies, businesses and developers can create functional and engaging iOS apps while minimizing development costs and time-to-market.
PO is dead, long live the PO - Italian Agile Day 2018Mauro Servienti
Cosa succederebbe se i prodotti non fossero gestiti dai manager? O addirittura, cosa se i manager non ci fossero proprio? Chi si prenderebbe la responsabilità di definire la priorità nel backlog? In Particular Software non c’è una struttura gerarchica. La gestione dei prodotti, intesa come vera e propria product ownership, è responsabilità di tutti. Sembra quasi che gli internati siano anche i gestori del manicomio. Non è proprio distante dalla realtà. Oggigiorno sempre più aziende si stanno orientando verso strutture organizzative fluide. Che cosa si può fare per abilitare chiunque a prendere decisioni a qualsiasi livello? C’è un modo per condividere il processo decisionale? Guarderemo come è strutturata Particular Software al fine di abilitare tutto ciò. Analizzeremo come vengono risolti i problemi e quali processi e strumenti utilizziamo per prendere decisioni. Tutto senza infermieri, ooops, senza manager.
Design a UI for your Microservices @ Do IT BetterMauro Servienti
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Microservices and pineapple on pizza what do they have in common - dos and ...Mauro Servienti
Microservices è una delle buzzword del momento. Sembra quasi che un'architettura a microservices sia fondamentale. È veramente così? Faremo un tortuoso viaggio tra le buzzword del momento cercando di districarci tra cosa è bene e cosa è meno bene, ma soprattutto perché. Obiettivo è quello di comprendere quali sono i limiti di certe scelte architetturali e quali gli errori da non commettere. Il tutto nell'ottica di garantire ai nostri sistemi 'lunga vita e prosperità' (cit.)
All our aggregates are wrong (ExploreDDD 2018)Mauro Servienti
It always starts well. At first glance the requirements seem straightforward, and implementation proceeds without hiccups. Then the requirements start to get more complex, and you find yourself in a predicament, introducing technical shortcuts that smell for the sake of delivering the new feature on schedule. In this talk, we'll analyze what appears to be a straightforward e-commerce shopping cart. We'll then go ahead and add a few more use-cases that make it more complex and see how it can negatively impact the overall design. Finally, we'll focus our attention to the business needs of these requirements and see how it can shed light on the correct approach to designing the feature. Walk away with a new understanding on how to take requirements apart to build the right software.
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Cosa succederebbe se i prodotti non fossero gestiti dai manager? O addirittura, cosa se i manager non ci fossero proprio? Chi si prenderebbe la responsabilità di definire la priorità nel backlog? In Particular Software non c’è una struttura gerarchica. La gestione dei prodotti, intesa come vera e propria product ownership, è responsabilità di tutti. Sembra quasi che gli internati siano anche i gestori del manicomio. Non è proprio distante dalla realtà. Oggigiorno sempre più aziende si stanno orientando verso strutture organizzative fluide. Che cosa si può fare per abilitare chiunque a prendere decisioni a qualsiasi livello? C’è un modo per condividere il processo decisionale? Guarderemo come è strutturata Particular Software al fine di abilitare tutto ciò. Analizzeremo come vengono risolti i problemi e quali processi e strumenti utilizziamo per prendere decisioni. Tutto senza infermieri, ooops, senza manager.
Shipping code is not the problem, deciding what to ship it is!Mauro Servienti
This document discusses an organization's approach to prioritizing work and developing software. It emphasizes focusing on solving clear problems rather than executing on estimates or deadlines. Work is organized into buckets or strategies, each with a dedicated squad prioritizing issues. Issues go through an intake process to clearly define the problem before being selected for a cross-functional task force to implement a solution. The goal is for squads to proactively address problems rather than reactively execute work.
GraphQL - Where are you from? Where are you going?Mauro Servienti
GraphQL, inventato da Facebook per risolvere un problema molto specifico, è diventato uno standard. Le applicazioni client lo utilizzano per leggere e manipolare i dati esposti dai server back-end. È così flessibile che recentemente GitHub l'ha adottata per tutte le sue API. Il paradigma è semplice e tuttavia potente tale da consentire la manipolazione flessibile e la loro composizione da molte fonti diverse. Mauro offre in questo intervento un'introduzione a GraphQL, partendo da una breve storia e poi analizzando come GraphQL risolva i tipici problemi in cui i progettisti API e i loro consumer si possono imbattere.
Dall'idea al deploy un lungo viaggio che passa per git flow e semverMauro Servienti
Parliamo tanto di DevOps e ci concentriamo sui tool senza soffermarci a pensare che DevOps è principalmente una metodologia. Lo scopo è rendere l'intera filiera il più fluida e lineare possibile, rimuovendo impedimenti e cercando di prevenire e anticipare problemi.
Possiamo costruire tutto il processo di sviluppo, partendo dai vagiti iniziali del backlog per finire che il deploy fisico in ottica DevOps? Il processo ha impatto sulle scelte tecniche? Pratiche come SemVer e GitFlow hanno invece un impatto sul backlog?
Analizzeremo l'intero processo di sviluppo di Particular Software, dalla gestione del backlog al deploy automatico in produzione, con lo scopo di evidenziare come pratiche che sembrano disconnesse abbiano invece impatto su tutta la filiera.
This document discusses different approaches to designing a user interface for a microservices architecture. It begins by proposing a domain model decomposition with individual services owning pieces of product data. However, this poses issues for users who need an aggregated view. An alternative presented is to have individual services cache normalized data and compose a view model at the edge. Later approaches incorporate client-side messaging, hosting the composition engine in MVC, and using view components to give services more ownership over vertical slices of the UI. The key takeaways are that the UI structure can be defined at the edge while still keeping domain responsibilities clear across services.
The road to a Service Oriented Architecture is paved with messagesMauro Servienti
One of the options on the table when implementing a Service Oriented Architecture (SOA), or the communication style across multiple microservices, is based on messages and a service bus. This talk will drive you through the basic SOA building blocks, introduce message based architectures, and will connect the dots between technology and architectural principles through some samples using NServiceBus.
The document discusses how a service-oriented architecture is built on a message-based infrastructure and outlines some of the benefits of using messaging patterns between services rather than direct integration. Messages allow for loose coupling between services, autonomous components that respect boundaries, and easy scalability through asynchronous communication and competing consumers. Transaction handling becomes simpler with messages since each operation is independent rather than spanning multiple systems.
How we daily manage and work in a dispersed company: Particular SoftwareMauro Servienti
Working in Particular Software is awesome and challenging at the same time, working in what we call a "dispersed" company can introduce a lot of friction in your daily job. This session aims to disclose how we work internally, how we manage daily tasks, how we manage communication and long term goals in a company were nearly no one works in the same city as anyone else and were most of us are alone in their countries. Not to mention all the time zones issues on top.
Lavoro da remoto, come Solution Architect, per Particular Software; Il lavoro da remoto è fantastico, porta tanta autonomia nella mia vita quotidiana, il problema è che più il team dispersed cresce più la frizione quotidiana aumenta. Obiettivo di questa sessione è rivelare come lavoriamo internamente in Particular Software, come gestiamo la quotidianità, la comunicazione e gli obiettivi di lungo periodo in un'azienda i cui dipendenti sono dispersi su 17 time zone.
DevOps e scelte architetturali: tre scenari realiMauro Servienti
DevOps è principalmente cultura aziendale e di team, DevOps è una nuova visione in cui alcune di quelle che sono le barriere tra mondo dello sviluppo e mondo operations vengono abbattute al fine di generare sinergie inimmaginabili prima. Vorrei raccontare due esperienze vissute in due scenari molto diversi tra loro, due scenari in cui DevOps è stato da un lato il traguardo di un processo evolutivo dal monolite ingestibile a SOA/Microservices e dell'altro invece DevOps è stato il motivo scatenante finalizzato a superare tutta una serie di ostacoli amministrativi e burocratici che rendevano impossibile il deploy in produzione.
Lavoro da remoto, come Solution Architect, per Particular Software; Il lavoro da remoto è fantastico, porta tanta autonomia nella mia vita quotidiana, il problema è che più il team dispersed cresce più la frizione quotidiana aumenta. Obiettivo di questa sessione è rivelare come lavoriamo internamente in Particular Software, come gestiamo la quotidianità, la comunicazione e gli obiettivi di lungo periodo in un'azienda i cui dipendenti sono dispersi su 17 time zone.
Lavoro da remoto, come Solution Architect, per Particular Software; Il lavoro da remoto è fantastico, porta tanta autonomia nella mia vita quotidiana, il problema è che più il team dispersed cresce più la frizione quotidiana aumenta. Obiettivo di questa sessione è rivelare come lavoriamo internamente in Particular Software, come gestiamo la quotidianità, la comunicazione e gli obiettivi di lungo periodo in un'azienda i cui dipendenti sono dispersi su 17 time zone.
In molti scenari Pub/Sub è un approccio vincente anche quando lo caliamo in uno scenario di front-end basato su un pattern chiamato Composite UI; Partiremo con una breve introduzione a Pub/Sub e ai concetti base di SOA per poi buttarci in un'applicazione di esempio al fine di comprendere come applicare questi concetti a una SPA con AngularJs, vedremo che AngularJs non è un requisito e analizzeremo pro e contro di tale approccio dal punto di vista dello sviluppo, del mantenimento e del deploy.
How do we design a UI when the back-end system consists of dozens (or more) microservices? We have separation and autonomy on the back end, but on the front end this all needs to come back together. How do we stop it from turning into a mess of spaghetti code? How do we prevent simple actions from causing an inefficient torrent of web requests? Join Mauro in building a Composite UI for Microservices from scratch, using .NET Core. Walk away with a clear understanding of what Services UI Composition is and how you can architect front end to be Microservices ready.
Superpower Your Apache Kafka Applications Development with Complementary Open...Paul Brebner
Kafka Summit talk (Bangalore, India, May 2, 2024, https://events.bizzabo.com/573863/agenda/session/1300469 )
Many Apache Kafka use cases take advantage of Kafka’s ability to integrate multiple heterogeneous systems for stream processing and real-time machine learning scenarios. But Kafka also exists in a rich ecosystem of related but complementary stream processing technologies and tools, particularly from the open-source community. In this talk, we’ll take you on a tour of a selection of complementary tools that can make Kafka even more powerful. We’ll focus on tools for stream processing and querying, streaming machine learning, stream visibility and observation, stream meta-data, stream visualisation, stream development including testing and the use of Generative AI and LLMs, and stream performance and scalability. By the end you will have a good idea of the types of Kafka “superhero” tools that exist, which are my favourites (and what superpowers they have), and how they combine to save your Kafka applications development universe from swamploads of data stagnation monsters!
In this infographic, we have explored cost-effective strategies for iOS app development, focusing on building high-quality apps within a budget. Key points covered include prioritizing essential features, leveraging existing tools and libraries, adopting cross-platform development approaches, optimizing for a Minimum Viable Product (MVP), and integrating with cloud services and third-party APIs. By implementing these strategies, businesses and developers can create functional and engaging iOS apps while minimizing development costs and time-to-market.
Secure-by-Design Using Hardware and Software Protection for FDA ComplianceICS
This webinar explores the “secure-by-design” approach to medical device software development. During this important session, we will outline which security measures should be considered for compliance, identify technical solutions available on various hardware platforms, summarize hardware protection methods you should consider when building in security and review security software such as Trusted Execution Environments for secure storage of keys and data, and Intrusion Detection Protection Systems to monitor for threats.
Baha Majid WCA4Z IBM Z Customer Council Boston June 2024.pdfBaha Majid
IBM watsonx Code Assistant for Z, our latest Generative AI-assisted mainframe application modernization solution. Mainframe (IBM Z) application modernization is a topic that every mainframe client is addressing to various degrees today, driven largely from digital transformation. With generative AI comes the opportunity to reimagine the mainframe application modernization experience. Infusing generative AI will enable speed and trust, help de-risk, and lower total costs associated with heavy-lifting application modernization initiatives. This document provides an overview of the IBM watsonx Code Assistant for Z which uses the power of generative AI to make it easier for developers to selectively modernize COBOL business services while maintaining mainframe qualities of service.
How GenAI Can Improve Supplier Performance Management.pdfZycus
Data Collection and Analysis with GenAI enables organizations to gather, analyze, and visualize vast amounts of supplier data, identifying key performance indicators and trends. Predictive analytics forecast future supplier performance, mitigating risks and seizing opportunities. Supplier segmentation allows for tailored management strategies, optimizing resource allocation. Automated scorecards and reporting provide real-time insights, enhancing transparency and tracking progress. Collaboration is fostered through GenAI-powered platforms, driving continuous improvement. NLP analyzes unstructured feedback, uncovering deeper insights into supplier relationships. Simulation and scenario planning tools anticipate supply chain disruptions, supporting informed decision-making. Integration with existing systems enhances data accuracy and consistency. McKinsey estimates GenAI could deliver $2.6 trillion to $4.4 trillion in economic benefits annually across industries, revolutionizing procurement processes and delivering significant ROI.
Alluxio Webinar | 10x Faster Trino Queries on Your Data PlatformAlluxio, Inc.
Alluxio Webinar
June. 18, 2024
For more Alluxio Events: https://www.alluxio.io/events/
Speaker:
- Jianjian Xie (Staff Software Engineer, Alluxio)
As Trino users increasingly rely on cloud object storage for retrieving data, speed and cloud cost have become major challenges. The separation of compute and storage creates latency challenges when querying datasets; scanning data between storage and compute tiers becomes I/O bound. On the other hand, cloud API costs related to GET/LIST operations and cross-region data transfer add up quickly.
The newly introduced Trino file system cache by Alluxio aims to overcome the above challenges. In this session, Jianjian will dive into Trino data caching strategies, the latest test results, and discuss the multi-level caching architecture. This architecture makes Trino 10x faster for data lakes of any scale, from GB to EB.
What you will learn:
- Challenges relating to the speed and costs of running Trino in the cloud
- The new Trino file system cache feature overview, including the latest development status and test results
- A multi-level cache framework for maximized speed, including Trino file system cache and Alluxio distributed cache
- Real-world cases, including a large online payment firm and a top ridesharing company
- The future roadmap of Trino file system cache and Trino-Alluxio integration
The Comprehensive Guide to Validating Audio-Visual Performances.pdfkalichargn70th171
Ensuring the optimal performance of your audio-visual (AV) equipment is crucial for delivering exceptional experiences. AV performance validation is a critical process that verifies the quality and functionality of your AV setup. Whether you're a content creator, a business conducting webinars, or a homeowner creating a home theater, validating your AV performance is essential.
14 th Edition of International conference on computer visionShulagnaSarkar2
About the event
14th Edition of International conference on computer vision
Computer conferences organized by ScienceFather group. ScienceFather takes the privilege to invite speakers participants students delegates and exhibitors from across the globe to its International Conference on computer conferences to be held in the Various Beautiful cites of the world. computer conferences are a discussion of common Inventions-related issues and additionally trade information share proof thoughts and insight into advanced developments in the science inventions service system. New technology may create many materials and devices with a vast range of applications such as in Science medicine electronics biomaterials energy production and consumer products.
Nomination are Open!! Don't Miss it
Visit: computer.scifat.com
Award Nomination: https://x-i.me/ishnom
Conference Submission: https://x-i.me/anicon
For Enquiry: Computer@scifat.com
Mobile App Development Company In Noida | Drona InfotechDrona Infotech
React.js, a JavaScript library developed by Facebook, has gained immense popularity for building user interfaces, especially for single-page applications. Over the years, React has evolved and expanded its capabilities, becoming a preferred choice for mobile app development. This article will explore why React.js is an excellent choice for the Best Mobile App development company in Noida.
Visit Us For Information: https://www.linkedin.com/pulse/what-makes-reactjs-stand-out-mobile-app-development-rajesh-rai-pihvf/
A Comprehensive Guide on Implementing Real-World Mobile Testing Strategies fo...kalichargn70th171
In today's fiercely competitive mobile app market, the role of the QA team is pivotal for continuous improvement and sustained success. Effective testing strategies are essential to navigate the challenges confidently and precisely. Ensuring the perfection of mobile apps before they reach end-users requires thoughtful decisions in the testing plan.
Penify - Let AI do the Documentation, you write the Code.KrishnaveniMohan1
Penify automates the software documentation process for Git repositories. Every time a code modification is merged into "main", Penify uses a Large Language Model to generate documentation for the updated code. This automation covers multiple documentation layers, including InCode Documentation, API Documentation, Architectural Documentation, and PR documentation, each designed to improve different aspects of the development process. By taking over the entire documentation process, Penify tackles the common problem of documentation becoming outdated as the code evolves.
https://www.penify.dev/
The Rising Future of CPaaS in the Middle East 2024Yara Milbes
Explore "The Rising Future of CPaaS in the Middle East in 2024" with this comprehensive PPT presentation. Discover how Communication Platforms as a Service (CPaaS) is transforming communication across various sectors in the Middle East.
Software Test Automation - A Comprehensive Guide on Automated Testing.pdfkalichargn70th171
Moving to a more digitally focused era, the importance of software is rapidly increasing. Software tools are crucial for upgrading life standards, enhancing business prospects, and making a smart world. The smooth and fail-proof functioning of the software is very critical, as a large number of people are dependent on them.
What is Continuous Testing in DevOps - A Definitive Guide.pdfkalichargn70th171
Once an overlooked aspect, continuous testing has become indispensable for enterprises striving to accelerate application delivery and reduce business impacts. According to a Statista report, 31.3% of global enterprises have embraced continuous integration and deployment within their DevOps, signaling a pervasive trend toward hastening release cycles.
14. Process Managers (a different point of view)
New requirement: collect tickets at the venue
OrderId ShippingId ShippingStatus Etc
12 1337 Delivered …
58 1338 Pending …
Orders table
mauroservienti
17. Process Managers, a retrospective.
•Violate Single Responsibility Principle
•Single Unit of Deployment
•Conflicting Changes/Merge Conflicts
•Contention/Performance Bottleneck
mauroservienti
33. Order Created Payment Succeeded
NY
Batch Shipping
at the Venue
Policy
Store for Venue
Delivery
Mark as Complete
Courier
Gateway
Batch Delivery Pick-up
Courier
Gateway
Delivery Pick-up
Deliver Tickets
Mark as Complete
mauroservienti
Shipping Policy
Shipping Policy
Delivery-Mode:
- Collect-at-the-Venue
- Ship-at-Home
?
Is Collect-at-the-Venue?
34. Order Created Payment Succeeded
NY
Store for Venue
Delivery
Mark as Complete
Courier
Gateway
Delivery Pick-up
Deliver Tickets
Mark as Complete
mauroservienti
Shipping Policy
Shipping Policy
Delivery-Mode:
- Collect-at-the-Venue
- Ship-at-Home
?
Is Collect-at-the-Venue?
Batch Shipping
at the Venue
Policy
Courier
Gateway
Batch Delivery Pick-up
Mark as Complete
43. Sagas (a different point of view)
OrderId ShippingId ShippingStatus Etc
12 1337 Delivered …
58 1338 Pending …
Orders table
Reservation Shipping Finance
OrderId TicketId
12 ABC
58 ACD
Reservations table
OrderId Address
12 Milan, Italy
58 Paris, France
Shipping table
OrderId Status
12 Paid
58 Overdue
Invoices table
VS
mauroservienti
44. Sagas (a different point of view)
Reservation Shipping Finance
Reservations table
OrderId Address
12 Milan, Italy
58 Paris, France
Shipping table
OrderId Status
12 Paid
58 Overdue
Invoices table
mauroservienti
Each service can evolve independently
OrderId TicketId
12 ABC
58 ACD
45. Sagas
•Business Process is distributed
•Respect Single Responsibility Principle
•Simpler/not conflicting evolution
•Independent Units of Deployment
•Independent scale out
mauroservienti
46. Every year is getting shorter
never seem to find the time…
Sagas Demo
bit.ly/eddd-state-machine
Udi Dahan about Sagas
go.particular.net/eddd-state-machine
mauroservienti