Ah, I love the Vocally Communicating Thought Generators.

Did you maybe mean to say Terraform, or am I missing a key aspect of my job role?

If you’ve been working as a SRE since 2011, I’d say now is a good time to refresh your knowledge on Ops. A lot has changed since then in terms of best practices.

I would recommend reading the DevOps Handbook. The audiobook version is quite easy to digest. There are many case studies about DevOps transformations in this book as well, including Etsy’s—the development techniques they used are quite interesting.

DevOps has introduced a swath of methodologies for increasing the stability and maneuverability of large technology companies. Ignoring or remaining ignorant of these standards puts companies at a steep disadvantage. CI/CD and IaC techniques allow technology companies to develop stable code efficiently without accruing technical debt.

I’ve worked in places where these principles were not followed and had to take on somewhat of a SRE role myself because of how many failures we were having. DevOps practices would have saved us, had we only had the knowledge and foresight to use them throughout the organization. I highly recommend increasing your awareness of these standards, regardless of what direction you want to take with your career.

As I understand, when you’re working with an object-relational mapper (ORM), the default is to refer to persistent objects which cannot have their types changed at runtime. If an object goes through some kind of transformation, introducing new attributes, the best practice in OOP is to create a new object with those attributes so you don’t leave nullable attributes in the original object’s class definition. But this would cause the ORM to be unaware of your new object unless you create custom code to swap the references out, which is messy. In functional programming, you create a new object and DB reference by default, so no custom code is needed.

Alternately, in OOP, you could create smaller objects to contain the attributes which are expected to change through the lifetime of the controlling object, and give the outer object an attribute which refers to the smaller object. This way, the contained object may change entirely, but the owner object’s type remains static in the ORM and always has a non-nullable attribute pointing to the mutable attributes (contained in objects which are swapped out functionally). It still means you have to tell the ORM when the smaller objects are swapped out, which is still messy, but at least it standardizes the process. That’s my understanding of this issue, in any case.