<p>I'm developing a webservice in Go. Currently I'm running it on a CloudatCost server, but it's not the best. </p>
<p>Are there any affordable, non-VPS alternatives?</p>
<hr/>**评论：**<br/><br/>mvitorino: <pre><p>Have you considered Google AppEngine? The Go runtime is now out of beta and the service has a free tier. Very easy deployment, extra services like queueing, cron, datas tore, full text search etc.</p></pre>insolent-octo-hocke: <pre><p>But it has vendor lock-in and is on the pricier of the sides</p></pre>kurin: <pre><p>How does it lock you in?</p></pre>mvitorino: <pre><p>Go instances start (and stop) in less than 1 second on AppEngine. You only need to pay if you go out of the free tier which may not be the case for a simple service like the one mentioned.</p></pre>mvitorino: <pre><p>Also, where is the vendor lock-in exactly and why should the guy asking care about it at this stage? Depends on which services you use and most of them are provided in some similar way or another by competing clouds. Logging, queuing, cron, nosql datastore are all services fairly easily to convert to equivalent solutions if it ever comes to that. </p>
<p>In my view, trying to prevent vendor lock-in is a form of premature optimisation.</p></pre>semi-: <pre><p>I disagree. Vendor lock-in is the kind of thing you need to be aware of early, because it's the easiest time to avoid it. Once your businessis depending on these lock-in features its a lot harder to find the time to safely migrate to something else.</p>
<p>Now, I don't think this kind of lock in is inherently 'bad' and needs to be avoided, but it is something you need to think about and the best time to do so is when you're still planning out your project, not after your project is up and running and depending on these things.</p></pre>FUZxxl: <pre><p>If you program in Go, the vendor lock in doesn't matter too much.</p></pre>insolent-octo-hocke: <pre><p>How do you mean that?</p></pre>FUZxxl: <pre><p>As far as I know there isn't much that differs a normal Go program from one written for the AppEngine.</p></pre>klaaax: <pre><p>the fact that you can't choose which DB you can use doesn't matter to you ?</p></pre>FUZxxl: <pre><p>For many simple applications the choice of DB does not matter too much.</p></pre>klaaax: <pre><p>and appengine rewrite your headers , disallow running multiple goroutines in parallel and has a crappy and slow SDK. doesn't seem like a good choice for someone who seek simplicity.</p></pre>mvitorino: <pre><p>You can use the builtin Cloud Datastore, you can use managed MySQL or whip up any database you would like on Compute Engine. Also the integrated log service is really nice and free. No need for Loggly or something like that. </p></pre>softiniodotcom: <pre><p>The one issue I have with using appengine is when I want to use SSL with a dedicated IP with it. It costs too much compared to if I go for someone like linode. Have a look at linode no complaints and it works well: <a href="https://www.linode.com/" rel="nofollow">https://www.linode.com/</a></p></pre>insolent-octo-hocke: <pre><p>You don't even get SSL for foobar.appengine.com?</p></pre>Martin_Ehrental: <pre><p>yes, you get free SSL support at your-app.appspot.com.</p>
<p>You also get free SNI support. So you can have cheap SSL for your-domain.com but not all browser support SNI. </p>
<p>But a dedicated IP for app engine costs $39/m.</p></pre>elithrar_: <pre><blockquote>
<p>You also get free SNI support. So you can have cheap SSL for your-domain.com but not all browser support SNI.</p>
</blockquote>
<p>To be fair, that's pretty much just IE6 on XP (Chrome on XP unaffected) and some early Android 2.0 versions. Even corporate users are on IE8 now. I agree that turning away users is bad, especially if you expect those kind of users, but the IE6 ship has definitely sailed.</p></pre>mvitorino: <pre><p>That is true. We pay $36/month for VIP + Google Apps is required. Although they say the GApps requirement is going away. But it's still there.</p></pre>elithrar_: <pre><p>I usually leap to Heroku for things like this, but Google Container Engine, RH OpenShift and/or Engine Yard are also decent options.</p>
<p>Although I <em>can</em> set up a VPS (or many of them) without any issues (automated via Ansible/Packer), unless I want to spend time maintaining it—upgrading packages, monitoring alarms, potentially waking up at 2AM if the DO VPS dies—I typically prefer to push to an PaaS service.</p>
<p>The nice thing about Go is that the performance:resource-usage ratio is so good that you can get away with undersized PaaS plans relative to things like Rails/Django/etc.</p></pre>xienze: <pre><p>Why do you not want a VPS? You can get one for as little as $5 per month.</p></pre>elithrar_: <pre><p>I suspect cost isn't the problem: it's time. Time to set it up (or write config to do it for you), keep it updated, add streaming replication, write-only backups, set up S3 and IAM users to handle those backups, test your backups, etc, etc, etc.</p>
<p>The cost of the VPS is usually dwarfed by the cost of your own time.</p></pre>catsushy: <pre><p>I don't understand why people struggle with this. But then I guess i have over a decade of Linux system administration under my belt. </p></pre>elithrar_: <pre><p>It's not even the struggle—it's the time. Even an experienced vet with a library of Ansible scripts has to deal with the machine failing, updating it to handle CVE's, configuring new sets of keys. If you're a small team (or solo dev) then the effort quickly starts to consume a non-negligible amount of time.</p></pre>dhdfdh: <pre><p>You only do that once.</p></pre>elithrar_: <pre><p>You only test your backups once? Can you restore from your backups to a fully-functioning server with data from < 30 mins ago (or less)? Keep things updated? Re-test your deployment scripts to make sure they still work/modules haven't been deprecated/dependencies haven't changed? This is what I mean by 'time'.</p></pre>dhdfdh: <pre><p>You set up your server once. Updating it is minimal. I don't know what you mean by streaming replication but that sounds like something you only do once. Backups should be automatic and set up once. </p>
<p>If you're doing any of that where it takes a significant amount of time after setting them up, you must be on Windows.</p></pre>elithrar_: <pre><blockquote>
<p>Backups should be automatic and set up once.</p>
</blockquote>
<p>If you're not <em>testing your backups</em> on a regular basis you're risking catastrophic failure:</p>
<ul>
<li>What if your backups are corrupted? Missing some files because you messed up a glob along the way?</li>
<li>Did you make sure your S3 permissions were correct? Did a software bug overwrite older backups?</li>
<li>Did a software update along the way cause incompatibility with your backups?</li>
<li>Ansible module deprecated? Syntax changed? Do your "from scratch" CM scripts still work 12 months later on a fresh install of Debian 8? No?</li>
<li>Did an attacker turn off the cron job that invokes duply each night? (I hope you're running Dead Man's Snitch)</li>
</ul>
<p>Streaming replication is something like <a href="https://github.com/wal-e/wal-e" rel="nofollow">WAL-E</a> that can stream Postgres backups to S3 (or similar), allowing you to roll-back your DB every X interval (minute, if you so desire) and/or restore it to a new box and have it be up to date quickly. You get that 'for free' with services like Amazon RDS or Heroku Postgres, which is a big plus.</p>
<p>I'm not sure what else I can add to this thread. You may think I'm overstating the failure modes, and you're welcome to think that. But I hope it illustrates all the "ops" related issues turn a $5 VPS into hours of regular upkeep and/or monitoring to keep running smoothly.</p>
<p>Of course, if it's a tiny side project that doesn't matter, then do what you like!</p></pre>dhdfdh: <pre><p>If you need to do all that on your $5 VPS, I think you need to rethink how you do things. You also have to understand most people don't use S3, don't know what Ansible is, don't use "streaming replication" and never will; specifically this OP.</p></pre>rock_neurotiko: <pre><p>I use OpenShift and I'm really happy :)</p></pre>drewmate: <pre><p>Agreed. It's really nice to be able to ssh in to the actual machine, or check the log for errors. I've been running a small service on their free tier for a few months now, and I'm a fan!</p></pre>klaaax: <pre><p>use a VPS -- or use Go http server in CGI mode on a shared host ( it works , the performances will be shitty but for a project that has like 10/20 concurrent connections max , it's fine ). But frankly use a VPS. On a limited box (512 MB RAM) you can deploy 4/5 go apps .</p></pre>foxh8er: <pre><p>That's what I'm doing now on a 512 meg box - it works fine and only uses about 5 megs currently, but SSHing into the server is a pain to handle code changes (I don't have a good workflow set up yet). I'd rather do continuous deployment or something like that. </p></pre>1Gijs: <pre><p>I use Dokku for this. So I only have to push the code to the git on the vps (512 Mb / 20 Gb). Works really great so far. Running 3 apps with still 60% ram unused.</p></pre>klaaax: <pre><blockquote>
<p>I don't have a good workflow set up yet</p>
</blockquote>
<p>use chef/puppet/ansible/shell script or whatever deployment tool that exists , there are zillions of them today , deployment should be 1 click on a script and you're done. I think it would be better to ask the question "how do you deploy Go code" instead. Otherwise there is Heroku (deploy with git) but you can't really run multiple apps on 1 dyno ( their VM unit )</p></pre>FIuffyRabbit: <pre><p>Host the code in a private git repo. Set a hook on git to hit an update URL on your server that causes it to pull the changes and then rebuild.</p></pre>kardianos: <pre><p>IBM bluemix uses cloud foundry and is reasonably priced with a free tier. You could reasonably host 4 or 5 apps for free there.</p></pre>klaaax: <pre><p>I tried bluemix and yes it is surprisingly good. Let's see what IBM does with it.</p></pre>010a: <pre><p>Heroku's free tier is fine if you don't have any real-time requirements and can survive the app only being up 16 hours every day. </p>
<p>App Engine has a better management interface and a way better free tier, but its tooling isn't as nice.</p>
<p>One issue with both of these is that you don't get dedicated IPs for free. This means you basically can't tie your app to a DNS record without redirects. </p>
<p>Setting up a VPS isn't as hard as you might think. Here we go:</p>
<ul>
<li><p>Get a VPS from (insert provider here) (I prefer DigitalOcean, $5/mo)</p></li>
<li><p>SSH in</p></li>
<li><p>Install golang from golang.org and set up your gopath (you should create a new user to run all this, but if you dont care about security then root will work)</p></li>
<li><p><code>apt-get install supervisor</code></p></li>
<li><p><code>go get myapp.git</code></p></li>
</ul>
<p>Put the following inside <code>/etc/supervisor/conf.d/myapp.conf</code></p>
<pre><code>[program:myapp]
command=/home/me/go/src/myapp/mybin
autostart=true
autorestart=true
startretries=10
user=me
directory=/home/me/go/src/myapp/mybin
</code></pre>
<ul>
<li><p>In your CI service: do an SSH deployment with the following command <code>ssh me@host.com "cd go/src/myapp && git pull && go build && supervisorctl reload"</code></p></li>
<li><p>If you need any databases with it, install them then create supervisor confs just like the golang one except, say, <code>command=redis-server</code>. </p></li>
</ul>
<p>You're done. You've got your very own Heroku-like server using github and codeship for free. Well, except the cost of the VPS. It works better than Heroku because it is up 24/7, and it works better than AppEngine because it integrates with the tooling you're already using.</p>
<p>You could definitely improve it with Docker, but that would just increase the complexity of your system. Plus I'm beginning to feel that Docker isn't as useful as most people in the industry want us to believe it is. </p></pre>djhworld: <pre><p>I used heroku up until they changed the free tier option, so I moved to DigitalOcean for $5 a month and installed Dokku to get that heroku like experience.</p>
<p>Seems to be working well for me! </p></pre>jahayhurst: <pre><p>I've been eyeballing docker - using a docker container for each app then just running probs CoreOS on the vm, or on my own colo.</p>
<p>Of course, servers are cheap for me.</p></pre>lapingvino: <pre><p>Google App Engine. Dead easy to deploy and maintain. Otherwise look at Heroku :).</p></pre>TheMerovius: <pre><p>There is also Google Container Engine, which provides you with docker containers (and AFAIK it's even free for small deployments). In general: Look at any cloud service provider, they will have an IaaS or PaaS product, which will probably be good for you :)</p></pre>softiniodotcom: <pre><p>My understanding of their pricing is they don't charge for container engine if you have up to 5 nodes, but container engine runs on top of google compute engine and you still have to pay for that so its not completely free!</p></pre>TheMerovius: <pre><p>Ah, I was wondering about that :) Didn't make any sense. But what you say seems plausible.</p></pre>FrenchDonkey: <pre><p>Appengine is freaking awesome.
One thing to keep in mind, if you use 3rd parties librabries, you will need to hack their source code to use <a href="https://cloud.google.com/appengine/docs/go/urlfetch/" rel="nofollow">urlfetch</a></p></pre>arihant5: <pre><p>No you don't. App Engine works fine with Go http package. URL Fetch is a set of convenience functions that expose additional App Engine functionality. You don't have to use it.</p>
<p>This goes for both Python and Go. In Python, all urllib requests automatically get routed through App Engine's custom infrastructure.</p></pre>calebdoxsey: <pre><p>Yes you do. Here is the error you will get when you try to use the default http client:</p>
<pre><code>Get http://www.google.com: http.DefaultTransport and http.DefaultClient are not available in App Engine. See https://cloud.google.com/appengine/docs/go/urlfetch/
</code></pre></pre>arihant5: <pre><p>Hard coding http.DefaultTransport and http.DefaultClient into a library is a horrible practice. It is not present in a lot of environments. Most libraries, (including oauth2 now, see <a href="https://github.com/golang/oauth2/issues/27" rel="nofollow">https://github.com/golang/oauth2/issues/27</a>), use agnostic approach. Which should be the case, using those two functions horribly breaks Go composability.</p>
<p>You should use http.Transport and http.Client, which work fine. Of course, you would need to define sane defaults. Most libraries now accept a transport, and you can easily pass a app engine Transport for ease without hacking anything. Or any other Transport for that matter. </p>
<p>Here:</p>
<p>client := &http.Client{
Transport: &urlfetch.Transport{Context: ctx},
}</p>
<p>You can also just copy paste code from DefaultTransport while making your own Transport. And that will work fine on App Engine.</p></pre>
