Scaling your service has usually been in the domain of system operators, which installed servers and developers tweaking software when the load got high enough to warrant scaling. Soon enough you’d be looking at tens or even hundreds of instances which took a lot of time to manage. With the release of Docker 1.12, you now have orchestration built in - you can scale to as many instances as your hosts can allow. And setting up a docker swarm is easy-peasy.
When you’re writing software it’s not so much the one liner that changes how you work, but the balancing act of programming patterns you use to build your software. I’m hoping to outline a few rules and patterns which make sense to me when building out software in Go.
A few months ago I had been participating in the Docker Maze challenge, where I was awarded a Raspberry PI 3. The package was lying on my desk for more time than I care to admit, but finally I decided on a project which seemed interesting to me. I was going to make a build status indicator. Whenever one of my projects would fail, I would turn on some external peripheral that would let me know that something broke.
The previous post on Dependency Injection in Go stirred up some heated responses on Reddit and Twitter. I’m writing this post to illustrate some good benefits of Dependency Injection in Go when applied to some benefit. I will also demonstrate an additional, declarative DI pattern of the Factory model presented in the previous installment on this subject.
Dependency Injection is a powerful approach to providing your applications with required objects and configuration instead of declaring them in code. This injection is usually used to provide mock objects for unit testing, or to run the same application in multiple environments.
We covered a few useful tricks in the previous installment of this blog series, and now I’m going to show you a few more which might make your life even simpler.
