Microservices in Go using Go-kit

Go-kit is a distributed programming toolkit for building microservices. It solves the common problems encountered while building distributed systems, so you can focus on your business logic. This article starts with a bit of background on microservices, then guidance on how to get started with Go-kit, including instructions on getting a basic service up and running on Heroku.

A Brief Intro to Microservices

Traditionally, web applications are built using a monolithic approach where the entire application is built, designed, deployed and maintained as a single unit. When working with a monolithic application various problems can arise over time: it’s easy for abstractions to leak across modules, tightly coupling them; different parts of the application may need more processing power than others, forcing you to scale in unpredictable ways; changes involve building and deploying a new version of the entire application; and tests can easily become convoluted and/or take an excruciatingly long time for the full suite to run.

A microservice based design addresses these issues. Applications designed using microservices consist of a set of several small (hence the term “micro”) services cooperating and communicating together. Separation between services is enforced by the service's external API. Each individual micro service can be scaled and deployed separately from the rest.

Read more →

Auto-generating a Go API client for Heroku

Editor's note: This is a cross post from Blake Gentry, an engineer at Heroku.

This is a post about the recently announced Heroku Platform API JSON Schema and how I used that schema to write an auto-generated Go client for the API.

Heroku's API team has spent a large part of the past year designing a new version of the platform API. While this is the 3rd incarnation of the API, neither of the two previous versions were publicly documented. In fact, the only documentation on the old APIs that was ever published is the source code of the Heroku Rubygem, which powers the Heroku Toolbelt. That worked fairly well at the time for Heroku's Ruby-centric audience, but it was never ideal, especially since Heroku's developer audience now uses many languages besides Ruby.

Additionally, the first two "versions" of Heroku's API were developed organically as the platform's capabilities evolved, with contributions made by many engineers over the years. The API was built primarily as an interface for the toolbelt, rather than as a product. It was also not properly versioned, as there was no process for managing changes publicly. And because the API was not treated as a product in and of itself, the old APIs are scarred by numerous inconsistencies and lack coherence.

Read more →

Browse the blog archives, subscribe to the full-text feed, or visit the engineering blog.