Recently I’ve been exploring containers, and what they might be able to do for my team at work. I’ve been experimenting with containerizing some of my own applications since there isn’t any time available for R&D during the work day. I’m a dyed in the wool FOSS/Linux fan, and work is solidly a Microsoft shop although that may be slowly changing.
We’re in the middle of a big transition into Salesforce. This will replace our legacy CRM software. This is the first real push to move our organization’s software into the cloud. With that comes more openness to putting our in house software in the cloud as well.
Right now we host all of our stuff in house. Website, several internal applications, a few single page apps that talk to a REST API. Most of this right now depends on being able to access our current CRM software. Once the transition to Salesforce is complete, we’ll have very little tying us to hosting everything ourselves.
There is, of course, organizational inertia to overcome. I will need to determine and demonstrate how moving our stuff to more managed platforms can make us more effective. I think there is opportunity to reduce some of our maintenance burden as well as some cost savings to be had by dropping some Windows licences.
There’s a lot to be done before we can really start putting stuff into containers. We need to bring our remaining software projects up-to-date with .NET by porting them to .NET Core. We could do this incrementally, but convincing management that we should do it, and then having management actually be OK with us doing it alongside other work, and potentially delaying that new work a bit are two different things. Management is also gun shy of breaking things in the process of such a port. This is understandable for a number of reasons:
- We don’t have a test suite
- Our business processes are complicated and convoluted
- I’ve pushed bugs to production before
I have conflicted feelings about No. 3. On the one hand, I should have tested my stuff more thoroughly. On the other hand I feel that a mindset that emphasizes developer correctness over processes to catch errors is less effective in the long run. Putting in place automated safe guards is more effective that simply leveling up the developer because those automated safeguards don’t suffer from fatigue, don’t get distracted, and don’t get bored. It takes careful design to get the tests to actually test what you intend but once that is achieved it is repeatable. And then progress on new things speeds up because the test suite catches problems quicker.
At least that’s what I’ve read. It makes sense to me. My existing team members don’t put as much stock in it as I do. That’s my assessment. Also, while I’ve put some effort into building a test suite before, I’ve never really gotten it to a state that really tests what it’s supposed to. Because of this, I haven’t really been able to demonstrate any benefits.
So yeah. I’ve got to work on stuff and really show the merits of the stuff I want to do if I want to convince people to try them.