And every 3 months, something is broken or it pukes an error which requires someone 3 hours of debugging and reverse engineering the stack to work out why.įundamentally, event sourcing, as the above, is the outcome of seeing something shiny and covered in marketing and wanting to play with it on any available business case rather than doing a rational evaluation of suitability.
#PL SQL DEVELOPER HISTORY BUFFER FULL#
But no it now needs a GitHub repo full of shite and 2 separate people to understand every facet of it who require 3x the salary of the original dude each. What it should have been was a one page thing in confluence with the business process in it and the sheet attached. This was of course a “massive business risk” and justified a project to replace it. Only after it was implemented we found out it was only run every 3 months and took the original dude 5 mins to paste it into his existing excel workbook and the data popped out in another sheet instantly. The python script itself was about 200 lines of the equivalent of spreadsheet cell manipulation basically. This entire thing had a bunch of lambda layers to pull in the pipeline, a build pipeline in jenkins, terraform to deploy it. We had a guy who spent two weeks writing a report script that collated data uploaded into S3 and wrote out another data lump into S3 after some post processing then sent this data lump to a guy via email.
This is a common problem I see across many things.
#PL SQL DEVELOPER HISTORY BUFFER SOFTWARE#
If you need something more enterprisey to sell to the VP-suite, use Debezium.Įvent sourcing sounds so awesome in theory and it is used to great effect in many demanding applications (like Postgres! WAL = event sourcing with fewer steps) but it's just too complex for non-infrastructure software without resources measured in the 10s or 100s of man years. Use wal2json and subscribe to the WAL stream - if you really need time travel or audit logs or whatever, they'll be much cheaper to implement using WAL. By the time the tooling is up and running enough to make a stable system, no one will trust it enough to use ES's landmark features except for a few developers still coming off the koolaid.ĩ9% of the time when ES sounds like a good idea, the answer is to just use Postgres.
It doesn't even mention the worst part that comes afterwards, when you realize after all of that pain that it is only used by a single person in the company to generate a noncritical report comparing a meaningless KPI that could have been manually done in four hours by a different intern every quarter. These problems are ever present in every ES project I've had the misfortune of coming into contact with. I've worked with several event sourcing systems and was even seduced into implementing one out of sheer hubris once.
0 kommentar(er)
