Most organisations do not have a “secrets strategy.” They have an AWS line item that grows every time someone creates another credential — and a platform team that still opens tickets to wire the next service into IAM.

AWS Secrets Manager charges $0.40 per secret, every month, plus API usage (official pricing). There is no volume discount. Forgotten secrets still bill. Cross-region replicas bill again. Copy the same logical secret into dev, staging, and prod and you pay three times.

That is not only a FinOps problem. It is an efficiency problem: two sources of truth (password manager for people, Secrets Manager for apps), cloud-locked access paths, and more glue each time you add a cluster.

We help organisations quantify that cost, redesign how secrets are delivered, migrate safely, and leave teams with an operating model that is cheaper and easier to run.

Batch and ML workloads often need resources that aren't known at Job creation time. The optimal allocation depends on cluster capacity, queue priorities, and hardware availability — all of which can change between submission and execution.

Kubernetes v1.36 promotes a feature to beta that solves this: mutable pod resources for suspended Jobs.

Before this, resource requirements in a Job's pod template were immutable. If a queue controller determined that a suspended Job should run with different resources, the only option was to delete and recreate the Job — losing metadata, status, and history.

Platform engineering is now a critical function in modern software organizations. Gartner predicts that 80% of large engineering organizations will have dedicated platform teams by 2026. But simply having a platform team isn't enough. The real challenge lies in structuring it successfully.

Many engineering teams struggle with balancing autonomy and alignment, often becoming either isolated silos or overloaded bottlenecks that slow down development instead of accelerating it.

This is where team topologies come in. A strategic approach to designing platform teams that ensures they integrate smoothly with engineering workflows and maximize their impact.

The problem of giant PRs that nobody wants to review is universal. You open a pull request with 50 modified files and think: "this is going to take days to review." Reviewers lose context, conflicts pile up, and feedback gets fragmented.

GitHub just launched gh-stack, a native tool to manage Stacked PRs — chained PRs that build on top of each other, independently reviewable but mergeable in cascade.

Keeping dependencies up to date is one of those things that everyone agrees is important… and yet no one enjoys doing.

Between version pinning, breaking changes, and endless npm audit noise, it’s easy for dependency updates to pile up. The result? A pile of technical debt that will keep growing and growing.

Renovate Bot is one of those tools that quietly removes that pain. It just runs in the background, opens clean pull requests when something is outdated, and — if you let it — merges them once your tests pass. You barely have to think about it.

Managing access in AWS can seem simple at first: a few accounts, a handful of users, and permissions that are easy to control from the console. But as an organization grows — as accounts, teams, and roles multiply — that manual management becomes a problem. Errors accumulate, inconsistencies appear, and traceability fades.
Who has access to what? What permissions does each user actually have? What changes were applied last week? These once-trivial questions become increasingly difficult to answer.

That’s where AWS IAM Identity Center (formerly AWS Single Sign-On) comes in. This service centralizes the management of identities and permissions across all your AWS accounts, letting you define from a single place who can access what, and with which level of privilege. It also simplifies auditing and compliance by maintaining a consistent record of assignments and permissions.

However, the existence of IAM Identity Center alone doesn’t solve scalability challenges — manual configuration doesn’t scale. Each user, group, and permission set must be configured account by account, multiplying effort and increasing the likelihood of mistakes. Keeping environments consistent is difficult, and auditing changes becomes a tedious, unreliable process.
In short: manual management isn’t sustainable in the long run.

The solution lies in automating with Terraform, leveraging the Infrastructure as Code (IaC) approach. With Terraform, your entire configuration is defined in version-controlled files — you can review, replicate, and apply changes in a consistent and auditable way. This not only reduces errors but also turns access management into a scalable, controlled, and well-documented process.

Shift-left Philosophy: Why Security Matters​

You might remember the recent supply chain attack that hit NPM packages — maybe your team even felt the impact. It was a good reminder that one vulnerable dependency can ripple across entire systems.

Modern software is a tangled web of dependencies, containers, and distributed codebases. Things move fast, and it’s easy to miss outdated packages or accidentally introduce new risks. All of that adds up to a big security challenge.

If you’ve ever tried to expose both TCP and UDP on the same port using Kubernetes with AWS Load Balancers, you’ve probably run into a common limitation: you can only choose one protocol per port, which complicates applications that need both (such as real-time communications or gaming).

The good news is that AWS has released a feature that allows configuring listeners for both TCP and UDP on the same port, avoiding complex workarounds.

Be Energy Part S.L leads the solar panel installation sector in Europe with their innovative green solutions. The company modernized their technology stack through an Internal Developer Platform developed in collaboration with Resizes Platform. This strategic partnership delivered significant improvements across multiple dimensions:

Monitoring a Kubernetes cluster is essential to know what is going on or to be able to detect if something is wrong in time. There are multiple tools available for this purpose, but in this implementation, we'll use Metrics Server, Alloy, Loki, Kube Prometheus Stack, and Alertmanager.

This setup will be deployed on an EKS cluster, with all configurations managed through Terraform and Helm charts.