Amazon introduced their IoT button, Wercker released a new way of working using workflows, and the EFF announced Certbot.

Internet of Buttons

Amazon released a new little toy last week: a button you can hook up to your AWS account. This uses the AWS IoT tools to acknowledge the button press and from there you can do whatever you want. Obviously this includes handling simple commands such as storing the click in DynamoDB or sending some sort of notification.

More interesting use cases however come along when you consider that you can also trigger Lambda functions. This means that you can easily have the button trigger anything you can program, and of course you don’t have to limit yourself to have it trigger a single action. If you want a button next to your bed that turns on the light in the morning, starts your coffee machine, puts on some music, and already drives your Tesla out of the garage with a single press you can do that.

As seems to be usual with Amazon, buying the button is restricted to people in the USA¹. Unfortunately it seems that the buttons were sold out within hours so if you didn’t get one (because you’re on a holiday for example) you’re out of luck for now and can only sign up to be notified when it’s back in stock. I for one will try to get a couple to play around with once they’re available again.

Wercker’s workflows

Last week I spoke of Jenkins introducing pipelines, and this week I’ll spend some words on Wercker’s version of this. This was in beta for a while, but last week it was released for everyone². Because of this I still haven’t been able to do anything with this, so I’ll just go over the theory of the new way of working and will follow this up once I’ve had a chance to play with it.

Traditionally, Wercker files had a build and deploy section. With the new system this has changed in that there are no more limits to the type and amount of sections. These sections are now referred to as pipelines so that’s the term I’ll use from here on. Pipelines can be triggered in the old way (by a git push), but they can also be triggered by a different action. Which is presumably how something like a deployment will work.

It’s also possible to trigger multiple pipelines at the same time, which can be useful when you have tasks that can run in parallel, such as multiple deployments. Naturally the user interface has been adjusted for this as well, but one of the best changes seems to be that you can now define a box/container specific for a step. The advantage of this is especially good if you wish to deploy a Docker container. I’ve mentioned before that it was only possible to use either a scratch container or your build container for your base.

The new workflow allows you to use any base container you wish to use for a specific step. In theory you can create a Docker container that you want to deploy your application in and then use this in de deploy step and have it be separate from the container you used to build, test, or compile your application. This separation of build and deploy containers should result in far leaner containers.

The new system seems to be missing³ a few things compared to the workflow in Jenkins. It doesn’t have the automatically adding of projects that Jenkins 2.0 introduced, but it also doesn’t seem to have an easy way to differentiate what pipelines should run based on what branch code is pushed to. This is for example useful if you want to automatically deploy your staging branch to your QA environment.

That said, I’m interested in playing around with it some more even if it means that I’ll have to update a number of articles as well as the Hugo tutorial.

Certbot

The EFF announced that they’re splitting off the ACME⁴ client for Let’s Encrypt into a standalone project and giving it a new name: Certbot.

Up until this point (and probably until the final release) this was the official Let’s Encrypt client. To be honest, I’m not entirely sure what the advantage is of splitting it off. The main reason seems to be to ensure the clients are distinctly named from the service itself. I assume this is in order to provide clarity on the name, but I don’t see the point.

I’m also not sure what this means, other than that you’ll get a different client by default (assuming you still get one). I doubt this change will have a significant impact on the usage, but it seems to add some confusion. Or maybe that’s just me.