4 ms·

Ask HN: Using Go in production

21 points by beckler 12y ago

For those who are using Go in production, what setup has worked out for you the most?

paulrosenzweig 12y ago
I'd check these out: mailing list - https://groups.google.com/forum/#!forum/golang-nuts https://groups.google.com/forum/#!forum/golang-nuts subreddit - https://www.reddit.com/r/golang https://www.reddit.com/r/golang
deferpanic 12y ago
Most of our stuff is plain old net/http w/some gorilla doing things we didn't want to code at the outset and never bothered to replace later on. While our main datastore is postgres we have 3 custom datastores that are starting to take a very active role. We have a lot of time-series data, very little relational, a bit of 'document' style and micro-service traces are living in their own. Not sure if this answers your question but maybe that gets you going in the right direction.
CyberFonic 12y ago
Only using it on a small scale. Go with Google App Engine. Works well both with SDK and on AppSpot.
deleted 12y ago
[deleted]
yourabi 12y ago
Using Go for the backend of https://snitch.io https://snitch.io 1. Use Godeps to vendor your deps 2. Use Logrus for logging 3. Figure out a deployment script early one. I have a Rake script that uses chef-api to lookup current production nodes, cross compiles locally and scp's the resulting binary out and restarts the process
nulltype 12y ago
I'm using Go on App Engine, decently large scale site. It's a pretty good setup. Includes a task queue, database, file storage, almost everything you need. Not having to manage those things yourself is pretty fantastic. No need to use godeps, setup logging, create a deployment system, or manage linux machines with a bunch of scripts. You can even pipe your logs into BigQuery for serious analysis (and copy your database there too, though this might be expensive for large databases). Main downside of App Engine is that network stuff has to go over urlfetch/socket api unless you use Managed VM, which is not really production ready yet. As for frameworks, the builtin http package is fine. Just make some http.Handler structs or wrappers and you're basically done.
damian2000 12y ago
Using standard net/http with the gorilla mux and sessions libraries on a Linode 2GB VPS. Serving both HTTPS and HTTP. Sites are low traffic but perform well. One uses the pq library for postgres database access.
- anon3_ 12y ago
  What exactly is gorilla/mux? Is it a microframework? It kind of reminds me of werkzeug.
  - giaour 12y ago
    It's a router that allows precise matching.
anon3_ 12y ago
For production, a nice thing to get out of the way is wrap your go instance / environmental variables in a container / service. supervisord: http://supervisord.org/ http://supervisord.org/ is working great so far.
chuhnk 12y ago
From Hailo. Running 200 microservices in production. 199 of which are Go. We run on AWS with our own system that orchestrates Go binaries but are also moving to containers.
- nulltype 12y ago
  That's a lot of microservices. How do you handle changing the interface of a service in a backward incompatible way? Or updating a dependency across all services?
  - chuhnk 12y ago
    We use protobuf rpc which allows us to maintain some form of backwards compatibility. New fields are ignored by old version of a service. We can also run multiple versions of a service in parallel and send a percentage of traffic to each. Also have the ability to do label based routing so new features are only enabled where a v1.1 header or something of that nature is seen. Updating dependencies across all services is somewhat of an anti pattern in microservices, this chain of dependencies shouldn't exist. Microservices are loosely coupled with a bounded context. In the case of bug fixes based on core libraries we have roll out procedures to update services over time but in a microservice world there's never a point where you look to update a block of services all at once. You should be able to deploy new versions of a service without breaking the system. Tradeoffs are made for a microservice architecture patterns but when organisations scale to 100+ people we deem these tradeoffs necessary as what we lose in convenience in monolithic tradition, we gain in speed of execution and a highly availably fault tolerant globally scaling system. You can learn more about our journey on our blog https://sudo.hailoapp.com/services/2015/03/09/journey-into-a-microservice-world-part-1/ https://sudo.hailoapp.com/services/2015/03/09/journey-into-a... And slides from former platform tech lead Matt Heath https://speakerdeck.com/mattheath https://speakerdeck.com/mattheath Also from current platform automation lead Boyan Dimitrov http://www.slideshare.net/nathariel http://www.slideshare.net/nathariel Various talks can also be found on youtube.
    - nulltype 12y ago
      Thanks for all the info! Very informative. "Updating dependencies across all services is somewhat of an anti pattern in microservices, this chain of dependencies shouldn't exist." But what about, say, your tracing library. It seems like that would be shared across all your services, right?

