That’s correct — you pay for the storage yourself in S3, and then you pay for the storage when it’s in the Regatta cache. We may expose the ability to limit the cache size in the future for teams who need controllable costs more than the highest performance.
This is super dependent on the application, and not something that I could answer without being an expert in SQLite. If SQLite only allows a single reader or writer, then yes. This could still be a good choice for applications which elect a “leader” to serve the database, though.
I have spent a lot of time thinking about this and believe that the most straight forward solution for long running (or even forever running) workflows is to allow hot upgrades.
A hot upgrade would only succeed if you can exactly replay the existing side effect log history with the new code. Basically you do a catchup with the new code and just keep running once you catch up. If the new code diverges, the hot upgrade would fail and revert to the old one. In this case, a human would need to intervene and check what went wrong.
There are other approaches, but I feel like this is the simples one to understand and use in practice. During development you can already test if your code diverges, using existing logs.
Is this the problem where you have workflows live and in progress, yet you want to update the workflow and have things not break? Would you want to have multiple versions at once, or rather some way to migrate the in progress ones to the latest workflow definition?
For short lived workflows, you may not care about updating; just let it finish.
For longer jobs, you want some way to replace the current logic and either resume from where the job left off, or restart it idempotently. Especially if your workflow spans months or years (which at least some of these systems are designed for).
The challenge is these systens shine when you manage the job state in-memory, but they don't "store" the data in a traditional sense. They just replay your logic and replay the original I/O results. So if your logic changes, the replay breaks and your state goes bye-bye.
(I think of it similarly to React's "rules of hooks": you can't do anything that makes the function call key APIs in a different order than previous executions)
So you either accept that you can never update an in-flight job (in a meaningful way, at least), or you track job state in some other system and throw away the distinguishing feature of these systems.
I'm curious how people normally handle this. When I worked with Azure Durable Functions I couldn't find a way around this.
I think the problem works both ways too, because for an in progress (but long-running) workflow, you may not want to retroactively apply your new business logic for the part that's already run because that would be unexpected. But for the logic that hasn't run yet, you would certainly want the latest and greatest.
I wonder if there could be an approach where you have both versions live simultaneously, and introduce some sort of "checkpoint" into the old version that would act similar to a DB migration. When re-computing a workflow you could then start from the latest checkpoint, but any workflows that were created with the old version that haven't reached a checkpoint would continue to run the old code until it does.
As a fellow German I didn't go induction on purpose, because I prefer the ceramic hob cooking experience. "Pans cannot be used" wasn't part of the decision. Having "control nobs" on the front rather than a touch area on the cooking surface was a hard requirement for me though and seems to be getting rarer every year.
I'm actually amazed how much people love induction here, but I guess that's also because it's mostly compared to gas?
What? Ceramic cook tops are crap, they get stained easily, scratched easily, and in the US at least, the way they work to "adjust" the temperature is to cycle on and off every few seconds.
Oh and if any of your pots or pans get warped, they become completely unusable!
Drop anything heavy on it, and the cook top breaks.
I once waited for 20 minutes for a small pot of water to boil on a ceramic cook top.
The old fashion coil burners are better than the stupid glass top ones.
My ceramic cooktop is basically stain and scratchfree after using it for cooking 4-5 times a week for 8 years. It's incredibly easy to clean as you can literally scratch of everything that doesn't just wipe away.
The temperature does cycle on and off usually based on a thermometer, so it does hold the selected temperature. I don't get why that's a drawback for you? The cooktop will literally be kept to your selected temperature.
Also the induction cooktops I know use the same kind of glass or ceramic plate on top, so you have the same advantages/disadvantages in regards to scratching, cleaning and breaking it.
Some glass top stovs work better than others. I won't go back to coils, but I currently have a glass top that bad. However I've has glass tops that were good so I know they exist. But I'll take gas over electric anyday. (I have never used induction so I reserve the right to change that stance)
I have induction with the control nobs to the front in the oven. That does exist, I guess you have to buy it together with the oven.
Induction is greatly superior to electric heating plates, ceramic or even metal, as it is much faster and more energy efficient. Whenever you use it you never want to go back.
Built-in separate cooktops are only the fashion trend right now, there isn’t anything intrinsic in induction that require such controls. This goes hand in hand with the separate built-in oven trend (often with a second oven or a microwave). Kitchen renovation fashion, I guess.
Yea I know it exists, it was just really rare from my limited shopping experience.
I have used induction a couple of times when cooking at my parents house and in a friends kitchen and I happily stay with my ceramic cooktop. Induction is much quicker and more energy efficient, but I just like that I literally control the heat on a fixed size cookfield rather than controlling the strength of the current, where effective heat will depend on the size of the pan.
Don't have one, but used to have cheap counter top thing. I think only pan or similar I can't use is my ceramic dutch oven. Never browned anything in that one either, so it is pretty academical... Just need to check the pans you pick up and you will be fine in general.
I would have liked an example of an attack this is supposed to stop.
I assume. something like this, but the article really isn't clear about that:
You're using a CDN which got compromised, but your CICD servers haven't and your DNS provider also hasn't been compromise. Therefore by looking at some DNS records the browser cam verify stuff that's loaded within your domain from a 3rd party CDN.
Or maybe, your TLS certs were hacked, but not the ones from the Cloudflare hash registry.
TBH those don't really seem like common attack vectors. If you're a state level actor and can fake TLS, the later example doesn't work and if your CDN gets hacked, chances are high this vendor is also your DNS and CI/CD provider...
