You operate a logistics company, and you want to improve event delivery reliability for vehicle-based sensors. You operate small data centers around the world to capture these events, but leased lines that provide connectivity from your event collection infrastructure to your event processing infrastructure are unreliable, with unpredictable latency. You want to address this issue in the most cost-effective way. What should you do?
To improve event delivery reliability for vehicle-based sensors and address the issue of unreliable leased lines with unpredictable latency in a cost-effective way, having the data acquisition devices publish data to Cloud Pub/Sub is the most suitable option. Cloud Pub/Sub is a fully managed messaging service that can reliably ingest and process event data while providing automatic retries and fault-tolerance. This allows for improved reliability of event delivery despite the unreliable connections. Additionally, Cloud Pub/Sub scales seamlessly, reducing costs associated with over-provisioning infrastructure.
Should be B
C. This is a tricky one. The issue here is the unreliable connection between data collection and data processing infrastructure, and to resolve it in a cost-effective manner. However, it also mentions that the company is using leased lines. I think replacing the leased lines with Cloud InterConnect would solve the problem, and hopefully not be an added expense. https://cloud.google.com/interconnect/docs/concepts/overview
Yea, this would definitely solve the issue, but it's not "the most cost-effective way". I think PubSub is the correct answer.
I agree, C is the only choice that addresses the problem. The problem is caused by leased line. How come pub/sub service can resolve it? Pub/sub will still use the leased line
the question also talks about a cost effective way...
DEFINITELY NOT COST EFFECT. C IS THE WORST CHOICE.
B. Have the data acquisition devices publish data to Cloud Pub/Sub. This would provide a reliable messaging service for your event data, allowing you to ingest and process your data in a timely manner, regardless of the reliability of the leased lines. Cloud Pub/Sub also offers automatic retries and fault-tolerance, which would further improve the reliability of your event delivery. Additionally, using Cloud Pub/Sub would allow you to easily scale up or down your event processing infrastructure as needed, which would help to minimize costs.
Feels like everyone is wrong. A. Deploy small Kafka clusters in your data centers to buffer events. - Silly in a GCP cloudnative context, plus they have messaging infra anyway B. Have the data acquisition devices publish data to Cloud Pub/Sub. - They have messaging infra, so why? Unless they want to replace, it, but that doesn't change the issue C. Establish a Cloud Interconnect between all remote data centers and Google. - Wrong, because Interconnect is basically a leased line. There must be some telecoms issue with it, which we can assume is unresolvable e.g. long distance remote locations and sometimes water ingress, and the telco can't justify sorting it yet, or is slow to, or something. Leased lines usually don't come with awful internet connectivity, so sound physical connectivity issue. Sure, an Interconnect is better, more direct, but a leased line should be bullet proof. D. Write a Cloud Dataflow pipeline that aggregates all data in session windows. - The only way to address dodgy/delayed data delivery
B is the answer.
yes it is B. Have the data acquisition devices publish data to Cloud Pub/Sub.
As usual the answer is hidden somewhere in the Google Cloud Blog: "In the case of our automotive company, the data is already stored and processed in local data centers in different regions. This happens by streaming all sensor data from the cars via MQTT to local Kafka Clusters that leverage Confluent’s MQTT Proxy." "This integration from devices to a local Kafka cluster typically is its own standalone project, because you need to handle IoT-specific challenges like constrained devices and unreliable networks." 🔗 https://cloud.google.com/blog/products/ai-machine-learning/enabling-connected-transformation-with-apache-kafka-and-tensorflow-on-google-cloud-platform
The question is asking from the on-premise infrastructure, which already has the data, to the event processing infrastructure, which is in the GCP, is unreliable.... it not asking from the sensors to the on-premise...
I might have to retract my answer... Are they talking about GCP in this question? where is the event processing infrastructure?
Are they talking about GCP in this question? Where is the event processing infrastructure? Answer A, might be correct!
Best answer is A, By using Kafka, you can buffer the events in the data centers until a reliable connection is established with the event processing infrastructure. But go with B, its google asking :P
I read this question again, I wanna answer C. Buying Data acquisition devices and set them up with sensor, i dont think its practical approach. Imagine, Adruino is cheapest IOT available in market for 15 dollars, but who will open the sensor box and install it .. omg,, its a big job. This question depends if IOT devices that are attached to sensor needs to be programmed. Big Headache right. Use google cloud connect to deal with current situation. Or reprogramme IOT if they have connected with sensors.
It has to be B.
Cloud Pub/Sub, it supports batch & streaming , push and pull capabilities Answer B
yeah, changing whole architecture arround the world for the use of pub/sub is so much more cost efficient than Cloud Interconnect (which is like 3k$).. It's C.
It's not a Cloud Interconnect, it's a lot of interconnect ones per data center, PUB/SUB addresses all the requirements. Its B
ALSO, the problem it's no t your connection, its the connectivity BT your event collection infrastructure to your event processing infrastructure, so PUSUB it's perfect for this
Wouldn't using cloud interconnect also result in amendments to each of the data center around the world? I don't see why there would be a huge architecture change when using PubSub, the publishers would just need to push messages directly to pubsub, instead of pushing to their own cost center. Also, if the script for pushing messages can be standardised, the data centers can share it around to
pub/sub is region is a global service It's important to note that the term "global" in this context refers to the geographical scope of the service
The question is misleading. But should be C since it addresses the unpredictablility and latency directly.
its says with unpredictable latency and here no need to worry about connection So B is the right one
I don't know why B is the most voted. The issue here is unreliable connectivity and C is the perfect use-case for that
Even with Cloud Pub/Sub, unpredictable latency or delays could still occur due to the unreliable leased lines connecting your event collection infrastructure and event processing infrastructure. While Cloud Pub/Sub offers reliable message delivery within its own network, the handoff to your processing infrastructure is still dependent on the leased lines. Replacing leased lines with Cloud Interconnect could potentially resolve the overall issue of unpredictable latency in event processing pipeline but it could be unnecessary expense provided data centers distributed world wide. Cloud Pub/Sub along with other optimization techniques like Cloud VPN or edge computing might be sufficient.
Option B: Have the data acquisition devices publish data to Cloud Pub/Sub. Rationale: Managed Service: Cloud Pub/Sub is a fully managed service, reducing the operational overhead compared to managing Kafka clusters. Reliability and Scalability: Cloud Pub/Sub can handle high volumes of data with low latency and provides built-in mechanisms for reliable message delivery, even in the face of intermittent connectivity. Cost-Effective: Cloud Pub/Sub offers a pay-as-you-go pricing model, which can be more cost-effective than setting up and maintaining dedicated network infrastructure like Cloud Interconnect. Global Availability: Cloud Pub/Sub is available globally and can handle data from multiple regions efficiently.