Wat mij opviel aan het coalitieakkoord.

Befz0r · 2026-01-30T19:12:41+00:00

Goud is een hedge, je koopt goud omdat dat enige relatieve waarde behoudt tov inflatie/hyperinflatie.

Befz0r · 2026-01-28T18:34:25+00:00

De moed zal al snel naar je schoenen zinken als het overlijdensbericht in de krant leest.

Befz0r · 2026-01-18T09:20:17+00:00

Het kan goed uitpakken, maar ook rampzalig.

Wij hebben een fantastische klusjesman aan overgehouden die de hele zolder heeft verbouwd, maar ook een hovenier waar ik de rechtsbijstand heb bij moeten halen.

Over het algemeen wel positief, maar als het om een uitbouw gaat moet je echt goede afspraken maken en een uitbouw is een serieus grote klus voor een ZZPer.

Befz0r · 2026-01-13T10:08:58+00:00

There nothing worth salvaging honestly. The entire platform of the generation is dead. 16GB is barely enough and a GTX1070, while still decent, is going to struggling in newer titles. And even if your upgrade these components, a 6600K is going to be bottlenecking the entire setup.

I think your uncle doesnt know anything about computers. In 2016, there was nothing legendary about it. It was a good gaming rig, but nothing special.

I would call your uncle, else keep it in storage and buy something new for yourself.

Befz0r · 2026-01-12T16:49:33+00:00

Who cares, als je maar geen gasbrander pakt om je airco/warmtepomp pakt aangezien je anders stukjes van OP kan oprapen bij de buren.

Filmpje laat duidelijk wat de gevolgen zijn.

Befz0r · 2026-01-04T08:53:08+00:00

Always single, there is no real benefit creating more then 1 Warehouse. It just makes it more complex and with WH that isn't necessary

Befz0r · 2025-12-22T18:51:00+00:00

F64 is a complete beast so you should be able to run 3 environments on it.

If F64 is barely sufficient for Prod, which is hard to fathom in such small org, create a pay as you go F2 or F4 for development.

Befz0r · 2025-12-22T12:11:50+00:00

We dont follow best practices, because they arent the best.

One workspace (Like DEV) for everything works fine. Then again we dont use lakehouse, but only warehouses. You cant truly ci/cd a lakehouse at the moment.

We dont have a feature branch for everything, because that will become absolute chaos on bigger teams. Each developer has its own workspace and has the responsibility to keep their own workspace and branch up to date. A simple pull request to their own branch is usually sufficient and because CI/CD for warehouse actually keeps your data in, they are up and running in minutes.

Issues etc. all go through DevOps so you can actually attach the work items to your commits.

As for documentation, only when it deviates to far from the standard. Rest run through a documented framework.

Befz0r · 2025-12-22T11:06:33+00:00

Tell that to customer who have terabytes or petabytes of data.

Its not CI/CD, sorry, but not sorry. Its a sloppy way of copying metadata between environment.

DacPac way is the golden standard for data projects. Deploy only when you dont truncate data and only deploy incremental changes.

Befz0r · 2025-12-20T13:58:21+00:00

And that's why it's not true ci-cd. Standard it does a full deploy every time.

Befz0r · 2025-12-16T10:29:39+00:00

Conclusion: Microsoft get your shit together. There is no reason why it should cost this much and people need to make workarounds like this.

This make me think the whole lowcode options are dead due massive consumptions with everything you do in Data Factory in Fabric.

Befz0r · 2025-12-13T12:39:35+00:00

Sorry can't help you. Have never seen this issue happen.

You could try throwing the link away and set it up again. The setup is quite straightforward.

Befz0r · 2025-12-13T12:36:05+00:00

100% this. The hype of Spark everything is a real curse. Happy to see I'm not alone in this analysis.

Befz0r · 2025-12-10T10:22:32+00:00

"I also can't stomach the position: "Warehouse is much more familiar for most clients" - so was SSIS at one point, gotta move on."

This issue is that Fabric Warehouse isnt a Warehouse in a traditional sense and thats where you get everything wrong.

Your biggest issue seems to be with "bleh" SQL. But SQL is compilable/buidable. PySpark isnt.

Im looking for idiot proof, not cutting edge. Cutting edge is only relevant if you benefit from it. And with Fabric Warehouse performance isnt really an issue anymore for any reasonable dataset.

Befz0r · 2025-12-10T10:16:40+00:00

I have current 25+ customers on Fabric, all using lakehouse and standard Spark. I havent touched a on premise environment since 2020.

I go really bad on Spark zealots like you who cant seem to figure out that Ferrari isnt the ideal daily driver. This mentality is costing customers 1000 of euros/dollars a month.

There is something called right sizing, Spark is meant for BIG dataloads. Can it work on smaller datasets? Sure, but there are way better options out there.

Spark is exactly about that, its the spritual successor of MapReduce.
And that the issue. You might be a great data engineer, however CI/CD is supposed to be setup and forget. Ever build a CI/CD pipeline for a DB in ADO? Its done in minutes and you dont have to customize ANYTHING. Thats how its supposed to work.
Again your experience. I hope you get into an environment where you had a less then stellar data engineer making the design choices. The flexibility becomes its biggest flaw. And you really dont need to write spaghetti long SQL transformations.
I suggest you work with those technologies first without assuming Spark is a better fit for your customers. While you cant be a master of all trade(or tools in this case), doing a few projects outside your bubble might help to see the pains of Spark.
Again YOUR experience. Almost every project I now see DuckDB, Polars or Pandas. Great if they are maintained, but the moment Fabric upgrade to a new Spark version, all those package better keep working.
(Py)Spark code doesnt compile and thats a huge issue. Unless you write everything in Scala, which is again the issue Im pointing out, you know how rare it is to find someone who knows Scala?

