The source code for this post can be found on Github.

Kubernetes has democratized the cloud more than any piece of software before or since. What used to be proprietary APIs by AWS, Azure, or GCP for things like auto scaling groups, load balancers, or virtual machines is now abstracted away behind never ending yaml configuration. Combine this wonderful abstraction with the pricing model of Digital Ocean and you’ve got all the makings of a developer party.

The source code for this post can be found on Github.

Terraform lets you define your infrastructure, e.g. a virtual machine, in code. Used properly, this saves you a lot of time, makes infra easier to manage, and will generally limit your ability to do something dumb, like delete or modify something your infrastructure is dependent on.

In a previous post, we saw how to create a digital ocean droplet and provision it with Ansible. Creating multiple droplets is very similar, you mostly just have to pay attention to the response object that you get back, which is different in the single vs. the many case.

Ansible allows you to provision servers in an idempotent fashion. It lets you see the state of your VM configuration as it resides in code, which is light years better than the sysadmin ways of yesterday.

You can see the sample code for this post on Github.

Consul Watches offer a way to hook into changes to the Consul cluster state at runtime.The specific type of changes we will be looking at hooking into in this post are checks. Whenever a node or service comes online and registers to Consul, whenever an existing node or service leaves Consul, or whenever an existing node or service becomes unresponsive, Consul will emit a check event. This check event can invoke a process to monitor the health of our services, alerting human being that action might soon be necessary.

The source code for this blog post can be found on GitHub.

Consul can run in either client or server mode. As far as Consul is concerned, the primary difference between client and server mode are that Consul Servers participate in the consensus quorum, store cluster state, and handle queries. Consul Agents are often deployed to act as middle-men between the services and the Consul Servers, which need to be highly available by design.

You can find the source code for this post on GitHub.

Consul is a distributed service discovery engine. It’s primary purpose is to track and manage services that interact with it–usually via an HTTP API. It monitors the health of services in near real time, providing a more robust way of routing services to healthy and responsive nodes.

You can see the source code for this post on GitHub.

We spent the last post figuring out how to migrate an embedded PostgreSQL database using Spring, while trying to side-step the extra magic that comes along with the framework. Here, we are going to build on that work to migrate a real PostgreSQL instance, which we will build in a local Vagrant Virtual Machine.

The source code for this post can be found on GitHub.

Flyway is a database migration tool. Migrating a database generally means that you are making a change to the way the database currently structures its data. It could also mean you are adding stuff like custom stored procedures or indexes to help speed up queries. Either way, migrating databases is easily the most difficult part of any deployment strategy–Flyway makes this process as painless as possible because it will, by default, only run migration scripts that haven’t yet run.

You can see the sample code for this post on GitHub.

PostgreSQL is still my favorite database, and if a project I’m working on makes sense as a relational database model, it’s always what I reach for.

You can see the sample code associated with this post on Github.

In two previous posts, we looked at how to provision a reverse proxy using nginx and then how to add caching to the nginx reverse proxy. The implementation we ended up with at the end of the last post was a “dumb” cache, meaning that it doesn’t know when or if any data gets updated–it just times out after 60 seconds and then asks for a new payload from the application it’s acting as proxy for.

The source code for this post can be found on Github.

In my last post, I provided an example for how to set up an Nginx Reverse Proxy for a Spring MVC application. One such reason to set up a reverse proxy is to utilize caching of resources. If you have dynamically generated content that doesn’t change very often, then adding caching at the site entry point can dramatically improve site responsiveness and reduce load on critical resources.