1. Overview
In this tutorial, we’re going to look at Spinnaker, an open-source continuous delivery platform built by Netflix. We can use it to deploy our applications across multiple cloud providers.
The system is built on top of Spring Boot and supports many cloud providers.
We’ll see how it works and for which cases we can use it.
2. Background
Let’s have a look at the history of software development. First, we had the Waterfall with infrequent releases.
After that, we started working Agile and delivered features every sprint. However, we still didn’t deploy to production every sprint. Unfortunately, the users still couldn’t use the new features, which were lying on a shelf.
There were some reasons for not deploying regularly. One of them was the fact that deployment steps were often manually executed and prone to human errors.
In addition, some people thought that deploying more often meant more risk for potential problems. Nowadays, we mostly agree that deploying small changes means less risk for big mistakes. Even so, if there is a mistake, we can quickly locate it in the small change and release a new version that resolves the issue.
3. Spinnaker
With Spinnaker, we can use continuous delivery or continuous deployment to release our application on production automatically. Continuous delivery means that everything is prepared for a production release.
However, the release is approved manually before the application is deployed on production. Continuous deployment means there is no manual intervention. All steps are executed, including the deployment to production. We just push our application code to a version control system and that’s it.
From pushing our code to version control until the deployment to production, we can execute lots of steps. We can build our code, unit test the code, deploy it on a test environment, and execute functional tests. We use a so-called pipeline to configure all those steps.
With Spinnaker, we can create such a pipeline and deploy our application on most cloud providers.
4. Components
Spinnaker basically consists of two parts: an abstraction layer on top of various cloud providers and a tool for continuous delivery.
4.1. Traditional Cloud Deployments
When we look at cloud providers, they all offer more or less the same services. Those services include things as instances, serverless, and container support.
However, the configuration of those services greatly varies between the providers. That makes it harder to switch between providers. It takes some time to move to another cloud provider and learn all the details, which means we basically have vendor lock-in with our cloud provider.
Netflix wanted to have the possibility to easily switch between cloud providers, rather than be dependent on just one. That’s why they built an abstraction layer on top of the cloud providers.
4.2. Abstraction Layer
When we use Spinnaker, it’s the same on all cloud providers. We can use it on Amazon Web Services, Microsoft Azure, Google Cloud Platform, OpenStack, Google App Engine, or Kubernetes. This allows us to move to another cloud provider if the prices are more competitive.
Even more, we can choose to deploy to multiple providers at the same time. That way we can run our application on two or more providers for extra redundancy.
Another benefit of the abstraction layer is that it focuses on the applications instead of the resources. Normally, cloud providers show us the resources that we currently use. However, we have to figure out ourselves what application is using which resources.
But resources aren’t interesting for us. We want to run our application without spending time keeping track of resources. Spinnaker has an application-centric view. So, when we look at it, we first see the application, and then we see the resources used by the application.
4.3. Continuous Delivery
On top of the abstraction layer, Netflix built a continuous delivery platform. This platform allows us to deploy our application on one or more cloud providers. It looks a bit like Jenkins, but it offers nicer integration with the cloud providers and requires less configuration.
We can trigger the continuous delivery pipeline from Jenkins, an uploaded Docker image, or a git push, for example. After that, we can simply create an image or a container with our application and start it on production.
However, there are many more options available such as automated tests and manual approvals before deploying on production.
We can even decide what strategy we want to follow when deploying a new version of an existing application. As such, it’s possible to simply replace the old version with the new version. However, a better strategy would be to run them side by side first. That way we can automatically or manually check if the new version works and, if so, remove the old version.
5. The Netflix Cloud Model
Every application consists of one or more server groups. The same version of the application runs on all instances in the server group. The following naming convention is used: <application-name>-<(optional) stack>-<(optional detail)>-<version-number>. The (optional) stack field is used to specify if the server group is for test, production or other purposes. The optional detail field is used for extra information.
Finally, we have the concept of a cluster that contains one or more server groups with the same name, stack, and detail. However, most of the time each server group in the cluster runs a different version of the application. Failing instances will be replaced by a new instance.
It’s also possible to automatically add instances to a server group to accommodate the increased load.
6. Deployment Strategy
When we deploy a new version of an application, the ‘red/black’ strategy is normally chosen. First, a new server group containing the new version of the application is deployed to the cluster. After the application deployment, a check is performed to verify if the new server group is healthy.
Now, the server group is enabled and available to our customers. Finally, the old server group is disabled.
In this scenario, it’s easy to roll back if something goes wrong with the new application server. We can simply enable the server group with the old version again and make it available to our customers.
7. Why Spinnaker
With Spinnaker, we can focus on our application instead of the cloud resources that we use. This makes it easier to deploy and maintain our applications.
Additionally, Spinnaker makes it possible to run on multiple cloud providers at the same time. Moreover, we can easily switch to other cloud providers depending on their pricing strategy and available features.
8. Conclusion
Spinnaker builds on the experience of Netflix. We can use their knowledge and work in the same way with minimal effort. Based on these tools, we can easily implement a deployment pipeline to deploy our applications to production.
To learn more about Spinnaker, download the free Continuous Delivery with Spinnaker ebook.