Here are the things that caught my eye recently in .NET. I’d love to hear what you found most interesting this week. Let me know in the comments or on Twitter.Follow @codeopinion
Today, we are announcing .NET Core 3.0 Preview 7. We’ve transitioned from creating new features to polishing the release. Expect a singular focus on quality for the remaining preview releases.
As a new open-source library, we present to you a read-only in-memory database that focuses on management use of master data.
We made it from our experience in game development up until now with an emphasis on the three points of “Saving memory (also because it is called in-memory, it pays attention to memory usage)”; “High-speed database loading (when it takes a long time to build, it will have a major effect on a game’s startup speed)”; and “High-speed search (similar queries as dictionary lookup.)”
In this series I’ve been looking at the Microsoft.FeatureManagement library (which is now open source on GitHub 🎉). This provides a thin layer over the .NET Core configuration system for adding feature flags to your application. But this library is new, and the feature flag concept is not – so what were people using previously?
Patterns to help you incrementally migrate from a monolith to microservices.
Big Bang rebuilds of systems is so 20th century. With our users expecting new functionality to be shipped ever more frequently than before, we no longer have the luxury of a complete system rebuild. In fact, a Big Bang migration of a Monolithic architecture into a microservice architecture can be especially problematic, as we’ll explore in this talk. We want to ship features, but we also want to change our architecture – and many of us want to be able to break down existing systems into microservice architectures. But how do you do this while still shipping features?
In this talk, I’ll share with you some key principles and a number of patterns which you can use to incrementally decompose an existing system into microservices. I’ll even cover off patterns that can work to migrate functionality out of systems you can’t change, making them useful when working with very old systems or vendor products. We’ll look at the use of stranger patterns, change data capture, database decomposition and more.