Recently, I have been fortunate enough to undertake some Azure training under one of the Solution Architects at Microsoft. We spent a lot of time focusing on Azure Service Fabric, Microsoft’s platform for developing microservice-based solutions. Much of what I heard reminded me of my experiences of Docker Swarm and Kubernetes, two very popular container orchestration platforms, and many of my questions in the training sessions were centered around why I might want to use Service Fabric over one of these other platforms that I knew a little better.
One point the trainer made that has stuck with me since is: containers often contain microservices, but microservices are not containers. It was clear to me then
This past Tuesday, the annual State of DevOps Report for 2017 was released. The report is one of the most respected in the industry and attempts to measure and comment on the direction that a broad range of organizations travel on their DevOps journey. There are usually some interesting comparisons and trends to analyze against the previous year’s results also.
The report is
When I was a junior developer, the sort of books and blogs I read off-the-clock tended to be about design patterns, abstractions, test-driven development (TDD) and so on. These topics haven’t gone away, but these days we tend to focus more on rapid application delivery, continuous integration, feedback loops and continuous improvement in the development process of that software, not necessarily the software itself.
Much of the classic developer reading material has strong craftsman-like overtones, the excellent Pragmatic Programmer being the most obvious example. On the other hand, some of the more recent material, like Continuous Delivery or The DevOps Handbook, describe the process of developing software as a factory production line to be optimized, inspired by the lean manufacturing revolution at the likes of Toyota in the 1980s.
Is the change in imagery from the master artisan to the fine-tuned production line a sign of progress or something to be worried about? It looks like the software industry’s Industrial Revolution might have started.
A match made in heaven
If you are a regular reader you will know just how much I have fallen for Golang recently. If not, see Fun with WebSockets in Golang for why I think it’s such a great language for writing backend services.
As explained in that blog post, my motivation for learning Golang originated with my experimentation with Docker. Golang programs are (usually) statically compiled to machine code, not bytecode, so no runtime interpreter like a JVM or Python is required to run them. This means that you can fit those programs into the smallest Docker containers possible for maximum density and reduced attack surface. Pair that with Golang’s performance (which is comparable to C++) and you have a match made in heaven.
Unit testing and the reason for mocking
If you’ve read my definitions of unit testing and system testing in my Ten Tenets of Test Automation, you’ll know that the primary differences between the two are target audience and granularity of coverage. Unit tests seek to validate the intentions of developers at a very fine, narrow scope, often at the function or small class level.
There should be lots of these fine-grained checks to validate your code base. Having them helps you understand the impact of evolving requirements. Having to deal with change in the life of developing a product is as certain as