The straight is narrow enough that they could use artillery to hit the ships in it.
And for US and/or Israel to prevent it, they would have to occupy the correspondingly wide strip of Iranian coast. At which point we're talking about a massive ground invasion (and of course then the same artillery would be firing at those troops, so you can't really just stop there either).
Desert Storm involved half a million troops on the ground. Iran is about 4x the size of Iraq and has more than 3x the population. The part of Iraq involved was flat desert terrain. Most of Iran is mountainous.
> During Desert Storm, US batteries returned fire before enemy rounds even hit apogee.
That's something ground-based. And to avoid counter-battery fire, tanks move after every shot.
The Arleigh Burke class of destroyers[0] might have similar capacity since each one holds 90 missiles in the vertical launch system[1] (so they might be loaded with anything: anti-ship, anti-sub, anti-satellite, anti-aircraft, ground attack or maybe anti-missile missiles). However, to reload those missiles involves several days in port. There are only 75 Arleigh Burke destroyers at this time. Not all are near the Gulf. It wouldn't be too hard for Iranian forces to fire $10k drones that require $1M missiles to stop.
Not the military, the IRGC. Which is a religiously indoctrinated military.
So it would still be a theocracy, same as before, but now also run by people who are conditioned to believe that more violence is always a solution to any problem.
> Hegseth: "God deserves all the glory. Tens of thousands of sorties, refuelings, and strikes, carried out under the protection of divine providence. A massive effort with miraculous protection."
I recently had Codex working for 80+ hrs non stop (as in literally that was a single running session in response to a single prompt!).
Even at $200 monthly subscription that kind of stuff burns through tokens at a rate where it's very difficult to believe that they are even breaking even, never mind profit.
The project is a semantic parser for Lojban that emits Lean. The specific task was to add the ability to go in reverse - from (a subset of) Lean back to Lojban. So the bot had a corpus of something like 25K test cases that it had to make roundtrip, and instructions to keep going until the test suite is green.
That's an argument for components with well-defined contracts on their interfaces, but making them microservices just complicates debugging for the model.
It's also unclear whether tight coupling is actually a problem when you can refactor this fast.
Whether you call it modularization, good design, SOLID principles, or micro services, etc. It all boils down to the same thing. I usually dumb it down to two easy to understeand metrics: cohesiveness and coupling. Something with high cohesiveness and low coupling tends to be small and easy to reason about.
Things that are small, can be easily replaced, fixed, changed, etc. with relatively low risk. Even if you have a monolith, you probably want to impose some structure on it. Whenever you get tight coupling and low cohesiveness in a system, it can become a problem spot.
Easy reasoning here directly translates into low token cost when reasoning. That's why it's beneficial to keep things that way also with LLMs. Bad design always had a cost. But with LLMs you can put a dollar cost on it.
My attitude with micro services is that it's a lot of heavy handed isolation where cheaper mechanisms could achieve much of the same effects. You can put things in a separate git repository and force all communication over the network. Or you can put code in different package and guard internal package cohesiveness and coupling a bit and use well defined interfaces to call a functions through. Same net result from a design point of view but one is a bit cheaper to call and whole lot less hassle and overhead. IMHO people do micro-services mostly for the wrong reasons: organizational convenience vs. actual benefits in terms of minimizing resource usage and optimizing for that.
> Or you can put code in different package and guard internal package cohesiveness and coupling a bit and use well defined interfaces to call a functions through.
While I do think actual microservices are over-kill. I don't think I've seen code anywhere that survives multiple years where somebody doesn't use internal state of another package. Like if you don't force people to use a hard barrier (i.e. HTTP) then there's going to be workarounds.
The problem with the latter has always been the same. It requires careful review to ensure that system boundaries aren't being crossed. It's very obvious if your repo sounds to access to a new database. Less so if it imports a function directly from an inappropriate package.
No, I think you’re not reading it literally enough. “Microservices” generally does mean separate HTTP (or at least RPC) servers. Near the beginning, the article says:
A microservice has a very well-defined surface area. Everything that flows into the service (requests) and out (responses, webhooks)
Are you purposely misreading the comment? Where did it say that http was the only form of communication (or even the best) between microservices? Where did it imply there weren't other methods?
> While HTTP can be considered as a transport layer for RPCs between microservices, it seems to me to be a very inefficient and bug-prone solution.
This is so irrelevant to the point being made it's nuts.
Why arbitrarily invent new meanings (for microservices) and new words (microlibraries) when there are already many adequate ways to describe modular, componentized architecures?
A totally valid and important point but it has been diluted by talking about microservices rather than importance of modular architectures for agent-based coding.
And for US and/or Israel to prevent it, they would have to occupy the correspondingly wide strip of Iranian coast. At which point we're talking about a massive ground invasion (and of course then the same artillery would be firing at those troops, so you can't really just stop there either).
reply