At the day job, one of my team’s current projects is a bespoke “serverless” script execution service for internal use, not unlike AWS Lambda or similar offerings. I’m not the main guy on this, but I’ve been involved in some interesting discussions about how we should control the execution environments. Ideally, they would be sandboxed and completely disposable, possibly only alive for the lifetime of the script they are executing. The obvious solution to this is to use containers.
The dominant scripting language amongst our user base is PowerShell, so we need to try
A match made in heaven
If you are a regular reader you will know just how much I have fallen for Golang recently. If not, see Fun with WebSockets in Golang for why I think it’s such a great language for writing backend services.
As explained in that blog post, my motivation for learning Golang originated with my experimentation with Docker. Golang programs are (usually) statically compiled to machine code, not bytecode, so no runtime interpreter like a JVM or Python is required to run them. This means that you can fit those programs into the smallest Docker containers possible for maximum density and reduced attack surface. Pair that with Golang’s performance (which is comparable to C++) and you have a match made in heaven.
You won’t need me to tell you that Docker has been a dominating force in automated infrastructure for the last couple of years. For the uninitiated, a container is an isolated, lightweight execution context for an app/service (and its dependencies) that share a kernel with other containers. Because an app can be delivered in its deployed state and run consistently by any Docker host, using containers greatly reduces the scope for environmental issues, e.g. incompatible versions of libraries on the host machine, interfering external processes, etc. Containers are the biggest advancement in application delivery since the birth of server virtualization, so they’re worth learning how to use.