“We haven’t touched our AWS infrastructure in three months out of fear of breaking something.” Sound familiar? The solution isn’t to change tools—it’s to change your methodology.

The lie we’ve believed

We all start the same: “Let’s do Infrastructure as Code—it’ll be amazing.” And indeed, the first few days are magical. You create your first VPC, security groups, a few instances… Everything works. You feel like a wizard.

Then reality hits.

Six months later, you have gigantic state files, tightly coupled modules, and every change feels like a game of Russian roulette. Does this sound familiar?

1. terraform plan → 20 minutes of waiting
2. A 400-line plan that no one understands
3. “Are you sure you want to apply this?”
4. Three hours debugging because something failed on line 247

But there’s one factor most teams overlook…

What actually works (and why no one tells you)

After rescuing dozens of Terraform projects, the formula is simpler than you think:

Small states + smart modules + GitOps that doesn’t scare you.

Layered states (not per project)

Forget “one state to rule them all.” Break it down like this:

terraform/
├── network/     # VPC, subnets, NAT gateways
├── data/        # RDS, ElastiCache  
├── compute/     # EKS, ECS, ASGs
└── apps/        # ALBs, Route53

Each layer evolves independently. The data team can update RDS without touching the network. This could be your game changer.

The remote state trick

The magic is in connecting layers without coupling them:

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "company-terraform-states"
    key    = "network/terraform.tfstate"
  }
}

# Use outputs from another layer
subnet_id = data.terraform_remote_state.network.outputs.private_subnet_id

Modules that don’t give you a headache

Create specific modules for each type of workload:

• secure-webapp/ – ALB + WAF + instances
• microservice/ – EKS service + ingress + monitoring
• data-pipeline/ – Lambda + SQS + RDS with backups

No more “universal” modules requiring 47 parameters.

Multi-cloud is already here

Now it gets interesting. Many teams are adopting hybrid strategies: AWS for critical applications, OpenStack for development and testing.

Why? Cost and control.

# Same module, different cloud
module "webapp" {
  source = "./modules/webapp"
  
  # On OpenStack for dev
  provider = openstack.dev
  instance_type = "m1.medium"
  
  # On AWS for prod  
  # provider = aws.prod
  # instance_type = "t3.medium"
}

The future isn’t “AWS or nothing.” It’s architectural flexibility. The power to choose the solution you want, when you want, adapted to your budget.

OpenTofu changes the game

With the recent changes in Terraform, OpenTofu is becoming the smart choice. Same syntax, open-source governance, zero vendor lock-in.

The advantage is huge: you can migrate gradually without changing a single line of code. Perfect for teams that want control without drama.

The question you should ask yourself

Did your last terraform apply take years off your life?

If yes, the problem isn’t technical—it’s methodological.

Do you recognize these symptoms in your team? The difference between success and chaos lies in applying the right techniques from the start.

If you want to dive deeper into these methodologies, our Terraform/OpenTofu courses cover everything from fundamentals to advanced GitOps with real multi-cloud use cases.

Ceph is a powerful and flexible solution for distributed storage, but like any complex tool, it is not exempt from errors that are difficult to diagnose. If you get the message “could not connect to ceph cluster despite configured monitors”, you know that something is wrong with your cluster. And no, it’s not that the monitors are asleep. This error is more common than it seems, especially after network changes, reboots or when someone has touched the configuration “just a little bit”.

In this article we get to the point: we tell you the real causes behind this problem and most importantly, how to fix it without losing your data or your sanity in the process.

What does the error “could not connect to ceph cluster despite configured monitors” really mean?

When Ceph tells you that it cannot connect to the cluster “despite configured monitors”, what is really happening is that the client or daemon can see the configuration of the monitors, but cannot establish communication with any of them. It’s like being ghosting, no matter how much you call, they don’t pick it up.

Ceph monitors are the brains of the cluster: they maintain the topology map, manage authentication, and coordinate global state. Without connection to the monitors, your Ceph cluster is basically a bunch of expensive disks with no functionality.

