Leadership wants two public clouds “for safety” for the same Kafka and Spark stack, but the city has deep skills in only one provider. What caution should the Big Data lead raise?
Select an answer to reveal the explanation.
Short Explanation
Owning two brands of fire truck does not help if the crew only trained on one. Multi-cloud “for safety” without skills often doubles the ways things break. Pick depth you can operate before chasing logos.
Full Explanation
Running two public clouds for the same Kafka and Spark stack without matching skills can double failure modes and operational load rather than automatically improving safety. Multi-cloud “for safety” is a strategic choice that demands depth in identity, networking, observability, and streaming operations on each provider. Leadership should hear that caution before logos multiply across the municipal stack.
Two clouds do not always erase every failure mode; they often introduce divergent tooling and incomplete failover practice under stress. Claiming multi-cloud never affects operational complexity for streaming stacks ignores doubled runbooks and skill fragmentation. Skill gaps matter for Big Data platforms at least as much as for desktop office suites when brokers and jobs must be recovered at 2 a.m.
Exam caveat: deliberate multi-cloud for specific portability or sovereignty goals can be valid when staffed and tested; the exam point is that unskilled dual running is not free resilience. Operational check: tabletop a Kafka/Spark outage on the secondary cloud with the current on-call roster and record whether staff can actually recover without the primary provider’s familiar consoles. Document the verified decision in the municipal architecture runbook so future on-call and audit staff inherit the same standard.