We have covered off the basic principles of DevOps in the previous episodes, now we’re looking at how this looks from a technology perspective. In this episode Andrew and Paul cover the technology stack that we are currently building on, and what each piece of the DevOps jigsaw does.
This article and episode is aimed at a technical audience: architects, developers and release managers.
A foundation for rapidly building microservices on Kubernetes
We’re looking now at the DevOps stack we’re building with, notably the stack that we are using to build Glu that will go into live Beta next month. If you’ve been following the podcast series you’ll know that we’re building a microservices platform leaning heavily on Kubernetes hosted in AWS. The tech stack we describe here is our way of doing this – if you’re looking to put in place a similar stack elsewhere you should be able to get some great ideas from what we’re discussing here.
You can always book a free call with us to talk about your technology stack and your DevOps needs, we love hearing from you!
Going through the stack one piece at a time
We’ll step through the stack piece by piece and explain what we use each of these for. This is a whistlestop tour of what we discuss in the episode, so please take time to listen to the episode in full!
GitHub
As we’ve said in the last episode, Git is the source of truth. This is true for both infrastructure and applications. You can use any flavour of Git; we have chosen GitHub for a number of reasons:
- Cloud-based, no maintenance, developers can access from anywhere.
- The ecosystem of apps that play well with GitHub via webhooks.
- The tooling around pull requests, branch permissions and protecting branches, meaning we can keep our core code branches clean, tested and high quality.
Shippable
We use a cloud-based CI tool called Shippable that integrates with GitHub. This runs our CI process. We use this because:
- Builds run in containers so we can control the build stack easily.
- It works well with GitHub for reporting build success and code coverage.
- It’s easy to use.
- It’s inexpensive.
- It’s cloud-based and hosted. Minimal maintenance.
Spinnaker
We use Spinnaker as a deployment platform. We host this in AWS using a dedicated Kubernetes cluster just for Spinnaker. This is because the DevOps tools need to run outside of the other environments. Spinnaker comes from the Netflix stable, and supports a number of deployment models we’re interested in using such as canary and blue-green.
Pypyr
Pypyr is an opensource pipeline runner developer by fellow 345 team member Thomas. We use Pypyr because it lets us do many of the DevOps tasks that you normally write shell scripts for, but Pypyr lets you express them as YAML files. This gives us a more readable script, plus the underlying code to execute the steps is tested and high quality.
ClickUp
We use ClickUp for project management. Tasks integrate with GitHub well, and the software is not opinionated in how it is used, unlike some others (JIRA, we might be looking at you here). ClickUp lets us organise tasks very flexibly through its tagging system, which lets a task belong to multiple hierarchies at the same time. We can prioritise, organise by actor, organise by size, area of the system. It’s easy to search, filter and update.
The software is still maturing and there are areas where it can be seen as weak, however the flexibility we gain more than offsets this (to us, at any rate).
Developer Workstation
We use a posix workstation for development. A lot of the devs like to work natively on Macs, whereas if you’re on Windows we use virtual machines running a flavour of Linux. Arch Linux is a popular one, as it’s so lean.
IDE
We are not prescriptive about IDE, but our default choice is Visual Studio Code. Some of the guys use other editors, it depends on their personal choice.
Slack
For internal communications we use Slack. This gives us a flexible ChatOps platform that integrates with the tools above so we get a feed from GitHub for pull requests and merges, we get a feed from Shippable for builds, and we can get feeds from ClickUp when actions have taken place on tasks.
This can lead to a very busy in terms of the volume of information
You can watch the video here:
You can listen to the audio here: