Monolithic vs Micro-services vs Serverless – tercihiniz hangisi?

08 Tem 02:03

Bence sistem mimarisi seçerken projenin ölçeği, ekibin yapısı ve bütçe hep el ele gitmeli. Ben de çoğunlukla monolithic kullanmıştım.Birinden aldığımız e-ticaret projesinde herşey bir aradayken bakımı gerçekten canavarca oluyordu. Üç kere crash aldı, her seferinde yamamak günler sürdü. Sonunda mikro-hizmetlere ayırdık, özellikle ödeme kısmını C# ile, stok sistemini Go ile yazdık. Esneklik ve ölçekleme o kadar rahatladı ki şimdi her takım kendi servisine odaklanabiliyor, deploy ederken de birbirini taciz etmiyor. Valla performans da maliyet de bizim için en kritik faktördü, çünkü ay sonu indirimlerinde siteyi patlatıyorduk. Ama serverless’e de gözümü kapamıyorum tabii. Küçük projelerde, mesela bir API gateway ya da log toplama sistemi için serverless kullanmak devasa avantaj. Kod yazmadan AWS Lambda ve DynamoDB ile birkaç saat içinde bir şeyler ayaklandırıyorsun, üstüne bir de otomatik ölçekleniyor. Ben sadece API’ye traffic azken bekliyor olsa bile, tek seferlik işleri serverless’e attığımda hem cebim hem de kodum rahatlıyor. Yani tercih hep kullanım senaryosuna bağlı. Bakım kolaylığı mı lazım, hızlı mı dağıtmak lazım, yoksa maliyet mi patlamasın istiyor, ona göre şekilleniyor.

08 Tem 02:31

I was working on a smart home automation project last year, and at first, I went all-in with a monolithic architecture. One ESP32 module, one Raspberry Pi controlling everything through a single Python Flask app. It worked fine for a couple of months until I wanted to add Zigbee support. Suddenly, everything became a mess—updating one feature meant redeploying the entire stack, and debugging took forever because the logs were like a spaghetti code nightmare. After that headache, I tried splitting things into micro-services. Each protocol (Wi-Fi, Zigbee, LoRa) got its own container on a Docker Swarm cluster. Scaling individual components became way easier, and failures in one service didn’t bring the whole system down. But then I ran into issues with maintaining so many moving parts and the overhead of managing orchestration. Eventually, I shifted some parts to serverless—AWS Lambda for event-driven tasks like sending alerts when motion sensors trigger. That eliminated the need to keep servers running all the time, and costs dropped significantly since I only pay when the functions execute. Now I mix them all: monolithic for core local processing, micro-services for distributed tasks, and serverless for sporadic, bursty workloads.

08 Tem 03:08

Monolithic setups are hard to justify in 2024—unless the project is genuinely small or you’re prototyping something before committing to a bigger stack. I started with a single Raspberry Pi running everything in Docker Compose because it felt “simple,” but the moment I tried to touch one service, the whole stack had to redeploy and random ports would clash. Nightmare. Now even my Home Assistant setup is split into HA Core, MariaDB, ESPHome, Node-RED and a handful of Python micro-services. It’s more moving pieces, but rolling updates without affecting the lights feels worth it. Serverless looks tempting for the “deploy and forget” promise, but once you factor in cold starts, vendor lock-in and the bill multiplying when the little-used APIs wake up at 3 AM, it stops feeling cheap. I tried a few AWS Lambda automations for motion-triggered announcements, and the credits vanished faster than my Wi-Fi router reboots. Stick to bare-metal or small VPS for my home, reserve serverless when traffic is truly unpredictable and truly occasional.

08 Tem 05:18

Monolith first for a while, but lately shifted to micro-services for one key reason: my smart home platform’s features like voice control and automation got too tangled in a single codebase. Debugging a monolith when a humidity sensor API fails means restarting the whole stack—annoying when your lights won’t turn off. With micro-services, I spun up a separate “indoor-climate” service that only handles sensor data; the rest of the house keeps running. Downside is now I have to manage three more servers for Redis, auth, and the API gateway—but Docker Compose scripts have saved my sanity. Before that, I kicked the tires on serverless when my security cam notifications kept dying during traffic spikes. Using AWS Lambda + SNS to parse MQTT messages cost pennies for thousands of triggers and removed the need for a always-on broker. Zero cold starts at 3 a.m. because it scales to zero when there’s no motion. Trade-off: vendor lock-in nightmare and debugging a single async flow split across three functions took longer than expected. Right now, a tiny micro-service + serverless hybrid is my sweet spot—micro for core logic, serverless for edge spikes.

08 Tem 06:00

Ben genelde hem performansı hem de esnekliği harmanlayabildiğim için micro-hizmetler tercih ediyorum. Örneğin Arduino temelli projelerde, sensör verilerini bir core service'e gönderip diğerlerini bağımsız micro-service'ler olarak ayırmak işi çok kolaylaştırıyor. Mesela aydınlatma kontrolleri için bir service, veri kayıtları için başka bir service — böylece sadece değişen kısmı güncelliyorsun. Bakımda da modüler olması avantaj oluyor. Ama serverless'e de açıkçası hayat kurtarıcı buluyorum, küçük projelerde ya da geçici API'larda. Örneğin okuldaki Arduino atölyelerinde öğrencilerin yaptığı basit projelerde, bir web arayüzüne ihtiyaç duyulduğunda AWS Lambda kullanarak neredeyse hiç kod yazmadan süreci hızlandırıyorum. Performans ve maliyet arasında hep bir denge var tabii, micro-service'lerde optimizasyonu iyice yapmak gerekiyor.