Reading Stephen’s editorial, “Check Out Any Time You Lilke…” reminds me of software patterns intended to help reduce the feeling of being tied to a specific technology. The reality is that it is very difficult to future proof anything. You can loosely couple, inject, micros kernel and much more, and still have dependencies you can’t walk away from.
I do a lot of work in SQL Server, Dot Net, and Angular. Within this limited tool suite I find a constant need to re-tool both my understanding of how they work, and update software so that it is not using a code base that has either been deprecated, or is no longer supported for potential issues or bug fixes.
Just the Dot Net library itself is a bit of a hassle. If you have a project of any size it is possible that one or two releases of the Dot Net framework will be released before you are code complete. So how do you create your tools in a way as to not be bound to a particular software suite or version of the software?
In some respects you can’t. The closest thing I have found to being independent is the user of micro services that stand alone. Each service may be written using completely different tools, while integrating and working with other software. Angular is interesting in how it works well with partial REST services providing CRUD capabilities, while not being dependent on the underlying code. You can write a REST service using any language, and as long as it continues to meet the REST interfaces the web code continues to function. Of course this now binds you to Angular. But there are alternatives even there.
The holy grail will never be possible. I think that micro services, REST Services or even RESTful services are methods available to us today providing potential for a longer lifetime for some of your software. Something to think about anyway.
Do you have things that help your software to have a longer lifetime of service? Drop a comment with your experience. Or, if you really get interested, submit it to SSWUG as your own editorial.
Cheers,
Ben