<p>I'm new to DevOps specifically using golang and microservice architecture.</p>
<p>I'm wondering if go applications should or should not be deployed in containers (Docker). In this case, I have a system built with micro-service architecture. For example here, I have 2 web services, A and B. Also, I have another web server that acts as a gateway in front of those two.</p>
<p>Both A and B need access to a database, MySQL for example. A handles table A, and B handles table B.</p>
<p>I know that in Go, source codes are compiled into a single executable binary file. And because I have 3 services here, I have 3 binaries. All three run as web servers exposing JSON REST API.</p>
<p>My questions are these:</p>
<ul>
<li><p><strong>Can I deploy these servers together in one host running on different ports?</strong>
If my host gets an IP x.x.x.x for example, my gateway can run in x.x.x.x:80, A in port 81, and B in port 82 for example. A and B will talk to a MySQL server somewhere outside or maybe inside the same host. Is this a good practice? Can Continuous Deployment works with this practice?</p>
</li>
<li><p><strong>Why should I deploy and run those binaries inside containers like Docker?</strong>
I know that since its release few years ago, Docker had found its way to be integrated inside a development workflow easily. But of course using Docker is not as simple as just compiling the code into a binary and then moving it to a deployment server. Using Docker we have to put the executable inside the container and then move the container as well to the deployment server.</p>
</li>
<li><p><strong>What about scalability and high availability without using Docker?</strong>
Can I just replicate my services and run them all at once in different hosts using a load balancer? This way I should deploy A, B, and gateway in one host, and another A, B, and gateway in another host, then set up the load balancer in front of them. A, B, and the gateway runs in ports 80, 81, and 82 respectively. This way I could have thousands of nodes in a form of VMs or LXD containers maybe, spread across hundreds of bare metals, deployed with a simple bash script and ssh, or Ansible if things get complex. Yes or no?</p>
</li>
<li><p><strong>And what about the scalability and availability of using Docker?</strong>
Should I just put all my services inside containers and manage them with something like Kubernetes to achieve high availability? Doing this does add overhead, right? Because the team will have to learn new technology like Kubernetes if they haven't known it yet.</p>
</li>
<li><p>Can you give me an example of some best practices for deploying golang services?</p>
</li>
</ul>

<blockquote>
  <p>I'm wondering if go applications should or should not be deployed in containers (Docker)<br>
  Why should I deploy and run those binaries inside containers like Docker?</p>
</blockquote>

<p>Of course, provided you separate the build from the actual final image (in order to not include in said final image build dependencies)<br>
See "<a href="https://made2591.github.io/posts/goa-docker-multistage" rel="noreferrer">Golang, Docker and multistage build</a>" from <strong><a href="https://made2591.github.io/about/" rel="noreferrer">Matteo Madeddu</a></strong>.</p>

<blockquote>
  <p>Can I deploy these servers together in one host running on different ports?</p>
</blockquote>

<p>Actually, they could all run in their own container on their own port, even if that port is the same.<br>
Intra-container communication will work, using <strong><a href="https://docs.docker.com/engine/reference/builder/#expose" rel="noreferrer">EXPOSEd port</a></strong>.
However, if they are accessed from outside, then their <a href="https://docs.docker.com/engine/reference/run/#expose-incoming-ports" rel="noreferrer"><em>published</em> port</a> need to be different indeed.</p>

<blockquote>
  <p>What about scalibility and high availability without using Docker?<br>
  And what about the scalability and availability of using Docker?</p>
</blockquote>

<p>As soon as you are talking about dynamic status, some kind of orchestration will be involved: see <a href="https://docs.docker.com/engine/swarm/" rel="noreferrer">Docker Swarm</a> or <a href="https://kubernetes.io/" rel="noreferrer">Kubernetes</a> for efficient cluster management.<br>
<a href="https://blog.docker.com/2017/12/kubernetes-in-docker-ee/" rel="noreferrer">Both are available with the latest docker</a>.</p>

<p>Examples:</p>

<ul>
<li>"<a href="https://medium.com/wattpad-engineering/building-and-testing-go-apps-monorepo-speed-9e9ca4978e19" rel="noreferrer"><strong>Building and testing Go apps + monorepo + speed</strong></a>": Or, how we test and build go code in a monorepo, with TravisCI, and deploy to Docker, quickly and easily. From <strong><a href="https://twitter.com/jharlap" rel="noreferrer">Jonathan Harlap</a></strong>, Principal Engineer @ Wattpad</li>
<li>"<a href="https://blog.alexellis.io/introducing-functions-as-a-service/" rel="noreferrer"><strong>Introducing Functions as a Service (OpenFaaS)</strong></a>", from <strong><a href="https://twitter.com/alexellisuk" rel="noreferrer">Alex Ellis</a></strong></li>
</ul>
