CRUD-based Architecture has always been a popular choice with DevOps, but can DevOps and Architects benefit from moving to Event Sourcing-based architecture?

Fettblog is a blog by Stefan Judis, offering articles, tutorials, and insights on web development, JavaScript, and performance optimization. Developers can learn about web development best practices, modern JavaScript features, and web performance optimization techniques to create fast and accessible web experiences.

DZone

CRUD is an acronym for Create, Read, Update, and Delete. This pattern is widely used by businesses across sectors and industries for tracking customer data, employee information, payment records, etc. Event Sourcing is a data storage technique that is seen as an upgrade of CRUD. It is often combined with Domain-Driven Design (DDD) and Command Segregation (CRS)

Why Move From CRUD to Event Sourcing Architecture?

Benefits of Adopting the Event Sourcing Architecture

Do not move from CRUD to Event Sourcing. Dip your toes in event driven architecture. Do not do event sourcing.
This article gives a good picture of the benefits; however, even the creator of event sourcing acknowledges that event sourcing is a HIGHLY complex state management system that should only be used in very tight, narrowly defined contexts, for a single domain, with very few anticipated changes.
You will very quickly run into problems with rehydration from snapshots, event schema versioning, and exponentially complex troubleshooting across distributed systems. Data migrations will be a nightmare. Task based UIs will become your bane.

This is something I’ve considered for a number of applications: game state, for example, might best be expressed as a series of events rather than a final state.