bertyjobbo.bsky.social
.NET Application Architect, LFC, music, cricket, golf, history, anything else I can shove into my brain and body.
94 posts
25 followers
57 following
Regular Contributor
Active Commenter
comment in response to
post
It's given me net framework code on multiple occasions. What I usually do is tell it off, then it comes around. Best one was where I asked it about dotnet 9 (late last year) and it gave me an answer then admitted it was a guess "based in dotnet 6". It's still mostly hype #choochoo
comment in response to
post
+1000
comment in response to
post
Incredible. Never knew that was even a temperature you could cook at. TIL. Enjoy! (if you haven't already)
comment in response to
post
52 degrees celcius?
comment in response to
post
Thanks Martin, I get that the mindset shift in some cases is part of the problem. In fact, had that exact conversation with a team recently who only had multi-system (from multiple repos) tests and weren't catching half their defects.
As with anything, it's what works best I suppose.
comment in response to
post
Oh brilliant ok. Sadly I can't be at NDC London but I'll keep an eye out for it from previous conferences (or London if not). Thanks Ian, really appreciate your wisdom on this - it will actually help me in a very real way in some upcoming conversations.
comment in response to
post
The response I usually get is "we do microservices - that's not microservices". Or "just put your logic in nuget packages".
comment in response to
post
It's an argument I've had many times, mainly with DevOps at our org who enforce a "one process per repo" rule. Which makes their work easier, but ours as architects/devs often much harder. And can lead to slow down, and a drop in quality. Or services which can't scales their workloads, separately.
comment in response to
post
I think the "micro" tends to skew bias towards people thinking it means "single process" when really (as you allude to with your database comment) it probably means "small-ish, cohesive, autonomous, logical service" (or whatever descriptor fits the last bit).
comment in response to
post
Thanks Ian. Completely agree with "Micro services belong in the development view". Describes what I'm trying to say in a much better way.
I am somewhat with others who I've heard say "micro" is probably a misleading term. "Service" or "Logic Responsibility/Boundary" is probably more appropriate?
comment in response to
post
I think all I'm arguing is that, that scenario is not unusual, nor legacy. But it's also not the best or only way, of course!
comment in response to
post
Yes, very much "it depends". Also terminology arguments - I'm not describing a monorepo. I'm describing a service repo which might have more than one deployable asset, because that makes the most sense and provides the highest quality software, for the given scenario.
comment in response to
post
Got you. And this is where I have to disagree. I've seen both ways and the separate repo version causes huge amounts of pain for devs. What you're describing is what EA and DevOps at my org enforce. And most teams hate it and it causes many defects because the logic is fragmented across repos.
comment in response to
post
But they'd be part of the same feature/story/PR/MR/deployment right?
comment in response to
post
But agree there's better ways to do most things than the Aspire way. It's neat and kinda fun. But doesn't really solve many problems, yet.
comment in response to
post
But you wouldn't want it in the same deployment/physical view because they need to scale differently. Whether that's old school or not, I'm not sure 😂
comment in response to
post
That's exactly what I'm saying. If you're writing an inventory service, that service might have eg endpoints to add/remove stock and others for querying stock levels from a customer facing {something}. Same logical concern, vastly different priorities. You would want that in the same developer view
comment in response to
post
But don't get me wrong, I see v little value in aspire for anything I've worked on. And feels a *bit* like a lock-in in the way it wants/needs to be in your app code.
comment in response to
post
Totally agree with everything other than the last bit. A logical service can comprise more than one "physical" service. And often should due to different scaling demands. Eg an event subscriber vs an HTTP endpoint.
comment in response to
post
Hey Martin. Re "legacy distributed monolith". What about a cohesive, logical service but might have many physical manifestations? Eg a few APIs and processes for different priority work? Be good for that, no? And that's not legacy.
comment in response to
post
I have to say though, of all the money-making OSS models, suddenly putting a relatively huge price on what is a clever but pretty basic syntactic sugar library, doesn't seem like the one.
comment in response to
post
It feels a little like what is happening in the private sector. That uneasy feeling of "being left behind" but you don't really know exactly what to do, or how it might help.
comment in response to
post
Great summary. One thing that's really killed our org is opinionated orchestration between domains. Classic route to a big ball of distributed mud. Choreography is the dream 💔
comment in response to
post
Saw that. Didn't read like a complaint at all!
comment in response to
post
Can't agree, sorry. Wayyy too much cognitive load for the average dev. I'd rather they spend their brain dollars think about the cohesion and maintainability of their code. Not how or where it's deployed. I've seen all three versions and dedicated team with proper resourcing is best by miles.
comment in response to
post
Definitely 👍
comment in response to
post
That you have to even consider whether or not to say this is an indictment on human nature itself. #LegoNotLegos
comment in response to
post
Oh nice thanks Oskar - I'll give that my full attention later.. 👂
comment in response to
post
Kidding, great album. My Dad used to stick it on the record player almost every Sunday afternoon!
comment in response to
post
comment in response to
post
Dark Side of The Moon? It's got to be in the top 3.
comment in response to
post
I know what you mean about the other albums. I suppose they have more significant, individual songs on them.
comment in response to
post
Oskar, with maximum respect and friendliness, *nobody* is underrating it. It's seminal. The first concept album. The Beatles trying to better Pet Sounds (which is literal perfection). It's incredible. Although... I can live without When I'm Sixty Four.
comment in response to
post
So giving them more money is a terrible idea. But nationalising them also isn't "the answer".
comment in response to
post
Speaking as the husband of a water company employee (sewage side), I promise you that, whilst I agree they should not be for-profit, that is only a very small piece of the puzzle. They have money. That isn't the issue.
comment in response to
post
💪
comment in response to
post
Really interesting, Vaughn. Biggest problem I've encountered with the pattern is in high throughput scenarios, as you describe. Great information, thank you.
comment in response to
post
You have excellent taste, sir.