Spring Cloud to Go – How to incorporate a Go service in the Spring Cloud Stack

TLDR – you can check out the Spring Cloud Service seed project I made on Github here https://github.com/silentFred/spring-cloud-go-service-seed This seed project enables full communication with Eureka, uses Spring Cloud Config and I implemented my own crude implementation of Ribbon for client-side load-balancing.

Some time ago my wife joined Over and was really excited to get stuck in Kotlin and Spring development. I was equally excited to show her some of what I have picked up over the last 6 years spending a lot of time with Spring Boot. 

However, just a few days after joining she was told that all new services were being written in Go. Suddenly I felt much less useful but also very curious to learn from her.

Almost a year later and I finally decided to jump in and see what all the fuss was about. Coming from a Spring background, I immediately wondered how cool it would be to plug a Go service into the Spring Cloud stack – and this is how the story “Go’s”…

I was first struck by how easy it was to set up (even on Windows). Just a simple installer, make sure the Go bin directory is in your PATH and you are sorted. Intellij also offers terrific support and since this is a strongly typed language I felt comfortable starting without doing much research on the syntax beforehand…I later realised that I need to do some more self-study. Needless to say, my wife had to deal with my impatience and disappointments as I hacked this service together.

Go is a very peculiar language. Not so much the fact that it’s one of the few popular languages that compile down to native machine code, but also in its simplicity. I have always liked this idea of getting back to native code especially as deployment targets for backend services are becomming more homogenous(think docker & Kubernetes) and interpreted languages are falling behind in many performance metrics.

Anecdotal side note – When compared with a lightweight Spring Boot deployment that occupies about 430MB of memory, the equivalent service in Go takes up only 3.8MB. If this does not blow you away then I don’t know what will! Compile and startup time can also waste a lot of time for the typical Java developer. Spring Boot typically takes around 15 seconds to compile and start-up on my PC, the Go twin takes less than a second to compile, startup and process requests.

That being said, there are a ton of features I really miss and I am still struggling to make peace with the fact that there are limited options when it comes to mature and opinionated micro-service frameworks for Go. It seems the general pattern in the industry is to DIY your own stack with tools like go-kit. Simple things like Dependency injection (DI), Aspect-oriented programming (AOP) capabilities and inheritance are what make some of the features in Java (and in particular Spring) so great. But when it comes to Go and the framework options out there – there is nothing as auto-magical like Spring – and that is by design. You can try and fight against the grain. You won’t get far unless you accept the Go proverbs and get on with your life.

Here is where my internal conflict began. Let’s take the concept of favouring Composition over Inheritance. Spring adopted this principle a long time ago by allowing the developer to compose and add behaviour to POJOs using annotations and configuration, but inheritance is still a thing in Java. You can have your cake and eat it too. Go on the other hand, abides by the same principle, to the extreme. There is no simple pattern for inheritance in Go. “Problem solved” they probably said. 

Similarly, in order to adhere to the idiomatic nature of Go there are very few libraries or frameworks that dare to create abstractions for the developer that is remotely magical. All the good stuff Spring gives you with a splash of annotations here and there with their clever use of AOP and reflection are considered dangerous! I really missed the productivity this gave me and the time it saved not having to build my own.

Libraries implementing any of these techniques are also labelled as dangerous and harmful by the community and die a slow death on Github. Like this poor framework, revel. Boasting great things like DI and Inversion Of Control (IOC) that the community deemed non-idiomatic and goes against what makes Go great – simplicity.

I can really see Go thrive in the tech startup scene and for good reason: there is little to no baggage attached to adopting it. You can keep it really simple and just get the job done without getting stumped by the typical dark magic that befalls the novice Spring recruit that needs a good few years before they can tame the beast.

In the post-monolith world where services are becoming smaller and increasing in numbers for organisations – there could be a very compelling cost-benefit in adopting Go due to its simplicity, small memory footprint and absurd speed.

You could argue that in comparing performance for basic computational performance between Java and Go that the differences are marginal, but at the end of the day if the language enforces behaviours and patterns that simply do not allow for bloated and heavy frameworks, maybe it’s better? At least in some use-cases, it’s likely to be given the recent uptake in popularity.

I’m not a Go proselyte just yet but I will definitely keep my eye on it and keep it as another great tool in my collection!

Are you a recent Go convert? I’m interested to know your thoughts and experiences.