Slow Down!!! So, you can go FAST!
Guardrails have the ability to allow you to execute at much faster speeds
I recently recorded a podcast episode with Ned Bellavance (@Ned1313), where we talked about the impact of developer-driven application platforms. Our example use case is the Portworx storage virtualization platform (see the Tech Field Day presentation). On the service, the solution is pretty slick. It allows Kubernetes-based applications to leverage persistent storage volumes across multiple clusters. Potential use cases include disaster recovery and high availability.
The tool enables site-to-site replication independent of the underlying storage platform. For example, if you have rights to a K8s cluster such as OpenShift, you have the ability to deploy the solution.
What could go wrong? Developers can now create highly redundant applications without waiting for the storage team to provision replication. Second, Portworx is native to K8s; there’s no stitching together constructs from legacy storage replication technologies to cloud-native architectures.
I always ask the question, what happens when something breaks? Developers shouldn’t develop applications in a vacuum. In an ideal world, the team developing the solution would reach out to the storage architecture team. The teams would collaborate and bring Portworx on as one of the internally supported replication technologies. In practice, the ops team can add visibility to the replication stream so that when something breaks, the application team will be the first to know.
It does add a layer of complexity to application development. However, the cost is worth it. It is much harder and time-intensive to fix a broken app without visibility vs. an application with the necessary support infrastructure.
What are your thoughts? Am I too much of a legacy IT hugger, or is there value in standards? How would you implement the cross-team collaboration needed to achieve the desired outcome?