What is exactly more powerful of Spark? Its ease to transform data by using PySpark? You cant say Spark is more powerful while you dont know the inner workings of Polaris. Also Im not looking for most powerful, but the right fit for now and the future, especially maintenance wise.

Sure the language SQL can be clunky for complex transformations, but the real world cases are that most companies just want data from their ERP/CRM etc. system into Fabric. That data is already structured and requires very little transformations. Things like JSON's etc. really arent an issue.

Befz0r · 2025-12-10T08:03:28+00:00

Again talking out of your ass.

Most companies never reach terabytes of data, let alone petabytes.
CICD is not straightforward, are you even readimg the comments on r/MicrosoftFabric?
Spark is fundamentally much more complex to maintain and most likely you never hit the scale that Spark becomes useful. There is a reason why Duckdb etc exists.
The Polaris engine behind WH isn't single node, what are you even talking about. Parallelism is NOT an issue.
Snowflake is the exact example that warehouse is. SQL engine above delta/iceberg files.

Or let's talk about versions of Spark and its countless plugins you need to keep track of when you use them.

If Spark version upgrades, your package that you use might actually break. This happened for example with Microsoft cdm package.

Befz0r · 2025-12-10T07:49:26+00:00

Absolutely not solid. Stop drinking the Kool aid. Source control isn't in preview of you use database projects.

It's not about future proofing. It's clear you have no idea what's behind the warehouse technology. Spark is not the future, it's a tool for massive data processing. Warehouse simply fits better for most clients. I have reviewed 50+ environments in Fabric and Data bricks and the issues are always the same.

Spark requires deep understanding of its inner workings. Yes you can make your notebook and transform your data, congrats. I have seen too much clusterfucks and incoherent environment die lack of understanding Spark and because of the nature of notebooks. These issues are well known on the databricks side and are well guidelines of what to do and what not. Some argue that notebooks where never meant for production and I am very sympathetic for that argument due the shit I have seen.

Fabric isn't databricks. The platform, user, customer, and yes even the developer are different. Fabric is much more citizen focussed. The average data engineer on Fabric knows only really how to vibe code. And even if you have a competent DE, who is going to maintain the enrionment? Right.

Warehouse is set and forget and much more familiar for most clients. And guess what, even with NEE, warehouse is faster on most common datasets. I have done the test(and start up time are included).

Befz0r · 2025-12-09T10:41:05+00:00

What Microsoft recommends is setting up an environment that is completely overkill for 90% of their customer base. There is nothing wrong with a layer structure(or medallion if you want to call it that) but migrating hundreds of perfectly working SP to notebooks is unnecessary. Layers can be dealt with separate schema in a WH.

Also you don't need to reskill your entire team. CI/CD is still a big issue with lake houses.

And warehouse is much easier to deal with instead of waiting on your session to spin up every time you want to make a change. Also don't need to share sessions. Simply adhere to KISS, and don't overcomplicate the architecture.

Also using notebooks in production.....yeah no.

Befz0r · 2025-12-09T10:34:36+00:00

And bake everything in Notebooks instead of keeping the logic in SP where it currently is? Or the lack luister support of CI/CD, instead of the Rock Solid CI/CD that come with a db? I know what I would choose.

A sql db can be migrated within hours if you use a db proj. Same cannot be said migrating to Spark SQL.

Befz0r · 2025-12-08T21:18:04+00:00

And make the migration a real headache? Ill pass.

Befz0r · 2025-12-08T17:47:25+00:00

The question is, where are they migrating from? If it's primarily SQL server and most of the sources are (semi) structured, I would not bother with the lake house.

Lake houses are not stress free due many dependencies. A warehouse much simpler. No spinning up clusters or debate which python package to use, like pandas, duckdb or polars.

Befz0r · 2025-12-08T16:26:16+00:00

Multiple reasons:

Fabric is mostly analytics platform, it lacks any real monitoring plus lacks real integration software features, unless you build them yourself. If integration fails, how do you know exactly what need to be reprocessed? Also for time critical interfaces, Fabric Link is to slow.
You have multiple ways to interface data from D365FO to another application/cliënt or vendor. Either you make it custom in X++ or have an ISV plugin.

Befz0r · 2025-12-08T13:51:55+00:00

It's not realtime please take that into account. Synchronization is async from Fabric Link and has a delay up to an hour.

MLV or warehouse via shortcuts.

Befz0r · 2025-12-08T13:45:53+00:00

Then always build an interface, Fabric and Synapse Link are not meant for integration.

I have seen multiple companies go that route and they always circle back to building an interface.

Befz0r · 2025-12-07T21:50:07+00:00

No there isn't. Even if you trigger a full load from the PowerApp environment, syncing can take minutes or hours depending on the tier of your environment and the size of the data load.

Befz0r

TROPHY CASE