Sure, I was perhaps too hyperbolic. In my case, the advantage was specifically fault isolation for a multi-tenant, low traffic, demanding workload that was traditionally deployed as a physical service.
It all depends, I think. I once used multi-threading to speed up the initialization of a Lambda which was just a "port" of a beefy rest service. It was ported to cut costs and for fault isolation. I managed to gain 2-3 seconds of initialization time, but it was something.
A Lambda deployment has the advantage that no one needs to manage it, and faults are isolated between clients. You could argue that if you need these properties your engineering organization has deeper flaws, and you'd be right, but in many companies engineers need to make do with what they get.
Your points are valid if your priority is to reduce cost. Totally agree. That said, Lambda has an API and SDK, and concurrency is managed. Warm up is a nightmare if you don't develop specifically for Lambda, but scalability is easy. There are trade-offs, it sucks for many use cases, but I don't think you should just shrug it off.
It's possible, but it requires investment, and it's likely to slow down productivity a little. The default approach in big traditional corps (not implying Apple is traditional) is to leave it up to IT, and maybe hire a Security Officer to signal virtue and assign blame.
To my shame I had never tried ADA before, but after a cursory look I find the syntax similar to Oracle's PL/SQL, which evokes many bad memories. I am sure I will be able to enjoy the language once I pass this barrier.
Well, for a system to be consistent (in the meaning of CAP) AND available, the problem with the concurrent writes would have to be solved anyway (i.e. via distributed locking), so I don't think this would be an issue after a partition event.
Always wondered, if the CAP theorem does not account for latency, one assumes infinite latency does not impact availability. Shouldn't then be possible to define a theoretical system with an infinite buffer that, in the event of a network partition, will simply keep all incoming requests on hold (infinitely or until the partition is undone), satisfying CAP?
I know this is a useless construct in practice, and there is probably a flaw in my reasoning, but it seems to me that you have to establish a non-infinite timeout for the proof to be consistent.
Do you think depth estimation could be done with two cameras plus computer vision (to find markers)? I think this is more or less what we do with our own eyes. Of course you would need much more processing power, but maybe for some applications the robot's brain doesn't need to be inside its body.
> Everyone is shy. Other people are waiting for you to introduce yourself to them, they are waiting for you to send them an email, they are waiting for you to ask them on a date. Go ahead.
While that is true, a microservices architecture can (and in my opinion should) rely on messaging and account for message schema evolution. Dependencies between services should be way less coupling than dependencies between an application and a library.
> invites developers to come up with clever explanations and workarounds instead of careful engineering
I don't like the accusative tone when talking engineering. There are plenty of good reasons not to use server-side sessions, including the need to replicate them between nodes, or otherwise offload them to an external database, and if you do it asynchronously you have to make your clients sticky. People use JWT to achieve statelessness, which makes it easier to increase availability.
The siblings already said it, but event sourcing requires you (at least for practical purposes) to segregate the read model from the write model using "projections". The good thing is that, whenever you create a new service, you can derive the projections that your service will need from the same source of truth. In this way, you create coupling on the data, but not on the concrete service that owns it.
This is not very different from what a relational database does with redo logs. In fact, in a way, using event sourcing resembles composing a system from the fundamental building blocks of a traditional DBMS, in a distributed way.
I agree with you, maybe except about the atomicity part. When you use event sourcing, your source of truth becomes the event log, so transactioning against your local representation of the state does not give you the same guarantees.
No, you should not compute the state you need from the event log on every request, this would be absurd. Your authorization service can maintain its own database (a "view" of the current state), or even an in-memory representation computed at startup, and update it whenever a new event pops up. Alternatively, if you are using Kafka, you can use stuff like KTables to do this.