This slide deck basically tries to address functional service design not only from a maintainability point of view, but also form an operational point of view. How to spread your business functionality across your service landscape to maximize availability and responsiveness?
It starts with the observation that virtually all system landscapes these days, including cloud-native, are distributed systems. Due to the failure modes of distributed systems every remote communication basically is a predetermined breaking point of your system.
After briefly discussing other options to increase availability and responsiveness the biggest part of the deck discusses the question how a good functional design can positively influence the aforementioned system properties.
Using a very simple eCommerce application as an example, first a typical design is shown and why it is suboptimal in terms of availability and responsiveness. After that, we briefly dive into classical CS papers and see what we can learn from them. We also learn that while the core insights of those papers are mostly timeless, their implementation instructions are not and that we need to update them to our current context.
Then we use the learnt ideas to derive a different functional decomposition approach starting with the system behavior and apply it to our example - which leads to a lot better system behavior in terms of availability and responsiveness. Finally we discuss the most important trade-offs of the different design approach - as every design decision of course also has its downsides ... ;)
As always, the voice track is missing (but afaik there will be a recording released from KanDDDinsky 2018). Still, I hope the slides on their own also offer you a few valuable ideas.
This slide deck addresses the importance of proper functional design for creating resilient distributed systems (not only, but also microservice-based systems).
It starts by explaining the pitfall that many developers fall into when getting started with resilience: Quite often the effects of the fundamentals, i.e., creating bulkheads and choosing the communication paradigm, on system robustness at runtime are heavily underrated. Instead, the pure technical measures like circuit breakers, backpressure, etc. are often overestimated.
Unfortunately, all technical measures will not help to create a robust system if the functional design leads to highly coupled services where the availability of one service functionally totally depends on the availability of another service. The same is true if you need to call many services that all need to be available to answer a client request.
To make it worse, most of the wide-spread design approaches like functional decomposition, DRY (don't repeat yourself), design for re-use or layered architecture exactly lead to those problems, i.e., they are not suitable for designing distributed systems.
This slide deck does not offer any silver bullets to solve the problem (and actually I believe there is no silver bullet), but at least a few guiding principles. Additionally, it shows how the choice of the communication paradigm influences the bulkhead design and this way creates more options to create a good service design that also supports resiliency on a functional level.
As always this slide deck is without the voice track, i.e., most of the information is missing. But I hope that the slides on their own also provide some helpful hints.
Remark: As the "dismiss reusability" slide tends to get quite some attention, one more remark about that slide: On the voice track I usually add "If you find something that is worth being made reusable, i.e., that it satisfies the commercial constraints of Fred Brooks 'Rule of 9' (see https://blog.codecentric.de/en/2015/10/the-broken-promise-of-re-use/ for details), do not put it in a service. Instead create a library and put the functionality in there. And make sure that changes to the library do not mean that all users have to upgrade at the same time, but that any library user can update whenever it fits the user's schedule. Otherwise, you would have introduced tight coupling through the back door again."
In this slide deck, I first describe what resilience is, what it is about, why it is important and how it is different from traditional stability approaches.
After that introductory part the main part is a "small" pattern language which is organized around isolation, the typical starting point of resilient software design. I used quotation marks for "small" as even this subset of a complete resilience pattern language still consists of around 20 patterns.
All the patterns are briefly described and for some of the patterns I added a bit of detail, but as this is a slide deck, the voice track - as usual - is missing. Also this pattern language is still sort of work in progress, i.e., it has not yet settled and some details are still missing. Yet I think (or at least hope), that the slides might contain a few useful insights for you.
This is basically a "lessons learned" talk. While dealing with resilient software design for several years meanwhile, I realized along the way that implementing a specific pattern like timeout detection, circuit breaker, back-pressure, etc. is the smallest of the challenges.
As so often in software development, the actual pitfalls that keep you from being successful with your project - here, creating a robust application - are not to be found in the area of creating code. Based on my experiences, the actual pitfalls are to be found in areas that are at best loosely related to resilient software design.
In this talk, I discuss some of those pitfalls that I have experienced more than once along my way. It starts with not understanding the goals of resilient software design, continues from a lack of understanding the characteristics of distributed system, over missing required feedback loops and deficiencies in functional design, to not understanding the trade-offs of applying resilience patterns, and ends with the problem of our continuous collective insight loss.
The main objective of the talk is to sensitize for the pitfalls. Wherever possible I also added some suggestions how to deal with the topics. Unfortunately, some topics neither have an obvious nor a simple solutions - at least none that I would know about ...
As always the voice track is missing and thus a huge part of the content of the talk. Yet, I hope the slides in themselves are of some use for you and offer some helpful ideas and pointers.
The SOLID Principles Illustrated by Design PatternsHayim Makabee
The goal of the SOLID design principles is to improve the Separation of Concerns, through weaker Coupling and stronger Cohesion. The main consequence should be software systems that are easier to maintain and to extend. However the definition of the SOLID principles is quite abstract, and some developers find it difficult to apply them in practice. In my talk I will show how well-known Design Patterns illustrate the application of the SOLID principles, and also show examples of how to follow these principles to Refactor and improve existing designs.
About the speaker:
Hayim Makabee was born in Rio de Janeiro. He immigrated to Israel in 1992 and completed his M.Sc. studies on Computer Sciences at the Technion. Since then he worked for several hi-tech companies, including also some start-ups. Currently he is a co-founder of the International Association of Software Architects (IASA) in Israel. Hayim is the author of a book about Object-Oriented Programming and has published papers in the fields of Software Engineering, Distributed Systems and Genetic Algorithms.
The talk belonging to this slide deck is basically a "sequel" of the "Patterns of resilience" talk. It briefly repeats a few core statements of the previous talk and then starts to complete the picture.
First, it creates a more complete pattern taxonomy and locates the taxonomy of the previous talk in it. Then, it repeats a few of the patterns of the first talk concerning core architectural patterns and error detection patterns, enriching them with some additional information.
After that the core part of this talk starts: The error recovery and error mitigation patterns. The talk presents several well known and not so well known patterns from those two domains, partially augmented with code examples. Then after, briefly touching fault treatment patterns, some more patterns of the error prevention domain are presented.
The talk concludes with a small guideline, how to identify the appropriate pattern set for a concrete situation.
As always, the voice track and therefore a lot of information is missing in this slide deck. Yet, I hope that it provides a few helpful pointers.
This slide deck addresses the importance of proper functional design for creating resilient distributed systems (not only, but also microservice-based systems).
It starts by explaining the pitfall that many developers fall into when getting started with resilience: Quite often the effects of the fundamentals, i.e., creating bulkheads and choosing the communication paradigm, on system robustness at runtime are heavily underrated. Instead, the pure technical measures like circuit breakers, backpressure, etc. are often overestimated.
Unfortunately, all technical measures will not help to create a robust system if the functional design leads to highly coupled services where the availability of one service functionally totally depends on the availability of another service. The same is true if you need to call many services that all need to be available to answer a client request.
To make it worse, most of the wide-spread design approaches like functional decomposition, DRY (don't repeat yourself), design for re-use or layered architecture exactly lead to those problems, i.e., they are not suitable for designing distributed systems.
This slide deck does not offer any silver bullets to solve the problem (and actually I believe there is no silver bullet), but at least a few guiding principles. Additionally, it shows how the choice of the communication paradigm influences the bulkhead design and this way creates more options to create a good service design that also supports resiliency on a functional level.
As always this slide deck is without the voice track, i.e., most of the information is missing. But I hope that the slides on their own also provide some helpful hints.
Remark: As the "dismiss reusability" slide tends to get quite some attention, one more remark about that slide: On the voice track I usually add "If you find something that is worth being made reusable, i.e., that it satisfies the commercial constraints of Fred Brooks 'Rule of 9' (see https://blog.codecentric.de/en/2015/10/the-broken-promise-of-re-use/ for details), do not put it in a service. Instead create a library and put the functionality in there. And make sure that changes to the library do not mean that all users have to upgrade at the same time, but that any library user can update whenever it fits the user's schedule. Otherwise, you would have introduced tight coupling through the back door again."
In this slide deck, I first describe what resilience is, what it is about, why it is important and how it is different from traditional stability approaches.
After that introductory part the main part is a "small" pattern language which is organized around isolation, the typical starting point of resilient software design. I used quotation marks for "small" as even this subset of a complete resilience pattern language still consists of around 20 patterns.
All the patterns are briefly described and for some of the patterns I added a bit of detail, but as this is a slide deck, the voice track - as usual - is missing. Also this pattern language is still sort of work in progress, i.e., it has not yet settled and some details are still missing. Yet I think (or at least hope), that the slides might contain a few useful insights for you.
This is basically a "lessons learned" talk. While dealing with resilient software design for several years meanwhile, I realized along the way that implementing a specific pattern like timeout detection, circuit breaker, back-pressure, etc. is the smallest of the challenges.
As so often in software development, the actual pitfalls that keep you from being successful with your project - here, creating a robust application - are not to be found in the area of creating code. Based on my experiences, the actual pitfalls are to be found in areas that are at best loosely related to resilient software design.
In this talk, I discuss some of those pitfalls that I have experienced more than once along my way. It starts with not understanding the goals of resilient software design, continues from a lack of understanding the characteristics of distributed system, over missing required feedback loops and deficiencies in functional design, to not understanding the trade-offs of applying resilience patterns, and ends with the problem of our continuous collective insight loss.
The main objective of the talk is to sensitize for the pitfalls. Wherever possible I also added some suggestions how to deal with the topics. Unfortunately, some topics neither have an obvious nor a simple solutions - at least none that I would know about ...
As always the voice track is missing and thus a huge part of the content of the talk. Yet, I hope the slides in themselves are of some use for you and offer some helpful ideas and pointers.
The SOLID Principles Illustrated by Design PatternsHayim Makabee
The goal of the SOLID design principles is to improve the Separation of Concerns, through weaker Coupling and stronger Cohesion. The main consequence should be software systems that are easier to maintain and to extend. However the definition of the SOLID principles is quite abstract, and some developers find it difficult to apply them in practice. In my talk I will show how well-known Design Patterns illustrate the application of the SOLID principles, and also show examples of how to follow these principles to Refactor and improve existing designs.
About the speaker:
Hayim Makabee was born in Rio de Janeiro. He immigrated to Israel in 1992 and completed his M.Sc. studies on Computer Sciences at the Technion. Since then he worked for several hi-tech companies, including also some start-ups. Currently he is a co-founder of the International Association of Software Architects (IASA) in Israel. Hayim is the author of a book about Object-Oriented Programming and has published papers in the fields of Software Engineering, Distributed Systems and Genetic Algorithms.
The talk belonging to this slide deck is basically a "sequel" of the "Patterns of resilience" talk. It briefly repeats a few core statements of the previous talk and then starts to complete the picture.
First, it creates a more complete pattern taxonomy and locates the taxonomy of the previous talk in it. Then, it repeats a few of the patterns of the first talk concerning core architectural patterns and error detection patterns, enriching them with some additional information.
After that the core part of this talk starts: The error recovery and error mitigation patterns. The talk presents several well known and not so well known patterns from those two domains, partially augmented with code examples. Then after, briefly touching fault treatment patterns, some more patterns of the error prevention domain are presented.
The talk concludes with a small guideline, how to identify the appropriate pattern set for a concrete situation.
As always, the voice track and therefore a lot of information is missing in this slide deck. Yet, I hope that it provides a few helpful pointers.
Stressed, Depressed, or Burned Out? The Warning Signs You Shouldn't Ignore (S...Cathrine Wilhelmsen
Stressed, Depressed, or Burned Out? The Warning Signs You Shouldn't Ignore (Presented at SQLBits on March 18th, 2023)
We all experience stress in our lives. When the stress is time-limited and manageable, it can be positive and productive. This kind of stress can help you get things done and lead to personal growth. However, when the stress stretches out over longer periods of time and we are unable to manage it, it can be negative and debilitating. This kind of stress can affect your mental health as well as your physical health, and increase the risk of depression and burnout.
The tricky part is that both depression and burnout can hit you hard without the warning signs you might recognize from stress. Where stress barges through your door and yells "hey, it's me!", depression and burnout can silently sneak in and gradually make adjustments until one day you turn around and see them smiling while realizing that you no longer recognize your house. I know, because I've dealt with both. And when I thought I had kicked them out, they both came back for new visits.
I don't have the Answers™️ or Solutions™️ to how to keep them away forever. But in hindsight, there were plenty of warning signs I missed, ignored, or was oblivious to at the time. In this deeply personal session, I will share my story of dealing with both depression and burnout. What were the warning signs? Why did I miss them? Could I have done something differently? And most importantly, what can I - and you - do to help ourselves or our loved ones if we notice that something is not quite right?
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.
In this session we will learn how we can handle fault tolerance in microservices using Resilince4J springboot and how it is Preferred over Hystrics for implementing fault-tolerance pattern circuit-Breaker
Windows Azure is Microsoft's application platform for the public cloud. You can use this platform in many different ways. For instance, you can use Windows Azure to build a web application that runs and stores its data in Microsoft datacenters. You can use Windows Azure just to store data, with the applications that use this data running on-premises (that is, outside the public cloud). You can use Windows Azure to create virtual machines for development and test or to run SharePoint and other applications.
Domain Driven Design and Hexagonal Architecture with RailsDeclan Whelan
You know that Domain Driven Design, Hexagonal Architecture, and the Single Responsibility Principle are important but it’s hard to know how to best apply them to Rails applications. Following the path of least-resistance will get you in trouble. In this session you will learn a way out of the “fat model, skinny controller” hell. You will leave with a roadmap to guide your design based on concepts from Domain Driven Design and Hexagonal Architecture.
Slides from AIS and Microsoft's half-day session on the recently-announced Windows Azure Infrastructure as a Service (IaaS) offering. After a brief overview of the Azure Platform as a Service (PaaS) model, we will focus on key IaaS concepts. Additionally, we will walk you through a number of scenarios enabled by Azure IaaS and several demonstrations.
Agenda:
Overview of Windows Azure Platform
Azure IaaS
Why IaaS?
IaaS Core Concepts
Supported Applications
Azure Virtual Machines
Disk Mobility
VM export / Import
Availability
Azure Virtual Network
Learn all about microservices from Product Marketing Manager Dan Giordano. We'll cover how to get started, the benefits, potential challenges, and how SmartBear can help.
A introduction to Microservices Architecture: definition, characterstics, framworks, success stories. It contains a demo about implementation of microservices with Spring Boot, Spring cloud an Eureka.
Intro to Sociotechnical Architecture: co-designing technical & organizational...Eduardo da Silva
(Presentation from Spaces Summit 2020, bol.com)
Traditionally software architecture focuses on designing software systems to provide value to customers. In most organizations there is little emphasis on the design of the organizational structure that will implement and own such technical architecture.
However, in our very competitive and fast moving world this can be a major drawback. We cannot design software systems at high-velocity without considering the organization that will deliver and own them. Architecture must be a co-design activity, considering organizational and software systems aspects. This is what Sociotechnical Architecture aims at.
In this talk I am going to show you what Sociotechnical Architecture is; why it is extremely relevant; and will also inspire you with several examples and patterns. My goal is to make clear that we must always consider these two dimensions to be able to maximize our impact and be able to achieve high-velocity on our product development.
Presentation video here: https://youtu.be/ekMPm78KFj0
Today, there are several trends that are forcing application architectures to evolve. Users expect a rich, interactive and dynamic user experience on a wide variety of clients including mobile devices. Applications must be highly scalable, highly available and run on cloud environments. Organizations often want to frequently roll out updates, even multiple times a day. Consequently, it’s no longer adequate to develop simple, monolithic web applications that serve up HTML to desktop browsers.
This site describes a new, alternative architecture: microservices. Applications with a microservice architecture consist of a set of narrowly focused, independently deployable services. Read on to find out more about this approach and its associated trade-offs. A good starting point is the Monolithic Architecture pattern.
Docker is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating-system-level virtualization on Linux.[5] Docker uses resource isolation features of the Linux kernel such as cgroups and kernel namespaces to allow independent "containers" to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines.
A popular pattern today is the injection of declarative (or functional) mini-languages into general purpose host languages. Years ago, this is what LINQ for C# was all about. Now there are many more examples such as the Spark or Beam APIs for Java and Scala. The opposite embedding is also possible: start with a declarative (or functional) language as the outer host and then embed a general purpose language. This is the path we took for Scope years ago (Scope is a Microsoft-internal big data analytics language) and have recently shipped as U-SQL. In this case, the host language is close to T-SQL (Transact SQL is Microsoft’s SQL language for SQL Server and Azure SQL DB) and the embedded language is C#. By embedding the general purpose language in a declarative language, we enable all-of-program (not just all-of stage) optimization, parallelization, and scheduling. The resulting jobs can flexibly scale to leverage thousands of machines.
Stressed, Depressed, or Burned Out? The Warning Signs You Shouldn't Ignore (S...Cathrine Wilhelmsen
Stressed, Depressed, or Burned Out? The Warning Signs You Shouldn't Ignore (Presented at SQLBits on March 18th, 2023)
We all experience stress in our lives. When the stress is time-limited and manageable, it can be positive and productive. This kind of stress can help you get things done and lead to personal growth. However, when the stress stretches out over longer periods of time and we are unable to manage it, it can be negative and debilitating. This kind of stress can affect your mental health as well as your physical health, and increase the risk of depression and burnout.
The tricky part is that both depression and burnout can hit you hard without the warning signs you might recognize from stress. Where stress barges through your door and yells "hey, it's me!", depression and burnout can silently sneak in and gradually make adjustments until one day you turn around and see them smiling while realizing that you no longer recognize your house. I know, because I've dealt with both. And when I thought I had kicked them out, they both came back for new visits.
I don't have the Answers™️ or Solutions™️ to how to keep them away forever. But in hindsight, there were plenty of warning signs I missed, ignored, or was oblivious to at the time. In this deeply personal session, I will share my story of dealing with both depression and burnout. What were the warning signs? Why did I miss them? Could I have done something differently? And most importantly, what can I - and you - do to help ourselves or our loved ones if we notice that something is not quite right?
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.
In this session we will learn how we can handle fault tolerance in microservices using Resilince4J springboot and how it is Preferred over Hystrics for implementing fault-tolerance pattern circuit-Breaker
Windows Azure is Microsoft's application platform for the public cloud. You can use this platform in many different ways. For instance, you can use Windows Azure to build a web application that runs and stores its data in Microsoft datacenters. You can use Windows Azure just to store data, with the applications that use this data running on-premises (that is, outside the public cloud). You can use Windows Azure to create virtual machines for development and test or to run SharePoint and other applications.
Domain Driven Design and Hexagonal Architecture with RailsDeclan Whelan
You know that Domain Driven Design, Hexagonal Architecture, and the Single Responsibility Principle are important but it’s hard to know how to best apply them to Rails applications. Following the path of least-resistance will get you in trouble. In this session you will learn a way out of the “fat model, skinny controller” hell. You will leave with a roadmap to guide your design based on concepts from Domain Driven Design and Hexagonal Architecture.
Slides from AIS and Microsoft's half-day session on the recently-announced Windows Azure Infrastructure as a Service (IaaS) offering. After a brief overview of the Azure Platform as a Service (PaaS) model, we will focus on key IaaS concepts. Additionally, we will walk you through a number of scenarios enabled by Azure IaaS and several demonstrations.
Agenda:
Overview of Windows Azure Platform
Azure IaaS
Why IaaS?
IaaS Core Concepts
Supported Applications
Azure Virtual Machines
Disk Mobility
VM export / Import
Availability
Azure Virtual Network
Learn all about microservices from Product Marketing Manager Dan Giordano. We'll cover how to get started, the benefits, potential challenges, and how SmartBear can help.
A introduction to Microservices Architecture: definition, characterstics, framworks, success stories. It contains a demo about implementation of microservices with Spring Boot, Spring cloud an Eureka.
Intro to Sociotechnical Architecture: co-designing technical & organizational...Eduardo da Silva
(Presentation from Spaces Summit 2020, bol.com)
Traditionally software architecture focuses on designing software systems to provide value to customers. In most organizations there is little emphasis on the design of the organizational structure that will implement and own such technical architecture.
However, in our very competitive and fast moving world this can be a major drawback. We cannot design software systems at high-velocity without considering the organization that will deliver and own them. Architecture must be a co-design activity, considering organizational and software systems aspects. This is what Sociotechnical Architecture aims at.
In this talk I am going to show you what Sociotechnical Architecture is; why it is extremely relevant; and will also inspire you with several examples and patterns. My goal is to make clear that we must always consider these two dimensions to be able to maximize our impact and be able to achieve high-velocity on our product development.
Presentation video here: https://youtu.be/ekMPm78KFj0
Today, there are several trends that are forcing application architectures to evolve. Users expect a rich, interactive and dynamic user experience on a wide variety of clients including mobile devices. Applications must be highly scalable, highly available and run on cloud environments. Organizations often want to frequently roll out updates, even multiple times a day. Consequently, it’s no longer adequate to develop simple, monolithic web applications that serve up HTML to desktop browsers.
This site describes a new, alternative architecture: microservices. Applications with a microservice architecture consist of a set of narrowly focused, independently deployable services. Read on to find out more about this approach and its associated trade-offs. A good starting point is the Monolithic Architecture pattern.
Docker is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating-system-level virtualization on Linux.[5] Docker uses resource isolation features of the Linux kernel such as cgroups and kernel namespaces to allow independent "containers" to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines.
A popular pattern today is the injection of declarative (or functional) mini-languages into general purpose host languages. Years ago, this is what LINQ for C# was all about. Now there are many more examples such as the Spark or Beam APIs for Java and Scala. The opposite embedding is also possible: start with a declarative (or functional) language as the outer host and then embed a general purpose language. This is the path we took for Scope years ago (Scope is a Microsoft-internal big data analytics language) and have recently shipped as U-SQL. In this case, the host language is close to T-SQL (Transact SQL is Microsoft’s SQL language for SQL Server and Azure SQL DB) and the embedded language is C#. By embedding the general purpose language in a declarative language, we enable all-of-program (not just all-of stage) optimization, parallelization, and scheduling. The resulting jobs can flexibly scale to leverage thousands of machines.
Fundamental and Practice.
Explain about microservices characters and pattern. And also how to be good build microservices. And also additional the scale cube and CAP theory.
Slides for my architectural session at the event: Docker From Zero To Hero.
We talked about what kind of expertises are need in order to build a true Microservices Solution; you'll need to understand some of the fundamentals on which Microservices is built upon: SOA, EDA and DDD just to name a few, then you can move to the container world.
Original event link: https://www.eventbrite.it/e/biglietti-docker-from-zero-to-hero-83372825365#
CPU and RAM costs continue to plummet. Multi-core systems are ubiquitous. Writing code is easier than it has ever been. Why, then, is it still so darn hard to make a scalable system?
It's easy to say... Microservices! Reality is we need to learn and apply concepts coming from many disciplines like SOA, EDA and DDD just to name a few! Mix them with some ALM and technical processes around Packaging and Deploying... and maybe then you get a true Microservices solution.
Microservices - stress-free and without increased heart attack riskUwe Friedrichsen
This is a slide deck belonging to a talk in which I talk about the challenges with µservices in general and provide a few ideas how to avoid the worst pitfalls.
The talk starts with a short explanation why µservice are always hard (yes, the title of the presentation is sort of an oxymoron) and when and when not to choose µservices.
After that introduction I provide a few ideas which from my experience help to get around the worst problems and pitfalls with µservices. As the ideas are from very different topic areas I organized them according to the software production chain starting with design hints and ending with resilience hints (a pure production related topic).
As always the voice track is missing but I hope that also the slides in themselves will give you a few helpful hints.
Microservices - stress-free and without increased heart-attack risk - Uwe Fri...distributed matters
A microservice is written quickly: Reasonable scope, a small REST interface, nice and easy and way lot cooler than those fat web applications we did before. But, is it really that easy? Well - no, not really! A single service is quite easy to manage, but therefrom the overall complexity does not go away. Instead of a few big web applications we now have lots of microservices - and to make sure that integration, operations and maintenance will not become a lottery game with increased heart-attack risk, it is crucial to consider a few things, that were not (so) important for traditional web applications. Should I use REST or would event driven be the better choice? How can I make sure the service collaboration works as desired? With GUI or better without GUI? How can I guarantee availability and scalability in production? How to deploy best? How I can I make sure that services are easily replaceable? How can I avoid service spaghetti? Those and many more questions will be answered in this session - to make sure the encounter with microservices will not become a health risk.
Discover and learn how to build a microservices platform, get a view of the best of breed architecture, solving common challenges, dig into Netflix stack, Yelp PaaSTA, AirBnB SmartStack, Apache Mesos, SoundCloud, Spinnaker experiences.
French audience : the JUG live recording is available here, https://www.youtube.com/watch?v=5LnL1HYmLwY&feature=youtu.be
MuCon 2015 - Microservices in Integration ArchitectureKim Clark
Discusses the how microservices fit into the ever evolving integration architecture, looking at how these concepts are often seen very differently through the eyes of enterprises with different lanscapes.
Here you find some points to think about if you're considering to use a microservice architecture in your next project. In the first part you'll find some management considerations and then some points about technologies and solutions for MS problems.
With popular poster children such as Netflix and Amazon, using microservices-based architectures seems to be the killer approach to twenty-first-century architecture. This session goes over the benefits, but more so the pitfalls, of using a microservices-based architecture. What impact does it have on your organization, your applications, and dealing with scale and failures, and how do you prevent your landscape from becoming an unmaintainable nightmare?
Presentazione dello speech tenuto da Carmine Spagnuolo (Postdoctoral Research Fellow - Università degli Studi di Salerno/ ACT OR) dal titolo "Technology insights: Decision Science Platform", durante il Decision Science Forum 2019, il più importante evento italiano sulla Scienza delle Decisioni.
The Reality of Managing Microservices in Your CD PipelineDevOps.com
As we shift from monolithic software development practices to microservices, our well-designed CD pipeline will need to change. Microservices are small functions, deployed independently and linked via APIs at run-time. While these differences seem minor, they actually have a large impact on your overall CD structure. Think hundreds of workflows, small of any builds and the loss of a monolithic 'application.'
Join Tracy Ragan, CEO of DeployHub and Brendan O'Leary, Developer Evangelist at GitLab, to learn more.
It's never too early to start the conversation.
Similar to Timeless design in a cloud-native world (20)
This is a slide deck from a presentation, that my colleague Shirin Glander (https://www.slideshare.net/ShirinGlander/) and I did together. As we created our respective parts of the presentation on our own, it is quite easy to figure out who did which part of the presentation as the two slide decks look quite different ... :)
For the sake of simplicity and completeness, I just copied the two slide decks together. As I did the "surrounding" part, I added Shirin's part at the place when she took over and then added my concluding slides at the end. Well, I'm sure, you will figure it out easily ... ;)
The presentation was intended to be an introduction to deep learning (DL) for people who are new to the topic. It starts with some DL success stories as motivation. Then a quick classification and a bit of history follows before the "how" part starts.
The first part of the "how" is some theory of DL, to demystify the topic and explain and connect some of the most important terms on the one hand, but also to give an idea of the broadness of the topic on the other hand.
After that the second part dives deeper into the question how to actually implement DL networks. This part starts with coding it all on your own and then moves on to less coding step by step, depending on where you want to start.
The presentation ends with some pitfalls and challenges that you should have in mind if you want to dive deeper into DL - plus the invitation to become part of it.
As always the voice track of the presentation is missing. I hope that the slides are of some use for you, though.
This slide deck is basically my take on the future development of microservices. It is not so much a technological prediction as a tactical prediction.
It starts with taking stock of IT: Where do we come from, where are we right now and what are the trends that (most likely) will shape our future? I try to address those issues from several points of view, not necessarily creating a totally consistent picture of IT (which imo is not possible anyway), but trying to point out the most influential drivers of the past, today and the future.
Then I try to locate microservices in that picture with mutliple angles - where they blend in. Having done that, I try to show how microservices will evolve in the future based on my observations. And in order to complete the journey, based on the anticipated future of microservices, I try to give a few recommendations for microservices developers of today how to prepare for that evolution.
While - as written in the beginning - this is my take on the evolution of microservices and the voice track is missing, I still hope that it is a bit helpful and delivers some food for thought.
The hitchhiker's guide for the confused developerUwe Friedrichsen
This talk is basically a successor of the "DevOps is not enough talk", but with a broader focus.
In the talk, after a short motivation, I try to take stock of the current state of IT from different points of view. After looking at, where we came from and where we are, I add the most important trends I currently see that affect us in IT.
But knowing where we came from, where we are and where we are going to usually is not enough. The key point is using this information - in this talk for evaluating your current position as a software engineer and figuring out your desired future position.
As all the details from the first part of the talk make it hard to do this evaluation, I suggest creating a model (actually a framework) on a reduced detail level that makes the evaluation and planning easier. Defining that framework is the third part of the talk.
Finally, the last part consists of some general recommendations that - based on my understanding - help you as a software engineer to stay ahead of the curve for a while.
While this is extremely much stuff (I really consider to split that plethora of information covered in this talk up in several, single-topic talks) and as always the voice track is missing, I still hope that the slide deck gives you a few ideas worth pondering.
Digitization solutions - A new breed of softwareUwe Friedrichsen
This slide deck is about the challenges we have to face if we deal with digitization solutions. As this term currently is massively overused, I first introduce a very simple definition to define what I mean with "digitization solution" in the context of the presentation.
Afterwards, I list the challenges - at least the most relevant ones - that arise from moving into the digitzation solution domain. Based on that, I try to examine the trends, prerequisites and limitations that you are confronted with from an IT point of view and you better need to adapt to if you are confronted with digitization in your company. Last, but not least, I try to derive some practical hints for us as individuals, how we can prepare for such an environment.
As always, the voice track is missing, but I hope also the slides on their own bear some value for you.
This slide deck tries to give an overview about the consistency options we have today and what we can expect in the future. It's an updated version of slide deck I had uploaded to SlideShare before. Unfortunately, SlideShare removed the option to update a slide deck. Thus, I had to remove the old slide deck and create a new one, even if it actually was just an update.
It starts with examining RDBMS and ACID transactions - especially looking at the fact that "ACID" does not necessarily mean serializablity (what most developers think of if they reason about consistency).
Then it describes the current state of IT affairs concerning Cloud, microservices, NoSQL databases and BASE transactions. It then dives a bit deeper into the topic of polyglot persistence and its challenges by introducing a little "storage dimension model" that may support you in picking the right storage solution that fits your needs. Especially it is pointed out that in the storage world there is no one-size-fits-all solution available and especially that NoSQL databases - definitely having their sweet spots where they shine - are no drop-in replacement for a RDBMS.
Afterwards, BASE transactions are examined in more detail - especially the fact that their trade-off for providing us with better availability and scalability is a very hard programming model. To underline that point the typical types of inconsistencies that you often will see with BASE transactions are sketched on what you need to do on the application level in order to cope with them.
In the third section, a peek into the future is made by looking at some current research results that will eventually find their way into commercial application development. The core observation is that even in highly available systems there are a lot of options regarding consistency. Yet, most of those options require to reason about consistency explicitly on the application level and no longer solely on the read/write level of the underlying data stores - including building explicit consistency support into the application.
In the last section, some recommendation for our daily work are given that can be derived from the former sections.
As always the voice track is missing, but hopefully it will give you a few helpful pointers, though. Especially, at the end a lot of references to computer science papers are included that this slide deck is based on.
Based on my observations, in IT we suffer from continuous collective amnesia and we are even proud of it.
For at least 50 years meanwhile, we struggle how to build systems, that are easy to understand, to maintain, to change and to operate in a reliable way. Each time we hit the wall again, we start to look for a new silver bullet on the horizon, strongly believing that it will solve the problem for good.
The key word is "new": "New" is good in our community, while "old" is bad, worthless, crap. We suffer from youthism, not only in recruiting, but in all areas. This way we discard any "old" knowledge, no matter if it is valuable or not. We separate by age, not by value.
Additionally we continuously lose our collective memory with every new generation that leaves university as they are also taught not to value anything old and instead only look for the new, shiny stuff.
While not all old knowledge is worth being preserved, admittedly, there is still a lot of valuable old knowledge available, offering answers to the problems that we face today - creating maintainable and reliable systems, dealing with distribution and tackling complexity, just to name a few of the challenges.
This presentation is a journey through some (very) old computer science papers that contain a lot of very valuable knowledge regarding the problems we face today. For each of the papers, some of the key ideas are presented and how they address our current challenges.
Of course, the voice track is missing and there are a lot more papers that would be worth being mentioned in this presentation. Still, I hope that also the slides alone will be of some value for you - and convince you a bit that not everything "old" in IT is automatically worthless ... ;)
In this slide deck I try to explore the meaning of the often misinterpreted sentence "You build it, you run it". Starting with its origin in a 2006 interview with Werner Vogels and a short description of the misinterpretation of that phrase that can be seen quite often these days in companies that try to pick up concepts like DevOps without really getting the idea behind it, I then start a bit longer journey.
It starts with the history and evolution of markets and IT. Based on that I dive deeper into the effects of uncertainty which these days is often predominant for companies facing narrow and highly dynamic markets. I try to approach from a financial point of view as well as from a risk management point of view (yes, even if we have become agile, managing risk and financial aspects have not gone away).
The basic result is that we need to go faster (in terms of cycle times) without compromising quality. I also add a quick litmus test to figure out where your own company currently is located as reality never is as simple as a slide deck - to avoid turning a thought model that should support reasoning into a dogma.
Having the task set and understanding that IT must support going faster without compromising quality, I look at DevOps as it targets exactly the same goal. After a short explanation of what DevOps actually means (we face a perfect confusion of ideas when talking about DevOps) and what the effects are if you do it seriously, I focus on the effects for the process organization.
The traditional process organization - while usually being set up nicely for cost efficiency - is very poor in terms of cycle times. In order to shorten cycle times those organization will eventually become cross-functional, autonomous teams with end-to-end responsibility. And while those teams have all skills and the full authority for all their activities, they also need to take over the full responsibility for their actions - their is no one left to blame ;)
And this naturally leads to "(You decide it,) you build it, you run it" which in the end is a required organizational prerequisite for going fast in a DevOps way.
There is a lot left out in the slides that would also be worth talking about (after all it is just a 60 min talk) and of course the voice track is missing, but I still hope that those slides are of some value for you.
This slide deck is basically an extended and updated version of the "Microservices - stress-free and without increased heart-attack risk" slide deck - yet quite a lot of extensions and updates.
The deck is organized in three parts: Why, What and How.
The first part addresses the question if and when you should use microservices at all. It tries to create a bigger picture by explaining changing (business) markets and a changing role of IT and fits microservices into that picture. When looking at this picture it also becomes clear that microservices always should accompanied by other measures like DevOps, Cloud and some more if you really want to leverage its benefits. Otherwise you usually only get the downsides of microservices with harvesting their benefits.
The second part revisits the famous blog post from James Lewis and Martin Fowler, using it to explain what characteristics the microservice architecural style has. It turns out that this post contains quite a lot of information and that quite often only a subset of the characteristics get implemented.
The third part, the "How" dives deeper into the challenges and pitfalls that you usually encounter if you decide to adopt microservices. While of course not being complete and not being a perfect guide that makes everything easy, it should at least help you tho avoid the most common problems and pitfalls.
As always the voice track is missing which contains most of the information (it is a 90 min talk after all), but hopefully also the slides alone contain some helpful information.
In this talk, I address two topics.
The first topic is the "one size fits all" dogma that we see quite often in IT. I try to explain, why we do it but also what the pitfalls are and how oversimplified solution spaces lead to the same kind of accidental complexity when trying to solve a given business problem as overly complex solution spaces.
The second and core topic is the influence that a communication paradigm you use has on your functional design. Based on the observation that synchronous request/response in all its flavors is the usually used "one size fits all" communication paradigm, I use a real-life example to demonstrate how two different communication paradigms (synchronous request/response and asynchronous event-based communication) can lead to very different functional service designs - and that synchronous request/response not necessarily leads to the more appropriate functional design.
The bottom line of the talk is that you should not give up your design options prematurely in order to be able to find the best problem-solution fit and that the choice of the communication paradigm is a more important options than most people usually think it is.
As always the voice track is missing and therefore quite a bit of the information (or probably most of the information) contained in the talk. But hopefully the slides still give you some useful pointers.
This is the slide deck of a keynote I gave at Java Forum Nord 2016.
I started with some of the contradictory requirements, developers find themselves often confronted with and the question, if there is a bigger context that we can use to make sense of it.
Then I did a bit of "time-traveling", explaining where we came from and how business and IT have evolved over time. The core finding was that we find ourselves in the middle of a revolution that is going on (not only) in IT.
The last part were some recommendations how an IT developer can at least reduce the risk to become "revolution roadkill".
As always most of the content was on the voice track. But maybe the slides are still a bit helpful on their own.
DevOps is not enough - Embedding DevOps in a broader contextUwe Friedrichsen
As the subtitle says, this talk tries to embed DevOps in a broader context. Therefore first briefly is sketched, how the state of IT is perceived by many people in IT. Additionally, DevOps is briefly defined by explaining the three ways as they were described in the book "The Phoenix Project".
After this short introduction the claim of the title is picked up: "Why is DevOps not enough?". In order to explain this claim, the history of economic markets and of IT are briefly explained. The bottomline is that almost all markets supported by IT have drastically changed in the years since IT became relevant for companies. Additionally, IT itself has changed dramatically in this period of time. Therefore, most of the common knowledge and best practices, we stick to in IT became counter-productive meanwhile because they solve a completely different problem, i.e., the problems of the times when the markets and IT itself were totally different.
The conclusion from the short examination of history is that we basically have to re-think IT as a whole, which is discussed briefly in the next section of the talk. This section first has a look at the new drivers that inflict change on IT. Then it derives the new goals of IT and shows some of the building blocks.
Having this new idea of IT at hand, the role of DevOps in it is finally considered. Starting with DevOps and its continuous pursuit of shortening cycle times in order to optimize outcome, DevOps can be used to drive the change of IT. This is exemplarily shown by starting with DevOps and then see, which question arise from that and what solutions it leads to. In the end of the example, many of the building blocks of the new IT are in place - just by starting with DevOps and continuously improving.
This is a very dense talk covering a lot of ground in order to lead to the final observation that DevOps can (and should) be used to drive the required change of IT and many detail have been left out. Also the voice track is missing of course, but I still hope that it provides you with some useful information.
This slide deck is about the production-readiness of software. First it explains why production-ready is more important than just feature-complete.
Then it takes a quick detour to DevOps. It explains the core ideas of DevOps and how this talks relates to the concepts of DevOps (by simulating the feedback loop from ops to dev while the wall between dev and ops still exists).
After this detour the needs of the administrators from the ops department are briefly described and the challenges that arise from that for developers who want to provide production-ready software.
Based on those challenges a selection of design principles are described (mostly in terms of topics to take care of in the design and implementation process). While not being complete by far, taking care of the topics described on these slides are a huge step towards production-ready software based on my experience.
Of course all the information from the voice track is missing, it is slides only. Even though the slides just carry a fraction of the information, I hope they will still contain some good pointers for you that help you to create better production-ready software.
This slide deck dives a bit in history to understand where IT comes from, where we are now and why we are there and what our options are. It starts with exploring the paradigms of the markets companies live in, travels through matching organizational approaches and finally looks at the history and current state of IT.
Based on that and after a quick look at Conway's law the market paradigms and organizational approaches are evaluated with respect to the drivers they imply on IT in general and architecture particularly.
And after all that foreplay (which is necessary to really understand where we are and what the forces are) several architectural styles and technologies are located on the scale that the market paradigms and organizational approaches span. This way sort of an "architectural fitness detector" is provided which helps to make architectural choices based on needs instead of hypes or habits (which are way to often the choice drivers).
The slide deck then finishes up with a few mismatches that are seen quite often in reality and it can be seen how the distance between architectural choices on the presented scale can be used to quickly determine potential mismatches.
As always the voice track is missing but I hope that the slides are still of some help for you.
Conway's law revisited - Architectures for an effective ITUwe Friedrichsen
This session is sort of a journey from the change drivers that affect today's IT to ways to respond to them in the architecture.
It starts with the business and technological drivers that force IT into change. After briefly sketching the big picture for IT as a whole, it focuses on the drivers and requirements that can be derived for architecture from the IT change drivers.
After carving out the architectural requirements, those are mapped to some trending topics. Based on the mapping results, it becomes obvious that there is no silver bullet (we all know that but this doesn't keep us from hoping that there still is one).
It is required to combine some ideas and concepts to a joint architectural style that becomes more than just the sum of its parts - and that's the last part of the story: Describing an architectural style that helps addressing the IT change drivers shown in the first part.
As a side note, at the end an idea is shown how EAM could fit into the picture laid out by the slides.
As always, many details are only on the voice track - and as always, sorry about that! But I hope that the slides still contain some ideas which are valuable for you.
Modern times - architectures for a Next Generation of ITUwe Friedrichsen
In this presentation I focus on the architectural aspect of the next generation of enterprise IT topic I already covered in some other presentations.
The slide deck starts with a quick motivation. It describes the external drivers that require traditional enterprise IT to change. Based on these drivers, the drivers and requirements for an architecture that supports the external drivers are derived.
The second major part of the slide deck then examines some of today's IT hype topics and evaluates them with respect to the architectural requirements derived before. Be aware that the evaluation partially is hard to understand without the voice track. Actually, at some places the explanations on the voice track are more important than the evaluations themselves. Thus, please do not take them too literally.
The last major part then tries to sketch a possible architectural style that suits the given requirements. Again, the rationale for picking the respective elements are on the voice track, and it is just one possible style. There are for sure more styles available that suit the needs.
Yet I think, the style described makes clear that the upcoming enterprise architectural styles are quite different from the styles that were predominant in the last 10 or 15 years and makes clear that we all have to face new challenges - not only on the architectural level.
Sorry again that the voice track is missing. Yet I think, that the presentation provides some helpful ideas even without the voice.
This is the successor of my Dr. Hectic and Mr. Hype presentation where I first explained the consequences of the economic darwinism for an enterprise IT and started to lay out a new, competitive IT that is ready to respond to the new change drivers.
In this presentation I try to provide a more comprehensive picture than in the former presentation. I added additional change drivers that were missing in the first presentation and derived the goals, the principles and the building blocks for an appropriate next generation of an enterprise IT in a lot more detail than in the first presentation.
Yet, the presentation is still very high level as it tries to lay out a complete vision for a future enterprise IT in 60 minutes, i.e., it would be possible to create one or more detailed presentation for mostly every single term and statement in this presentation. Thus, it might appear too high level for some persons. On the other hand I think it is important to create such a high level vision as it makes it a lot easier to classify all those trends that are pushing on us every single day.
And as always the voice track is missing. Yet, I hope that the presentation provides some valuable insights.
Why resilience - A primer at varying flight altitudesUwe Friedrichsen
This session provides a primer to resilience at varying flight altitudes.
It starts at a management level and motivates why resilience is important, why it is important today and what the business case for resilience is (or actually is not).
Then it descends to a high level architectural view and explains resilience a bit more in detail, its correlation to availability and the difference between resilience and robustness.
Afterwards it descends to a design level and explains some selected core principles of resilience, some of them garnished with grass-root level flight altitude code examples.
At the end the flight altitude is risen again and some recommendations how to introduce resilient software design into your software development process are given and the correlation to some related topics is explained.
Of course this slide deck will only show a fraction of the actual talk contents as the voice track is missing but I hope it will be helpful anyway.
This slide deck explains a bit how to deal best with state in scalable systems, i.e. pushing it to the system boundaries (client, data store) and trying to avoid state in-between.
Then it picks arbitrarily two scenarios - one in the frontend part and one in the backend part of a system and shows concrete techniques to deal with them.
In the frontend part is examined how to deal with session state of servlet containers in scalable scenarios and introduces the concept of a shared session cache layer. Also an example implementation using Redis is shown.
In the backend part it is examined how to deal with potential data inconsistencies that can occur if maximum availability of the data store is required and eventual consistency is used. The normal way is to resolve inconsistencies manually implementing business specific logic or - even worse - asking the user to resolve it. A pure technical solution called CRDTs (Conflict-free Replicated Data Types) is then shown. CRDTs, based on sound mathematical concepts, are self-stabilizing data structures that offer a generic way to resolve inconsistencies in an eventual consistent data store. Besides some theory also some examples are shown to provide a feeling how CRDTs feel in practice.
Resilience becomes a must. Actually resilience is an issue for a long time, but with ever-increasing distribution it becomes a must. But how can we implement resilience into our applications? Hystrix, an open-source library developed by Netflix provides a nice starting point. It provides downstream isolation by implementing patterns like timeout, circuit breaker and load shedder. This presentation gives an introduction into Hystrix, providing lots of code examples.
With the raise of NoSQL databases consistency models that are less strict than ACID transactions became popular again. After the first enthusiasm the developer community became aware that those relaxed consistency models hold some new challenges they never knew about in the ACID world. Fortunately there are some concepts around how to deal with those challenges. This presentation gives a rough introduction into the different consistency models that are available and their characteristics. Then it focusses on two techniques to deal with relaxed consistency. The first one are quorum-based reads and writes which provides a client-side strong consistency model (even if the database only implements eventual consistency). Then CRDTs (Conflict-free Replicated Data Types) are presented. CRDTs are self-stabilizing data structures which are designed for environments with extremely high availability requirements - and thus extremely weak consistency guarantees. Even though as always the majority of the information is on the voice track, I designed the slides in a way that they also provide some useful information without the voice.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
"Impact of front-end architecture on development cost", Viktor TurskyiFwdays
I have heard many times that architecture is not important for the front-end. Also, many times I have seen how developers implement features on the front-end just following the standard rules for a framework and think that this is enough to successfully launch the project, and then the project fails. How to prevent this and what approach to choose? I have launched dozens of complex projects and during the talk we will analyze which approaches have worked for me and which have not.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Key Trends Shaping the Future of Infrastructure.pdf
Timeless design in a cloud-native world
1. Timeless design in a cloud-native world
Ageless foundations, gently updated and applied to modern service design
Uwe Friedrichsen – codecentric AG – 2016-2018
2. Uwe Friedrichsen
IT traveller.
Dot Connector.
Cartographer of uncharted territory.
Keeper of timeless wisdom.
CTO and Fellow at codecentric.
https://www.slideshare.net/ufried
https://medium.com/@ufried
@ufried
4. “Cloud native computing uses an open source software stack
to deploy applications as microservices,
packaging each part into its own container,
and dynamically orchestrating those containers
to optimize resource utilization.”
Source: Cloud Native Computing Foundation Homepage (https://www.cncf.io/)
13. ... lead to a variety of effects
• Lost messages
• Incomplete messages
• Duplicate messages
• Distorted messages
• Out-of-order message arrival
• Partial, out-of-sync local memory
• ...
14. These effects are based on the non-determinism
introduced by remote communication
due to distributed failure modes
15. Understand that remote communication points are
predetermined breaking points of your application
Accept that the effects will hit you at the application level
17. Typical measures
• High-availability (HA) hardware/software
• Only applicable for very small installations
• Usually not available in cloud environments
• Delegate failure handling to infrastructure level
• Partial relief, will not solve all problems
• Implement resilient software design patterns
• Very important, still will not fix a bad design
• Minimize number of remote communication points
• Minimize problem surface by design
19. Reducing remote communication points
Reduce the number of
distributed runtime artifacts
i.e., create coarser grained services
Reduce the need to
communicate across
runtime artifact boundaries
i.e., get the functional design right
20. Reducing remote communication points
Reduce the number of
distributed runtime artifacts
i.e., create coarser grained services
Reduce the need to
communicate across
runtime artifact boundaries
i.e., get the functional design right
22. If you can get away with a monolith, just do it!
You are still allowed to structure it well ... ;)
23. Still, your functional domain usually will be too big
to put it all in a single monolith
Thus, you will need to distribute your system landscape to a certain degree
24. Rule of thumb
Always think (at least) twice before distributing functionality
Only do it if you really need independent deployments
Addendum
You may also want to distribute your functionality if you have
very disparate NFRs for different parts of your functionality
(e.g., security *, availability, reliability, scalability **, portability,
resource utilization)
* forgotten most of the time
** less often needed than most people assume
25. Reducing remote communication points
Reduce the number of
distributed runtime artifacts
i.e., create coarser grained services
Reduce the need to
communicate across
runtime artifact boundaries
i.e., get the functional design right
26. Case study
(Very simple) eCommerce shop
• Implements the core functionalities
• Search & show
• Add to shopping cart
• Checkout
• Shipment
• Payments only touched as black box
• No recommendations, etc.
28. Typical design approach
Focus on avoiding redundancy and maximizing reuse
1. Start with a comprehensive domain (actually: E/R) model
29. *
*
*
*
Customer
• name
• address
• payment methods
E
Order
• customer
• payment information
• shipping information
• order items
• product
• quantity
E
Product
• name
• description
• image(s)
• price
• items in stock
• packaging information
(size, weight, special care)
E
30. Typical design approach
Focus on avoiding redundancy and maximizing re-use
1. Start with a comprehensive domain (actually: E/R) model
2. Wrap entities with services
32. Typical design approach
Focus on avoiding redundancy and maximizing re-use
1. Start with a comprehensive domain (actually: E/R) model
2. Wrap entities with services
3. Spread functionality over services
34. Typical design approach
Focus on avoiding redundancy and maximizing re-use
1. Start with a comprehensive domain (actually: E/R) model
2. Wrap entities with services
3. Spread functionality over services
4. Add “process services” for “complex use cases”
• i.e., use cases that touch more than one data service
36. Typical design approach
Focus on avoiding redundancy and maximizing re-use
1. Start with a comprehensive domain (actually: E/R) model
2. Wrap entities with services
3. Spread functionality over services
4. Add “process services” for “complex use cases”
• i.e., use cases that touch more than one data service
5. Add missing data maintenance use cases
43. Properties of the design
• Focus on avoiding redundancy and maximizing reuse
• Based on traditional OO design practices
• Results in high coupling between services
• Results in moderate cohesion inside services
• Okay for CRUD applications
• But then better use a generator, scaffolding framework, ...
• Okay-ish for single-process applications
• Tends to affect maintainability negatively
• Not okay for distributed services
• Big failure surface, bad response times
47. “The fewer and simpler the connections between modules, the easier it is to
understand each module without reference to other modules.
Minimizing connections between modules also minimizes the paths
along which changes and errors can propagate into other parts of the
system, thus eliminating disastrous ‘ripple’ effects, where changes in one
part cause errors in another, necessitating additional changes elsewhere,
giving rise to new errors, etc.”
[Ste 1974]
48. “Coupling is the measure of the strength of association
established by a connection from one module to another.”
[Ste 1974]
49. Coupling
High
Low
Contributing factors
Interface
Complexity
Type of
Connection
Type of
Communication
Simple,
obvious
Complicated,
obscure
To module
by name
(depending
on interface)
To internal
elements
(depending on
implementation)
Data
(control flow handled
by environment)
Control
(Explicit passing
of control)
Hybrid
(Manipulation of internal
control flow by parameters)
[Ste 1974]
50. Realize that this paper was written at a very different time
and in a very different context than we face today
While the core concepts are timeless and still valid,
we usually need to rethink the concrete instructions
51. Contributing factors
Interface
Complexity
Type of
Connection
Type of
Communication
Simple,
obvious
Complicated,
obscure
To module
by name
(depending
on interface)
To internal
elements
(depending on
implementation)
Data
(control flow handled
by environment)
Control
(Explicit passing
of control)
Hybrid
(Manipulation of internal
control flow by parameters)
* Ability of a service to complete its task without the other service being present
Functional
Independence*
Independent
(does not need other
service to work)
Fully dependent
(does not work
without other service)
Partly dependent
(graceful degradation
of service)
Coupling
High
Low
52. “Coupling is reduced when the relationships among elements not in the
same module are minimized.
There are two ways of achieving this – minimizing the relationships among
modules and maximizing relationships among elements in the same
module. In practice, both ways are used. [...]
Binding is the measure of the cohesiveness of a module. The objective
here is to reduce coupling by striving for high binding.”
[Ste 1974]
53. On the criteria to be
used in decomposing
systems into modules
by David L. Parnas
[Par 1972]
54. “The effectiveness of a ‘modularization’ is dependent upon the criteria used in
dividing the system into modules.”
“The second decomposition was made using "information hiding" as a
criterion. [...] Every module in the second decomposition is characterized by
its knowledge of a design decision which it hides from all others. Its
interface or definition was chosen to reveal as little as possible about its
inner workings.”
“There are a number of design decisions which are questionable and likely to
change under many circumstances. [...] By looking at these changes we can
see the differences between the two modularizations.”
[Par 1972]
55. Separation of concerns
One concept/decision per module
Information hiding
Reveal as little as possible about
internal implementation
+
Better changeability
Changes are kept local
Independent teams
Teams can easier work
independently on different modules
Easier to comprehend
Modules can be understood on
their own easier
56. Research findings
• High cohesion, low coupling leads the right way
• Separation of Concerns and Information hiding
support implementing them
• Concrete paper instructions should not be followed blindly
• Different context (single process, very limited hardware)
• Would lead to nano or pico services à lots of remote calls
• You need to rethink instructions in the current context
• Required for all CS papers from a different time & context
• Leads to concept of Functional Independence in this context
• Reduces risk of “vertical decomposition” (i.e., layered design)
58. Vertical decomposition
• Based on “uses” relation
• Typical drivers are reuse and avoidance of redundancy
• Creates strong coupling (high functional dependence)
• Often useful pattern inside a process boundary
• Due to deterministic communication behavior
• Problematic across process boundaries
à Should be avoided in service design
59. Horizontal decomposition
• Based on functional segregation
• Typical drivers are autonomy and independence
• Creates low coupling (high functional independence)
• Useful pattern across process boundaries
• Can also be useful inside a process boundary
• Less accidental "ripple" effects due to changes
à Should be preferred in service design
60. Watch out!
• Vertical decomposition is our default design approach
• We’ve learned it in our CS education (divide and conquer, ...)
• It’s emphasized in our daily work (DRY, reusability, ...)
• Even our IDEs support it (“Extract method”)
• It's everywhere! It's predominant!
• It takes energy not to apply vertical decomposition
• Most people never learned horizontal decomposition
63. DDD to the rescue?
• Naive application of building block patterns leads
to the counter-example design we have seen before
• Not useful in our context due to high coupling
• “Service” pattern leads to process service working on entities
• Anti-pattern in our context due to high coupling
• “Conceptual contours” supports high cohesion
• Yet, tends to be too fine grained for our context
• “Bounded contexts” supports low coupling
• Yet, tends to be too coarse grained for our context
à Mixed emotions: Good, but not the expected panacea
65. For good service design, look at the behavior first, not the data
66. Case study
(Very simple) eCommerce shop
• Implements the core functionalities
• Search & show
• Add to shopping cart
• Checkout
• Shipment
• Customer self-care
• Product catalog maintenance
• Payments only touched as black box
• No recommendations, etc.
67. Core reasoning
To reduce the number of remote calls needed for a given functionality,
we need to spread the functionality between the services in a way
that a single use case/user interaction less often needs to cross service
boundaries.
Therefore, we try to organize services around use cases/user interactions.
68. Search & Show
Add to
shopping cart
Checkout
Shipment
Customer
self-care
Product catalog
maintenance
eCommerce shop
Customer
Back office
employee
Warehouse
employee
69. Search & Show
Add to
shopping cart
Checkout
Shipment
Customer
self-care
Product catalog
maintenance
eCommerce shop
Customer
Back office
employee
Warehouse
employee
Three different actors
• Indicator for cohesion boundaries
• (At least) three different UIs
• Could be completely different architectures
• Depending on user needs, usage patterns and other NFRs
• As an architect this gives you additional options
70. Search & Show
Add to
shopping cart
Checkout
Shipment
Customer
self-care
Product catalog
maintenance
eCommerce shop
Customer
Back office
employee
Warehouse
employee
Could be a mobile-first FE
with service-oriented backend
Could be a special warehouse device FE
with a monolithic backend
Could be a rich
desktop app
Could be a
desktop browser
first FE with a
service-oriented
backend
71. Search & Show
Add to
shopping cart
Checkout
Shipment
Customer
self-care
Product catalog
maintenance
72. Behavior-based design approach
Focus on minimum cross-service communication
inside a use case/user interaction
1. Each use case/user interaction is a service candidate
74. Behavior-based design approach
Focus on minimum cross-service communication
inside a use case/user interaction
1. Each use case/user interaction is a service candidate
2. Possibly split big use cases in multiple services
• Only if really needed (e.g., multiple teams, disparate NFRs)
• Look for functional clusters with low coupling between them
75. ShoppingCartService
• Add to shopping cart
S
CheckoutService
• Checkout
S
SearchService
• Search/show
S
ProductCatalogService
• Product catalog
maintenance
S
ShipmentService
• Shipment
S
CustomerMDService
• Customer self care
S
Splitting up use cases in multiple services not needed in this example
76. Behavior-based design approach
Focus on minimum cross-service communication
inside a use case/user interaction
1. Each use case/user interaction is a service candidate
2. Possibly split big use cases in multiple services
• Only if really needed (e.g., multiple teams, disparate NFRs)
• Look for functional clusters with low coupling between them
3. Try to group several use cases in a single service
• Strive for a sweet spot in terms of an overall trade-off
• Look for service candidates that operate on the same data
77. ShoppingCartService
• Add to shopping cart
S
ProductCatalogService
• Product catalog
maintenance
S
CheckoutService
• Checkout
S
ShipmentService
• Shipment
S
SearchService
• Search/show
S
CustomerMDService
• Customer self care
S
Product catalog
Customer master data
Shopping cart
Buying order
Inventory data / shipping order
Product catalog
78. ShoppingCartService
• Add to shopping cart
S
ProductCatalogService
• Product catalog
maintenance
S
CheckoutService
• Checkout
S
ShipmentService
• Shipment
S
SearchService
• Search/show
S
CustomerMDService
• Customer self care
S
Product catalog
Customer master data
Shopping cart
Buying order
Inventory data / shipping order
Product catalog
Service candidates working on the same data
79. Architectural reasoning
• Same data ...
• ... but different actors
• Option to work on a single product catalog database
here outweighs different actors using a single service
à Unite in one service
(unless you decide to use a different architectural style
for the back office employee application)
80. ShoppingCartService
• Add to shopping cart
S
ProductCatalogService
• Product catalog
maintenance
• Search/show
S
CheckoutService
• Checkout
S
ShipmentService
• Shipment
S
CustomerMDService
• Customer self care
S
Customer master data
Shopping cart
Buying order
Inventory data / shipping order
Product catalog
81. ShoppingCartService
• Add to shopping cart
S
ProductCatalogService
• Product catalog
maintenance
• Search/show
S
CheckoutService
• Checkout
S
ShipmentService
• Shipment
S
CustomerMDService
• Customer self care
S
Customer master data
Shopping cart
Buying order
Inventory data / shipping order
Product catalog
Service candidates
working on the
same type of data
(shopping cart is a
preliminary order)
82. Architectural reasoning
• Some (sequential) cohesion and could work on same data ...
• ... but unification is still not imperative
• Need to ponder other aspects and balance trade-offs
• Different representations for shopping cart and order needed?
• UI part of the service?
• How does payment interfere (not considered in the example)?
à Here we assume that it is best to unite the services
83. ProductCatalogService
• Product catalog
maintenance
• Search/show
S
OrderCreationService
• Add to shopping cart
• Checkout
S
ShipmentService
• Shipment
S
CustomerMDService
• Customer self care
S
Customer master data
Shopping cart / buying order
Inventory data / shipping order
Product catalog
84. Additional reasoning
• Buying order vs. shipping order
• Less commonalities than shopping cart and buying order
• Shipping order is only “ephemeral” entity
• Different actors using them
à Keep them separated (we need a signaling mechanism then)
• Who updates items in stock?
• No longer part of product catalog maintenance
• Warehouse employee responsible (more reasonable anyway)
à Add additional use case “Fill up inventory”
85. CustomerMDService
• Customer self care
S
Customer master data
OrderCreationService
• Add to shopping cart
• Checkout
S
Shopping cart / buying order
WarehouseService
• Shipment
• Fill up inventory
S
Inventory data / shipping order
ProductCatalogService
• Product catalog
maintenance
• Search/show
S
Product catalog
86. Nice, but is this design any better?
Again: How good is it in terms of remote communication?
91. 1st law of architectural work:
Every decision has its price.
No decision is for free.
(Translation: No decision only has upsides. Every decision also has downsides.)
92. 2nd law of architectural work:
A decision can only be evaluated
with respect to its context.
(Translation: Decisions are not invariably “good” or “bad”, but only in a given context.)
93. Trade-offs of the approach
• Biggest concern: What about the data?
• Data replication and reconciliation
• Entity distribution (no single source of truth for an entity)
• Question cannot be answered in general
• Here we will evaluate it with respect to the given example
• Plus some general considerations (but no general evaluation)
94. *
*
*
*
Customer
• name
• address
• payment methods
E
Order
• customer
• payment information
• shipping information
• order items
• product
• quantity
E
Product
• name
• description
• image(s)
• price
• items in stock
• packaging information
(size, weight, special care)
E
This diagram is misleading!
95. *
*
*
*
Customer
• name
• address
• payment methods
E
Order
• customer
• payment information
• shipping information
• order items
• product
• quantity
E
Product
• name
• description
• image(s)
• price
• items in stock
• packaging information
(size, weight, special care)
E
Only used as copy template
Only relevant for search/show
Only relevant for checkout
Just an ID for
business related
referencing purposes
Only relevant for checkout
(including invoice address)
Only relevant for shipment
Only relevant for shipment
(including delivery address)
Different for checkout and shipment
(only IDs and quantities needed)
Immutable after completion
(all data copied into order)
96. CustomerMDService
• Customer self care
S
Customer master data
OrderCreationService
• Add to shopping cart
• Checkout
S
Shopping cart /
buying order
WarehouseService
• Shipment
• Fill up inventory
S
Inventory data / shipping order
ProductCatalogService
• Product catalog
maintenance
• Search/show
S
Product catalog
Putting these use cases in a
single service avoids the need
for data replication
3
3
3
Putting these use cases in a
single service avoids the need
for data signaling
4
4
Needs to signal data
for shipment order
(signaling mechanism required)
2
2
2
Needs to copy some
product (and customer) data
into the order
(could be handled by the frontend)
1
1
1
1
97. Findings
• All use cases are robust and fast
• Minimal need to transfer data between services
• Solvable via frontend and standard data transfer solution
(batch file, transfer table, message queue, ...)
• No data replication and reconciliation solution needed
Side note: It is not always as nice and simple as in this example
98. Still, it is not always that nice and easy
Translation: There are situations where two or more copies of the same data need to be kept in sync
99. CustomerMDService
• Customer self care
S
Customer master data
OrderCreationService
• Add to shopping cart
• Checkout
S
Shopping cart /
buying order
WarehouseService
• Shipment
• Fill up inventory
S
Inventory data / shipping order
ProductCatalogService
• Product catalog
maintenance
• Search/show
S
Product catalog
Might want to allow update
of payment methods in the
context of customer self care
and checkout
(requires two-way synchronization
of master data after change)
1
1
1
Might want to allow adding
items to shopping cart only if
items are in stock
(requires one-way synchronization
of transactional data after change)
2
2
2
It might even hit us
in our example
101. Options to keep data in sync
• Shared database
• Compromises original reasoning to use services
• Distributed transactions (2-phase commit)
• Tight coupling compromises service independence
• Compromises availability and scalability
• Eventual consistency
• Sufficient for basically all functional requirements
• Supports low coupling and high availability
• Downside: Much harder programming model than ACID TX
✖
✖
✔
102. Options for eventual consistency
• Batch pull
• Consumer pulls data batch when ready to process data
• Very robust approach (also suitable for legacy integration)
• Data sync delay may be longer than acceptable
• Batch bootstrapping & delta push
• Initial state sync via batch pull, then push of delta updates
• Often combined with event sourcing, CQRS, reactive, ...
• Fast, robust (if done right) and still quite lightweight
• Distributed log
• Offers advantages of previous approach in one technology
• Kafka currently is the best-known implementation
• Still have a plan how to recover if the tool breaks
104. Pondering single source of truth
• Usually task for analytical data processing
• Orthogonal, well-understood issue
• Many solutions available
• Sometimes needed in transactional systems (e.g., CRM)
• Question if it is really a need or just a habit
• Strive for eventual consistency
• Go for event streams or distributed logs for fast updates
106. Wrap-up
• Think (at least) twice before distributing functionality
• Strive for low coupling, support with high cohesion
• Prefer horizontal decomposition in service design
• Favor functional independence over reuse
• The magic is in the behavior, not the data
• Employ use cases to find service boundaries
• Prefer eventual consistency for data synchronization
• Value the timeless wisdom
• But update the instructions to the given current context
107.
108. Uwe Friedrichsen
IT traveller.
Dot Connector.
Cartographer of uncharted territory.
Keeper of timeless wisdom.
CTO and Fellow at codecentric.
https://www.slideshare.net/ufried
https://medium.com/@ufried
@ufried