Raising the bar(code) with microservices
We’ve been closely following the hype around Docker, Kubernetes and all things containerisation for some time. It’s hard not to get caught up in it! However, rather than just microservice-ing all the things, we thought it best to test the waters and gradually upskill ourselves in the land of containers. This post documents one of our early forays.
As part of one of our projects, we found ourselves needing to generate a barcode to display in a PDF. We primarily use Microsoft SQL Server Reporting Studio (SSRS) for our PDF generation so we began our research. We were upset to find that the main accepted way of doing this is to drop a DLL into a specific folder on the Reporting Server. This DLL then provides VBScript functions to generate the barcodes. It felt a bit hacky to just drop DLLs into special folders, the report then becomes dependent on the DLL with no obvious link. In addition to this, our reports would become tied to the server that had the DLL installed.
This microservice has been deployed for a couple of months now and we’ve had no issues with it. However, this doesn’t mean everyone should adopt microservices universally. In our eyes, microservices are not a drop-in replacement for our current project structure, rather a way to augment our systems to help us provide the optimal solution to our clients. I’d highly recommend Sam Newman’s Building Microservices for an excellent exploration of the pros, cons and use cases where microservices are appropriate (hint: far less often that you might think).
The hosting technologies which underpin them, however, offer great value for all kinds of projects. Our containerisation strategy exists to enable us to leverage the ease and repeatability of Docker, the cost-savings, resiliency, vendor independence and scalability of Kubernetes, and the deployment and upgrade management of Helm.
Be sure to watch this space for tales of our future endeavours!