Michael Perry
Software Mathematician
Dallas, Texas, United States
Actions
Software is math. Every class is a theorem. The compiler is the proof. And unit tests check our work.
Michael wrote The Art of Immutable Architecture, a book on applying mathematics to building distributed systems. Learn more at https://immutablearchitecture.com.
Michael has recorded Pluralsight courses on Distributed Systems, XAML Patterns, and Cryptography, in addition to Provable Code. Formerly a Microsoft MVP for seven years, he maintains the spoon-bending Assisticant and Jinaga open-source libraries. You can find his videos about distributed systems at historicalmodeling.com. And he helps his clients at Improving benefit from the power of software mathematics.
Links
Area of Expertise
Topics
Identity, Immutability, and .NET Polyglot Notebooks
Let's talk code.
In fact, let's talk in code.
.NET has a cool new capability that lets us share ideas directly in code. They are called .NET Polyglot Notebooks. I want to try an experiment with you. Let's have a conversation about software design using only code.
The ideas that I'd like to talk about are identity and immutability. Identity is how we say which object we are talking about, from the primary key in a database to the URL in an API. And immutability is the self-imposed constraint that we will not change an object once it's created. These ideas taken together help us make informed decisions about software design and architecture.
Would you like to keep data in sync across databases? Between microservices? On mobile devices? Then you need to think about how you identify objects, and how you allow them to change.
During this discussion, we will be modeling an application using Jinaga.NET. I am still building this open-source library, which will be the cornerstone of how I build ASP.NET microservices, Blazor web apps, and Xamarin mobile applications. If you would like to help shape this core architectural middleware, I'd be happy to have your help. But even if you are building apps using traditional ORMs and APIs, you will be able to apply these patterns.
Kubernetes. Now What? Data Management in a Distributed Cluster
You have a cluster. You can scale up and down at a moment's notice. You can roll updates without taking down your services. So are all your problems solved?
Not quite. You still have the issue of keeping your microservices in sync.
You want each service to be able to make its own decisions autonomously. They therefore need to store their own copy of the data that they need. But that copy is not always up-to-date. To achieve consistency at scale, you need to design messages that will let pods converge within a reasonable time. Those messages need to be idempotent so that repeats do not cause duplication. And they need to be commutative so that pods will converge even after receiving messages in different orders.
These are not trivial properties. They are difficult to achieve in a traditional mutation-based paradigm. But if your model was immutable, then you would get these properties almost for free. Every copy of an immutable record is just as good as any other, and it will never be out-of-date. The trick then is how to model your application using only immutable records.
Let me show you how.
We'll begin by analyzing your problem domain using a causal historical model. You will see how workflow patterns take us beyond state-machine thinking and solve technical problems and business problems simultaneously. Then we will map that immutable model into messages so that we can deploy it to our cluster. Use AMQP, Kafka, or any messaging infrastructure that you are comfortable with. Finally, we will employ the sidecar pattern to translate the immutable model back into the mutation-based entities that our application containers expect.
Kubernetes is a wonderful tool for managing workloads. Now that you have it, apply the patterns of immutable architecture to manage data within your distributed cluster.
Jinaga: End-to-End State Management for Offline-First Web Applications
State management libraries like Redux make it easier to coordinate changes in all parts of your web applications. But they stop at the browser. You are still responsible for developing the API and back-end data store.
Jinaga is an end-to-end state management solution. No custom API. No app-specific database. You write your model, and Jinaga takes it from there:
• Local storage for offline-first web apps and PWAs
• Reliable communication with delivery guarantees
• Application-agnostic persistence for low-friction data evolution
• Server-sent events for real-time collaboration
What makes this work is a completely different approach to data management. You won't find stores, actions, and reducers. Instead, Jinaga is based on Immutable Architecture. Store the user's decisions as immutable facts. Share those decisions with other clients who express interest. And then interpret those decisions as UI updates.
This does require a shift to your mental model. It won't be easy. But if you apply immutability end-to-end, you might find that many of the hard problems of collaborative web apps are no longer hard problems.
Please allow me to introduce you to Jinaga.
3 Mathematical Concepts that Every Developer Should Know
Not all developers need Category Theory or Linear Algebra. But every developer can benefit from Logic, Graph Theory, and Degrees of Freedom. Even if you don't think you are good at math, these are the skills that you use every day. You are a better mathematician than you give yourself credit for. Let's formalize those skills so that you can apply them with confidence.
We'll identify the Degrees of Freedom of a problem. Then we'll see how those degrees of freedom manifest in the solution. This will help us create better MVVM applications, better APIs, and better relational database models.
We'll learn some of the cool properties of Directed Acyclic Graphs, and how they help us track dependencies, and construct data models. We'll apply that knowledge to traversing those graphs in a way that always produces the correct result with the minimum necessary work.
We'll practice some of the tools of Predicate Calculus, and see how it helps us specify better requirements, and express concise queries. From that, we'll ensure that we've covered every edge case without overly complicating our code.
Math is not hard. Writing proofs is not complicated. In fact, it's exactly like writing programs.
How Not to Destroy Data
CRUD apps destroy data.
Delete is an obviously destructive operation, but Update is no better. Updates overwrite the data that was once present. What would software look like if the only valid operations were Create and Read?
Historical Modeling is a technique for designing and building software systems that permit only inserts, no updates, no deletes. The only way to "modify" an object is to insert related records. You can then read the state of the object by querying for the presence or absence of those related records. We'll start with the assumption that all records are immutable and indelible. From there, we'll build a set of patterns that yield some surprising benefits.
With a historical model, synchronizing disparate nodes is trivial: just insert what you don't yet have. Building offline-first web applications is easy. Viewing a snapshot of the system at any point in the past is a simple query.
Let's build a historical model together, and see these benefits for ourselves. Let's put aside the assumptions of CRUD applications and discover a whole new set of patterns. Once you master these techniques, you will never destroy data again.
Git as Blockchain
You and your co-workers want to keep track of who picks up the check at lunch. But they can't be trusted. Build a solution in Git that keeps things fair without trust.
The solution: blockchain!
In Git, it's a shared repository; in blockchain, a distributed ledger. Where Git has commits, blockchain has blocks. Git uses SHA, and so does blockchain. Discover how blockchain technology actually works by building a blockchain using Git. Along the way, you'll discover features such as:
• Wallets
• Proof of work
• Mining
• 51% attack
By the end of this demonstration, you will know how blockchain solves the zero-trust problem. You will clearly see its limitations. And you will discover what you are sacrificing for that solution.
Learn several patterns that you could use to solve the problems you really have. But the problems that blockchain solves best, you don't have. That's why you don't need a blockchain.
But if you really do, here's how they work.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top