131–140 of 153 posts
So: end-user -> app -> expensive_operation -> increase number of instances
rather than:
end-user -> app -> flame -> app_pool -> expensive operation -> scale pool
I guess this isn't 'specific parts' of my code by practically aren't you using the same app image in the pool? You'd have to have ffmpeg available, for example. I'm not sure I see the difference.
Earlier quoted context omitted.
That's why I'm always wary of people who hardly ever seem to stay anywhere more than a couple of years. There's valuable learning (and empathy too) in having to see your own decisions and creations through their whole lifecycle. Understanding how tech debt comes to be, what tradeoffs were involved and how they came to bite later. Which ideas turned out to be bad in hindsight through the lens of the people making them…
>That's why I'm always wary of people who hardly ever seem to stay anywhere more than a couple of years Do have some empathy for when job markets or life make people move on. I'd like to stay at an employer for more than 1-2 years, but between the layoffs (avoiding them or getting laid off) or the need for a higher salary that often only comes from switching jobs, its not always possible to build tenure. Frankly its…
I got way more by switching jobs (after 4 years) than I was ever going to get by staying.
Earlier quoted context omitted.
A pattern I see over and over, which has graduated to somewhere between a theorem and a law, is that motivated developers can make just about any process or architecture work for about 18 months. By the time things get bad, it's almost time to find a new job, especially if the process was something you introduced a year or more into your tenure and are now regretting. I've seen it with a handful of bad bosses, at lea…
That's why I'm always wary of people who hardly ever seem to stay anywhere more than a couple of years. There's valuable learning (and empathy too) in having to see your own decisions and creations through their whole lifecycle. Understanding how tech debt comes to be, what tradeoffs were involved and how they came to bite later. Which ideas turned out to be bad in hindsight through the lens of the people making them…
It is possible to avoid these traps, but then there are a lot of traps that we collectively have the wisdom to avoid but individually do not.
I started taking things apart and putting them back together at a very young age. When I was a young man I was in a big hurry to get somewhere, and so I could walk into a brownfield project and slowly reconstruct and deconstruct how we got here, would I have made the same decisions with the same information, and how do I feel about this news. Not only was I not falling into the "1 year of experience 10 times" dilema, I got more like 3-4 years of experience 4 times in 10 years, by playing historian.
My first almost-mentor left me with a great parting gift at the start of the dot-com era. He essentially convinced me of the existence of the hype cycle (in '95!), that we were at the beginning of one/several, he had seen previous ones play out, and they would play out again. Not cycles for new things, mind you, but cycles trying to bring back old things that had been forgotten. Like fashion. If anything it made me more likely to want to excavate the site.
Going into the trap knowing it's a trap doesn't necessarily save you, but it does improve your odds. Of course it also makes you a curmudgeon at a tender age.
Earlier quoted context omitted.
A pattern I see over and over, which has graduated to somewhere between a theorem and a law, is that motivated developers can make just about any process or architecture work for about 18 months. By the time things get bad, it's almost time to find a new job, especially if the process was something you introduced a year or more into your tenure and are now regretting. I've seen it with a handful of bad bosses, at lea…
And don’t forget that the developer fought like hell to use that new process, architecture, pattern, framework, etc
There's only so much interesting code you can add to interesting code, before every single conversation becomes a proxy discussion of The Mythical Man Month - we can't teach anybody new how to use this code in anything like a reasonable time frame. The best we can do is create new experts as fast as the old ones disappear.
Really Interesting Code is more at home surrounded by Really Fucking Boring code. You get so blinded by the implementation details of the Interesting Code that you cannot see the forest for the trees. That is the secret wisdom of Relentless Refactoring. The more I rearrange the pieces the more things I can see that can be made out of them, some of which are better, and a few of which are much better or brilliant.
Last week I implemented something in 2 days that we wanted years ago and didn't do because it would have taken more than a month of 1.5 people working on it to fix. But after a conversation in which I enumerated all the little islands of sanity I had created between Here and There, it took a couple dozen lines of code to fix a very old and very sore problem.
> Also thanks to Fly infrastructure, we can guarantee the FLAME runners are started in the same region as the parent. If customers think this is a feature and not a bug, then I have a very different understanding about what serverless/FaaS is meant to be used for. My division is pretty much only looking at edge networking scenarios. Can I redirect you to a CDN asset in Boston instead of going clear across the country…
> If customers think this is a feature and not a bug, then I have a very different understanding about what serverless/FaaS is meant to be used for. My division is pretty much only looking at edge networking scenarios. Can I redirect you to a CDN asset in Boston instead of going clear across the country to us-west-1? We would definitely NOT run Lamba out of us-west-1 for this work. I'm not sure how you're misundersta…
Every solution is easy when you oversimplify the problem.
None of what you said is true if you care about persistent state in the app. Local reads and distant writes are how you avoid speed of light problems.
Author here. I’m excited to get this out and happy to answer any questions. Hopefully I sufficiently nerd sniped some folks to implement the FLAME pattern in js , go, and other langs :)
I created something similar at my work, which I call "Long Lamda", the idea is that what if a lambda could run more than 15 minutes? Then do everything in a Lambda. An advantage of our system as is you can also run everything locally and debug it. I didn't see that with the FLAME but maybe I missed it. We use it for our media supply chain which processes a few hundred videos daily using various systems. Most other te…
> you can also run everything locally and debug it. I didn't see that with the FLAME but maybe I missed it. He mentioned this: > With FLAME, your dev and test runners simply run on the local backend. and this > by default, FLAME ships with a LocalBackend
Earlier quoted context omitted.
> you can also run everything locally and debug it. I didn't see that with the FLAME but maybe I missed it. He mentioned this: > With FLAME, your dev and test runners simply run on the local backend. and this > by default, FLAME ships with a LocalBackend
Yes, but does mean you can debug it?
With autoscaling runtimes like Cloud Run isn't this the sorta default? So: end-user -> app -> expensive_operation -> increase number of instances rather than: end-user -> app -> flame -> app_pool -> expensive operation -> scale pool I guess this isn't 'specific parts' of my code by practically aren't you using the same app image in the pool? You'd have to have ffmpeg available, for example. I'm not sure I see the dif…
TL;DR: you get granular and programmatic scaling, including the ability to scale using specific resources (for example, machines with GPUs for certain workflows).
Earlier quoted context omitted.
This looks great. Hopefully Microsoft are paying attention because Azure Functions are way too complicated to secure and deploy, and have weird assumptions about what kind of code you want to run.
> weird assumptions about what kind of code you want to run Those "weird assumptions" are what makes the experience wonderful for the happy path. If you use the C#/v4 model, I can't imagine you'd have a hard time. Azure even sets up the CI/CD for you automatically if your functions are hosted in Github. If your functions need to talk to SQL, you should be using Managed Identity authentication between these resources.…
I think our “best” issue is how sometimes our functions won’t be capable of connecting to their container registry. For no apparent reason. We have an Entra ID group that has Arc Pull access and we add new function slot identities to it automatically, and for the most part it works fine, but then suddenly it won’t.
We currently has a pipeline slot, that is completely the same as the four other slots, which will only deploy a new function version if you deploy it twice through the Azure pipeline. We’ve had Microsoft look at it and their suggestion was to delete the pipeline and create it again.
And that’s just part of it. Then comes the VNETs, the subnets the private endpoints and how both subscriptions and resource groups make everything a tiny battle.
I don’t really mind that much, we’re abandoning it in favour of Azure Container Apps and a fully run Bicep + Dapr pipeline and we’re never looking back.
Though, to be fair to Microsoft, the way they designed Azure Functions makes the migration away from them really, really, easy. Which is frankly a brilliant design for the more managed side of “serverless” in my opinions. It’s just a shame that the managed part just doesn’t work very well. The functions themselves work fine, well maybe not if you don’t use .net in isolation, but I can’t speak about that as we weren’t going to trust Microsoft to update our dependencies (even if they are Microsoft SDKs).