Hello everyone, I am Amit Roy, and my talk is about how the implementation of a framework has significantly enhanced developer productivity in the TechOps organization of DELL Technologies while also reducing support costs. Moreover, I will touch upon the utilization of low code/no code approaches for microservice development. You can find my talk here. Please feel free to provide feedback and ask any questions in this channel/🧵. I want to extend my gratitude to the PlatformCon team for organizing this event and for their excellent work. Thank you.

Hey @Amit Roy thank you for your talk with Robert , i wanted to ask how does the framework handle complex configuration management in a multi-tenant system where some configurations are supplied by the platform and others are supplied by the business units? Can you provide more details on how it consolidates and presents these configurations to developers? 🤔

Hi @Lydia Dranetti - Configuration management warrants its own discussion. We were supposed to present it in DevOps World, Orlando, 2022, which was cancelled due to bad weather at the last minute. I will post the slides to you. In short, 1. the configurations can be classified as global (i.e., all microservices deployed for all tenants will have the same value), tenant specific (i.e., shared by all microservices deployed for a tenant), microservice specific (i.e., the same microservice deployed for all tenants will have the same configuration value) and local override (i.e., a tenant wants to override a particular value). 2. Each type can be a separate configmap in K8s. 3. During start of the microservice, the framework consolidates the configurations from the different configmaps and produces a single dictionary for the microservice to use. This helps the developer and simplifies the business logic because now the developer does not need to remember, which configmap is the source of a particular configuration. 4. However, the consolidation requires dealing with conflict. For example, a tenant wants to over-write a global configuration value. Who over-writes whom? This is resolved via naming convention in the configmap. For example, 1.foo.yml can over-write 0.foo.yml. 5. There are some additional merge rules to place a configuration parameter under the right hierarchy. Hopefully the above answers some of your questions.