3 ms·

> You don't need 15 lambdas, 4 micro-services, dynamoDB, API Gateway, etc. to build your internal app that gets 10 TPS I keep trying and failing to make this a

> You don't need 15 lambdas, 4 micro-services, dynamoDB, API Gateway, etc. to build your internal app that gets 10 TPS I keep trying and failing to make this argument at work. The majority of the team are primarily PHP developers and if you want their best and quickest work they can write you a perfectly good internal service in PHP. But someone several levels above me drank the kool-aid and now everything takes four times as long and turns out crappy because half the team is spinning wheels learning new proprietary cloud tech and reimplementing the base-level tooling we already had. I am yet to hear any explanation why this cost is worth it beyond vague mutterings of “scalability” and “enterprise”.

frank_nitti 2y ago
We had a “monolithic” on-prem application that was forced to rewrite for cloud. The original system was blazingly fast — it was actually a set of composable TCP workers and coordinators, but repeatedly called dirty names like monolith, legacy, synchronous by ambitious managers trying to demonstrate the need to migrate. Proceed to bring on legions of contractors and offshore teams to move everything to HTTP and AMQP, fully coupled to the cloud vendor’s mechanisms for these with all of the goodies. Today they are paying a fortune for a slower system, full vendor lock-in, real customers dismayed and prospective customers aghast at the prices. Recently they came back to the original engineering teams to “make it a real-time system” and panicked at the realization that this capability was unceremoniously sacrificed in the name of microservices, the cloud for the sake of hot-shot aspiring upper management to make their name in “modernizing” the tech. Yikes
- ffsm8 2y ago
  You gotta remember that the optimal career choices of an engineering manager in medium to large enterprise are technically highly destructive to the health of the company and productivity of the people they're managing. They need to balloon the amount of people they manage and be involved in as many projects as possible for bullet points on their CV when they're applying for the next position.

frank_nitti 2y ago

We had a “monolithic” on-prem application that was forced to rewrite for cloud. The original system was blazingly fast — it was actually a set of composable TCP workers and coordinators, but repeatedly called dirty names like monolith, legacy, synchronous by ambitious managers trying to demonstrate the need to migrate. Proceed to bring on legions of contractors and offshore teams to move everything to HTTP and AMQP, fully coupled to the cloud vendor’s mechanisms for these with all of the goodies. Today they are paying a fortune for a slower system, full vendor lock-in, real customers dismayed and prospective customers aghast at the prices. Recently they came back to the original engineering teams to “make it a real-time system” and panicked at the realization that this capability was unceremoniously sacrificed in the name of microservices, the cloud for the sake of hot-shot aspiring upper management to make their name in “modernizing” the tech. Yikes

ffsm8 2y ago
You gotta remember that the optimal career choices of an engineering manager in medium to large enterprise are technically highly destructive to the health of the company and productivity of the people they're managing. They need to balloon the amount of people they manage and be involved in as many projects as possible for bullet points on their CV when they're applying for the next position.