This is a necessary and an important position to fill, as now-days every dev wants to push for Lambda / Kinesis / SQS and other tech architectures that mainly look cool on their CVs and add nothing to the product (except for risks down the road).
Companies need someone who understands the trade-offs, knows which use cases are right for this architecture and save the company (and future devs working on these systems) a lot of headache.
> now-days every dev wants to push for Lambda / Kinesis / SQS and other tech architectures that mainly look cool on their CVs and add nothing to the product
Is there a way we can push back against this? I feel like the battle has been lost and it's not just devs being guilty of this, it's entire companies.
For a lot of startups it seems that solving the business problem is now secondary to engineering itself, aka how many microservices and moving parts they can cram into their stack so they can then give talks about it and write on their tech blog.
I've lost business in the past because a client wanted to build a prototype with Lambda and similar. They were either severely misguided, or their main objective wasn't to build a successful product but merely present themselves as the next hyperscaler due to the complexity of their tech stack (all to serve a whopping 2 HTTP requests/second, if even).
I think this has been going on forever. I've had to deal with folks since the dawn of time who want to just try and make the geekiest new nerd tech out there part of their project because they want to screw around with something fun. It doesn't matter if it's 10x more complex or hard to support, it's a new toy to play with so folks want to use it.
You have to filter those people out as being unreliable, and also when dealing in enterprise level companies also keep out of the room the complete and utter idiots who have no idea what they are talking about and haven't touched any of the tech hands on in decades but want to also throw up road blocks to everything you propose.
That sum a critical part of my job, help clients navigate and find the middle-ground between bloated old-school enterprise solutions on one end and hype/resume-driven developers on the other.
Two of those are not like the other. Having queues in your system is most of the time a good decision. Decoupling workloads, buffering jobs, distributing workload, all of those are great benefits and with queues you get them all with an extremely simple interface (put, get). There isn't a lot of gotchas (there are some as with any software system) but it's a completely different thing compared to lambdas or kinesis.
