<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Operations on Build in Public</title><link>https://build.ralphmayr.com/tags/operations/</link><description>Recent content in Operations on Build in Public</description><generator>Hugo</generator><language>en-us</language><copyright>©️ Ralph Mayr 2026</copyright><lastBuildDate>Fri, 26 Sep 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://build.ralphmayr.com/tags/operations/index.xml" rel="self" type="application/rss+xml"/><item><title>The memory consumption patterns of LangChain are… disturbing</title><link>https://build.ralphmayr.com/posts/88-the-memory-consumption-patterns-of-langchain-are-disturbing/</link><pubDate>Fri, 26 Sep 2025 00:00:00 +0000</pubDate><guid>https://build.ralphmayr.com/posts/88-the-memory-consumption-patterns-of-langchain-are-disturbing/</guid><description>&lt;p&gt;As I said in
&lt;a href="../21-no-you-dont-have-to-learn-langchain/"&gt;No, you don&amp;rsquo;t have to learn LangChain&lt;/a&gt;, we shouldn&amp;rsquo;t get distracted by the artificial complexity introduced by our frameworks. LangChain is mostly a wrapper around the REST APIs of various LLM providers. Useful? Yes&amp;mdash;switching between models becomes easy.&lt;/p&gt;
&lt;p&gt;But here&amp;rsquo;s a mystery I can&amp;rsquo;t explain.&lt;/p&gt;
&lt;p&gt;When I added Gemini as a fallback to DeepSeek (see yesterday&amp;rsquo;s post about DeepSeek refusing to touch Chinese politics), I thought it would be straightforward:&lt;/p&gt;</description></item><item><title>There is no cloud (it’s just somebody else’s computer)</title><link>https://build.ralphmayr.com/posts/80-there-is-no-cloud-its-just-somebody-elses-computer/</link><pubDate>Thu, 18 Sep 2025 00:00:00 +0000</pubDate><guid>https://build.ralphmayr.com/posts/80-there-is-no-cloud-its-just-somebody-elses-computer/</guid><description>&lt;p&gt;&amp;hellip;and ultimately, that &amp;ldquo;someone&amp;rdquo; is going to send you a real invoice for actual money. In my case, I&amp;rsquo;m running poketto.me almost entirely on Google Cloud. While it&amp;rsquo;s not terribly expensive right now, it is a cost I had to factor into my pricing strategy.&lt;/p&gt;
&lt;p&gt;But here&amp;rsquo;s the good news: Google offers various programs to support early-stage startups! Check out
&lt;a href="https://cloud.google.com/startup?hl=en" target="_blank" rel="noopener noreferrer"&gt;https://cloud.google.com/startup?hl=en&lt;/a&gt; for details.&lt;/p&gt;
&lt;p&gt;Today, I&amp;rsquo;m happy to share that poketto.me made it into the &amp;ldquo;START&amp;rdquo; tier of that program, which means: no Google Cloud bills in my mailbox for the foreseeable future!&lt;/p&gt;</description></item><item><title>Multi-threaded TTS: A bad idea</title><link>https://build.ralphmayr.com/posts/57-multi-threaded-tts-a-bad-idea/</link><pubDate>Tue, 26 Aug 2025 00:00:00 +0000</pubDate><guid>https://build.ralphmayr.com/posts/57-multi-threaded-tts-a-bad-idea/</guid><description>&lt;p&gt;Running text-to-speech in the cloud is fun&amp;mdash;until it isn&amp;rsquo;t.&lt;/p&gt;
&lt;p&gt;Early on, I didn&amp;rsquo;t think much about thread safety. During my own testing, rarely would more than one TTS task be running in parallel, so there were no big issues. But once more users started using the feature, strange bugs popped up:&lt;/p&gt;
&lt;p&gt;Errors like &amp;ldquo;Assertion srcIndex &amp;lt; srcSelectDimSize failed&amp;rdquo; started showing up in the logs&amp;mdash;and worse, once triggered, the entire Cloud Run instance would become unusable until a redeploy.&lt;/p&gt;</description></item><item><title>GCS Caching Can Be a Pain in the Neck</title><link>https://build.ralphmayr.com/posts/46-gcs-caching-can-be-a-pain-in-the-neck/</link><pubDate>Fri, 15 Aug 2025 00:00:00 +0000</pubDate><guid>https://build.ralphmayr.com/posts/46-gcs-caching-can-be-a-pain-in-the-neck/</guid><description>&lt;p&gt;I love GCS (Google Cloud Storage). It&amp;rsquo;s a simple, robust, and powerful solution for storing files online and accessing them either programmatically or via HTTP. Storage is dirt cheap&amp;mdash;especially if you don&amp;rsquo;t need global replication or sophisticated backups. And you can even turn a GCS bucket into an HTTPS-secured, internet-facing web server for static websites.
&lt;a href="https://poketto.me" target="_blank" rel="noopener noreferrer"&gt;https://poketto.me&lt;/a&gt;, for example, runs on that architecture.&lt;/p&gt;
&lt;p&gt;Another good use case: the #podcast feature in poketto.me. Naturally, the generated MP3 files need to live somewhere, and storing them in a database or serving them through my Python web server would be&amp;hellip; silly. So I push the generated files to a GCS bucket, and all is well: HTTPS-secured, fast, and compatible with any podcast client in the world.&lt;/p&gt;</description></item><item><title>‘Cloud Idenity’ is a secret well kept by Google</title><link>https://build.ralphmayr.com/posts/34-cloud-idenity-is-a-secret-well-kept-by-google/</link><pubDate>Sun, 03 Aug 2025 00:00:00 +0000</pubDate><guid>https://build.ralphmayr.com/posts/34-cloud-idenity-is-a-secret-well-kept-by-google/</guid><description>&lt;p&gt;Permissions on Google Cloud resources are assigned to principals. Principals, in principle 😏, are Google accounts. My personal @gmail.com address, for example, is the principal that &amp;quot;owns&amp;quot; most of my Google Cloud stuff. So far, so good.&lt;/p&gt;
&lt;p&gt;However, in some cases, I was required to delegate ownership of a resource to a principal with an @poketto.me email address &amp;mdash; a domain for which I don&amp;rsquo;t have a Google Workspace account. Consequently, these addresses aren&amp;rsquo;t recognized as regular Google Accounts. (See exhibit A)&lt;/p&gt;</description></item><item><title>Good things come to those who wait ⏳</title><link>https://build.ralphmayr.com/posts/29-good-things-come-to-those-who-wait/</link><pubDate>Tue, 29 Jul 2025 00:00:00 +0000</pubDate><guid>https://build.ralphmayr.com/posts/29-good-things-come-to-those-who-wait/</guid><description>&lt;p&gt;Remember when I was complaining about
&lt;a href="../8-running-text-to-speech-in-the-cloud-is-harder-than-you-would-think-part-one/"&gt;how hard it is&lt;/a&gt; to run even basic ML workloads on GCP? Turns out, Google has listened 😊 (well, probably not to me personally, but in general).&lt;/p&gt;
&lt;p&gt;You can now request GPUs for Cloud Run instances in the UI as well as on the command line. That means all the hassle I went through deploying my text-to-speech service into a Docker environment running inside a preemptible VM with GPUs&amp;mdash;and then figuring out how to start, stop, and deploy the VM automatically&amp;mdash;was&amp;hellip; well, not exactly wasted, but at least: not necessary anymore.&lt;/p&gt;</description></item><item><title>Cloud Build beats GitLab CI for my use case.</title><link>https://build.ralphmayr.com/posts/15-cloud-build-beats-gitlab-ci-for-my-use-case/</link><pubDate>Tue, 15 Jul 2025 00:00:00 +0000</pubDate><guid>https://build.ralphmayr.com/posts/15-cloud-build-beats-gitlab-ci-for-my-use-case/</guid><description>&lt;p&gt;When I set up my personal blog,
&lt;a href="https://ralphmayr.com" target="_blank" rel="noopener noreferrer"&gt;ralphpmayr.com&lt;/a&gt;, years ago, I opted for a GitLab CI pipeline to build and deploy it. However, for poketto.me, I was looking for something faster, cheaper and more closely integrated with the Google Cloud ecosystem.&lt;/p&gt;
&lt;p&gt;I opted for Google's own CloudBuild and discovered that it integrates seamlessly with GitLab.com. In GitLab, all you need to do is create two API keys (one for read access and one for edit access), configure these in Google Cloud and CloudBuild will then be able to fetch and build any GitLab project.&lt;/p&gt;</description></item><item><title>Running text-to-speech in the #Cloud is harder than you would think (part three)</title><link>https://build.ralphmayr.com/posts/10-running-text-to-speech-in-the-cloud-is-harder-than-you-would-think-part-three/</link><pubDate>Thu, 10 Jul 2025 00:00:00 +0000</pubDate><guid>https://build.ralphmayr.com/posts/10-running-text-to-speech-in-the-cloud-is-harder-than-you-would-think-part-three/</guid><description>&lt;p&gt;So, after finally setting up a dedicated virtual machine (VM) to run my text-to-speech workloads and wiring up all the build and deployment scripts, I got a bit excited. Could I reduce the TTS latency even further if the VM had GPU power?&lt;/p&gt;
&lt;p&gt;In theory: Yes. In practice: Google doesn't give you access to their GPUs straight away. There&amp;rsquo;s a special quota setting for VM instances with GPUs, and by default that&amp;rsquo;s set to zero. As a regular user, you cannot increase this without contacting Google Cloud Support.&lt;/p&gt;</description></item><item><title>Running text-to-speech in the #Cloud is harder than you would think (part two)</title><link>https://build.ralphmayr.com/posts/9-running-text-to-speech-in-the-cloud-is-harder-than-you-would-think-part-two/</link><pubDate>Wed, 09 Jul 2025 00:00:00 +0000</pubDate><guid>https://build.ralphmayr.com/posts/9-running-text-to-speech-in-the-cloud-is-harder-than-you-would-think-part-two/</guid><description>&lt;p&gt;Do you remember when I mentioned the difficulty of running 🐸 CoquiTTS in the cloud yesterday? My first experiment was to run it directly in my Cloud Run backend service. In theory, this could have worked, but you'll never guess why it failed in practice.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;x86 CPUs&lt;/strong&gt;. Really. Like the ones we had in our computers in the 90s. How did I figure this out? After taking a horribly long time to start up, the TTS service failed with a message saying that it was running on an 'incompatible' CPU architecture. Specifically, 32-bit x86 CPUs.&lt;/p&gt;</description></item><item><title>Running text-to-speech in the #Cloud is harder than you would think (part one)</title><link>https://build.ralphmayr.com/posts/8-running-text-to-speech-in-the-cloud-is-harder-than-you-would-think-part-one/</link><pubDate>Tue, 08 Jul 2025 00:00:00 +0000</pubDate><guid>https://build.ralphmayr.com/posts/8-running-text-to-speech-in-the-cloud-is-harder-than-you-would-think-part-one/</guid><description>&lt;p&gt;For the podcast automation feature that I&amp;rsquo;m planning for a future version of poketto.me, I&amp;rsquo;ve been experimenting with various text-to-speech solutions. The easiest and highest-quality approach would have been the ElevenLabs API. However, considering the &amp;ldquo;throwaway&amp;rdquo; nature of these audio files &amp;ndash; most of which would only be listened to once by one person &amp;ndash; and the cost structure that this would introduce, I desperately need a cheaper approach.&lt;/p&gt;
&lt;p&gt;The Python library 🐸 CoquiTTS is pretty awesome: There are many different models to choose from, ranging from 'super low latency' to 'high quality' (including voice cloning). Therefore, poketto.me users could choose from many different voices, and from a commercial perspective, I could set different price points for different levels of quality and latency. However, they all require significant computing power to function.&lt;/p&gt;</description></item><item><title>CloudSQL is prohibitively expensive (at least for small projects)</title><link>https://build.ralphmayr.com/posts/6-cloudsql-is-prohibitively-expensive-at-least-for-small-projects/</link><pubDate>Sun, 06 Jul 2025 00:00:00 +0000</pubDate><guid>https://build.ralphmayr.com/posts/6-cloudsql-is-prohibitively-expensive-at-least-for-small-projects/</guid><description>&lt;p&gt;When I started setting up the cloud infrastructure for &lt;strong&gt;poketto.me&lt;/strong&gt;, I didn&amp;rsquo;t give much thought to costs. I thought it was such a small project that it just wouldn&amp;rsquo;t matter. I launched a #&lt;strong&gt;CloudSQL&lt;/strong&gt; (MySQL) database with pretty much the default settings and was quite happy with it &amp;ndash; until I checked the billing dashboard a couple of days later and realised that I was already spending almost €4 per day on the database alone. 120 euros per month just for a few MySQL tables? That couldn&amp;rsquo;t be right.&lt;/p&gt;</description></item><item><title>Multi-threaded webservers in Python: A rabbit hole you don’t want to get into.</title><link>https://build.ralphmayr.com/posts/4-multi-threaded-webservers-in-python-a-rabbit-hole-you-dont-want-to-get-into/</link><pubDate>Fri, 04 Jul 2025 00:00:00 +0000</pubDate><guid>https://build.ralphmayr.com/posts/4-multi-threaded-webservers-in-python-a-rabbit-hole-you-dont-want-to-get-into/</guid><description>&lt;p&gt;Put simply, serving web requests properly in Python is not easy. poketto.me uses a fairly basic off-the-shelf stack (#&lt;strong&gt;Flask&lt;/strong&gt; as a web framework and #&lt;strong&gt;SocketIO&lt;/strong&gt; for websocket communication), and you would never guess the issues you could encounter with it. For starters, Flask comes with a built-in web server (&amp;ldquo;werkzeug&amp;rdquo;), which is convenient for development, but absolutely not for production (it even warns you in bright red).&lt;/p&gt;
&lt;p&gt;🧵It runs on a single thread &amp;ndash; I'm not kidding. This means it can only handle one web request at a time. If that request involves any actual work, such as extracting web content, it cannot handle any other requests at the same time.&lt;/p&gt;</description></item></channel></rss>