🤙Deploy Object Detection In 1 Min 🤙

wrannaman
SugarKubes
Published in
4 min readApr 7, 2019

SugarKubes was meant to enable dev teams to build anything quicker. We pay careful attention to ops, deployment, and are constantly striving to make this as simple as possible. If you want to learn more or purchase the container shown here today, please signup at sugarkubes.io. If you want it for *free* invite some friends!

Before we begin make sure you have both a SugarKubes account and a Google account.

Today we’re going to show you how simple it is to deploy an object detector to a public address and start calling it immediately. We’re going to use Google’s new Cloud Run, which will autoscale down to zero if it’s not being used 🤙. Or at least it should. It’s based on Knative which scales down to zero so hopefully, this does too.

First head over to SugarKubes, we’re going to be using the object-detcion cpu container . For the first 100 humans, it’s half off!

Once you’ve purchased the container (or if you want to grab a test container, you can use our public UI), let’s tag it and push to our own Google cloud repo.

# Paid Versiondocker tag registry.sugarkubes.io/sugar-cv/object-detection:cpu gcr.io/<YOUR PROJECT ID>/object-detection:cpudocker push gcr.io/<YOUR PROJECT ID>/object-detection:cpu# Free Version docker tag sugarkubes/testing_ui:latest gcr.io/<YOUR PROJECT ID>/testing_ui:latestdocker push gcr.io/<YOUR PROJECT ID>/testing_ui:latest

After you push to the Google Registry, your container should appear in the container registry. It’s a little difficult to find, keep scrolling.

Now that we have our container up on GCR, let’s publish it with Cloud Run!

Simply select your container and make sure to pop open those optional settings.

Make sure under the advanced settings you set the memory limit to 1 GB (for the paid version of the real machine learning app, for the testing UI, you can keep it at 256MB), this container running a cpu only machine learning model gets a little hungry.

This 1GB is only required for the ML model, not the free Testing UI

After a few seconds you should get a url just like this one:

You’ll get a URL for your new app! With SSL!
And it actually works! Holy Heck!

Miracle. I didn’t have to do very much and I got ssl!

Wait but does it actually do what it’s supposed to?

# You can do this and run it locally or you can spin up 
# another Google Cloud Run instance with the Testing UI!
# This is free, no login required docker run -ti -p 7777:7777 -e PORT=7777 sugarkubes/testing_ui:latest

Let’s load up 7777.

Once we change our url to the correct one (from above), let’s fire away and see what we get!

Amazing! Machine Learning! Easy!

Now the inference time is garbage. This is true. The inference time on my MacBook Pro is roughly 500ms for reference. But heck, if you spin up a bunch of these the marginal inference time can be pretty damn close to zero, you’re in the cloud baby you do you (sorry for the excitement, I’ve spent the past 4 years in the embedded computing space where having a 4 core CPU and a decent network is a luxury 🤷‍♀️.)! Also, stay tuned for proper GPU deployments.

Wait, let’s get meta, what if we deployed the UI on a serverless infrastructure?!?! Let’s try it…

Following the same steps as above, but just selecting a different image … behold… MAGIC

OMG, it’s on the internets 🥳…

Notes

The only real issue I encountered is that Cloud Run seems to set a PORT environment variable that your app is expected to listen on. Once I figured that out and slightly modified my apps it worked like a dream.

# Useful snippet to start node apps from ENV variables... // package.json...
"scripts": {
"start": "next start -p ${PORT}"
},
...
# Then you can run it with
npm run start

I’ll leave this on for a few days and see what they end up charging me for this sweet piece of wizardry… will report back. 🙃

--

--