December 8, 2016 · spinnaker

An Introduction to Spinnaker: Under the Hood

I've been a part of the Spinnaker team for about 18 months now. If you're unfamiliar, Spinnaker is a tool for doing safe and continuous deployment to a cloud environment. Check out the link above for much more detail about what it is and what you can do with it - I won't rehash that here.

In that time, I've had the pleasure of doing a lot of refactors of the components to make the product multi-cloud, which at the time meant Amazon Web Services (AWS) and the Google Compute Engine (GCE).

In this series of blog posts, I plan on doing deep dives into several of the components in order to help others interested in knowing how Spinnaker works under the hood, and some of the development decisions that went into building it.

First, we'll take the 10,000 foot view. Spinnaker is composed of several micro-services:

The core pieces of Spinnaker's architecture

This is a non-exhaustive list of the main components:

Each of these micro-services is a Spring Boot based application coded mostly in Groovy (except for Deck, which is a Node based Javascript single page application).

The team is pushing for all new components to be in Java 8, since it has finally caught up to some of the niceties Groovy has, with stronger typing.

Except for collection literals - I really wish Java 8 had those.

def myList = ["item1"]  
def myMap = ["key": value]  

is much nicer than:

List<String> myList = new ArrayList<>();  
myList.add("item1");

Map<String, Object> myMap = new HashMap<>();  
myMap.put("key", value);  

I digress...

Each of the backend components also follows the scalability design pattern of separating out state from execution. I'll dive more into this in a later post, because I think it's an important software architectural design pattern.