Your current IoT Core Services will remain available through August 15, 2023. Start your migration to alternative solutions.
Hello [NAME],<p>We’re writing to let you know that Google Cloud’s IoT Core Service will be discontinued on August 16, 2023 at which point your access to the IoT Core Device Manager APIs will no longer be available. As of that date, devices will be unable to connect to the Google Cloud IoT Core MQTT and HTTP bridges and existing connections will be shut down.<p>Your current IoT Core Services will remain available through August 15, 2023, unless you terminate your usage of IoT Core at an earlier date.<p>What do I need to do?
We recommend that you take action early to migrate from IoT Core to an alternative service. As an initial step, connect with your Google Cloud account manager if you have questions about your migration plans. Your account manager can also help you learn more about Google Cloud partners that offer alternative IoT technology or implementation services that meet your business requirements.<p>Over the next year, we will continue to reach out with additional information to support you during your migration.<p>—The Google Cloud IoT Core Product Team
If you haven't, please read the classic "Dear Google Cloud: Your Deprecation Policy is Killing You" [1] by the always fantastic Steve Yegge (who used to work at Google). As he so succinctly put it, the email follows the standard Google GCP template:<p>Dear RECIPIENT,<p>Fuck yooooouuuuuuuu. Fuck you, fuck you, Fuck You. Drop whatever you are doing because it’s not important. What is important is OUR time. It’s costing us time and money to support our shit, and we’re tired of it, so we’re not going to support it anymore. So drop your fucking plans and go start digging through our shitty documentation, begging for scraps on forums, and oh by the way, our new shit is COMPLETELY different from the old shit, because well, we fucked that design up pretty bad, heh, but hey, that’s YOUR problem, not our problem.<p>We remain committed as always to ensuring everything you write will be unusable within 1 year.<p>Please go fuck yourself,<p>Google Cloud Platform<p>[1] <a href="https://steve-yegge.medium.com/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc" rel="nofollow">https://steve-yegge.medium.com/dear-google-cloud-your-deprec...</a>
3 years ago Google killed off Android Things[1] and told everyone to migrate to IoT Core. Now IoT Core is dead. But don't worry about all that, just connect with your Google Cloud account manager! They'll tell you exactly which Google platform you should migrate to next.<p>[1]: <a href="https://android-developers.googleblog.com/2019/02/an-update-on-android-things.html" rel="nofollow">https://android-developers.googleblog.com/2019/02/an-update-...</a>
Google should just go ahead and shut down their entire Cloud business. I mean, nobody in their right mind would build a business or anything substantial on top of any Google provided service, and the hobbyist market can't be <i>that</i> big. Just go ahead and drop out Google, and quit fucking wasting everybody's time.
I'm in the process of migrating PrintNanny.ai's remote command/event system off Cloud IoT Core. I've been running on IoT Core for 1.5 years. Here's my breakdown of the costs...<p>- $236.99 in usage, approx 1% of project's total revenue<p>- ~20 hours to implement pub/sub applications running on a mix of Raspberry Pi & GCP VMs. Implementations were in Rust and Python. It would have taken much, much longer to stand up a managed MQTT broker and identity/key management that I felt comfortable using in my own home, let alone providing to customers.<p>- Hundreds of hours implementing and debugging glue between GCP's Pub/Sub product, websocket-based subscribers, and MQTT subscribers/publishers.<p>I don't regret my decision (wouldn't have shipped otherwise), but I'm looking forward to the next phase. Here's what I'm migrating towards:<p>- NATs message broker. NATS supports connections via MQTT and Websocket protocols, besides NATS own protocol.<p>- django-nats-nkeys for org, identity, and JWT management (not production-ready, don't use this until I've been eating my own dog food for a few months) [1]<p>- AsyncAPI schemas [2] for core message APIs, including schemas for 3rd-party printer software events (OctoPrint, Moonraker, Repetier, etc). This will underpin PrintNanny's plugin system.<p>[1] <a href="https://github.com/bitsy-ai/django-nats-nkeys" rel="nofollow">https://github.com/bitsy-ai/django-nats-nkeys</a><p>[2] <a href="https://www.asyncapi.com/" rel="nofollow">https://www.asyncapi.com/</a>
hahaa; wow. So, we were doing this sensor project; and I picked "boring" things like raspberry-pi, python scripts, wiring the GPIO with a screw-down terminal or using SDR for other off-the shelf sensors to build the network. And in one of the demos showing our very low-budget type project a reviewer said: "you should look at IoT managers like the G offering, we're using it". So, they declined to use our methods and built their own around G-IoT. It's important to "own" what you can in your stack otherwise this vendor-driven-churn is forced on you and is outside a schedule you control. Sure, 365 days is a lot of time to migrate -- which, IME, leads to "we can fix this later" which then leads to "oh crap!"
I see Google is getting a spanking in this thread and I wouldn’t suggest for a moment that they don’t deserve it.<p>However, I hadn’t seen anyone mention the specific Enterprise API / product designation they rolled out over a year ago to deal with this kind of thing.<p>If I understood things correctly when they launched it [1] the plan was to start by saying which parts of the GCP platform you could confidently rely on with the implication that the other parts you should understand you’re using products and services that haven’t proven their long term value inside of Google and as a result things like this can happen and you should plan accordingly.<p>As far as I know this is the first thing to go since making that announcement but I’d be happy to be corrected as well.<p>[1] <a href="https://cloud.google.com/blog/topics/inside-google-cloud/new-api-stability-tenets-govern-google-enterprise-apis" rel="nofollow">https://cloud.google.com/blog/topics/inside-google-cloud/new...</a>
I've been a defender of GCP in the past, and I've been quick to point out that while Google has a reputation for killing products, GCP has been fairly stable. This, however, changes my opinion.<p>I've been successfully using Cloud IoT for a few years. Now I need to find an alternative. There's a vendor named ClearBlade that announced today a direct migration path, but at this point I'd rather roll my own.
This is starting to feel like the Windows platform post MFC/Win32.<p>Every couple years, it was a new initiative to get developers and the middle management deciders revved up. A sort of a “we’re building it so that you’ll come, right?” thing. And then a year or so later, a new initiative replaced it, the offering was dramatically watered down, or just altogether sunset’ed.
So Google is basically breaking their commitments to their own users again, they don't give a fuck about back-compatibility as usual, they feel like the whole world should care of what their internal product teams want to do, and they feel entitled to set whatever arbitrary deadline for users to migrate (usually less than a year), and if you don't migrate then your money-making software will just stop working. Oh, and of course they provide no customer support whatsoever nor any way to provide feedback - because, of course, it's Google, and it needs to be dumbly unhuman and faceless to the core.<p>Google has become an abomination and a complete denial of what software is supposed to be. It deserves to die in a ball of fire, and none of its shitty products should be spared.
I'd think IoT-related services (<i>especially</i> an entire gateway) would have years-long deprecation schedules, not a single year. If you coupled your product to cloud-based updates only (no companion app stuff), then this means your unsold inventory <i>right now</i> has a timer to be sold until it's dead and requires shipping back for manual updating.
What devices are there in the field are reliant on the Google IoT Core Service platform?<p>Are there ‘smart’ devices that are just going to stop working unless people rewrite the firmware for a different system like AWS or Azure IoT?
Google was probably first when it came to managing 100s of 1000s of servers. They had the know how, they could have eclipsed AWS before they could even start. They weren’t too late to the game either, Azure started late and ramped up fast.<p>The scale at which Google managed to fuck up their cloud business says a lot about their DNA.<p>I was so excited about AlloyDB, but the documentation is crap. After two days of setting things up and dealing with their complex network configuration I gave up. Why would they make it so complex for a new dev to try their shiny new DB? Do cloud googlers seriously not think about new user experience?
If there is anyone trying to find a way to migrate from Google, Qubitro offers you a warm welcome.<p>The offer for six months of free credits as well as free technical support and more is here: <a href="https://blog.qubitro.com/migrate-from-iot-core-to-qubitro/" rel="nofollow">https://blog.qubitro.com/migrate-from-iot-core-to-qubitro/</a>
Honesty, this is "just" MQTT/HTTPS ingress.<p>Further communication to Pub/Sub wouldn't change in any way.<p>IoT Core as a service has some design choices that make it attractive such as JWT token auth, and complex to optimize, such as communication pattern details.<p>If any of you would be interested in migrating to a fully compatible solution, give me a shout at rwarz[at]softserveinc.com since we are building one ;)
At this point it might be useful to think of what Google projects are <i>unlikely</i> to be deprecated soon, or rather, has the potential of surviving deprecation. For instance, would Flutter being an open-source framework be able to save it from Google discontinuing it? Or is having to update it to mimic iOS behavior across its Cupertino widgets with each update too much?
"Google Cloud IoT Core is being retired on August 16, 2023. Contact your Google Cloud account team for more information." -<a href="https://cloud.google.com/iot-core" rel="nofollow">https://cloud.google.com/iot-core</a>
This doesnt surprise me, I wrote about this not long ago and how the Cloud Providers are only paying basic lip service to MQTT and IoT.
There is not one single Cloud Provider that implements MQTTv5 properly (Azure implements a subset of it), and considering it came out in 2019 after being in "close to final draft" status for several years before that, the clouds have been very slow to pick this up.<p>I refuse to believe that anyone is actually using IoT Core on AWS or GCP for modern MQTT workloads. Pulling data in from a few "things" - sure, but industrial level capability across multiple systems, I really don't see it.
How could the costs of keeping a managed MQTT service running for a few more years possibly outweigh the negative press from this move? I just don't understand.
Looking at the release notes (<a href="https://cloud.google.com/iot/docs/release-notes" rel="nofollow">https://cloud.google.com/iot/docs/release-notes</a>) it seems like you could see it coming as there was no new features since 2019. This doesn't help GCP credibility compared to other cloud providers, AWS still supports legacy EC2-Classic from the early 2010s for god sake.
Are we talking about this? <a href="https://cloud.google.com/solutions/iot" rel="nofollow">https://cloud.google.com/solutions/iot</a>
I don't work for Google or really care, but the GCP bashing dogpile every time they cancel a product is just getting pretty unimaginative. They offer hundreds to thousands of services, and some bets just don't work out. Glad to see many other people have perfectly functioning crystal balls.
How are they going to keep the “google home” ecosystem alive without IoT Core ?<p>They said they were going full on the matter protocol but I don’t see how this will replace it fully yet.