21 points by beckler 12y ago

For those who are using Go in production, what setup has worked out for you the most?

I'd check these out: mailing list - https://groups.google.com/forum/#!forum/golang-nuts https://groups.google.com/forum/#!forum/golang-nuts subreddit - https://www.reddit.com/r/golang https://www.reddit.com/r/golang

deferpanic 12y ago

Most of our stuff is plain old net/http w/some gorilla doing things we didn't want to code at the outset and never bothered to replace later on. While our main datastore is postgres we have 3 custom datastores that are starting to take a very active role. We have a lot of time-series data, very little relational, a bit of 'document' style and micro-service traces are living in their own. Not sure if this answers your question but maybe that gets you going in the right direction.

CyberFonic 12y ago

Only using it on a small scale. Go with Google App Engine. Works well both with SDK and on AppSpot.

deleted 12y ago

[deleted]

yourabi 12y ago

Using Go for the backend of https://snitch.io https://snitch.io 1. Use Godeps to vendor your deps 2. Use Logrus for logging 3. Figure out a deployment script early one. I have a Rake script that uses chef-api to lookup current production nodes, cross compiles locally and scp's the resulting binary out and restarts the process

nulltype 12y ago

I'm using Go on App Engine, decently large scale site. It's a pretty good setup. Includes a task queue, database, file storage, almost everything you need. Not having to manage those things yourself is pretty fantastic. No need to use godeps, setup logging, create a deployment system, or manage linux machines with a bunch of scripts. You can even pipe your logs into BigQuery for serious analysis (and copy your database there too, though this might be expensive for large databases). Main downside of App Engine is that network stuff has to go over urlfetch/socket api unless you use Managed VM, which is not really production ready yet. As for frameworks, the builtin http package is fine. Just make some http.Handler structs or wrappers and you're basically done.

damian2000 12y ago

Using standard net/http with the gorilla mux and sessions libraries on a Linode 2GB VPS. Serving both HTTPS and HTTP. Sites are low traffic but perform well. One uses the pq library for postgres database access.

anon3_ 12y ago
What exactly is gorilla/mux? Is it a microframework? It kind of reminds me of werkzeug.
- giaour 12y ago
  It's a router that allows precise matching.

anon3_ 12y ago

For production, a nice thing to get out of the way is wrap your go instance / environmental variables in a container / service. supervisord: http://supervisord.org/ http://supervisord.org/ is working great so far.

chuhnk 12y ago

From Hailo. Running 200 microservices in production. 199 of which are Go. We run on AWS with our own system that orchestrates Go binaries but are also moving to containers.

nulltype 12y ago
That's a lot of microservices. How do you handle changing the interface of a service in a backward incompatible way? Or updating a dependency across all services?
- chuhnk 12y ago
  We use protobuf rpc which allows us to maintain some form of backwards compatibility. New fields are ignored by old version of a service. We can also run multiple versions of a service in parallel and send a percentage of traffic to each. Also have the ability to do label based routing so new features are only enabled where a v1.1 header or something of that nature is seen. Updating dependencies across all services is somewhat of an anti pattern in microservices, this chain of dependencies shouldn't exist. Microservices are loosely coupled with a bounded context. In the case of bug fixes based on core libraries we have roll out procedures to update services over time but in a microservice world there's never a point where you look to update a block of services all at once. You should be able to deploy new versions of a service without breaking the system. Tradeoffs are made for a microservice architecture patterns but when organisations scale to 100+ people we deem these tradeoffs necessary as what we lose in convenience in monolithic tradition, we gain in speed of execution and a highly availably fault tolerant globally scaling system. You can learn more about our journey on our blog https://sudo.hailoapp.com/services/2015/03/09/journey-into-a-microservice-world-part-1/ https://sudo.hailoapp.com/services/2015/03/09/journey-into-a... And slides from former platform tech lead Matt Heath https://speakerdeck.com/mattheath https://speakerdeck.com/mattheath Also from current platform automation lead Boyan Dimitrov http://www.slideshare.net/nathariel http://www.slideshare.net/nathariel Various talks can also be found on youtube.
  - nulltype 12y ago
    Thanks for all the info! Very informative. "Updating dependencies across all services is somewhat of an anti pattern in microservices, this chain of dependencies shouldn't exist." But what about, say, your tracing library. It seems like that would be shared across all your services, right?