Nanoservices
For the past few years in the software development world, there has been a push to break-up monolithic applications into microservices. These smaller pieces of code perform one task and contain a small amount of code. Often, these microservices are contained within Docker images and reside on shared infrastructure.
At first, it seems that there isn't much of a place for infrastructure in a microservices environment. But I want to introduce the concept of nanoservices to everyone. These are even smaller than microservices and contain basic logic that infrastructure teams manage on a daily basis.
For instance, at Unbounce some of our applications
don't handle redirects to SSL internally (think JIRA, Confluence, Jenkins).
In the past, this was accomplished by managing an Nginx/Apache Web server
on the machine, complete with configuration and privilege controls, to
simply take http:// calls and perform a 301 redirect to https://. It's
such a tiny set of logic, yet it requires custom packages to be installed
and running on a server.
To help refactor this out into a nanoservice, I wrote a docker image called http2httpsredirect that performs the Nginx installation with a single virtual host job to redirect all requests to SSL.
Infrastructure teams no longer need to provision packages on our servers, they simply launch this docker image from Docker Hub and bind it to port 80. Once the external redirect happens to SSL, the request goes back out to the load balancer and comes back into the system as an SSL request to the correct process.
It's as simple as this:
docker run -d -p 80:80 unbounce/http2httpsredirect
And it can be tested locally (or remotely) like this:
curl -I localhost
HTTP/1.1 301 Redirect
Location: https://localhost
HTTP 301 redirects are used
because that informs clients to no longer use that URL anymore (at least,
the http:// component) and instead use the location specified in the
response.
Simple and clean.