Today we continue discussing the best practice from storage engineering :
670) There is no special requirement for performance or security from the containerization framework than what the application wants from the host because this is internal and not visible to the user.
671) Operators like update involve scaling down the nodes, then performing the update and then scaling back up. There is no restriction to reuse logic between operators.
672) Operators generally work one at a time on the same cluster. This prevents states from being mixed and allowing each reconcile between state and deploy to happen sequentially.
673) Operators do not have retain any information between invocations. Anything that needs to be persisted has to be part of state.
674) There is no limit to the number of operators run during deploy. It is preferred to run them sequentially one after the other. The more granular the operators the better they are for maintenance.
675) The diagnosability of operators improves with each operator being small and transparent.
676) The upgrade operator can be rolling upgrades. Then the operator does not require scale up or down.
677) The operators can invoke methods defined in other operators as long as they are accessible.
678) Frequently storage applications are written with dependencies on other applications. Those applications may also support operators. Operators can be chained one way or the other.
679) Requirements on operator logic change whether the product is an analysis package or a storage product.
680) There is a lot in common between installer packages on any other desktop platform and the containerization deployment operators.
670) There is no special requirement for performance or security from the containerization framework than what the application wants from the host because this is internal and not visible to the user.
671) Operators like update involve scaling down the nodes, then performing the update and then scaling back up. There is no restriction to reuse logic between operators.
672) Operators generally work one at a time on the same cluster. This prevents states from being mixed and allowing each reconcile between state and deploy to happen sequentially.
673) Operators do not have retain any information between invocations. Anything that needs to be persisted has to be part of state.
674) There is no limit to the number of operators run during deploy. It is preferred to run them sequentially one after the other. The more granular the operators the better they are for maintenance.
675) The diagnosability of operators improves with each operator being small and transparent.
676) The upgrade operator can be rolling upgrades. Then the operator does not require scale up or down.
677) The operators can invoke methods defined in other operators as long as they are accessible.
678) Frequently storage applications are written with dependencies on other applications. Those applications may also support operators. Operators can be chained one way or the other.
679) Requirements on operator logic change whether the product is an analysis package or a storage product.
680) There is a lot in common between installer packages on any other desktop platform and the containerization deployment operators.
No comments:
Post a Comment