<?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>Technology on Taubyte Blog</title><link>/blog/categories/technology/</link><description>Recent content in Technology on Taubyte Blog</description><image><title>Taubyte Blog</title><url>/blog/opengraph.jpg</url><link>/blog/opengraph.jpg</link></image><generator>Hugo -- 0.146.0</generator><language>en-us</language><lastBuildDate>Sat, 21 Feb 2026 16:00:00 +0000</lastBuildDate><atom:link href="/blog/categories/technology/index.xml" rel="self" type="application/rss+xml"/><item><title>Docker: When Containers Add Overhead Instead of Value</title><link>/blog/posts/docker-performance-fresser/</link><pubDate>Sat, 21 Feb 2026 16:00:00 +0000</pubDate><guid>/blog/posts/docker-performance-fresser/</guid><description>&lt;p>Docker is everywhere. Every application runs in containers. Every deployment uses Docker. Every team containerizes everything. But here&amp;rsquo;s the thing: Docker adds a runtime layer between your application and the OS. That layer has overhead. That overhead costs money.&lt;/p>
&lt;p>Containers aren&amp;rsquo;t free. They consume CPU. They consume memory. They consume disk space. They add complexity. They add operational burden.&lt;/p>
&lt;p>Most applications don&amp;rsquo;t need containers. Most applications can run directly on the OS. Most applications don&amp;rsquo;t need the isolation. Most applications don&amp;rsquo;t need the portability.&lt;/p></description></item><item><title>Service Mesh: The Sidecar Tax That Eats Your Memory</title><link>/blog/posts/service-mesh-performance-fresser/</link><pubDate>Fri, 20 Feb 2026 16:00:00 +0000</pubDate><guid>/blog/posts/service-mesh-performance-fresser/</guid><description>&lt;p>Service meshes are everywhere. Istio. Linkerd. Consul Connect. Every microservices architecture needs one. Or so the marketing says.&lt;/p>
&lt;p>But here&amp;rsquo;s the thing: service meshes add sidecar proxies to every pod. Envoy, Istio&amp;rsquo;s sidecar, uses 50-200 MB RAM per pod. Linkerd-proxy uses 20-100 MB. Multiply by hundreds of pods. That&amp;rsquo;s gigabytes of memory just for service mesh overhead.&lt;/p>
&lt;p>All of this before your applications run. All of this just for inter-service communication. All of this overhead.&lt;/p></description></item><item><title>etcd: The Consensus Tax You're Probably Paying For Nothing</title><link>/blog/posts/etcd-performance-fresser/</link><pubDate>Thu, 19 Feb 2026 16:00:00 +0000</pubDate><guid>/blog/posts/etcd-performance-fresser/</guid><description>&lt;p>etcd sits at the heart of Kubernetes. Before your applications run, etcd is storing cluster state, coordinating elections, and replicating data. It consumes 2-8 GB RAM per node. It requires 3-5 nodes for high availability. That&amp;rsquo;s 6-40 GB RAM just for cluster coordination.&lt;/p>
&lt;p>Most teams don&amp;rsquo;t need distributed consensus. Most teams don&amp;rsquo;t need high availability at the cluster level. Most teams are running small clusters that would work fine with a single node and backups.&lt;/p></description></item><item><title>Cloud Hyperscalers: The $10M Lesson from 37signals</title><link>/blog/posts/cloud-hyperscalers-performance-fresser/</link><pubDate>Wed, 18 Feb 2026 16:00:00 +0000</pubDate><guid>/blog/posts/cloud-hyperscalers-performance-fresser/</guid><description>&lt;p>Cloud-first is the default. Every startup uses AWS. Every enterprise migrates to Azure. Every consultant recommends GCP. But here&amp;rsquo;s the thing: 37signals went from $3.2M per year to $1.3M per year after leaving the cloud. Over $10M saved in five years.&lt;/p>
&lt;p>GEICO spent a decade migrating to the cloud. Result: 2.5x higher costs. They&amp;rsquo;re not alone.&lt;/p>
&lt;p>The cloud isn&amp;rsquo;t always cheaper. It&amp;rsquo;s often more expensive. Especially when you factor in hidden costs: egress fees, managed services, vendor lock-in.&lt;/p></description></item><item><title>Microservices: What Amazon Prime Video Learned the Hard Way</title><link>/blog/posts/microservices-performance-fresser/</link><pubDate>Tue, 17 Feb 2026 16:00:00 +0000</pubDate><guid>/blog/posts/microservices-performance-fresser/</guid><description>Amazon Prime Video cut costs by 90% by moving away from microservices back to a monolith.</description></item><item><title>NGINX: When Reverse Proxies Cost More Than They're Worth</title><link>/blog/posts/nginx-performance-fresser/</link><pubDate>Mon, 16 Feb 2026 16:00:00 +0000</pubDate><guid>/blog/posts/nginx-performance-fresser/</guid><description>&lt;p>NGINX sits between your users and your application. Before a single request reaches your code, NGINX is parsing configs, terminating SSL, rewriting URLs, and logging everything. All of this overhead. All of this complexity.&lt;/p>
&lt;p>The Ingress-NGINX controller is being retired in March 2026. About 50% of cloud-native setups depend on it. No more fixes. No more patches. Migrating means rewriting ingress configs across hundreds of services. Staying means increasing security risk. Pick your poison.&lt;/p></description></item><item><title>Kubernetes: The Orchestration Tax Most Teams Don't Need</title><link>/blog/posts/kubernetes-performance-fresser/</link><pubDate>Sun, 15 Feb 2026 16:00:00 +0000</pubDate><guid>/blog/posts/kubernetes-performance-fresser/</guid><description>&lt;p>Kubernetes was built to orchestrate Google&amp;rsquo;s global infrastructure. You are not Google. Terribly sorry.&lt;/p>
&lt;p>82% of container users run Kubernetes in production. Most of them shouldn&amp;rsquo;t.&lt;/p>
&lt;h2 id="the-control-plane-tax">The Control Plane Tax&lt;/h2>
&lt;p>Before your application serves a single request, Kubernetes needs etcd chewing through 2-8 GB RAM per node. Then kube-apiserver, kube-scheduler, kube-controller-manager, kubelet (reserving 25% of node memory by default), CoreDNS, kube-proxy, and a CNI plugin. All of this before your code runs.&lt;/p></description></item><item><title>Secrets in the AI Era: Where Plaintext Lives</title><link>/blog/posts/secrets-for-ai-era/</link><pubDate>Thu, 22 Jan 2026 16:00:00 +0000</pubDate><guid>/blog/posts/secrets-for-ai-era/</guid><description>Secret management in the age of AI agents requires rethinking trust boundaries. The critical question is no longer who can access secrets, but where plaintext can ever exist.</description></item><item><title>Secrets in the AI Era: Where Plaintext Lives (Deep Dive)</title><link>/blog/posts/secrets-for-ai-ear-deep-dive/</link><pubDate>Thu, 22 Jan 2026 16:00:00 +0000</pubDate><guid>/blog/posts/secrets-for-ai-ear-deep-dive/</guid><description>A deep dive into secret management threat models in the age of AI agents. The critical question is no longer who can access secrets, but where plaintext can ever exist, and what that implies for risk, blast radius, and operational burden.</description></item><item><title>Differences Between Cloud Computing and Distributed Computing</title><link>/blog/posts/dist-vs-cloud-computing/</link><pubDate>Sat, 22 Jun 2024 23:14:00 +0000</pubDate><guid>/blog/posts/dist-vs-cloud-computing/</guid><description>The digital transformation of businesses has significantly increased reliance on advanced computing paradigms, primarily cloud computing and distributed computing. Cloud computing offers scalable, on-demand access to computing resources over the internet, managed centrally by providers like AWS and Google Cloud. In contrast, distributed computing involves a network of interconnected computers working collaboratively to solve complex problems, enhancing fault tolerance and processing speed. While cloud computing excels in flexibility and cost-efficiency with a pay-as-you-go model, distributed computing provides superior performance for parallel processing tasks. The integration of AI into cloud platforms further enhances capabilities, driving innovation and efficiency in various applications.</description></item></channel></rss>