Deprecation

Transformation from monolithic stacks to continuous delivery takes an other approach. In a monolithic environment it is a good practise to deprecate certain parts of the software, but it is not mandatory, everything is upgraded at once. But if one is going to deliver several updates a month, week or preferably a day, there need's to be a model to let applications and API users adapt to the new features.

Deprecation is when certain parts of the code are deemed obsolete and are ready to be removed. Because a lot of applications and interfaces depend on those parts of the code, it is hard to remove them. Therefor they should be marked deprecated and removed in time. Changing code, by refactoring for instance should never change a function call. A call should always be backward and forward compatible. Adding new parameters to the call is fine, removing any of them is considered evil. Whenever something is being deprecated a end of life time should be communicated, being either a date or a version. A version number can also tell us about deprecated features, whenever a major version changes, expect a cleanup of deprecated functions. Minor version changes should never break code.

So far, this has been the easy part. Code is easy to maintain an deprecate. It get's harder when we switch to API's. Most API's carry a version number in their URI. Which means that there is no deprecation, and whenever a new version of the API is released on a new URI, it is allowed to break all protocols compared to the previous version. A better practise is to update the existing API with new methods, extra parameters and communicate about what interfaces will disappear in the
comming period. This allows clients of the API to make adjustments to their client software in a timeslot whenever it suits them best.

Database updates are the hardest in my experience. A lot of times things get really fuzzy at this point. Adding columns when upgrading, inserting new base data, perhaps some PLSQL is added or removed. In a monolithic model an upgrade and a rollback of software goes hand in hand. We need extra SQL to make rollbacks possible. In a continuous delivery environment there is no need, because we only roll forward. However, changes to SQL need to be versioned as well; not in a single big SQL script for all applications. But added to the mini-, micro- or macro-service, in the module. In many projects I find nicely separated modules but one big cloth of SQL. Add the SQL of a module to that module, so it's kept under the same version as the code. A base SQL to generate the major version of the database, and all updates as separate files.

So far this is a very small piece of text from me about deprecation; barely scratching the surface, but there are lot's of good websites explaining how it should work. GIYF

A note about SSL/TLS trusted certificate stores, and platforms

Why are there so many places on a Linux machine to put in certificates? AdamW has a nice explanation I don't want to hold out. In short: /etc/ssl is Debian bases, /etc/pki is RHEL based. There is no standard, and all do what they like.


Gratitude to AdamW: https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/