Derek Campbell

Kubernetes doesn’t fail loudly at first. It waits. The first time I thought I’d “broken” something, nothing was actually down. Pods were running. Services were up. But behaviour was off. Latency where I didn’t expect it. Resources drifting. Permissions doing more than they should. Nothing dramatic. Just quiet signals. That’s when it clicked. Kubernetes exposes intent. If you’re unclear, the system reflects that back over time. Scheduling choices show up as performance issues. Loose permissions turn into risk. Missing limits become cost and instability. There’s no magic. Just consequences. That’s the mindset I’m carrying into my EKS work. Design first. Assumptions written down. Trade-offs made intentionally. Because in Kubernetes, clarity compounds. And ambiguity always shows up eventually. #DevOps #Kubernetes #EKS #CloudEngineering #PlatformEngineering #CoderCo

75

10 Comments

So what makes a good Solutions Architect? Most job specs list tools. Terraform. Kubernetes. A bit of cloud. Some buzzword soup. The best architects I speak to don’t lead with tools — they lead with clarity, they bring out the best in others. They simplify complexity. They guide delivery without ego. They know where to challenge and where to compromise. Good architecture still comes down to judgment. That’s who I headhunt. And work with :)

9

1 Comment

Something I’ve noticed speaking with DevOps engineers Early in their careers there’s a lot of focus on tools Docker Kubernetes Terraform CI/CD But when companies hire more experienced DevOps or Platform Engineers, they’re usually looking for something else Engineers who’ve actually dealt with production issues The sort of people who can: • work through incidents calmly • understand why systems break • improve deployments and reliability over time • think about the whole platform rather than just individual tools The tools matter, but the ability to think in systems tends to be what separates strong DevOps engineers from average ones ⚙️ Tools matter, but ownership and problem-solving usually matter more

75

33 Comments

🚨 I see brilliant contractors fail interviews every week. Not because they’re not good enough …but because they forget to show what they know. 💡 These are seriously talented people who can spin up an environment, debug a mess of legacy code, and deliver clean, scalable solutions. But when it comes to interviews? They undersell themselves. Here’s the problem 👇 Clients don’t see your skill they only hear what you can explain. If you can’t walk them through your thinking, they can’t picture you doing the job. That’s why I always tell my contractors to use the P.E.E. method: 👉 Point  Evidence  Explain When asked a question: Point: Make your main point clearly. Evidence: Back it up with a real example from a project. Explain: Tie it back to how it fits their role or tech environment. 🧠 Example: “I’d approach that with a microservices pattern. In my last project, we split a monolith into 6 services using Node and Docker that reduced deploy times by 40%, which sounds similar to what you’re describing.” That’s not just answering that’s selling your value. ✨ Bonus prep tips for contractors: Ask your recruiter if they have insight from others who’ve interviewed it’s often gold. Check if there’s a tech test and prep accordingly. Review the tech stack brush up on fundamentals and common interview questions. Practice talking through your examples out loud great devs often think clearly but explain vaguely 🎯 Bottom line: Intelligence isn’t enough in an interview communication is what sells it. You already know your stuff. Your goal is to make sure the client knows it too.

14

New to Terraform? Start here. Terraform helps teams provision infrastructure more efficiently, whether in the cloud, on-prem, or across SaaS environments. Swipe to see: ✔️ How Terraform supports collaboration ✔️ How policies are built into workflows ✔️ How teams can move faster with self-service

161

I'm seeing loads of updates regarding the AWS outage and some suggesting having redundancy in another Cloud provider... I’m all for resilience, but let’s get real — how many smaller companies actually have the budget to run full infrastructure in another cloud provider sitting idle or nearly idle, just in case? 💸 Here’s the reality I see: You pick a cloud provider and build your stack around it — you’re effectively married to that provider. Trying to be cloud-agnostic? Great in theory, but it takes a lot of time, money, and effort to maintain parity between providers. Sooner or later you’ll likely pick one main provider anyway, or suffer from duplicate work and fragmented systems.

51

2 Comments

Not all SaaS secrets management platforms are built the same. This side-by-side comparison breaks down how on-prem vaults, traditional SaaS secrets platforms, and Akeyless zero-knowledge SaaS differ across architecture, key ownership, environment scope, cost, and compliance, so teams can understand where each model fits. Read the full article: https://hubs.li/Q03Z8JFY0 #secretsmanagement #cloudsecurity #identitysecurity

12

IAM is not login. It is control. I have seen many SSO implementations that worked perfectly in demos and UAT, yet were fundamentally wrong in real life. This is mostly a problem when setting up new client ecosystems. Mature environments usually have IAM discipline. New ones rarely do. Keycloak often gets blamed. That is convenient. The issue is not the tool, It is the thinking and miss architecture. Teams stop at authentication. Once users can log in, the work is declared complete. Authorization is rushed. Roles are loosely defined. Access accumulates quietly and never gets revisited. SSO then becomes a risk amplifier. One identity. Too much access. Everywhere. The core mistake is confusing identity with entitlement. Job titles become roles. Roles become permanent. Tokens are trusted blindly. Applications stop enforcing controls because they assume IAM handled it. That is not IAM. That is convenience mistaken for security. SSO is only the entry point. Real IAM begins after login. If an IAM design does not feel uncomfortable during review, it is probably too permissive.

41

2 Comments