• It’s no secret that web development tooling have been steadily trending towards use of open-source software over the last decade. At conferences and meetups, we’ve seen Lenovos and Toshibas being edged out by Macbooks of every kind, and even the occasional non-Apple laptop is not unlikely to be running some flavour of Linux (as happens to be the case with my Thinkpad).

    I recently started working with a large team of web developers who are - for the most part - Windows-based, and this led me to a surprising discovery: much of the open-source web development tool ecosystem is just paaainful to use on Windows. Open-source projects, which traditionally and practically favour Linux, treat the Microsoft system as an afterthought, if at all. So when a .NET developer attempts to jump into working with Node / Golang / Python, they are immediately disadvantaged by tooling barriers and lack of community content and support.

    Every step of the way, Windows creates friction for web developers who choose to build web products using modern open-source technologies.

    Thanks to its Unix underpinnings, macOS has become an almost de-facto standard in this space. But many developers do prefer to use Windows as their primary desktop OS - for a multitude of very valid reasons, or just due to personal tastes, or simply because gaming.

    The practice of DevOps teaches us to build bridges. And so we shall certainly do whatever is necessary to build as good of a web dev experience possible in the Microsoft ecosystem. But I feel this experience will always lag behind that of working on Linux or macOS, just due to the sheer size of the ecosystem shared by, and targeting, those other two dominant platforms.

    An example:
    • Everyone Most of us either already are, or are soon going to be, using this little tool known as Docker.
    • Also, many devs use VirtualBox, because this free virtualization platform is what a lot of the tooling and community knowledge are centered around.
    • But, on Windows, Docker needs Hyper-V.
    • But! Hyper-V is incompatible with Virtualbox.
    • But!! Virtualbox has the broadest ecosystem of getting shit done in a fun automated way (Vagrant, basically).
    • But!!! Lisa needs braces Docker needs Hyper-V…

    /shrug.

    If you wish, here is another shining example of the hoops one needs to jump through to get some Node.js action on Windows. I won’t post more because the Interwebs are ripe with them (or just talk to some Node developers who happen to use Windows).

    What can we do today to improve this?

    • Automate everything. In place of PowerShell scripts, use task runners. While the venerable make can be installed on Windows, it’s a bit of a ceremony, so try some alternative, cross-platform task runners. We are successfully using go-task.
    • Write tooling around Docker, and try to run as much of your toolchain in containers as possible. Standardise on an image that will work identically across platforms. Encourage yourself and your team to think “container-first”.
    • (reluctantly) use docker-toolbox. Yes, this is a legacy solution, but at least it will get around the Hyper-V requirement, and enable use of Vagrant and Virtualbox. docker-toolbox’s days, however, are probably numbered.

    Other ways exist to ease the path of a Windows web dev, which I will explore in future posts. In the meantime, reach out to @boomstik on twitter with your thoughts, comments and ideas.

  • Tue, Sep 26, 2017

    – Hey, we need to do a deployment.

    5 developers swarm in to participate in the process. The fun begins with importing CSVs into Azure tables, a trivial task that we’ve yet to automate. Then off we go to deploy the application. Each deployment is a special snowflake - some services get updated, some not… We set the dials and hit the button. After all, “Those progress bars ain’t gonna watch themselves” (© Stan). All seems to be going well for 15 minutes…

    …until someone realizes that – apparently – something else had to be deployed first.

    – uh, can’t you cancel it?

    uh, NOPE.

    so we wait for this deployment to complete, because canceling a running deployment is bad luck (trust me). Then we deploy the prerequisite (it’s an ARM template, FYI). Finally, we’re ready to deploy the original application, and so we push the button and twiddle thumbs…

    until 20 minutes later:

    hey, did we change that variable?

    guess what ensues?… correct - all sorts of good times.

    fast forward, and the redeployment of the prerequisite is done. We’re into the 2nd hour of this extravaganza now, by the way. We go back to re-re-deploy the apps (3rd time if you’re keeping count). This is it, and then we’re done, right?

    riiight.

    As is tradition, post-deployment, the three scripts exist, which must be manually run on a snowflake box, as a final sacrifice of tears to the great pool of entropy. This involves, uh, pasting the actual scripts into that thing over there, complete with executable paths and all. I don’t know but I’ve been told, this will take like 3 hours to run.

    And it would indeed… only if someone didn’t

    restart the remote-script-runner-service-thingamajig because it was being slow.

    Suddenly what happens? Pop quiz? I hope you said “those script processes are now disowned”, which they are, they bloody are. They are running, but apparently either doing nothing, or something useless. Logs? What if I told you: there are no logs.

    Long story short (not really): I get on chat with the server admin. He checks the box for me, does admin things. We have no visibility into what the scripts are doing. We leave them alone for the time being.

    And a few hours later, they are still humming along…


    There are some takeaways from here. something something.

  • Fri, Dec 30, 2016

    I’ve been thinking of technical debt lately, and came to extend some interesting (or at least cute) parallels:

    • Technical debt doesn’t just accumulate. It incurs interest, in form of dependencies that will break and will then need to be refactored to repay this debt in full.

    • Perhaps you can also default on technical debt. That’s when things get so much out of hand that you scrap the whole thing and rewrite/rebuild it from scratch. Engineers often love the “let’s rebuild it, for realsies this time!” approach. Having seen some shit, I don’t always disagree.

    • Finally… you can go technically bankrupt. That’s when you lose it completely, give up, flip the table, and fire up the ol’ QBASIC.

    10 PRINT "LOL"
    20 GOTO 10
    

    (If that’s you - maybe get help. Maybe from someone like me.)

Hosting AWS Docker Microservices Tooling Automation