 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
It’s time for platform engineering to correct this overcorrection.We asked frontend engineers to become experts in Kubernetes ingress controllers. We asked backend developers to understand complex identity and access management (IAM) role chaining in AWS. We turned their IDEs into cockpits with 50 flashing warning lights. The result isn’t faster delivery; it’s decision fatigue, context-switching paralysis, and burnout. It’s time for platform engineering to correct this overcorrection. The future isn’t about shifting more left onto the human; it’s about “shifting down” into the platform.
package terraform.analysis
import input as tfplan
# Define allowed Cost Centers
allowed_cost_centers = {"engineering", "sales", "product-ops"}
# Rule to deny resources missing required tags
deny[msg] {
resource := tfplan.resource_changes[_]
resource.type == "aws_s3_bucket"
not resource.change.after.tags["CostCenter"]
msg := sprintf("S3 Bucket '%v' is missing required 'CostCenter' tag.", [resource.address])
}
# Rule to validate tag values against allowed list
deny[msg] {
resource := tfplan.resource_changes[_]
tags := resource.change.after.tags
not allowed_cost_centers[tags["CostCenter"]]
msg := sprintf("Resource '%v' has invalid CostCenter tag. Allowed: %v", [resource.address, allowed_cost_centers])
}
The platform handles the “No,” so the developer can focus on the “Yes.”By embedding this Rego directly into the deployment pipeline (a standard cloud governance practice in tools like env zero), we abstracted the compliance requirement away from the developer’s daily concerns. The platform handles the “No,” so the developer can focus on the “Yes.” Imagine the impact of this shift-down practice at scale: Any policy the platform team wants to enforce can be achieved through the deployment pipeline, across dozens if not hundreds of policies scoped to the appropriate provisioning scenarios. 2. Pre-deployment cost gates FinOps is perhaps the area where shifting left failed most spectacularly. Asking an engineer to manually calculate the potential monthly run rate of an auto-scaling EKS cluster before they deploy it is ridiculous. The business needs financial predictability, but the developer needs velocity. Shifting down means the platform intercepts the Infrastructure as Code (IaC) execution plan, runs it against cloud pricing APIs, and generates a cost estimate before provisioning. If a developer opens a PR that accidentally changes an EC2 instance type from `t3.medium` to `x1e.32xlarge`, the platform shouldn’t just log it. It should block the deployment based on a pre-defined budget policy. The technical implementation involves parsing the Terraform plan JSON output, identifying resource changes, and querying pricing databases. The developer experience, however, is simple: their PR gets a comment saying, “This change exceeds our $500/month delta threshold for dev environments. Approval required from @team-leads.” We’ve shifted the financial concern down into the automation layer. As with the OPA example, these principles enacted at scale are the hallmark of a modern, first-rate platform engineering organization. The CEO perspective: The ROI of abstraction Why do I, as a CEO, care about Rego policies or Terraform plan parsing? Because cognitive load is a silent killer of velocity. Every minute a senior engineer spends debugging an IAM policy attachment error is a minute they aren’t building the features that drive our revenue. If your platform team is only building paved roads that are fast but lack guardrails, you’re just helping your developers crash faster. The next phase of platform engineering isn’t about giving developers more tools; it’s about taking requirements off their plate. By shifting governance down into the platform layer, we restore the developer’s ability to focus on what actually matters: shipping great software.
