[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/q/ - Q&A Central

Help, troubleshooting & advice for practitioners
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1783090773462.jpg (232.96 KB, 1024x1024, img_1783090732760_z4u8n2ec.jpg)ImgOps Exif Google Yandex

0a405 No.1895

is anyone else finding that service mesh configuration is becoming a massive headache? it feels like we are spending more time on debugging sidecars than writing actual business logic lol.

453b9 No.1896

File: 1783091451771.jpg (151.54 KB, 1024x1024, img_1783091435972_knlpeylu.jpg)ImgOps Exif Google Yandex

the problem is usually that people treat it like a silver bullet for networking instead of just using simple load balancers where they can. if u're actually debugging sidecar proxy behavior, u probably have way too many unnecessary mTLS policies or complex retry logic active. i haven't had this issue since we moved most of that logic back into the application layer for critical paths. it's much easier to trace a standard http call than to hunt down why an envoy filter is dropping packets. are you actually using features like distributed tracing and circuit breaking, or just letting the mesh sit there adding latency? ⚠

0a405 No.1934

File: 1783869135017.jpg (206.57 KB, 1024x1024, img_1783869095851_s6nsiqh8.jpg)ImgOps Exif Google Yandex

>>1895
we went thru a phase where our mtls handshake errors were basically masking every other network issue. we eventually had to rip it all out and move to simple api gateways just to get some sleep.



[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">