LinkedIn Post Content — All 13 Carousels
Attach the corresponding PDF carousel to each post.
1. finops-mindset-shift
Attach: linkedin-finops-mindset-shift.pdf
Your cloud bill isn’t too high.
You just don’t own it yet.
There’s a difference between “reduce the bill” and “own the bill” — and most cloud cost initiatives never make that shift. They cut spend, it creeps back, and the cycle repeats.
Ownership looks different: being able to finish the sentence “We spend $47k/month on EC2 because…” at the resource level. Not the account level. The resource level.
Swipe through → to see the mindset shift that changes this permanently.
Full post: nuvikatech.com/blog/posts/finops-mindset-shift
#FinOps #CloudCost #CloudOptimization #EngineeringLeadership #AWS #Azure #GCP
2. fastapi-over-django
Attach: linkedin-fastapi-over-django.pdf
We picked FastAPI over Django for our 84-endpoint backend.
18 months later — here’s the honest verdict.
What we got right: async-native I/O for a backend that fires hundreds of cloud API calls simultaneously. FastAPI’s Depends() system for composable auth and tenant isolation. Clean OpenAPI docs with zero extra effort.
What we completely missed: Django Admin. We spent 4 weeks building an internal admin panel that Django would have given us in a week.
Neither framework is wrong. The decision depends on your workload — and what you’re going to need for the next 18 months.
Swipe through → for the full breakdown.
Full post: nuvikatech.com/blog/posts/fastapi-over-django
#FastAPI #Django #Python #BackendDevelopment #SoftwareEngineering #WebDevelopment
3. cloud-run-vs-kubernetes
Attach: linkedin-cloud-run-vs-kubernetes.pdf
$800/month in idle Kubernetes node charges.
So we switched to Cloud Run. Costs dropped to ~$60/month. Then we hit a problem nobody warned us about.
Our Celery workers were loading AWS, Azure, and GCP SDKs at module level. Cold start time: 70 seconds. Cloud Run’s SIGTERM timeout: 60 seconds.
Workers were being terminated before they could boot. Silently. No error logs.
The fix was one architectural rule that’s now permanent in our codebase. The second-order effect rewrote 40 test files.
Swipe through → for the full story.
Full post: nuvikatech.com/blog/posts/cloud-run-vs-kubernetes
#CloudRun #Kubernetes #GCP #SoftwareEngineering #DevOps #PythonDevelopment
4. nine-commits-claim-filing
Attach: linkedin-nine-commits-claim-filing.pdf
9 commits. 3 cloud providers. Here’s the honest story of shipping our SLA claim filing module.
Including the three bugs we caught before they reached a single customer — and the one that would have silently written wrong data to production.
The critical bug: AWS get_claim_status() returned “resolved”. Our code checked for “approved”. They didn’t match. The else branch ran. Every successfully resolved AWS claim was marked as “Credit Denied.”
No exception. No warning. Just wrong data.
Swipe through → for all 9 commits and the bugs that almost shipped.
Full post: nuvikatech.com/blog/posts/nine-commits-claim-filing
#SoftwareEngineering #CloudComputing #SLA #CodeReview #EngineeringBlog #AWS #Azure #GCP
5. tri-cloud-deployment
Attach: linkedin-tri-cloud-deployment.pdf
We built a platform to help companies control cloud costs.
Then deployed it across all three clouds simultaneously. Yes, we see the irony.
Dev → GCP Cloud Run. QA → Azure Container Apps. Prod → AWS ECS.
Not a mistake. Three separate decisions, each made for a specific reason. And the topology we landed on means every environment continuously scans the other two — so a regression in our AWS scanner is caught by two environments within the hour.
The cost: ~$180/month plus real operational overhead. The business case: clear.
Swipe through → for the full architecture and why we’d make the same call again.
Full post: nuvikatech.com/blog/posts/tri-cloud-deployment
#AWS #Azure #GCP #CloudArchitecture #DevOps #MultiCloud #SoftwareEngineering
6. 433-scan-rules-architecture
Attach: linkedin-433-scan-rules-architecture.pdf
433 cloud scan rules. 6 provider categories. One shared interface.
AWS (193), Azure (149), GCP (59), Kubernetes, on-prem, multi-cloud — all discoverable, testable, and extendable by any engineer.
The architecture that makes this scale: every rule implements the same BaseRule. Rules are pure functions — they receive pre-fetched data, never call cloud APIs. A new rule is a file in the right directory with a unique ID. The registry finds it automatically at startup.
The result: hundreds of rules run in parallel, reproduce against synthetic test data, benchmark independently.
Swipe through → for the full architecture.
Full post: nuvikatech.com/blog/posts/433-scan-rules-architecture
#CloudOptimization #SoftwareArchitecture #FinOps #AWS #Azure #GCP #EngineeringBlog
7. 920-tests-ai-pair-programming
Attach: linkedin-920-tests-ai-pair-programming.pdf
920 tests. 0 failures.
Here’s what AI pair programming actually looks like on a real production feature — not autocomplete on steroids.
The more significant benefit is harder to explain. AI doesn’t feel time pressure. The discipline that humans skip when they’re moving fast — writing the failing test first, confirming it fails for the right reason before implementing — holds every time.
The process: brainstorm → spec → implementation plan → subagent execution → two-stage review. Each stage has a gate. Nothing is implemented until the spec is approved.
The bugs that almost shipped? All caught at review stage 2.
Swipe through → for the full breakdown.
Full post: nuvikatech.com/blog/posts/920-tests-ai-pair-programming
#AIEngineering #SoftwareEngineering #TDD #CodeReview #ClaudeAI #EngineeringBlog
8. error-handling-auto-file
Attach: linkedin-error-handling-auto-file.pdf
What happens when your auto-filing system fails at 2am and a customer’s breach record is mid-resolution?
The naive answer: let the exception propagate, roll back the transaction. This is wrong.
Breach resolution is a deterministic database write. Claim filing is an external API call to AWS, Azure, or GCP. Different reliability profiles. Tying them together means a vendor support tier issue can corrupt your breach record.
The right answer: total error containment. The filing step can fail. The breach resolution cannot.
And when filing fails, “Assisted Filing Required” isn’t a failure state — it’s a defined, actionable outcome with evidence pre-attached.
Swipe through → for the full error handling design.
Full post: nuvikatech.com/blog/posts/error-handling-auto-file
#SoftwareEngineering #SystemDesign #ErrorHandling #BackendDevelopment #SLA #EngineeringBlog
9. sla-breach-lifecycle
Attach: linkedin-sla-breach-lifecycle.pdf
Detecting an SLA breach is the easy part.
Most enterprises lose the money at step 2.
The full lifecycle: Detect → Quantify → File → Poll. Each step has complexity that isn’t obvious until you build it.
Quantification: if a breach starts January 28th and ends February 3rd, the credit splits across two billing periods automatically. GCP’s filing window is 30 days — miss it and the credit is forfeited, no exceptions. Providers don’t send webhooks for approvals, so you poll daily and normalise their vocabulary to a shared schema.
The credits exist. The provider owes them. The process is designed to require effort.
Swipe through → for the full lifecycle.
Full post: nuvikatech.com/blog/posts/sla-breach-lifecycle
#SLA #CloudCost #FinOps #AWS #Azure #GCP #SoftwareEngineering
10. provider-vocabulary-normalisation
Attach: linkedin-provider-vocabulary-normalisation.pdf
AWS says “resolved”. Azure says “closed”. GCP says “SOLUTION_PROVIDED”.
Get the translation wrong and valid credits are silently marked as denied.
We got it wrong. Our poll endpoint checked if credit_status == "approved". AWS returned “resolved”. No match → else branch → “Credit Denied.” On every successfully resolved AWS case. No exception. No warning. Just wrong data in the database.
It was caught in code review — by someone who traced the full flow from API response to database write and asked “what does this actually return?”
The fix: normalise at the provider boundary. The consumer sees only approved / denied / pending / unknown.
Swipe through → for the architecture.
Full post: nuvikatech.com/blog/posts/provider-vocabulary-normalisation
#MultiCloud #SoftwareEngineering #SystemDesign #AWS #Azure #GCP #EngineeringBlog
11. focus-1-2-billing-standard
Attach: linkedin-focus-1-2-billing-standard.pdf
“How much did we spend on compute last month?”
Simple question. Try answering it across AWS, Azure, and GCP at the same time.
AWS calls it lineItem/UsageType. Azure calls it MeterCategory. GCP calls it service.description. Three names for the same concept — and no shared query that answers the question without a provider-specific translation layer.
FOCUS 1.2, maintained by the FinOps Foundation, gives them all the same column name. 37 standardised columns. One table. One query.
What it unlocked: one anomaly detection algorithm for all three. One SQL query for SLA credit calculations. Cross-cloud budgets without knowing provider-specific service names.
The cost: 6 weeks of migration. Worth it.
Swipe through → for the full implementation.
Full post: nuvikatech.com/blog/posts/focus-1-2-billing-standard
#FinOps #FOCUS #CloudBilling #AWS #Azure #GCP #DataEngineering
12. postgresql-row-level-security
Attach: linkedin-postgresql-row-level-security.pdf
One database. 100+ tenants. No data leaks possible.
Not because we’re disciplined. Because the database won’t allow it.
The alternative approaches: separate databases per tenant (airtight, nightmare at scale), or shared tables with application-layer filtering (simple, and dangerous — one missed WHERE clause and you have a compliance incident).
PostgreSQL Row-Level Security is a third option: isolation enforced at the database engine level. Set the tenant once per request. After that, even a query with no WHERE clause returns only that tenant’s rows. A developer who forgets to filter gets back only their data. The bug has no blast radius.
35 tables. Zero possible cross-tenant leaks.
Swipe through → for the full implementation.
Full post: nuvikatech.com/blog/posts/postgresql-row-level-security
#PostgreSQL #SoftwareEngineering #MultiTenancy #SaaS #DatabaseDesign #Security
13. finops-audit-checklist
Attach: linkedin-finops-audit-checklist.pdf
5 questions every cloud team should be able to answer.
Most can’t.
- Which SLA incidents from the past 60 days are eligible for credit claims?
- How would you know if your bill was 15% higher than it should be this month?
- What’s your Reserved Instance / Committed Use coverage — and where are the gaps?
- Which resources are idle — and do you have a process for terminating them?
- Is your cost allocation accurate enough to make decisions with?
Most teams are in the “At-Risk” column on at least two of these. That’s normal. The goal is knowing where you stand.
Swipe through → for the benchmark table and what good looks like for each.
Full post: nuvikatech.com/blog/posts/finops-audit-checklist
#FinOps #CloudCost #CloudOptimization #AWS #Azure #GCP #EngineeringLeadership