The 5 most common causes (and their solutions)

Network and connectivity problems

The number one cause is usually the network. Either because of misconfigured firewalls, IP changes or routing problems.

Rapid diagnosis:

# Verifica conectividad básica
telnet [IP_MONITOR] 6789
# o con netcat
nc -zv [IP_MONITOR] 6789

# Comprueba las rutas
ip route show

Solution:

• Make sure that ports 6789 (monitor) and 3300 (msgr2) are open.
• Verify that there are no iptables rules blocking communication.
• If you use firewalld, open the corresponding services:

firewall-cmd --permanent --add-service=ceph-mon
firewall-cmd --reload

2. Monmap out of date after IP change

If you have changed node IPs or modified the network configuration, it is likely that the monmap (monitor map) is obsolete.

Diagnosis:

# Revisa el monmap actual
ceph mon dump

# Compara con la configuración
cat /etc/ceph/ceph.conf | grep mon_host

Solution:

# Extrae un monmap actualizado de un monitor funcionando
ceph mon getmap -o monmap_actual

# Inyecta el monmap corregido en el monitor problemático
ceph-mon -i [MON_ID] --inject-monmap monmap_actual

3. Time synchronization problems

Ceph monitors are very strict with time synchronization. An offset of more than 50ms can cause this error.

Diagnosis:

# Verifica el estado de NTP/chrony
chrony sources -v
# o con ntpq
ntpq -p

# Comprueba el skew entre nodos
ceph status

Solution:

# Configura chrony correctamente
systemctl enable chronyd
systemctl restart chronyd

# Si tienes servidores NTP locales, úsalos
echo "server tu.servidor.ntp.local iburst" >> /etc/chrony.conf

4. Critical or corrupted monitors

If the monitors have suffered data corruption or are in an inconsistent state, they may not respond correctly.

Diagnosis:

# Revisa los logs del monitor
journalctl -u ceph-mon@[MON_ID] -f

# Verifica el estado del almacén del monitor
du -sh /var/lib/ceph/mon/ceph-[MON_ID]/

Solution:

