What we’re working on
This August, our team has been working on a feature that empowers users to perform self-service maintenance on cluster nodes., the UX and operational technology behind a new technical feature that will enable our customers to trigger node maintenance upgrades on their terms before a scheduled maintenance deadline.
This project was inspired by reflections on the experiences of our Operations team and our customers in our recent campaign to upgrade the Linux operating system of our collective infrastructure to maintain our high security standards. We came to realize that while we schedule upgrades and consider customer feedback on their individual rules and conditions on operations load, downtimes, etc, the varying needs of our customers and the healthcare industry they service require more granularity and control on their terms. Many teams also wanted to test the maintenance update on a staging or development cluster before doing it in production.
We will be introducing the ability for customers to be notified of maintenance of their clusters or individual nodes automatically, right from the MedStack Control dashboard interface. This feature will run very similarly to the way consumers might initiate operating system upgrades of their mobile phones, for example. In future iterations, we’re exploring ways for users to schedule maintenance instead of just the on-demand option.
Most excitingly, we’ve built the UX of this new feature with close feedback from some of our most active customers with very sensitive deployments in important healthcare environments. None of our high security or compliance standards and commitments will be impacted by this new capability.
MedStack Control Feature Highlight
Our August MedStack Control feature highlight is our users ability to stop their services without deleting their configuration. Occasionally, users create a service, but don’t want long lasting containers to be running. An example of this would be when a service is created experimentally. For service configurations, especially more complex cases, it would be ideal to keep the service configuration so it does not need to be rewritten in the cluster. This can be done by simply stopping the service, rather than deleting it. This can be done by changing the replica value to 0.
This will stop all service containers, while allowing users to retain the service configuration. When they are ready, starting services requires changing the replica value to 1 or greater. This allows our users the flexibility and freedom to start and stop their services without having to redo the service configuration each time.
What do you want to see in our next product blog?
We want to hear from you! Going forward, MedStack will be releasing a monthly blog highlighting a different feature of MedStack Control, as well as providing updates about what our product and engineering teams have been working on.
