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.