Christmas time is always a slump when it comes to news in the tech world. So, this week we’ve got some new things and a bit older news I didn’t get around to including before. This includes the Go font, and the rest is focused on Docker news.
Go font
Let’s start with some very unexpected news1. For some reason the programming language Go now has its own fonts. Apparently this is related to the work being done on building a user interface part for the language. I’m completely in favor of having a decent user interface framework2, and as this is meant to be cross-platform it then also makes sense to have a language that can work cross-platform without any licensing issues. Especially as the fonts are licensed under the same license as Go itself.
While not stated, it’s also implied that the font is the preferred font to do your Go programming in. I’ll probably try it out at some point to see if it’s good enough to replace my current development font, and it’s always a good thing to have more choice in these kinds of matters. Despite all this though, it still feels weird to me for a programming language to have its own font. Then again, that’s the benefit of having a big corporate backer. They can assign unrelated resources to something like this.
Docker spins of containerd
In 2016, there have been a number of complaints with regards to Docker as to how it was trying to do everything. Originally it started as just the basic container, which other projects could then build on for orchestration. Over time however it became clear that Docker wanted to do a lot more than just providing the container. Especially with the various releases this year, including version 1.12’s Swarm, it became clear that Docker was aiming to provide a complete solution.
This has actually led to some complaints from framework providers who didn’t like how this was interfering with their products. To be clear, while I’m sure that they didn’t particularly care for the extra competition, their complaints were focused on the fact that it became harder to use the ever more abstracted containers. It’s simply a fact that a product build for ease of use by the end users often isn’t as easy to integrate into other projects. So, to deal with that Docker has announced that they’ll split off containerd in its own project.
containerd is the part of Docker that actually controls the container, and therefore the exact part that other projects want to use. It’s also not usually accessible by end user, and because of that most people won’t notice any difference. This means that the underlying container will be separate from the rest of Docker, and its development going forward will be a group effort with some of the biggest names in containerization becoming involved with it. This includes both companies like Google (who make Kubernetes and were using containers before most of us even knew what they were) but also AWS and Microsoft who have their own orchestration projects in their respective cloud offerings3.
The work to break out containerd has apparently been going on since Docker 1.11, and Docker expects that it will be separate in the first quarter of 2017. Obviously I think this is a good move as having containerd become a group effort instead of being controlled by a single company makes it far more likely to stick around in the future. It will also make it far more interesting from a competition point of view. With no need to rely upon the complete Docker stack platforms can develop into very different ways, while still being compatible with each other. For a more complete explanation from Docker about how this will work, you should read their blog post about it.
ECS supports Windows containers
Speaking of containers, AWS announced a beta program for running Windows containers in ECS. This isn’t entirely unexpected after Windows server 2016 added support for Docker, but it’s still a good thing to see. Having dealt with Windows server applications, and the efforts to install all the correct dependencies4, I can only applaud this. No, Windows containers aren’t as light as Linux ones, and starting them up takes a lot longer as well, but compared to an actual Windows server they are so much better.
While people like myself would love to see everyone switch to using Linux for their server needs, that’s obviously not possible quite yet. Because of this, making the process easier for those who have to deal with Windows5 is great.
Some obvious caveats come with the ECS implementation. You need to use a Windows AMI for the instances that your containers run on, and you can’t mix Linux and Windows. I hope that last one might change in the future, as technically it’s possible to run Linux containers on Windows, but it’s early days.
Next week
Due to the expected lack of news during the holidays, and that I’ll be taking a short trip, there won’t be a note next week.
-
At the time at least, this was almost two months ago so it’s possible everyone knows by now. ↩︎
-
Which is obviously a great thing as it allows for different and more interactive applications than only a CLI interface does. ↩︎
-
To be complete here, while AWS only offers their own ECS solution, Microsoft offers multiple ways of orchestration that now include Kubernetes. ↩︎
-
Seriously, while I might be unaware of some things that make it easier, I really missed being able to use apt-get and its like to install things. There are so many things that make life easier for servers on Linux that working with Windows feels like going back 15 years. ↩︎
-
If you feel like I’m unfairly judging Windows, take into account that all my recent experience was with Server 2012. It’s possible that 2016 makes things work better, but in my opinion the best part of Windows is currently the built-in Ubuntu. ↩︎