Back in November 2022 I was browsign the then Twittosphere (now Exosphere?) when I ran across an interesting tweet from @manishrjain: What is happening? Caddy is 2x outperforming NGINX in my reverse proxy test 🚀 With Caddy, there's practically no difference in HTTPS vs HTTP performance. If legit, this is clearly a David vs Goliath story. @mholt6 — Manish R Jain (@manishrjain) November 23, 2022 It caught my attention, but not because of the claim that Caddy outperforms Nginx by 2x, but instead because often, when it comes to benchmarking and comparing technologies, especially when it comes to Servers, Internet and Network Requests, you could often overlook specific details.
With Hashicorp moving a bit away from their roots in the Open Source world and going into the more locked-in, don’t-compete-with-me kinda scenario, it’s hard not to start thinking whether you should be looking at jumping ship away from your massive Terraform setup. If you’re in that boat, where can you go? What are the alternatives to Terraform? In this article, I’ll provide some of my recommendations as to where to go, with some pros and cons on each option.
Recently I’ve been playing with a few different tools to make me more proficient when working with Kubernetes. Additionally, people that know me know I play lots of games – sinking more and more time into Destiny 2 – so I keep Windows as my daily desktop driver and even with all the grievances of WSL – including random loss of networking – I still use it as a daily driver to write code and do other work in a Linux environment while still retaining a Windows “desktop”.
We’ve all been there: we’re working on our next super-hyper-duper Kubernetes operator, we’re about to deploy it but we’re doing some local testing, so we create a ConfigMap or a Secret, we mount it to the Pod, launch our app and we see the entire directory is now gone, replaced with our ConfigMap or Secret’s contents. This post will show you how to mount a ConfigMap or Secret on a preexistent folder without deleting all its data.
Working with service meshes is really an interesting concept and sells you the benefits of, well, the service mesh itself, mutual TLS, end-to-end encryption, and more. Unfortunately though, not everything is as straightforward as you might think. In fact, Istio’s own documentation page has a full section dedicated to “common issues”. These issues are not so evident if you come from an Ingress Controller world and you assume you would understand Istio using the same knowledge as you would have when using Ingress Controllers instead.
Here’s an interesting problem I ran into while doing some work a few days ago. I was working on a pipeline to deploy new resources using ArgoCD. Everything was going great until one of the Kubernetes resources was, in fact, a resource managed by a Kubernetes controller: that is, applying it will not create it, it will merely tell the controller to create it, eventually. In practical terms, during my time at Sourced Group, we’ve been working closely with Anthos and some of their applications, including Anthos Config Connector, a nifty little controller that allows you to declare Google Cloud resources as Kubernetes YAMLs, and have this Config Connector – or ACC for short – create them for you.
I know I’m not the first one to create this and, in fact, there are a plethora of options out there to use as of right now. Still, I wrote my own version of wait-for, and there are a few differences that make it to be a little more useful than the alternatives. For those of you who have never heard about this, wait-for is a very simple and tiny application with a unique purpose: it allows you to define several TCP endpoints – that is, endpoints like a MySQL Database (or MariaDB if you’re in line with the new waves), or even NoSQL ones, like Redis or MongoDB – and wait for them to be ready.
Hola! Uff, qué raro se siente escribir en un blog de nuevo. Después de un par de días de trabajo, he logrado recuperar el blog. Inicialmente, este blog usaba Hugo, pero por varios años de descuido – entendiendo que el último artículo que escribí fue en Enero del 2015, 7 años atrás! – no me fue posible recuperar la tecnología de fondo del blog. Si mal ni menos no recuerdo, el “motor” de Hugo era 0.
Google Web Fonts es una herramienta bastante útil al momento de diseñar sitios web. No sólo porque te ofrece un sinnúmero de beneficios, gracias a que hospeda las fuentes por ti, las optimiza para mostrarlas y, además, basado en el User-Agent del usuario, entrega la fuente correcta, sin enviar fuentes adicionales innecesarias. Positivamente, las web fonts o, más correctamente, las font-face han tenido un largo trayecto. Por ejemplo, las WOFF2 ya no son un sueño, y son soportadas por Chrome y Firefox y por ende, tenemos un mismo tipo de fuente para distintos navegadores.
Para los amigos webmasters que deciden alojar sus ideas en beta y desarrollos básicos en Heroku, éste presenta una gran alternativa: es fácil de usar, no se requiere inversión inicial, y además, acelera de sobremanera todo el trabajo de sysoperations, puesto que no hay que hacer más que un simple git push heroku master para tener la app funcionando en línea. ¿El único problema? Las apps free en Heroku se duermen si, durante una hora, no reciben tráfico alguno.