No crash allowed - Fault tolerance patterns
•
11 likes•4,614 views
This is a short introduction to fault tolerance in the context of scale out solutions. I gave this talk at SEACON 2012 and my biggest problem was to compress a topic that usually needs at least 4 hours down to 45 min. Thus, this just gives a very brief overview and presents a few basic patterns. Nevertheless it should help to get a first idea how fault tolerant design is different from normal enterprise application design we are used to for the last 10 or 15 years.
Report
Share
Report
Share
Recommended
Emergent architecture
This talk is basically a follow-up of the agile architect talk. It discusses in depth if it is possible to do architectural design emergent only.
By examining the different activities and objectives of architecture I show that emergent architecture is valuable but not sufficient and I show a little joint approch how to combine the different kinds of things to do within architectural work.
Cloud Compliance - Bestimmungen, Zertifizierungen und all das
In diesem Vortrag spreche ich über das Thema Cloud Compliance. Welche Regelwerke und Standards gibt es, wie sieht es mit Zertifizierungen für Cloud Security aus und was steckt in so einem Regelwerk praktisch drin?
Neben einem Überblick über die wichtigsten Vertreter der Regelwerke und Standards am Markt analysiere ich dann das aktuelle Eckpunktepapier des BSI zu Sicherheitsempfehlungen für Cloud-Computing-Anbieter genauer und nehme die verschiedenen Anforderungen kritisch unter die Lupe - letzteres leider primär auf der Tonspur, d.h. in den Folien ist dazu nicht viel zu lesen.
Scalability patterns
This talk is about concepts and patterns for highly scalable systems.
It starts with a few guiding principles. Then the dimensions of scalability are explained. Afterwards some selected patterns are shows and some recommendations about storage and tools are made. The presentation ends with a short glimpse about what I did not talk about in this presentation and several pointers to further literature.
Cloud fuer entscheider
In diesem Vortrag erläutere ich, wie man als "normaler IT-Mitarbeiter" seinem Chef oder einem Entscheider bei seinem Kunden Cloud Computing erklären kann.
Ich gehe kurz auf die Problematik der Begriffsverwirrung ein und zeige dann mögliche Ansätze, um einem Entscheider in seiner Begriffs- und Denkwelt Nutzen, Potentiale, Business Case und Risiken bzgl. Sicherheit und Compliance darzustellen.
Da es bei Cloud Computing nicht um "Mache ich es oder nicht?", sondern um "Wofür möchte ich es einsetzen?" geht, d.h. die Einsatzszenarien sehr individuell sind, gibt es keine fertige, sondern eine Reihe an möglichen Ansatzpunkten, aus der man sich dann seine individuelle Argumentation aufbauen kann.
Komplexität - Na und?
In diesem Vortrag geht es darum, wie man mit Komplexität umgehen kann - und solchen Dinge, von denen wir nur glauben, dass sie komplex seien.
Es werden eine Reihe von Ideen und Konzepten und der Systemtheorie und der Managementlehre vorgestellt. Außerdem habe ich noch einen Teil über essentielle und unbeabsichtigte Komplexität ergänzt.
In Summe lassen sich daraus einige Ideen ableiten, wie man besser mit all den täglichen herausfordernden Situationen umgehen kann.
Der Business Case für Architektur
In diesem Vortrag geht darum, wie man den Wert von Architektur bestimmen und berechnen kann.
Ausgehend von verschiedenen Tätigkeiten der Architekturarbeit skizziere ich dabei unterschiedliche Ansätze, um den Geschäftswert von Architekturarbeit zu bestimmen.
Letztlich geht es mir dabei nicht darum, eine geschlossene Formel zu präsentieren, sondern darum, mögliche Ansätze zu zeigen und deren Möglichkeiten und Grenzen, insbesondere bei einem so indirekt auf die Kosten einwirkenden Thema wie Architektur.
Down with the_sandals
This is a nightschool talk I gave at W-JAX in Munich 2012. The nightschool talks are meant to be less technical and more entertaining since they are held after a long day of sessions.
In this talk I ranted a bit about the disciple attitude, imho seen too often in the IT community. If a "guru" unburdens himself from another piece of wisdom, many people do not use their brain to reflect it - it is just "the truth" because the guru said it.
I used several of those wisdoms to demonstrate that a critical reflection is still valuable, no matter who said something or how many people are repeating it.
Actually, I did not rant against the ideas themselves - many of them are very, very valuable - I ranted against the dogmatism of the people spreading it and the even worse dogmatism of many people picking up the ideas.
After all my message was: You are smart, so use your brain to reflect new ideas. Be critical (in a construcitve way), no matter who tells you something. Be inspired by new ideas, do not turn them into a dogmatism. Keep your sandal at your foot.
The slides are not very narrative (sorry for that), but you probably get the idea anyway ... and probably you will have even better examples for it than I have presented ... ;-)
The agile Architect - Craftsmanship on a new Level
In this talk I reason about the need of architectural work in the context of the craftsmanship movement and about the idea how to use the agile values to make the architectural work more valuable.
I also give a few hints about how to transfer the core ideas and values into real world architectural world.
Recommended
Emergent architecture
This talk is basically a follow-up of the agile architect talk. It discusses in depth if it is possible to do architectural design emergent only.
By examining the different activities and objectives of architecture I show that emergent architecture is valuable but not sufficient and I show a little joint approch how to combine the different kinds of things to do within architectural work.
Cloud Compliance - Bestimmungen, Zertifizierungen und all das
In diesem Vortrag spreche ich über das Thema Cloud Compliance. Welche Regelwerke und Standards gibt es, wie sieht es mit Zertifizierungen für Cloud Security aus und was steckt in so einem Regelwerk praktisch drin?
Neben einem Überblick über die wichtigsten Vertreter der Regelwerke und Standards am Markt analysiere ich dann das aktuelle Eckpunktepapier des BSI zu Sicherheitsempfehlungen für Cloud-Computing-Anbieter genauer und nehme die verschiedenen Anforderungen kritisch unter die Lupe - letzteres leider primär auf der Tonspur, d.h. in den Folien ist dazu nicht viel zu lesen.
Scalability patterns
This talk is about concepts and patterns for highly scalable systems.
It starts with a few guiding principles. Then the dimensions of scalability are explained. Afterwards some selected patterns are shows and some recommendations about storage and tools are made. The presentation ends with a short glimpse about what I did not talk about in this presentation and several pointers to further literature.
Cloud fuer entscheider
In diesem Vortrag erläutere ich, wie man als "normaler IT-Mitarbeiter" seinem Chef oder einem Entscheider bei seinem Kunden Cloud Computing erklären kann.
Ich gehe kurz auf die Problematik der Begriffsverwirrung ein und zeige dann mögliche Ansätze, um einem Entscheider in seiner Begriffs- und Denkwelt Nutzen, Potentiale, Business Case und Risiken bzgl. Sicherheit und Compliance darzustellen.
Da es bei Cloud Computing nicht um "Mache ich es oder nicht?", sondern um "Wofür möchte ich es einsetzen?" geht, d.h. die Einsatzszenarien sehr individuell sind, gibt es keine fertige, sondern eine Reihe an möglichen Ansatzpunkten, aus der man sich dann seine individuelle Argumentation aufbauen kann.
Komplexität - Na und?
In diesem Vortrag geht es darum, wie man mit Komplexität umgehen kann - und solchen Dinge, von denen wir nur glauben, dass sie komplex seien.
Es werden eine Reihe von Ideen und Konzepten und der Systemtheorie und der Managementlehre vorgestellt. Außerdem habe ich noch einen Teil über essentielle und unbeabsichtigte Komplexität ergänzt.
In Summe lassen sich daraus einige Ideen ableiten, wie man besser mit all den täglichen herausfordernden Situationen umgehen kann.
Der Business Case für Architektur
In diesem Vortrag geht darum, wie man den Wert von Architektur bestimmen und berechnen kann.
Ausgehend von verschiedenen Tätigkeiten der Architekturarbeit skizziere ich dabei unterschiedliche Ansätze, um den Geschäftswert von Architekturarbeit zu bestimmen.
Letztlich geht es mir dabei nicht darum, eine geschlossene Formel zu präsentieren, sondern darum, mögliche Ansätze zu zeigen und deren Möglichkeiten und Grenzen, insbesondere bei einem so indirekt auf die Kosten einwirkenden Thema wie Architektur.
Down with the_sandals
This is a nightschool talk I gave at W-JAX in Munich 2012. The nightschool talks are meant to be less technical and more entertaining since they are held after a long day of sessions.
In this talk I ranted a bit about the disciple attitude, imho seen too often in the IT community. If a "guru" unburdens himself from another piece of wisdom, many people do not use their brain to reflect it - it is just "the truth" because the guru said it.
I used several of those wisdoms to demonstrate that a critical reflection is still valuable, no matter who said something or how many people are repeating it.
Actually, I did not rant against the ideas themselves - many of them are very, very valuable - I ranted against the dogmatism of the people spreading it and the even worse dogmatism of many people picking up the ideas.
After all my message was: You are smart, so use your brain to reflect new ideas. Be critical (in a construcitve way), no matter who tells you something. Be inspired by new ideas, do not turn them into a dogmatism. Keep your sandal at your foot.
The slides are not very narrative (sorry for that), but you probably get the idea anyway ... and probably you will have even better examples for it than I have presented ... ;-)
The agile Architect - Craftsmanship on a new Level
In this talk I reason about the need of architectural work in the context of the craftsmanship movement and about the idea how to use the agile values to make the architectural work more valuable.
I also give a few hints about how to transfer the core ideas and values into real world architectural world.
Hochskalierbare Cloud-Architekturen
Auf der W-JAX 2011 haben mein Kollege Patrick Peschlow und ich über hochskalierbare Cloud-Architekturen gesprochen. Der Ausgangspunkt dafür war ein konkretes Cloud-Projekt, in dem es um ein praktisch beliebig skalierbares Cloud-SaaS-Angebot ging. In dem Vortrag geht es um typische Aufgaben und Fallstricke aus Architektursicht sowie eine ganze Reihe praktischer Erfahrungen, die wir in dem Zusammenhang gemacht haben.
Kommunikation und Qualität - Java Forum Nord 2016
Dies sind die Slides von meinem Vortrag auf dem Java Forum Nord 2016 in Hannover. Es geht hierbei stark um die Qualität der Kommunikation und wie jeder einen Anspruch an seine eigene Qualität entwickeln soll.
Dr. Hectic and Mr. Hype - surviving the economic darwinism
This is a slidedeck about a topic I already talk about for a while: Every company is affected by the economic darwinism, i.e. the companies that respond best to change will survive. And the IT is not a bland cost center, it is the neural system of every company. No IT, no business!
Combining those two observations it becomes obvious that the responsiveness of the IT about new business features is a crucial survival factor in the long run - we are no longer talking about months or years for new business features, but about weeks or days.
In this slide deck I explain why the approaches most IT departments are not helping (sometimes even being counter-productive) and which building blocks you have to implement in order to survive the economic darwinism.
Some of the slides badly miss the audio track but the core ideas should become clear.
OAuth 2.0
This slide deck gives an introduction to OAuth 2.0, starting with some concepts, explaining the flow plus a few hints. The reminder of the slides are about implementing an OAuth 2.0 server using the Apache Amber library (renamed to Apache Oltu lately). My impression is that many developers shy away as soon as they hear "security" and so I did not only want to talk about the concepts of OAuth 2.0 but also wanted to show how easily you can implement an OAuth 2.0 server ... hope it reduces the fear of contact a bit ... ;-)
How to survive in a BASE world
This talk I gave at the NoSQL matters 2013. It quickly introduces BASE transactions and then illustrates the challenges a developer encounters when switching from ACID to BASE using a (very) simple example application.
First the ACID variant is shown. Then a naive BASE transformation is done. After that the typical problems with that approach are shown one by one a how to handle them on a conceptual and code level.
Of course the voice track is missing again but lots of stuff should become clear from the slides, though.
Fault tolerance made easy
Fault tolerance in general is a challenging topic. Yet we need fault toleranct designs more badly than ever in order to provide robust, highly available systems - especially in times of scale out systems becoming more and more popular.
Unfortunately, most developers do not care too much about a fault tolerant design, either because they are scared by the complexity of the realm or because they do not care enough. One of the problems is that a lack of fault tolerant design does not hurt a lot in development or in QA, but it hurts a lot in production - as Michael Nygard said: "It's all about production!" (at least figuratively).
In this presentation I do *not* try to give a general introduction to fault tolerant design. Instead I pick a few generic case studies that demonstrate the results of missing fault tolerant design, try to sensitize a bit about the production relevance of fault tolerant design and then go along with a few selected patterns. I picked a few patterns which are surprisingly easy to implement and help to mitigate the problems of the former case studies.
This way I try to show two things:
1. A piece of architecture or design as a pattern is not necessarily hard to implement. Sometimes the code is written quicker than it takes to explain the pattern beforehand.
2. Even if fault tolerant design as a general topic might be hard, some parts of it can be implemented very easily and it's more than worth the coding effort if you look how much better your system behaves in production just from adding those few lines of code.
Patterns of resilience
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.
Hadoop HDFS Architeture and Design
Hadoop Distributed File System
An overview HDFS, its components, and its design.
Layered Software Architecture
A presentation on layered software architecture that goes through logical layering and physical layering, the difference between those two and a practical example.
HDFS Design Principles
HDFS Design Principles and the Scale-out-Ability of Distributed Storage.
SVForum, Software Architecture & Platform SIG. May 23, 2012.
Timeless design in a cloud-native world
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.
Deep learning - a primer
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.
Life after microservices
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 developer
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 software
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.
Real-world consistency explained
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.
The 7 quests of resilient software design
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.
Excavating the knowledge of our ancestors
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 ... ;)
The truth about "You build it, you run it!"
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.
The promises and perils of microservices
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.
Resilient Functional Service Design
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."
More Related Content
Viewers also liked
Hochskalierbare Cloud-Architekturen
Auf der W-JAX 2011 haben mein Kollege Patrick Peschlow und ich über hochskalierbare Cloud-Architekturen gesprochen. Der Ausgangspunkt dafür war ein konkretes Cloud-Projekt, in dem es um ein praktisch beliebig skalierbares Cloud-SaaS-Angebot ging. In dem Vortrag geht es um typische Aufgaben und Fallstricke aus Architektursicht sowie eine ganze Reihe praktischer Erfahrungen, die wir in dem Zusammenhang gemacht haben.
Kommunikation und Qualität - Java Forum Nord 2016
Dies sind die Slides von meinem Vortrag auf dem Java Forum Nord 2016 in Hannover. Es geht hierbei stark um die Qualität der Kommunikation und wie jeder einen Anspruch an seine eigene Qualität entwickeln soll.
Dr. Hectic and Mr. Hype - surviving the economic darwinism
This is a slidedeck about a topic I already talk about for a while: Every company is affected by the economic darwinism, i.e. the companies that respond best to change will survive. And the IT is not a bland cost center, it is the neural system of every company. No IT, no business!
Combining those two observations it becomes obvious that the responsiveness of the IT about new business features is a crucial survival factor in the long run - we are no longer talking about months or years for new business features, but about weeks or days.
In this slide deck I explain why the approaches most IT departments are not helping (sometimes even being counter-productive) and which building blocks you have to implement in order to survive the economic darwinism.
Some of the slides badly miss the audio track but the core ideas should become clear.
OAuth 2.0
This slide deck gives an introduction to OAuth 2.0, starting with some concepts, explaining the flow plus a few hints. The reminder of the slides are about implementing an OAuth 2.0 server using the Apache Amber library (renamed to Apache Oltu lately). My impression is that many developers shy away as soon as they hear "security" and so I did not only want to talk about the concepts of OAuth 2.0 but also wanted to show how easily you can implement an OAuth 2.0 server ... hope it reduces the fear of contact a bit ... ;-)
How to survive in a BASE world
This talk I gave at the NoSQL matters 2013. It quickly introduces BASE transactions and then illustrates the challenges a developer encounters when switching from ACID to BASE using a (very) simple example application.
First the ACID variant is shown. Then a naive BASE transformation is done. After that the typical problems with that approach are shown one by one a how to handle them on a conceptual and code level.
Of course the voice track is missing again but lots of stuff should become clear from the slides, though.
Fault tolerance made easy
Fault tolerance in general is a challenging topic. Yet we need fault toleranct designs more badly than ever in order to provide robust, highly available systems - especially in times of scale out systems becoming more and more popular.
Unfortunately, most developers do not care too much about a fault tolerant design, either because they are scared by the complexity of the realm or because they do not care enough. One of the problems is that a lack of fault tolerant design does not hurt a lot in development or in QA, but it hurts a lot in production - as Michael Nygard said: "It's all about production!" (at least figuratively).
In this presentation I do *not* try to give a general introduction to fault tolerant design. Instead I pick a few generic case studies that demonstrate the results of missing fault tolerant design, try to sensitize a bit about the production relevance of fault tolerant design and then go along with a few selected patterns. I picked a few patterns which are surprisingly easy to implement and help to mitigate the problems of the former case studies.
This way I try to show two things:
1. A piece of architecture or design as a pattern is not necessarily hard to implement. Sometimes the code is written quicker than it takes to explain the pattern beforehand.
2. Even if fault tolerant design as a general topic might be hard, some parts of it can be implemented very easily and it's more than worth the coding effort if you look how much better your system behaves in production just from adding those few lines of code.
Patterns of resilience
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.
Hadoop HDFS Architeture and Design
Hadoop Distributed File System
An overview HDFS, its components, and its design.
Layered Software Architecture
A presentation on layered software architecture that goes through logical layering and physical layering, the difference between those two and a practical example.
HDFS Design Principles
HDFS Design Principles and the Scale-out-Ability of Distributed Storage.
SVForum, Software Architecture & Platform SIG. May 23, 2012.
Viewers also liked (11)
Kommunikation und Qualität - Java Forum Nord 2016
Kommunikation und Qualität - Java Forum Nord 2016
Dr. Hectic and Mr. Hype - surviving the economic darwinism
Dr. Hectic and Mr. Hype - surviving the economic darwinism
More from Uwe Friedrichsen
Timeless design in a cloud-native world
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.
Deep learning - a primer
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.
Life after microservices
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 developer
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 software
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.
Real-world consistency explained
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.
The 7 quests of resilient software design
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.
Excavating the knowledge of our ancestors
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 ... ;)
The truth about "You build it, you run it!"
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.
The promises and perils of microservices
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.
Resilient Functional Service Design
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."
Watch your communication
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.
Life, IT and everything
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.
Resilience reloaded - more resilience patterns
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.
DevOps is not enough - Embedding DevOps in a broader context
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.
Production-ready Software
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.
Towards complex adaptive architectures
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 IT
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.
Microservices - stress-free and without increased heart attack risk
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.
Modern times - architectures for a Next Generation of IT
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.
More from Uwe Friedrichsen (20)
DevOps is not enough - Embedding DevOps in a broader context
DevOps is not enough - Embedding DevOps in a broader context
Conway's law revisited - Architectures for an effective IT
Conway's law revisited - Architectures for an effective IT
Microservices - stress-free and without increased heart attack risk
Microservices - stress-free and without increased heart attack risk
Modern times - architectures for a Next Generation of IT
Modern times - architectures for a Next Generation of IT
Recently uploaded
State of ICS and IoT Cyber Threat Landscape Report 2024 preview
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...
Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head of Product, Amazon Games
JMeter webinar - integration with InfluxDB and Grafana
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
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP of Product, Amplitude
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Elevating Tactical DDD Patterns Through Object Calisthenics
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
DevOps and Testing slides at DASA Connect
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.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Mission to Decommission: Importance of Decommissioning Products to Increase E...
Mission to Decommission: Importance of Decommissioning Products to Increase Enterprise-Wide Efficiency by VP Data Platform, American Express
Neuro-symbolic is not enough, we need neuro-*semantic*
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.
Securing your Kubernetes cluster_ a step-by-step guide to success !
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Key Trends Shaping the Future of Infrastructure.pdf
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.
Bits & Pixels using AI for Good.........
A whirlwind tour of tech & AI for socio-environmental impact.
Knowledge engineering: from people to machines and back
Keynote at the 21st European Semantic Web Conference
GraphRAG is All You need? LLM & Knowledge Graph
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
When stars align: studies in data quality, knowledge graphs, and machine lear...
Keynote at DQMLKG workshop at the 21st European Semantic Web Conference 2024
Leading Change strategies and insights for effective change management pdf 1.pdf
Leading Change strategies and insights for effective change management pdf 1.pdf
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
AI for Every Business: Unlocking Your Product's Universal Potential by VP of Product, Slack
Recently uploaded (20)
State of ICS and IoT Cyber Threat Landscape Report 2024 preview
State of ICS and IoT Cyber Threat Landscape Report 2024 preview
Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...
Unsubscribed: Combat Subscription Fatigue With a Membership Mentality by Head...
JMeter webinar - integration with InfluxDB and Grafana
JMeter webinar - integration with InfluxDB and Grafana
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
Elevating Tactical DDD Patterns Through Object Calisthenics
Elevating Tactical DDD Patterns Through Object Calisthenics
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Mission to Decommission: Importance of Decommissioning Products to Increase E...
Mission to Decommission: Importance of Decommissioning Products to Increase E...
Neuro-symbolic is not enough, we need neuro-*semantic*
Neuro-symbolic is not enough, we need neuro-*semantic*
Securing your Kubernetes cluster_ a step-by-step guide to success !
Securing your Kubernetes cluster_ a step-by-step guide to success !
Key Trends Shaping the Future of Infrastructure.pdf
Key Trends Shaping the Future of Infrastructure.pdf
Knowledge engineering: from people to machines and back
Knowledge engineering: from people to machines and back
When stars align: studies in data quality, knowledge graphs, and machine lear...
When stars align: studies in data quality, knowledge graphs, and machine lear...
Leading Change strategies and insights for effective change management pdf 1.pdf
Leading Change strategies and insights for effective change management pdf 1.pdf
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...