UPDATED (May 8, 2020 @ 0930 UTC): I’ve updated the document to reflect a slight change in the architecture. It still uses the Ports and Adapters architectural pattern but is now more faithful in its implementation of it. Namely the business logic are no longer named “handlers” but just functions whereas the “handler” term is used exclusively within the charm module as it should be.
==============
I just revisited my work on charm-k8s-prometheus which I wrote with the help of the Operator Framework. For this pass I wanted to focus on its design architecture rather than its functionality. I wanted to ensure ease of code maintenance so I doubled down on adopting Alistair Cockburn’s Ports and Adapters Pattern.
Here is a short discussion on the design decisions I made: Google Doc.
I’m looking for some feedback on this architectural decision as well as notes from others who’ve worked with the Operator Framework about their own architecture.
@mmaglana I have really enjoyed reading through this all.
As far as maintenance and testing are concerned, the adoption of these concepts in the authoring of charm code would be revolutionary.
The work you did conveying the mapping of the design principles to their respective implementation in charm code is superb. How does it go - “sometimes a picture is worth a thousand words”?
I’m just starting to dig in and get my feet wet with the new framework so I can’t really speak to much here. From a charm author/maintainer perspective, I think it is going to be very valuable to have a set of a few different standards/architectures for people to reference as they dig in and attempt to charm their software stacks with the operator framework. That said, I feel that having concrete examples like this will prove invaluable going forward.
Really exciting to see what you have done here @mmaglana. Thanks!
Thanks for the kind words @jamesbeedy! I agree with you that a set of reference architectures for writing charms would be a great resource especially since I expect that the architecture I adopted is not always the best for all situations. Keep us posted on your foray into the Operator Framework and do share notes!
I’ve updated the document to reflect a slight change in the architecture. It still uses the Ports and Adapters architectural pattern but is now more faithful in its implementation of it. Namely the business logic are no longer named “handlers” but just functions whereas the “handler” term is used exclusively within the charm module as it should be.