# Para un monitor específico, reconstruye desde los OSDs
systemctl stop ceph-mon@[MON_ID]
rm -rf /var/lib/ceph/mon/ceph-[MON_ID]/*
ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --journal-path /var/lib/ceph/osd/ceph-0/journal --type bluestore --op update-mon-db --mon-store-path /tmp/mon-store
ceph-mon --mkfs -i [MON_ID] --monmap /tmp/monmap --keyring /tmp/ceph.mon.keyring

5. Incorrect client configuration

Sometimes the problem is on the client side: outdated configuration, incorrect keys or poorly defined parameters.

Diagnosis:

# Verifica la configuración del cliente
ceph config show client

# Comprueba las claves de autenticación
ceph auth list | grep client

Solution:

# Regenera las claves de cliente si es necesario
ceph auth del client.admin
ceph auth get-or-create client.admin mon 'allow *' osd 'allow *' mds 'allow *' mgr 'allow *'

# Actualiza la configuración
ceph config dump > /etc/ceph/ceph.conf

When to ask for help (before it’s too late)

This error can escalate quickly if not handled correctly. If you find yourself in any of these situations, it’s time to stop and seek professional help:

• All monitors are down simultaneously
• You have lost quorum and cannot regain it.
• Data appears corrupted or inaccessible
• The cluster is in production and you can’t afford to experiment.

Ceph clusters in production are not trial and error territory. One false move can turn a connectivity problem into a data loss.

The best solution to the error “could not connect to ceph cluster despite configured monitors” : prevent

To avoid encountering this error in the future:

Proactive monitoring:

• Configure alerts for monitor status
• Monitors network latency between nodes
• Monitors time synchronization

Best practices:

• Always deploy at least 3 monitors (better 5 in production).
• Keep regular backups of the monmap and keys.
• Document any network configuration changes
• Uses automations (Ansiblefor example, is perfect for configuration changes).

Regular testing:

• Periodically tests connectivity between nodes
• Simulates monitor failures in development environment
• Verify that your recovery procedures are working

Need help with your Ceph cluster?

Distributed storage clusters such as Ceph require specific expertise to function optimally. If you have encountered this error and the above solutions do not solve your problem, or if you simply want to ensure that your Ceph infrastructure is properly configured and optimized, we can help.

Our team has experience solving complex Ceph problems in production environments, from urgent troubleshooting to performance optimization and high availability planning.

We offer help with

• Ceph technical support and consulting
• Introductory initiation y advanced courses at Ceph
• Urgent system support

Don’t let a connectivity problem become a major headache. The right expertise can save you time, money and, above all, stress.

Artificial intelligence no longer just responds, it also makes decisions. With frameworks like LangGraph and platforms like watsonx.ai , you can build agents that reason and act autonomously 🤯.

In this article, we will explain how to implement a ReAct (Reasoning + Action) agent locally and deploy it on IBM Cloud, all this with a practical example that includes a weather query tool 🌤️.

A practical guide to using your agents with LangGraph and Watsonx.ai

Project architecture

• Machine with local project
  • Here you develop and test the agent with Python, LangGraph and dependencies.
• ZIP (pip-zip)
  • Package with your code and additional tools.
• Software Specification
  • Environment with libraries necessary to execute the agent.
• watsonx.ai
  • Platform where you deploy the service as a REST API.
• IBM Cloud Object Storage
  • Stores deployment assets.

Let’s prepare the environment for our agent

We need:

• Python 3.12 installed
• Access to IBM Cloud and watsonx.ai
• Poetry for dependency management

Have you got everything? Well, first things first, clone the repository that we will use as an example. It is based on the official IBM examples.

git clone https://github.com/thomassuedbroecker/watsonx-agent-langgraph-deployment-example.git 
cd ./agents/langgraph-arxiv-research

First of all, let’s understand the example project.

The main files of the agent are:

Let’s configure the environment

We also recommend the use of Anaconda or miniconda. It allows us to manage virtual environments or Python packages in a simple way and is widely used in ML.

In order for Python to find our custom modules (such as agents and tools), we need to include the current directory in the environment variable PYTHONPATH

export PYTHONPATH=$(pwd):${PYTHONPATH}

Once we have the environment ready, it is time for the variables. You must create a config.toml file if you don’t already have one and use your IBM Cloud credentials:

You will find your variables here:

https://dataplatform.cloud.ibm.com/developer-access

Once there, select your deployment space and copy the necessary data (API Key, Space ID, etc.).

Execution at the agent’s premises

It is time to test the agent:

Since it’s a weather agent why don’t you try it with something like something like…?

“What is the current weather in Madrid?”

The console should give you the time in Madrid. Congratulations! we only need to do the deploy in watsonx.ai

Agent deployment in watsonx.ai

source ./.venv/bin/activate
poetry run python examples/query_existing_deployment.py

Conclusions

If you have any doubts, we recommend the following video tutorial where you can follow step by step the development connected with watsonx.ai

If you want to continue exploring these types of implementations or learn more about cloud development and artificial intelligence, we invite you to explore our AI courses.👇

• At IBM
• In Canonical / Ubuntu

When it comes to IBM Power servers, many decisions seem like a battle between two worlds: the almost legendary robustness of IBM i 7.6 and the freedom of Ubuntu Linux. But what if the best choice is not one or the other, but both? In this article we cut to the chase: we tell you what no one else can explain clearly, without selling you smoke and mirrors, without marrying ourselves to a single approach. Just the technical truth, well told.

IBM i: a closed (but very efficient) fortress

If you’ve worked with IBM i, you know what we’re talking about: stability, performance and a database that won’t crash even if you throw a nasty core dump on it.

IBM i is not just an operating system, but an integrated platform: OS, database (Db2 for i), security, backups, virtualization and native HA (PowerHA, Db2 Mirror) in a single environment optimized for Power10. The integration of these layers avoids intermediate layers or dependencies between external tools.

Technical matters: IBM i runs on a microkernel that manages persistent objects on disk with a native object-oriented, non-file-based model. Its journaling system guarantees consistency even in the face of power outages, and allows remote journaling for DR replication without the need for snapshots.

IBM i 7.6 improves native SQL performance, strengthens security (with integrated multi-factor authentication and more object-level encryption), and enables more modern APIs (REST, OpenAPI, JSON), which allow traditional business logic (RPG, COBOL) to be exposed as microservices. At SIXE we already have an analysis of all the new features of IBM i. If you want to take a look , click here.

Ubuntu in Power: freedom, but with responsibilities

On the other hand, if you are from the Linux team, you already know what Ubuntu brings: DevOps ecosystem, containers, microservices and official Canonical support for Power for years, with optimized images for the ppc64le architecture.

Ubuntu is not plug-and-play like IBM i, but it doesn’t pretend to be either. You can deploy PostgreSQL, MongoDB, Redis, Apache Kafka, Ceph… you name it. And if you mount KVM (already integrated into PowerVM), you can use LXD, OpenStack or orchestrators like MAAS or Juju to manage the environment at scale.

But yes: there is no magic. You’ll have to build the stack yourself: HA with Pacemaker, backups, security with SELinux… And that implies having good Ansible playbooks or well-defined CI/CD pipelines. Nothing is done by yourself.

In HPC and AI, Ubuntu on Power is taking off strong: Power10 (and soon Power11) has brutal bandwidth, and with the upcoming IBM Spyre accelerator on the horizon, you can train models without relying on NVIDIA GPUs.

What about security?

This is where IBM i shines by design: the entire system is security-oriented. Each object has its own authority, with highly granular user profiles and an audit journal that logs everything that happens, without having to install and configure syslog-ng or ELK stack.

Ubuntu, on the other hand, has everything you need: ufw, auditd, encryption with LUKS, application-level protection with AppArmor or SELinux… but you have to integrate it manually and maintain it. A poorly patched Ubuntu environment is an easy target.

On IBM i, security patches are few and far between and controlled; on Ubuntu there are almost daily updates. That’s not a bad thing, but it requires well automated patch management processes.

Costs: beware of what looks cheap

Many people see Ubuntu and say “free!”. But not all that glitters is gold. On Power servers, the hardware is the same, and the operating cost can skyrocket if you don’t automate well or if you need to replicate services that IBM i comes ready to use.

IBM i has a more expensive license, yes. But you can do more with less staff. If your load is critical, stable and doesn’t vary every week, in the medium term TCO can play in your favor.

Modernization: Do I stay with RPG or switch to microservices?

If you have code in RPG, IBM i 7.6 lets you continue to use it… and even modernize it with REST APIs, Node.js or Python (via PASE). VS Code is also getting into the game and is gaining more traction so you can modernize and write code more easily.

Does your team prefer to work in containers, use CI/CD and deploy? Ubuntu. Nothing more to say.

Conclusion: one, the other… or both?

Sometimes it’s not a matter of choosing black or white. In many Power environments, what really works is combining the best of each world. Here are some recommendations:

What if I don’t want to choose?

Good question. In fact, many companies don’t. They use IBM i for critical and stable loads (billing, ERP, etc.), and Ubuntu for everything new: APIs, frontends, microservices, AI.

This hybrid approach gives you the best of both worlds: the reliability of IBM i, with the agility and ecosystem of Ubuntu.

What’s next?

If you are in doubt, in the middle of planning or directly with the licensing Excel open… in SIXE we help you to analyze your environment and design the most realistic way: either maintain, migrate or combine. Fill out the form here and we will contact you.

No smoke. No impossible promises. Only solutions that work (really) and face to face with our engineers.