There are few options in the cloud that are really worth investing time in. Amazon (AWS) is clearly important as the market leader, and Google Cloud (GCP) offers a variety of very interesting technology. Microsoft (Azure) has some remarkable technology, especially for Windows-oriented shops. After that, options are much smaller scale: there are big names like IBM (BlueMix) to much newer startups (such as Digital Ocean). None of them are very distinct. However, if we’re willing to take a slightly less western-centric approach, there is another: AliCloud.
Everyone is now talking about the CPU security problems that are now being fully disclosed: they’re dubbed Meltdown and Spectre. Meltdown is a problem that mainly or entirely affects Intel CPUs, but Spectre is a problem that affects all designs.
I haven’t seen any “explain it like I’m 5” on the Spectre paper yet, so here’s my take. Sadly, it’s not 5-year-old level, but I’ve tried to make it a bit more accessible. If you want a lot more detail, the Google blog has code.
I just listened to “Troubleshooting Agile”, a new audio series from CTO Craft contributor Douglas Squirrel and his podcast partner Jeffrey Fredrick. The first edition is on blameless culture, which I think is a great starting point: it’s very difficult to develop, and taking baby steps toward that in a team which doesn’t have it often feels wrong.
Sam Altman has published a thoughtful piece about what was previously called the Singularity, which he now refers to as The Merge. I’m not sure these concepts are quite the same – the traditional Singularity was less a statement about humanity than a theory that, at some point, the improvement of intelligence of machines is sufficiently fast that it becomes pointless to predict the future. “The Merge” for Altman is about the point at which human intelligence might start accelerating – which assumes the machines will want to bring us with them. Not quite the same.
However, Altman believes The Merge has already started. I’m pretty convinced it hasn’t, but I think what is interesting is identifying which signs might be indicative or not.
Gosh, I wish I was at re:Invent. Personally, I don’t like the States much (the place is great; getting through the airports is an exercise in frustration) and while I’ve never been to Las Vegas there isn’t much that ordinarily attracts me to the place. But, to have so many incredible people in one place – amazing.
For those – like me – not there, what do the announcements today mean? I’m not going to focus on the tech so much, but more on the additional options and architecture that is becoming available. Let’s look at a strategic level.
This evening’s RedMonk article on linguistic prescriptivism is, as usual, excellent reading. Does it matter what people call things? Is the intent behind the name something significant, which should be respected?
In computer science we “have form” on this subject. The names or symbols we assign to things are very clearly different from the values involved. We might write
1.999..., and these symbols are distinctively different from the concept of two-ness, and indeed in another language we might write a two using very different symbols, like
(() ()). Often this logic gets carried forward into other areas – somewhere else on Twitter, a discussion about Serverless was happening.
It has been just over a week since I wrote that software architecture is failing, which received a level of response I didn’t expect. The reason I wrote the post in the first place was to set the scene for some future posts I want to write: as I said, I don’t think we talk enough about architecture for SMEs particularly, and I want to spend some time focussing on those. This post described the reason why.
However, one thing was very clear: the post overall, and many of the ideas within it, strongly resonate with a much larger group of people than I expected. I want to reflect on that a little, but first, let’s look at some stats.
Everyone wants faster Continuous Integration (CI). The quicker you can get from commit to test results, the better – but there’s a bit of tension here. A CI should start close to “first principles”, so that you know an entire build is good and repeatable. But the more work the CI is doing, the slower it will go.
I’ve mentioned before that I use a combination of stowage and container-based CI systems, and in professional life we’re very heavily invested in GitLab now (which is an excellent system in general). Containers are a good starting point for CI, because they’re very easy to set up, do some work, and then throw away again. Getting clean builds is very straightforward.
Today I released version 0.5.0 of stowage, which brings a few additional small features which really simplifies usage in CI.
On social media right now, strong rumours are spreading that the WPA2 encryption scheme has been broken in a fundamental way. What this means: the security built into WiFi is likely ineffective, and we should not assume it provides any security.
The current name I’m seeing for this is “KRACK”: Key Reinstallation AttaCK. If this is true, it means third parties will be able to eavesdrop on your network traffic: what should be a private conversation could be listened in to.
This has happened before with WiFi: who remembers WEP passwords? However, what is different this time around: there is no obvious, easy, replacement ready and waiting. This is suddenly a very big deal.
I doubt there has ever been a time when software architecture was seen as a raging success. The “three-tier architecture” of the web has held up extremely well and is an excellent place for many people to start. The “12 Factor App” approach has encouraged developers to adopt practices that make deployment and scaling much simpler. Over the last couple of years, though, I’ve noticed developers advocating for architectures I consider to be extreme and limited in utility, foisting highly complex systems into startup environments at great cost. It appears to me to be getting worse.