Go Microservices, Part 1: Building Microservices With Go

in this blog series, we'll build microservices using the go programming language and piece by piece add the necessary integrations to make them run nicely on docker in swarm mode within a spring cloud / netflix oss landscape.

if you're unsure what a microservice is, i suggest reading martin fowler's article about them. for more about the operations model for microservices, this blog post from my colleague magnus explains the key concepts really well.

this blog series won't be a beginner's guide to coding in go, though we will nevertheless write some code as we progress through the series and i'll explain some key go concepts along the way. we'll be looking at a lot of code especially during the first parts where we'll cover basic functionality, unit testing, and other core topics.

part one will be an introduction to key concepts and the rationale for exploring the possibilities with go-based microservices.

note: when referring to "docker swarm" in this blog series, i am referring to running docker 1.12 or later in swarm mode . " docker swarm " as a standalone concept was discontinued with the release of docker 1.12.

landscape overview

the image below provides an overall view of the system landscape we'll be building throughout this blog series. however, we'll start by writing our first go microservice from scratch and then as we progress along the parts of the blog series, we'll get closer and closer to what the image below represents.

the legend is basically:

• the dashed white box: a logical docker swarm cluster, running on one or more nodes.
• blue boxes: supporting service from the spring cloud / netflix oss stack or some other service such as zipkin.
• sand-colored / white box: an actual microservice.

it's more or less the same landscape used in magnus larssons microservices blog series , with the main difference being that the actual microservices are implemented in go instead of java. the quotes-service is the exception as it provides us with a jvm-based microservice we can use for comparison as well as a testbed for seamless integration with our go-based services.

the rationale - runtime footprint

why would we want to write microservices in go, one might ask? besides being a quite fun and productive language to work with, the main rationale for building microservices in go is the tiny memory footprint go programs comes with. let's take a look at the screenshot below where we are running several go microservices as well as a microservice based on spring boot and spring cloud infrastructure on docker swarm:

the quotes-service is the sprint boot one while the compservice and accountservice ones are go-based. both are basically http servers with a lot of libraries deployed to handle integration with the spring cloud infrastructure.

does this really matter in 2017? aren't we deploying on servers these days with many gigabytes of ram that easily fits an impressive number of let's say java-based applications in memory? that's true - but a large enterprise isn't running tens of services - they could very well be running hundreds or even thousands of containerized (micro)services on a cloud provider. when running a huge amount of containers, being resource-efficient can save your company a lot of money over time.

let's take a look at amazon ec2 pricing for general purpose on-demand instances (per 2017-02-15):

comparing the various t2 instances, we see that for a given cpu core count, doubling the amount of ram (for example: 4 to 8 gb from t2.medium to t2.large) also doubles the hourly rate. if you're not cpu-constrained, being able to fit twice the amount of microservices into a given instance could theoretically halve your cloud provider bill. as we'll see in later blog posts, even when under load our go services use a lot less ram than an idling spring boot-based one.

non-functional requirements on a microservice

this blog series is not just about how to build a microservice using go - it's just as much about having it behave nicely within a spring cloud environment and conform to the qualities a production-ready microservice landscape will require of it.

consider (in no particular order):

• centralized configuration
• service discovery
• logging
• distributed tracing
• circuit breaking
• load balancing
• edge
• monitoring
• security

all of these are things i think you must take into account when deciding to go for a microservice architecture regardless if you're going to code it in go, java, js, python, c# or whatever's your liking. in this blog series i'll try to cover all these topics from the go perspective.

another perspective are things within your actual microservice implementation. regardless of where you're coming from, you probably have worked with libraries that provides things such as:

• http / rpc / rest / soap / whatever apis
• persistence apis (db clients, jdbc, o/r mappers)
• messaging apis (mqtt, amqp, jms)
• testability (unit / integration / system / acceptance)
• build tools / ci / cd
• more...

i won't touch on all of these topics. if i would, i could just as well write a book instead of a blog series. i'll cover at least a few of them.

running on docker swarm

a basic premise of the system landscape of this blog series is that docker swarm will be our runtime environment which means all services - be it the supporting ones (config server, edge etc.) or our actual microservice implementations will be deployed as docker swarm services . when we're at the end of the blog series, the following docker command:

docker service ls

will show us a list of all services deployed in the sample landscape, each having one replica.

again - please note that the services listed above include a lot more services than we'll have when we'll setup up our swarm cluster in part 5 of the blog series.

performance

ok - so go microservices has a small memory footprint - but will they perform? benchmarking programming languages against each other in a meaningful way can be quite difficult. that said, if one looks at a site such as benchmarkgame where people can submit implementations of explicit algorithms for a variety of languages and have them benchmarked against each other, go is typically slightly faster than java 8 with a few notable exceptions. go in it's turn, is typically almost on par with c++ or - in the case of a few benchmarks - a lot slower. that said - go typically performs just fine for typical "microservice" workloads - serving http/rpc, serializing/deserializing data structures, handling network io etc.

another rather important attribute of go is that it is a garbage collected language. after the major rewrite of the garbage collector for go 1.5 gc pauses should typically be a few milliseconds at most. if you're coming from the world of jvms (as i do myself), the go garbage collector is perhaps not as mature but it does seem to be very reliable after changes introduced somewhere after go 1.2 or so. it's also is a miracle of non-configurability - there is exactly one knob ( gogc ) you can tweak regarding gc behavior in go which controls the total size of the heap relative to the size of reachable objects.

however - keeping track of performance impact as we'll build our first microservice and then add things like circuit breakers, tracing, logging etc. to it can be very interesting so we'll use a gatling test in upcoming blog posts to see how performance develops as we add more and more functionality to the microservices.

boot time

another nice characteristic of your typical go application is that it starts really fast. a simple http server with a bit of routing, json serialization etc. typically starts in a few hundred milliseconds at the most. when we start running our go microservices within docker containers, we'll see them healthy and ready to serve in a few seconds at most, while our reference spring boot-based microservice typically needs at least 10 seconds until ready. perhaps not the singularly most important characteristic, although it can certainly be beneficial when your environment needs to handle unexpected surges in traffic volumes by quickly scaling up.

statically linked binaries

another big upside with go-based microservices in docker containers is that we get a statically linked binary with all dependencies in a single executable binary. while the file isn’t very compact (typically 10-20 mb for a real microservice), the big upside is that we get really simple dockerfiles and that we can use very bare base docker images. i’m using a base image called iron/base that weighs in at just ~6 mb.

from iron/base

expose 6868
add eventservice-linux-amd64 /
entrypoint ["./eventservice-linux-amd64", "-profile=test"]

in other words - no jvm or other runtime component is required except for the standard c library (libc) which is included in the base image.

we’ll go into more detail about how to build our binaries and that -profile=test thing in later blog posts.

summary

in this blog post, we introduced some of the key reasons for building microservices using go such as small memory footprint, good performance and the convenience of statically linked binaries.

in the next part, we'll build our first go-based microservice.