Recently I experienced something most of us run into at one time or another. It’s related to the DRY (don’t repeat yourself) principle. I was looking into using a custom tool designed in house, and applying it to a new internal application. The first thing we talked about was how to connect the two applications together. We had already done the integration a couple of times, and were looking to clone the implementation.
Our immediate thought was that this could be a micro service. If we did that, then the integration point could then be used again as we continued to implement this tool with other applications. Any new application would simply require connectivity to the new micro service.
So, here is the conundrum. My application already has a service layer. We could easily import the project into my application service in a matter of a few minutes. However, if we want to stand it up as an independent micro service, I would have to build the hosting infrastructure, and the rest calls to integrate the two services for communication. The time grows from a few minutes to a few hours, or maybe even a couple of days.
Like everyone out there, I have limited time to get things done. In fact, the whole reason for using this integration is to help us get caught up on a project that is behind schedule. What would you do? Create the micro service with the intention that it could be used again, but there is nothing in the current plans to do so? Or, use the project in an existing service, recognizing that a micro service should be the implementation the next time this capability is needed. In short, do it in the next project that doesn’t already have requirements and project deadlines?
Share your thoughts in our comments or by email to btaylor@sswug.org.
Cheers,
Ben