Why I wrote grelmicro
Python is great for scripts, home labs and small apps that run in one container or on one machine. The trouble starts when the app has to scale. Move it to Kubernetes, or across availability zones for geo-redundancy, and you meet the problems of distributed systems. Two replicas run the same job. A shared limit counts twice. One failing dependency takes everything down. Solving that by hand feels like rewriting the app.
Disclosure: I wrote and maintain grelmicro, an open-source Python library for services that scale horizontally: shared tasks, locks, rate limits, circuit breakers and health checks.
Why Python#
Python is the fastest way I know to build a prototype. It also leads in data analysis, AI tools and machine learning. In network automation, many tools exist only in Python. FastAPI became a popular Python web framework after Flask, which the DevNet course of the Cisco Networking Academy teaches.
The layer Python was missing#
The trigger came during my CAS in Microservices and Operations. In Java, Spring Boot and Resilience4j made these patterns smooth. Back in Python, I was frustrated. FastAPI is not a framework like Spring Boot, or Symfony in PHP. It lacks the enterprise and integration patterns I needed, and I struggled to solve them cleanly, project after project. Chris Richardson calls this layer a microservice chassis. Java has Spring Boot. Go has Go kit. Python had no chassis I could build on, so grelmicro is mine. AI is now a really good programmer. Still, choosing the right pattern and implementing it correctly stays hard.
What grelmicro solves, and what it does not#
grelmicro tackles two of three problems:
- One implementation across all my projects. When I find a bug, I fix it once.
- No more coding each pattern again. I use it from grelmicro.
The third problem stays open: knowing which pattern fits which case. That takes software engineering skill, experience, and business knowledge of the external systems we integrate with. No library can replace it. Good docs and AI help a lot, but a human still has to decide. This is the reason I did the CAS mentioned before.
Moving the cursor#
Today, a Python app works well up to a certain scale. Then teams often rewrite it in Java, Go or Rust. A rewrite is costly, and it only pays off once business needs are stable. They rarely are: requirements keep changing. So we often keep Python, slower and hungrier for CPU and memory, but easier to adapt. With grelmicro, I want to move that limit, so Python can go further into enterprise apps. If the system is well split, as microservices, self-contained systems or a modular monolith, a stable module can still move to Rust, Go or Java later. Be careful with Rust, though: I found fewer ready-made patterns for distributed systems there too.
In Python with grelmicro, the key is Pydantic and explicit, strict typing. ty or mypy checks the types at build time. Pydantic checks them at runtime, at the edges of the code: inputs and outputs. This is the biggest step toward enterprise-grade development.
Agent or hand, the same code#
This works the same whether an agent writes the code or I do. Each need is one documented pattern with a small typed API: @tasks.every, RateLimiter, CircuitBreaker, HealthChecks. The pattern looks the same in FastAPI, Starlette, Litestar and FastStream.
That means less glue code. There is no lock to hand-roll, no shared counter to get wrong, no probe endpoint to write. When I review what an agent wrote, I read a decorator and a provider line, not a hundred lines of coordination code.
The docs also publish llms.txt, a short index of the documentation written for a coding agent to read first.
Try it#
- Follow First steps to wire one pattern and one provider.
- Read the series: From prototype to replicas, then When devices or the network fail.