DEV Community: Oleg Pustovit

AWS Serverless: Still the Boring Correct Choice

Oleg Pustovit — Fri, 16 Jan 2026 12:26:40 +0000

In the last 6 months, I've helped 3 AI startups migrate from Vercel or Cloudflare to AWS Lambda. The pattern is the same: they start on a platform with great DX. Then the wall shows up: background jobs, retries, queues, cron, and eventually a "this endpoint needs 2-8 GB RAM for 4-10 minutes" workload — and they land on AWS.

To be fair: Vercel and Cloudflare captured developer attention for good reasons. Vercel ships Next.js fast — previews, simple deploys, great DX. Workers are great for edge use-cases: low latency, fast cold starts, global distribution. Both solve real problems.

Where things get harder is when the app grows a backend shape: queues, retries, scheduled jobs, heavier compute, private networking. Vercel still relies on third-party partners for queuing (like Upstash or Inngest), adoption involves piecing together vendors. Workers are fantastic for edge latency, but you feel constraints fast (memory limits, lack of native binary support, and file system restrictions), when Lambda is built for "bigger" invocations in mind (more memory and longer max runtime), with SQS, DynamoDB, and EventBridge under the same network.

For request-based apps calling LLMs, AWS Lambda tends to cover what startups actually need: compute, queues, persistence, scheduling in one network. Pay-per-use, no infra to manage, often near $0 for small workloads. The tooling improved too — SST made deployment much easier. But the hype moved on before anyone noticed.

The Hype Died, but did Serverless?

The biggest criticism of serverless technology, especially with AWS, is that setting up the infrastructure is complicated, starting from defining policies to actually creating all of the AWS resources and connecting them together. It has a learning curve and tools like SAM simplify it, but they oftentimes are brittle or have bugs. SAM was a great start — it built the hype and community around serverless — but it wasn't as straightforward as modern development tools. Working at orgs where I had to introduce it to engineers used to Docker containers, Docker was a faster workflow than CloudFormation wrappers. SST fixed this, but by then developers had already moved to Vercel or Cloudflare.

Another big problem is cold start with the compute itself, the time that is required to spin up the compute resource and load the runtime and then execute the code. This means serverless shouldn't be viewed as a short-running server process, but rather as a different computing paradigm that requires factoring specifics of the underlying constraints.

Spacelift, a CI/CD platform, went the other direction in 2024: ECS to Lambda for async jobs. Spiky traffic made always-on containers expensive.

When NOT to use Serverless

Of course, serverless is not universal. Know when to reach for something else.

In 2025, Unkey moved away from serverless after performance struggles. Their pattern: high-volume workloads with tight coupling between components. As traffic grew, pay-per-invocation stopped making economic sense. This mirrors the Prime Video case from 2023 — both had architectures where serverless overhead exceeded the benefits. The lesson isn't that serverless failed; it's that serverless has a sweet spot, and high-throughput tightly-coupled systems aren't in it.

When to reach for something else:

Long-running processes. Applications like AI agent orchestrators would not work on Lambda due to hard 15-minute timeout. In this case, switch to Fargate or regular EC2 instance.
Predictable high traffic or constant load. You would gain more benefit from using containers in this case. Serverless is way better for bursty or unpredictable traffic.
GPU workloads. Lambda does not support GPUs: for machine learning inference that requires CUDA, you have to use either EC2 or SageMaker.
High-throughput media pipelines. Orchestrating many state transitions per second through Step Functions gets expensive fast. The Prime Video case is typical — they triggered a transition for every single video chunk, hitting massive limits and costs. Use containers for stream processing.
Your team is already efficient elsewhere. If you have existing infrastructure — Kubernetes, for example — and the team knows it well, don't force serverless. It takes time for an org to adopt an unfamiliar paradigm. For greenfield projects and validation, serverless is great. For teams already shipping on K8s, keep shipping.
Legacy dependencies that need a full OS. Some applications depend on libraries that are hard to package for Lambda. At times you just need a VM to run the thing. Serverless is problematic when you're fighting runtime constraints.
Unsupported programming languages. Don't experiment with languages Lambda doesn't officially support. Custom runtimes add overhead that's rarely worth it. Stick to Node.js, Python, Go, Java, .NET — the supported options.

For request-based apps with variable traffic, especially AI-integrated APIs, serverless fits well.

The Stack

If you already have AWS basics, building serverless there makes sense. Here's the stack and how to use it effectively.

Presentation Layer

For the presentation layer, use a CDN and object storage for static assets. That's typically CloudFront + S3, as you get benefits from the edge computing and the AWS infrastructure. S3 is useful because you can just build your HTML and CSS artifacts and upload them to the object storage. This decouples your frontend and web assets from your server, but brings architectural limitations: you can only do static exports. Fine for blogs, but you lose Server-Side Rendering (SSR) capabilities needed for dynamic SEO or personalized content.

When you have the CDN in place, it's worth thinking about how you would coordinate request execution. You can use an Application Load Balancer to forward requests to Lambda, but I'd recommend API Gateway for most cases. It handles request routing, rate limiting, and authorization out of the box. Getting IAM permissions right is critical, but once configured, your requests flow directly to Lambda.

Compute

The next component is your compute layer — where business logic lives. For serverless execution, use AWS Lambda. It runs your code without provisioning servers, with usage-based pricing: you pay per 100ms of execution. Lambda is designed for event-driven workloads and short-lived compute (up to 15 minutes); anything longer, reach for Fargate. For prototypes, web apps, and AI-integrated APIs, Lambda is a natural starting point — call LLMs, build UI wrappers, handle business logic, all without managing servers.

When deploying Lambda, you have two options: native runtime or custom Docker images. Native is recommended for faster cold starts. Cold starts are real, treat Lambda as an event-driven runtime, not a "tiny server". Keep the handler small with simple initialization, and be intentional about concurrency and the warmup when latency becomes a problem.

For complex configurations, use Lambda Layers to package dependencies separately from your function code. Layers let you include binaries, libraries, or custom runtimes while keeping cold starts fast. Use Docker as a last resort, when you need full control over the OS environment or dependencies that won't fit in layers. The tradeoff: slower cold starts and CI/CD complexity. On GitHub Actions, you need a Docker build pipeline instead of just dropping code to S3 and calling the update API.

Background processing

For async work, use SQS. Lambda's event source integration handles batching, scaling, and polling for you.

Years back, I worked with an enterprise architect on a startup backend. He proposed SQS for our messaging layer. At the time, this seemed odd — SQS wasn't easy to run locally. You couldn't reproduce the infrastructure the way you could with RabbitMQ. But what I gained from that experience was understanding that sometimes you should explore managed services and accept the tradeoff: you lose local reproducibility, but you stop dealing with memory and compute constraints entirely.

To this day, if the messaging architecture is simple, I go with SQS and Lambda combined with event source mapping. You don't have to write the consumer yourself — the integration handles all of that. And that consumer code is often problematic to test anyway.

At a clickstream startup, we faced this exact pattern: process event data from high-traffic e-commerce sites, unknown traffic patterns, weeks to launch. Lambda workers pulled from SQS with event source batching, processing multiple events per invocation. CDK handled deployment. The system scaled on its own.

An EKS equivalent would have meant provisioning a cluster, configuring autoscaling, setting up observability, managing node health. We skipped all of that and shipped.

Persistence

For persistence, use DynamoDB, but don't treat it like a relational database. Its power comes from partition keys, sort keys, and secondary indexes, so invest time understanding the data model. Think of it as an advanced key-value store with sorting capability. Optimize your queries when you hit scale; for prototypes, just build. For deeper learning, Alex DeBrie's DynamoDB Guide covers single-table design and access patterns.

At a B2B marketing startup I was working on, the main data tier was MongoDB collecting events from large e-commerce stores. But the application had also domain tables to store data related to dashboard: organizations, users, authentication, settings. Originally they lived on RDS, which was overkill. At the start there were 10-15 enterprise clients, and paying a dedicated RDS instance for that load made no sense.

RDS Cost: ~$35.00 / month for db.t3.small, DynamoDB cost after migration: ~$0.00 - $2.00 / month (mostly storage costs) for the same workload.

On launch we stored that data in DynamoDB, organizations, users, auth, settings had their own table. At a later point Dynamo was used for the more data-intensive part with session tracking (by using TTL indexes) and debugging logs. The pattern worked for low traffic tables because of zero maintenance and pay-per-request pricing.

Observability

For observability, CloudWatch shows your errors and aggregations. Metrics and alarms work out of the box, and logs appear automatically without configuration. Later you can instrument with OpenTelemetry or connect other services, but for a basic serverless application, CloudWatch is more than enough.

For years, I found CloudWatch UI and Insights sluggish compared to Grafana. But now I wire AWS SDK to Claude Code and let the AI pull logs and analyze issues. The stable CLI and REST API make log processing trivial.

How to be successful with AWS serverless

Build applications without technology bias. A few years ago, Docker containers and microservice orchestration were popular, which created misconceptions about serverless. Aim for simplicity: reduce your problem to the simplest actions, refine your data model, and design your system as a transactional request-based application. That's what makes serverless work.

Start with an Infrastructure as Code tool like Terraform, AWS CDK, or the increasingly popular SST. You define how infrastructure gets created, then deploy that stack to your AWS account. I personally use Terraform because I want full control over my infrastructure. But for getting started quickly with pre-built blocks, SST is the better choice since productivity matters early on.

Previously, AWS was less approachable since deploying with CloudFormation or SAM was painful. CloudFormation itself is stable and battle-tested: CDK and SST (before v3) both sit on top of it, but the raw DX isn't great. That's why picking the right abstraction layer matters: you get CloudFormation's reliability without writing YAML by hand.

Pick your IaC tool carefully

In 2026, Lambda deployment has vastly improved. For getting deep expertise in AWS, I'd recommend learning a few alternatives: start with CloudFormation and CDK to understand AWS-native infrastructure, then explore Terraform.

Tool	Advantages	Disadvantages
SST	Rethought DX for serverless, hot-reload, efficient resource usage	New, smaller ecosystem
Terraform	Full control, predictable plan/apply, scales to EKS and complex infra	HCL learning curve
CDK	Native TypeScript/Python, easy to code	CloudFormation underneath, can be brittle

In the startup teams I've consulted, Terraform is typically the go-to infrastructure as code solution because of its architecture where you execute plan and apply changes. It's been reliable in practice.

For developer experience and prototyping, SST fits well. A few years ago, serverless meant wrestling CloudFormation stacks. SST changed that, so you can hot-reload Lambda functions and iterate fast without managing infrastructure YAML. For getting started, SST is a solid default.

Setting up Lambda + API Gateway + DynamoDB with SST v3 is simple:

/// <reference path="./.sst/platform/config.d.ts" />

export default $config({
  app(input) {
    return {
      name: "my-api",
      removal: input?.stage === "production" ? "retain" : "remove",
      home: "aws",
    };
  },
  async run() {
    const table = new sst.aws.Dynamo("table", {
      fields: { pk: "string", sk: "string" },
      primaryIndex: { hashKey: "pk", rangeKey: "sk" },
    });

    const api = new sst.aws.ApiGatewayV2("api");

    api.route("POST /", {
      handler: "functions/handler.main",
      link: [table],
    });

    return { url: api.url };
  },
});

With coding agents like Claude Code or OpenCode, getting this stack running takes minutes. Point the tool at your project, describe what you need: "set up Next.js with Lambda, SQS, and API Gateway using SST", and it figures out the configuration, writes the infrastructure code, and deploys it for you. The entire setup is under 100 lines of code. The barrier to serverless dropped from "learn CloudFormation" to "describe what you want."

Cloudflare Workers is popular but still maturing for backend use cases. Lambda remains the more common choice for serverless backends.

What about Vercel? It provides Next.js with serverless functions, but you can't build background execution logic or advanced infrastructure like queue services. The serverless environment is limited to Node.js API routes. It's popular among beginners because React and Node.js are familiar, but you're locked into Vercel as a vendor. Enterprises and startups still use AWS, and even modern AI applications run on AWS Bedrock. As a full-stack developer, investing in AWS serverless gives you more flexibility and portability.

Why not Vercel or Cloudflare?

Vercel with Next.js

Vercel is a good service for having everything set up. You write code, push it to GitHub, and it gets configured and deployed without any effort. It supports previews and permissions, simple environment variable configuration, and your frontend available on a CDN — all without messing with infrastructure code. This is powerful for getting your software out, and that's why it got popular. Not only because they develop Next.js, but because Next.js integrates well with Vercel, and it’s frictionless.

Vercel works for prototypes and UI-driven apps. If you're in the React ecosystem, you can move fast. I've built several apps on Vercel, mostly AI-integrated tools that need a quick frontend. Last time I created a poster generator with custom typography — the app called an LLM to generate a JSON schema, then rendered the poster. Vercel handled that perfectly: simple UI, one API route, done.

In my consulting work, I've seen two patterns:

Pattern 1: Vercel as frontend layer. One social network startup runs their infrastructure on Kubernetes but still uses Vercel for the web app. Why? The implementation stays in sync with their React Native mobile app, and Vercel's API routes connect cleanly to their backend. They get the benefits of both: React ecosystem on the frontend, scalable backend on K8s.

Pattern 2: Vercel + AI pipeline. An AI startup I'm working with uses Next.js as the frontend layer connecting to their document processing pipeline. The LLM-driven backend handles research on internal documents; Next.js just renders results. You'll find tons of templates for this pattern.

Vercel's limitation is the backend. They announced queues in 2025, but it's still in limited beta. For background jobs today, you need external services like Inngest or QStash. And you're locked into their platform; Fluid Compute is Vercel-proprietary.

I've seen this limitation create absurd workarounds. One project I consulted on — a news aggregator built on Netlify — needed scheduled background jobs. Their solution: GitHub Actions calling a Netlify serverless function on a cron. It had no retries, no timeouts, and when the function failed, nobody knew until users complained. We reworked it to AWS: EventBridge scheduled rule triggering a Lambda with built-in retries, CloudWatch alarms, and dead-letter queues. The hacky setup became infrastructure that worked.

For a frontend layer that connects to backend services, Vercel works. For a complete backend, you'll outgrow it.

If you want Next.js without vendor lock-in, look at OpenNext. It's an open-source adapter that deploys Next.js to AWS Lambda, and SST uses it under the hood. You get App Router, Server Components, ISR, image optimization — most Next.js features work. The deployment is one line: new sst.aws.Nextjs("Web"). NHS England, Udacity, and Gymshark run production workloads on it. The main gotcha is middleware: it runs on the server, not at the edge, so cached requests skip it. For most apps, that's fine. If you want Next.js but need AWS infrastructure underneath, OpenNext is the escape hatch.

Cloudflare Workers

Cloudflare is good at edge computing with innovative technologies. Workers run in V8 isolates — a smart idea that gives you near-instant cold starts. They excel at CDN and DNS, and offer a compelling alternative to get started.

I use Cloudflare for CDN and frontend hosting. The UI is clean, the CLI is simple, and deployment is quick. For static sites and edge caching, it's easier than AWS CloudFront.

But Workers are a different runtime model — not full Node.js. That's a feature for edge latency (cold starts under 5ms), but a constraint if you expect full Node compatibility or heavier workloads: many npm packages don't work. The 128 MB memory per isolate and 5-minute CPU time limit (not wall clock) make sense for edge, but they're restrictive compared to Lambda's multi-GB memory options and 15-minute max runtime. I played with deploying WebAssembly apps in Rust and Go, and the developer experience wasn't there yet.

I wouldn't build a startup on Cloudflare Workers yet. For edge routing and authentication, it's fine. For a full backend, it falls behind AWS.

Firebase

At one startup, we had the infrastructure partially on AWS — the AI agent running in the background, but the frontend was React with Firebase Functions calling Firestore. Firebase did a great job as a prototyping tool; we were able to build a complex frontend with the database initially. But the problems stacked up:

The data was fragmented, living outside AWS. Generally considered bad practice.
React calling Firestore directly created tight vendor lock-in with Firestore.
Google Cloud feels disjointed compared to Firebase — Firebase is its own island.

We spent two months migrating to AWS, using equivalent resources to keep networking and IAM policies consistent across the whole application.

The one exception: I typically choose Firebase for Google authentication. It's the easiest way to get Google auth working — pluggable, no client configuration needed. For that specific use case, Firebase is a solid default. Otherwise, I go straight to AWS.

Why I default to AWS

For startups expecting growth, here's why AWS makes sense.

Industry-proven. Large companies run production workloads on Lambda. Capital One runs tens of thousands of Lambda functions after going all-in on serverless. Thomson Reuters processes 4,000 events per second for usage analytics on Lambda. The failure modes are well-documented; the solutions exist.
Infrastructure flexibility. You can optimize costs, swap components, migrate from Lambda to Fargate — all within one network. With Vercel plus external services, you're stitching together pieces that don't guarantee coherent infrastructure.
One network space. Your Lambda talks to DynamoDB talks to SQS without leaving AWS. No cross-provider latency, no credential juggling, no surprise egress fees.
Low cost to start. Some argue serverless is overkill — just rent a $5/month VPS. But a VPS costs money from day one, while Lambda's free tier includes 1 million requests and 400,000 GB-seconds per month permanently, DynamoDB gives you 25 GB free, and API Gateway offers 1 million HTTP calls free for 12 months. For low-traffic projects you can run for near $0 — and for prototypes with variable traffic, serverless is often cheaper than fixed infrastructure.
AI-ready. AWS is investing heavily in AI, and Bedrock gives you access to Anthropic models (Claude and others) within AWS networking, so your Lambda calls Claude without leaving the network. If you qualify as a startup, they offer generous credits for large inference workloads. For AI-integrated apps, the whole stack stays in one place.

Learn the alternatives. When you need to scale, start with AWS serverless.

How to get started with it in 2026

Start by building a complete backend within serverless constraints. Design around cold start limitations and use SQS and EventBridge for background execution. This stack works well for AI apps that call LLM inference APIs — not for AI agents that need to run for hours, but for request-based AI features. Whether you're a beginner or an advanced full-stack developer, serverless is worth the investment. Understand the limitations first, build after. The serverless stack rewards this discipline.

One caveat: serverless requires your team to think differently. At an ad tech startup, I watched a team struggle with a Lambda-based bidding system. The architecture was designed serverless because of the maintenance overhead we'd avoid — in theory, it was much easier to add or change parts of the ad tech we were building. But the backend engineers came from Docker and long-running servers. They understood request-response, but the tooling around AWS serverless — CloudWatch, S3, the whole stack — felt alienating compared to containerized apps built on FastAPI or Django. That workflow just wasn't available for serverless. The deadline moved three months, which brought a lot of problems. We had to switch to an ECS cluster with containers, which was suboptimal for the bursty nature of ad bidding. The architecture wasn't wrong; the team-stack fit was. If your engineers aren't familiar with serverless, budget time for learning or pick what they know.

Start with SST, hit your first bottleneck, then reevaluate.

The serverless stack isn't going anywhere. Master the constraints, and you'll ship faster than teams managing their own infrastructure.

References

AWS Lambda Pricing & Free Tier — Detailed pricing information including the generous free tier (1M requests/month permanently).
DynamoDB Guide - Alex DeBrie — The definitive resource for DynamoDB data modeling, covering single-table design and access patterns.
SST Documentation — Official docs for SST v3, the modern serverless framework with hot-reload and TypeScript support.
OpenNext — Open-source adapter for deploying Next.js to AWS Lambda without vendor lock-in.
Spacelift: AWS Lambda Migration (2024) — Case study of migrating from ECS to Lambda for async workloads with spiky traffic.
Unkey: Moving Away from Serverless (2025) — Counter-example showing when high-volume tightly-coupled systems outgrow serverless.
Prime Video Serverless to Monolith (2023) — The infamous case where Step Functions costs drove a move to ECS for video analysis.
OpenCode — Open-source AI coding agent by SST, provider-agnostic and privacy-focused.
Inngest — Durable workflow engine for background jobs, often used with Vercel.
QStash — Serverless message queue from Upstash, an alternative for Vercel deployments.

In 2025, Apple still makes it hard to play your own MP3s, so I wrote my own app

Oleg Pustovit — Thu, 22 May 2025 11:08:24 +0000

In 2025, playing your own music on an iPhone is surprisingly hard, unless you pay Apple or navigate a maze of limitations. So I built my own player from scratch, with full text search, iCloud support, and a local-first experience. GitHub link

Why I Built My Own Audio Player

Like many people, I've picked up too many subscriptions, some through Apple (iCloud, Apple Music), others got lost in random platforms (like Netflix, which I forgot I was still paying for). I actually used Apple Music regularly (and previously Spotify), but the streaming turned out to be more convenience than necessity. With a curated local library, I didn't lose much, just the lock-in.

Initially I thought, I'd just keep using iCloud Music Library for cross-device music synchronization, but once I cancelled the Apple Music subscription, the sync stopped working. Turns out this feature is behind a paywall. You can technically get it back via iTunes Match ($24.99/year). Match just stores 256-kbps AAC copies online; your original files stay put unless you choose to replace them. On a modern Mac, you do all this in the Music app. Without either subscription, cloud sync is gone, and you're back to cable/Wi-Fi syncing.

Frustrated with the lack of options, I went the builder route. If I bought a computing device (iPhone in this case), what stops me from just building exactly what I need with code to use it? In this article, I want to share my full journey of frustrations towards creating a basic music player functionality: loading audio files, organizing and playing them back, but mostly, I wanted to remind myself, this is still a general-purpose computer, I should be able to make it do what I want.

What Apple (and Others) Offer Today

Before writing my own app, I explored the official and third-party options for offline music playback.

Apple's Built-in Apps

Apple technically lets you play music directly from iCloud via the Files app, but its functionality is not designed for music listening. It lacks essential features such as playlist management, metadata sorting, or playback queues. While it supports music playback, it's very limited and overall not a good user experience.

Third-Party Apps

I went to the app store to look for cool apps that solve my problem, while there are many of them, many rely on subscription-based pricing, a questionable model for an app that simply plays files users already own. There's one app that I liked, Doppler. I've played with it during a trial, but the UX is built around managing albums. The search wasn't that good, and the import functionality from iCloud was slow and hard to use on a large number of nested folders. The upside was, it had a single payment pricing model.

Going Builder Mode: My Technical Journey

With that said, I decided to create my own ideal music player that solves my pain points:

Flexible full-text search across iCloud folders, so I can select and import a folder with music or specific files quickly.
Functionality in managing music at least on par with the official Music App: queue, playlist management, and sorting by albums, etc.
Familiar and friendly interface.

Trying React Native First

Initially, I avoided Swift because of my previous experience with it. A few years back, I liked the syntax (felt closer to TypeScript) and appreciated the Rust-like memory safety, but without native async/await at that time, writing concurrent code compared to Go or JS/TS felt clunky and boilerplate-heavy. That experience left me frustrated, so when I revisited this project, I initially reached for something more familiar.

That said, I went with React Native or Expo, hoping to reuse my web development experience and plug in a player UI from existing templates. Building the playback UI was straightforward; there are numerous open-source examples and tutorial videos on building good-looking music players that fit my needs. I picked an existing template project by Gionatha Sturba, because it looked to have every feature I need for my app.

Accessing the file system and syncing cloud files hit major roadblocks: libraries like expo-filesystem supported basic file picking, but recursive traversal over deeply nested iCloud directories often failed or even caused app crashes. This made it clear that a JavaScript-based approach introduced more complexity than just working with Apple's native APIs, even if it meant a steeper learning curve.

iOS sandboxing prevents apps from reading files without explicit user permission, which meant React Native couldn't access external folders reliably. Switching to Swift gave me more control over iCloud file access and sandboxed permissions.

Switching to SwiftUI

I went with SwiftUI instead of UIKit or storyboards because I wanted a clean and declarative UI layer that would stay out of the way while I focused on domain logic and data synchronization. With modern features like async/await and integration with Swift Actors, I found it easier to manage data flow and concurrency. SwiftUI also definitely made it easier to structure the app into isolated ViewModel components, which in turn helped me get better results from LLMs like OpenAI o1 and DeepSeek. LLMs could produce pure UI code or data binding code without introducing messy interdependencies.

App Architecture and Data Model

Let's go over the architecture of the app I've created: I used SQLite for persistent data storage and approached the app architecture as a simple server application. I avoided CoreData because I needed tight control over schema, raw queries, and especially full-text search. SQLite's built-in FTS5 support let me add fast fuzzy search without pulling in heavy external search engines or building my own indexing layer.

Three Main Screens

The app consists of 3 screen/modes:

Library import. This is where you add your iCloud library folder. The app scans every folder for audio files and inserts every path into a SQLite database. This way, you can have full flexibility in searching, adding folders, and subfolders. Apple's native file picker is very clunky; you cannot select multiple directories that you searched by keyword and then also a bunch of files in one go. It simply is not designed to do that.
Library management. This is where you can manage the added songs and organize playlists. For the most part, I've reflected the way Apple did that in their Music app, and it was good enough for my needs.
Player and playback. This part of the application manages queue management (repeat, shuffle), etc., and play, stop, and next song functionality.

A simple user flow diagram is shown here:

User flow in practice: When the app launches with an empty library, it lands on the Sync tab, showing a big "Add iCloud Source" button. Pick a folder there, and the Sync screen displays a progress bar while it walks the tree. As soon as indexing finishes, it switches you to the Library tab, whose first screen lists Playlists / Artists / Albums / Songs. Dive into any list, tap a track, and a Mini-Player pops up along the bottom; tap that mini-bar to open the full-screen Player with shuffle, repeat, queue reorder, and volume. Swipe or tap the close icon, and you're straight back to the Library while playback continues. Any time you need more music, jump back to Sync, hit the "+" in the nav bar, select another folder, and the import service merges new songs in the background, no restart required.

Backend-Like Logic Layer

Having a web/cloud background and shipped a lot of server code while working in startups, I went with a backend-like architecture for the mobile app. The whole domain/logic layer was separated from the View and View-Model layer because I had to nail the cloud syncing, metadata parsing aspect of the app and having clean data access to a SQLite DB. Here's an approximate layered architecture diagram that I used here:

How the layers talk: SQLite sits at the bottom, storing raw song rows and FTS indexes. Then repositories wrap the database and expose async APIs. On top of those live my domain actors, Swift actors that own all business rules (import, search, queue logic) so state mutations stay thread-safe. ViewModels subscribe to the actors, transform the data into UI-ready structs, and SwiftUI views simply render whatever they get. Nothing crosses layers directly, keeping iCloud sync, playback, and UI nicely decoupled.

Implementing Full Text Search with SQLite

Like I previously mentioned, it's fortunate that you can import an SQLite version with FTS capabilities: starting around iOS 11, it's available out of the box without extra setup. This made it easy to integrate fuzzy search into my music library without any third-party dependencies. Additionally, I used the SQLite.swift library for regular queries (which works as a sort of query builder with compile-time safety); however, for FTS queries, I had to resort to regular SQL statements.

SQLite's FTS5 extension ended up being one of the most valuable pieces of the architecture. It let me query across file names and metadata like artist, album, and title without extra indexing infrastructure.

Setting Up the FTS Tables

Domain	Swift actor / repo	FTS5 table	Columns that get indexed
Library songs	`SQLiteSongRepository`	`songs_fts`	`artist`, `title`, `album`, `albumArtist`
Source-browser paths	`SQLiteSourcePathSearchRepository`	`source_paths_fts`	`fullPath`, `fileName`

I used two FTS5 tables: one for indexed songs (artist/title/album) and one for file paths during folder import. Both tables live next to the primary rows in plain‐old B-tree tables (songs, source_paths). FTS is read-only for the UI; all writes happen inside the repositories so nothing slips through the cracks.

Creating the search index

SQLite's built-in FTS5 makes quick searches easy. Here's a simple table definition I used:

try db.execute("""
CREATE VIRTUAL TABLE IF NOT EXISTS songs_fts USING fts5(
  songId UNINDEXED,
  artist, title, album, albumArtist,
  tokenize='unicode61'
);
""")

I used unicode61 tokenizer to ensure that a wide variety of characters are handled. Non-searchable keys are flagged with UNINDEXED, so they don't bloat the term dictionary.

Updating data reliably

To keep things simple and safe, I wrapped updates and inserts in transactions. This ensures the search index never gets out of sync, even if the app crashes or gets interrupted.

func upsertSong(_ song: Song) async throws {
    db.transaction {
        // insert or update main song data
        // insert or update search index data
    }
}

Querying with Fuzzy Search

For user-friendly search, I add wildcard support automatically. If you type "lumine," it searches for "lumine*" internally, giving instant results even with partial queries.

I also leverage SQLite's built-in smart ranking (bm25) to return more relevant results without extra complexity:

SELECT s.*
FROM songs s JOIN songs_fts fts ON s.id = fts.songId
WHERE songs_fts MATCH ?
ORDER BY bm25(songs_fts)
LIMIT ? OFFSET ?;

Overall, using raw SQLite gave me the flexibility I needed: predictable schema, local-first access, and powerful full-text search, without introducing any network dependencies or external services. This approach was ideal for an app designed to be private and offline-first.

Working with iOS Files and Bookmarks

On iOS, apps can store persistent bookmarks to file locations, but security-scoped bookmarks, which grant extended access to files outside the app's sandbox, are only available on macOS. iOS apps can use regular bookmarks to remember file paths and request access again through the document picker, but that access isn’t guaranteed to persist silently. See Apple's bookmark documentation.

To mitigate this, I implemented a fallback mechanism that copies files into the app's own sandboxed container. This avoids the fragile lifecycle of security-scoped bookmarks that can silently break if iOS resets the permissions. By copying files proactively in the background, while the bookmark is valid, there's no risk in accessing invalid audio-file references.

This approach also improves indexing speed. I can scan the folder structure once (while access is active), import only relevant audio files, and safely traverse deeply nested directories. But reliably playing back individual audio files from external locations, especially after device restarts, remains an unsolved problem to me. This highlights how under-supported this use case is, even for native apps, and how complex it still is to handle file access reliably on iOS.

Building the Playback and UI

Metadata Parsing

To parse metadata from audio files, I used Apple's AVFoundation framework, specifically the AVURLAsset class, which allows inspection of media file metadata, such as title, album artist, etc. While metadata parsing is handled by the native SDK, certain fields like track numbers you have to manually look up from ID3 tags. I relied on GitHub search to find examples, since the official documentation lacked coverage for edge cases.

Audio Playback with AVFoundation

After the library is indexed, implementing an audio player feels pretty simple: you just have to initialize an instance of AVAudioPlayer and let the audio play. Additionally, for quality-of-life features: playing music from the control center, I had to implement the AVAudioPlayerDelegate protocol and also hooked into Apple's MPRemoteCommandCenter, which lets developers respond to system-level playback controls.

Reflections: Apple, Developer Lock-In, and the Future

Here's what stood out during development:

The Bad

Xcode's limitations remain frustrating. Real-time SwiftUI previews are definitely a step forward, but the overall development experience still isn't on par with what Flutter offered five years ago: tight VSCode integration, real-time simulator reloads, and familiar debugging tools.

Lack of editor flexibility. Setting up Language Server Protocol (LSP) support for Swift in Neovim or VSCode requires extra tooling like xcode-build-server, and still doesn't fully match the developer experience of web-first ecosystems.

Some corners of Apple's SDK still live in Objective-C land. Spotlight file search, for instance, is only exposed through NSMetadataQuery, which uses Key-Value Observing (KVO) and string keys, no Swift-friendly wrapper yet. Documentation is often sparse, which steepens the learning curve.

SwiftUI's declarative UI is great, but debugging iCloud interactions still requires manual mocks. SwiftUI previews can't emulate full app behaviors involving iCloud entitlements, so you have to mock cloud interactions manually, a minor annoyance but notable.

The Good

Async/await. Finally, I can write I/O-bound concurrent code like an imperative one with no annoying callbacks. That's a big win, and I greatly appreciate how easy it is to write even sync code into Actors and call it like you do in JavaScript ecosystems.

Plethora of native libs. Yes, you're not limited by open source bindings like in React Native/Flutter ecosystems. Here you have much more freedom in developing something "more serious" than your company/product website replacement (because of poor mobile-first experience). Many Apple's APIs are available with examples, which made it easy to get started.

SwiftUI itself. Yes, the React-style approach to building UIs gives more productivity and space for explorations. It's just great that Apple adopted it.

Summary: Building Should Be Easier

After 1.5 weeks of hacking around, I was able to get the piece of software which exactly satisfies my needs: a local/offline music player that can import audio files from cloud storage.

But developers quickly realize they can't easily deploy apps to their own devices these days and forget about it: apps only run for 7 days without a dev certificate, and after that, you have to rebuild it, unless you paid $99 to Apple to enroll in the development program.

Even after the DMA Act in the EU, sideloading still isn't fully open. EU users can now install apps from third-party marketplaces directly from a developer's site, but only if that developer still enrolled in Apple's $99/year program and agrees to Apple's Alternative Terms. For personal/hobbyist use, this still doesn’t remove the 7-day dev build limitation.

This makes ultimately no sense. An innovative technology company actively puts roadblocks into democratized application development. Even Progressive Web Applications (PWAs) face notable limitations on iOS: even after Apple's 16-18.x updates, iOS PWAs still run inside Safari's sandbox. They get WebGL2 and web-push, but they don't get Web Bluetooth/USB/NFC, Background Sync, or more than ~50MB of guaranteed storage. WebGL runs through Metal shim, so real-world frame-rates often trail native Metal apps; this is good enough for UI, but not for AAA 3D games.

Nowadays, AI has reduced the complexity of modern software development by allowing anyone to tackle unknown technologies by providing all the necessary knowledge in an accessible way. You can clearly see how web development got more interest from non-technical people who have a way to build their ideas without specializing in a plethora of technologies. But when it comes to mobile apps, you just have to play by the artificial rules. Even if you built it yourself, for yourself, Apple still gets the final say before you can run it for more than a week. The same company that once empowered independent developers now imposes tight restrictions that hinder personal app development and distribution. AI has made it easier than ever to build new tools, unless you're building for iOS, where the gate is still locked.

Microservices Are a Tax Your Startup Probably Can’t Afford

Oleg Pustovit — Wed, 07 May 2025 20:59:32 +0000

Why splitting your codebase too early can quietly destroy your team’s velocity — and what to do instead.

In a startup, your survival depends on how quickly you can iterate, ship features, and deliver value to end-users. This is where the foundational architecture of your startup plays a big role; additionally, things like your tech stack and choice of programming language directly affect your team’s velocity. The wrong architecture, especially premature microservices, can substantially hurt productivity and contribute to missed goals in delivering software.

I've had this experience when working on greenfield projects for early-stage startups, where questionable decisions were made in terms of software architecture that led to half-finished services and brittle, over-engineered and broken local setups, and demoralized teams who struggle maintaining unnecessary complexity.

Before diving into specific pitfalls, here’s what you’re actually signing up for when introducing microservices prematurely:

Microservices Early On: What You’re Paying For

Pain Point	Real-World Manifestation	Developer Cost
Deployment Complexity	Orchestrating 5+ services for a single feature	Hours lost per release
Local Dev Fragility	Docker sprawl, broken scripts, platform-specific hacks	Slow onboarding, frequent breakage
CI/CD Duplication	Multiple pipelines with duplicated logic	Extra toil per service
Cross-Service Coupling	"Decoupled" services tightly linked by shared state	Slower changes, coordination tax
Observability Overhead	Distributed tracing, logging, monitoring	Weeks to instrument properly
Test Suite Fragmentation	Tests scattered across services	Brittle tests, low confidence

Let's unpack why microservices often backfire early on, where they genuinely help, and how to structure your startup's systems for speed and survival.

Monoliths Are Not the Enemy

If you're building some SaaS product, even a simple SQL database wrapper eventually may bring a lot of internal complexity in the way your business logic works; additionally, you can get to various integrations and background tasks that let transform one set of data to another.

With time, sometimes unnecessary features, it's inevitable that your app may grow messy. The great thing about monoliths is: they still work. Monoliths, even when messy, keep your team focused on what matters most:

Staying alive
Delivering customer value

The biggest advantage of monoliths is their simplicity in deployment. Generally, such projects are built around existing frameworks — it could be Django for Python, ASP.Net for C#, Nest.js for Node.js apps, etc. When sticking to monolithic architecture, you get the biggest advantage over fancy microservices — a wide support of the open source community and project maintainers who primarily designed those frameworks to work as a single process, monolithic app.

At one real-estate startup where I led the front-end team, and occasionally consulted the backend team on technology choices, we had an interesting evolution of a Laravel-based app. What started as a small dashboard for real-estate agents to manage deals gradually grew into a much larger system.

Over time, it evolved into a feature-rich suite that handled hundreds of gigabytes of documents and integrated with dozens of third-party services. Yet, it remained built on a fairly basic PHP stack running on Apache.

The team leaned heavily on best practices recommended by the Laravel community. That discipline paid off, we were able to scale the application’s capabilities significantly while still meeting the business’s needs and expectations.

Interestingly, we never needed to decouple the system into microservices or adopt more complex infrastructure patterns. We avoided a lot of accidental complexity that way. The simplicity of the architecture gave us leverage. This echoes what others have written — like Basecamp’s take on the “Majestic Monolith”, which lays out why simplicity is a superpower early on.

People often point out that it's hard to make monoliths scalable, but it's bad modularization inside the monolith that may bring such problems.

Takeaway: A well-structured monolith keeps your team focused on shipping, not firefighting.

But Isn’t Microservices “Best Practice”?

A lot of engineers reach for microservices early, thinking they’re “the right way.” And sure — at scale, they can help. But in a startup, that same complexity turns into drag.

Microservices only pay off when you have real scaling bottlenecks, large teams, or independently evolving domains. Before that? You’re paying the price without getting the benefit: duplicated infra, fragile local setups, and slow iteration. For example, Segment eventually reversed their microservice split for this exact reason — too much cost, not enough value.

Takeaway: Microservices are a scaling tool — not a starting template.

Where Microservices Go Wrong (Especially Early On)

In one early-stage team I advised, the decision to split services created more PM-engineering coordination overhead than technical gain. Architecture shaped not just code, but how we planned, estimated, and shipped. That organizational tax is easy to miss — until it’s too late.

Diagram: Coordination overhead grows linearly with services — and exponentially when you add product managers, deadlines, and misaligned timelines.

Here are the most common anti-patterns that creep in early.

1. Arbitrary Service Boundaries

In theory, you often see suggestions on splitting your applications by business logic domain — users service, products service, orders service, and so on. This often borrows from Domain-Driven Design or Clean Architecture concepts — which make sense at scale, but in early-stage products, they can ossify structure prematurely, before the product itself is stable or validated. You end up with:

Shared databases
Cross-service calls for simple workflows
Coupling disguised as "separation"

At one project, I watched a team separating user, authentication, and authorization into separate services, which led to deployment complexity and difficulties in service coordination for any API operation they were building.

In reality, business logic doesn't directly map to service boundaries. Premature separation can make the system more fragile and often times difficult to introduce changes quickly.

Instead, isolate bottlenecks surgically — based on real scaling pain, not theoretical elegance.

When I’ve coached early-stage teams, we’ve sometimes used internal flags or deployment toggles to simulate future service splits — without the immediate operational burden. This gave product and engineering room to explore boundaries organically, before locking in premature infrastructure.

Takeaway: Don’t split by theory — split by actual bottlenecks.

2. Repository and Infrastructure Sprawl

When working on the application, typically a next set of things is important:

Code style consistency (linting)
Testing infrastructure, including integration testing
Local environment configuration
Documentation
CI/CD configuration

When dealing with microservices, you need to multiply those requirements by the number of services. If your project is structured as a monorepo, you can simplify your life by having a central CI/CD configuration (when working with GitHub Actions or GitLab CI). Some teams separate microservices into separate repositories, which makes it way harder to maintain the code consistency and the same set of configurations without extra effort or tools.

For a three-person team, this is brutal. Context switching across repositories and tooling adds up to the development time of every feature that is shipped.

Mitigating issues by using monorepos and a single programming language

There are various ways to mitigate this problem. For early projects, the single most important thing is — keeping your code in a monorepo. This ensures that there's a single version of code that exists on prod, and it's much easier to coordinate code reviews and collaborate for smaller teams.

For Node.js projects, I strongly recommend using a monorepo tool like nx or turborepo. Both:

Simplify CI/CD config across subprojects
Support dependency graph-based build caching
Let you treat internal services as TypeScript libraries (via ES6 imports)

These tools save time otherwise spent writing glue code or reinventing orchestration. That said, they come with real tradeoffs:

Complex dependency trees can grow fast
CI performance tuning is non-trivial
You may need faster tooling (like bun) to keep build times down

To summarize: Tooling like nx or turborepo gives small teams monorepo velocity — if you’re willing to invest in keeping them clean.

When developing go-based microservices, a good idea early in the development is to use a single go workspace with the replace directive in go.mod. Eventually, as the software scales, it's possible to effortlessly separate go modules into separate repositories.

Takeaway: A monorepo with shared infra buys you time, consistency, and sanity.

3. Broken Local Dev = Broken Velocity

If it takes three hours, a custom shell script, and a Docker marathon just to run your app locally, you've already lost velocity.

Early projects often suffer from:

Missing documentation
Obsolete dependencies
OS-specific hacks (hello, Linux-only setups)

In my experience, when I received projects from past development teams, they were often developed for a single operating system. Some devs preferred building on macOS and never bothered supporting their shell scripts on Windows. In my past teams, I had engineers working on Windows machines, and often it required rewriting shell scripts or fully understanding and reverse engineering the process of getting the local environment running. With time, we standardized environment setup across dev OSes to reduce onboarding friction — a small investment that saved hours per new engineer. It was frustrating — but it taught a lasting lesson on how important it is to get the code running on any laptop your new developer may be using.

At another project, a solo dev had created a fragile microservice setup, that the workflow of running Docker containers mounted to a local file system. Of course, you pay a little price for running processes as containers when your computer runs Linux.

But onboarding a new front-end dev with an older Windows laptop turned into a nightmare. They had to spin up ten containers just to view the UI. Everything broke — volumes, networking, container compatibility — and the setup very poorly documented. This created a major friction point during onboarding.

We ended up hacking together a Node.js proxy that mimicked the nginx/Docker configuration without containers. It wasn’t elegant, but it let the dev get unblocked and start contributing.

Takeaway: If your app only runs on one OS, your team’s productivity is one laptop away from disaster.

Tip: Ideally, aim for git clone <repo> && make up to have the project running locally. If it's not possible, then maintaining an up-to-date README file with instructions for Windows/macOS/Linux is a must. Nowadays, there are some programming languages and toolchains that don't work well on Windows (like OCaml), but the modern widely popular stack runs just fine on every widely used operating system; by limiting your local setup to a single operating system, it's often a symptom of under-investment in DX.

4. Technology Mismatch

Beyond architecture, your tech stack also shapes how painful microservices become — not every language shines in a microservice architecture.

Node.js and Python: Great for rapid iteration, but managing build artifacts, dependency versions, and runtime consistency across services gets painful fast.
Go: Compiles to static binaries, fast build times, and low operational overhead. More natural fit when splitting is truly needed.

It's very important to pick the right technical stack early on. If you look for performance, maybe look for the JVM and its ecosystem and ability to deploy artifacts at scale and run them in microservice-based architectures. If you do very fast iterations and prototype quickly without worrying about scaling your deployment infrastructure — you're good with something like Python.

It's quite often for teams to realise that there are big issues with their choice of technology that wasn't apparent initially, and they had to pay the price of rebuilding the back-end in a different programming language (like those guys were forced to do something about legacy Python 2 codebase and migrated to Go).

But on the contrary, if you really need to, you can bridge multiple programming languages with protocols like gRPC or async message communication. And it's often the way to go about things. When you get to the point that you want to enrich your feature set with Machine Learning functionality or ETL-based jobs, you would just separately build your ML-based infrastructure in Python, due to its rich ecosystem of domain-specific libraries, that naturally any other programming language lacks. But such decisions should be made when there's enough head count to justify this venture; otherwise, the small team will be eternally drawn into the endless complexity of bridging multiple software stacks together.

Takeaway: Match the tech to your constraints, not your ambition.

5. Hidden Complexity: Communication and Monitoring

Microservices introduce an invisible web of needs:

Service discovery
API versioning
Retries, circuit breakers, fallbacks
Distributed tracing
Centralized logging and alerting

In a monolith, a bug might be a simple stack trace. In a distributed system, it's "why does service A fail when B’s deployment lags C by 30 seconds?"
You would have to thoroughly invest in your observability stack. To do it "properly", it requires instrumenting your applications in specific ways, e.g. integrating OpenTelemetry to support tracing, or relying on your cloud provider's tools like AWS XRay if you go with a complex serverless system. But at this point, you have to completely shift your focus from application code towards building complex monitoring infrastructure that to validate whether your architecture is actually functioning in production.

Of course, some of the observability instrumentation is needed to be performed on monolith apps, but it's way simpler than doing that in terms of the number of services in a consistent way.

Tip: Understand that distributed systems aren't free. They're a commitment to a whole new class of engineering challenges.

When Microservices Do Make Sense

Despite the mentioned difficulties with microservices, there are times where service-level decoupling actually is very beneficial. There are cases where it definitely helps:

Workload Isolation: a common example for that would be in AWS best practices on using S3 event notifications — when an image gets loaded to S3, trigger an image resizing/OCR process, etc. Why it is useful: we can decouple obscure data processing libraries in a self-isolated service and make it API focused solely on image processing and generating output from the uploaded data. Your upstream clients that upload data to S3 aren't coupled with this service, and there's less overhead in instrumenting such a service because of its relative simplicity.
Divergent Scalability Needs: — Imagine you are building an AI product. One part of the system (web API) that triggers ML workloads and shows past results isn't resource intensive, it's lightweight, because it interacts mostly with the database. On the contrary, ML model runs on GPUs is actually heavy to run and requires special machines with GPU support with additional configuration. By splitting these parts of the application into separate services running on different machines, you can scale them independently.
Different Runtime Requirements: — Let’s say you've got some legacy part of code written in C++. You have 2 choices — magically convert it to your core programming language or find ways to integrate it with a codebase. Depending on the complexity of that legacy app, you would have to write glue code, implementing additional networking/protocols to establish interactions with that service, but the bottom line is — you will likely have to separate this app as a separate service due to runtime incompatibilities. I would say even more, you could write your main app in C++ as well, but because of different compiler configurations and library dependencies, you wouldn't be able to easily compile things together as a single binary.

Large-scale engineering orgs have wrestled with similar challenges. For instance, Uber's engineering team documented their shift to a domain-oriented microservice architecture — not out of theoretical purity, but in response to real complexity across teams and scaling boundaries. Their post is a good example of how microservices can work when you have the organizational maturity and operational overhead to support them.

At one project, that also happens to be a real-estate one, we had code from a previous team that runs Python-based analytics workloads that loads data into MS-SQL db, we found that it would be a waste to build on top of it a Django app. The code had different runtime dependencies and was pretty self-isolated, so we kept it separate and only revisited it when something wasn't working as expected. This worked for us even for a small team, because this analytics generation service was a part that required rare changes or maintenance.

Takeaway: Use microservices when workloads diverge — not just because they sound clean.

Practical Guidance for Startups

If you're shipping your first product, here's the playbook I'd recommend:

Start monolithic. Pick a common framework and focus on getting the features done. All known frameworks are more than good enough to build some API or website and serve the users. Don't follow the hype, stick to the boring way of doing things; you can thank yourself later.
Single repo. Don't bother splitting your code into multiple repositories. I’ve worked with founders who wanted to separate repos to reduce the risk of contractors copying IP — a valid concern. But in practice, it added more friction than security: slower builds, fragmented CI/CD, and poor visibility across teams. The marginal IP protection wasn’t worth the operational drag, especially when proper access controls inside a monorepo were easier to manage. For early-stage teams, clarity and speed tend to matter more than theoretical security gains.
Dead-simple local setup. Make make up work. If it takes more, be very specific on the steps, record a video/Loom, and add screenshots. If your code is going to be run by an intern or junior dev, they'll likely hit a roadblock, and you’ll spend time explaining how to troubleshoot an issue. I found that documenting every possible issue for every operating system eliminates time spent clarifying why certain things in a local setup didn't work.
Invest early in CI/CD. Even if it's a simple HTML that you could just scp to a server manually, you could automate this and rely on source control with CI/CD to do it. When the setup is properly automated, you just forget about your continuous integration infrastructure and focus on features. I've seen many teams and founders when working with outsourced teams often be cheap on CI/CD, and that results in the team being demoralized and annoyed by manual deployment processes.
Split surgically. Only split when it clearly solves a painful bottleneck. Otherwise, invest in modularity and tests inside the monolith — it’s faster and easier to maintain.

And above all: optimize for developer velocity.

Velocity is your startup’s oxygen. Premature microservices leak that oxygen slowly — until one day, you can't breathe.

Takeaway: Start simple, stay pragmatic, and split only when you must.

If you go with a microservice-based approach

I had micro-service-based projects created earlier than they should have been done, and here are the next recommendations that I could give on that:

Evaluate your technical stack that powers your micro-service-based architecture. Invest in developer experience tooling. When you have service-based separation, you now need to think about automating your microservice stack, automating config across both local and production environments. In certain projects, I had to build a separate CLI that does administrative tasks on the monorepository. One project I had contained 15-20 microservice deployments, and for the local environment, I had to create a cli-tool for generating docker-compose.yml files dynamically to achieve seamless one-command start-up for the regular developer.
Focus on reliable communication protocols around service communication. If it's async messaging, make sure your message schemas are consistent and standardized. If it's REST, focus on OpenAPI documentation. Inter-service communication clients must implement many things that don't come out-of-the-box: retries with exponential backoff, timeouts. A typical bare-bones gRPC client requires you to manually factor those additional things to make sure you don't suffer from transient errors.
Ensure that your unit, integration testing, and end-to-end testing setup is stable and scales with the amount of service-level separations you introduce into your codebase.
On smaller projects that use micro-service-based workloads, you would likely default to a shared library with common helpers for instrumenting your observability, communication code in a consistent way. An important consideration here — keep your shared library as small as possible. Any major change forces a rebuild across all dependent services — even if unrelated.
Look into observability earlier on. Add structured-JSON logs and create various correlation IDs for debugging things once your app is deployed. Even basic helpers that output rich logging information (until you instrumented your app with proper logging/tracing facilities) often save time figuring out flaky user flows.

To summarize: if you're still going for microservices, you should beforehand understand the tax you're going to pay in terms of additional development time and maintenance to make the setup workable for every engineer in your team.

Takeaway: If you embrace complexity, invest fully in making it manageable.

Conclusion

Premature microservices are a tax you can’t afford. Stay simple. Stay alive. Split only when the pain makes it obvious.

Survive first. Scale later. Choose the simplest system that works — and earn every layer of complexity you add.

Related resources

Monolith First — Martin Fowler
The Majestic Monolith — DHH / Basecamp
Goodbye Microservices: From 100s of problem children to 1 superstar — Segment Eng.
Deconstructing the Monolith — Shopify Eng.
Domain‑Oriented Microservice Architecture — Uber Eng.
Go + Services = One Goliath Project — Khan Academy

How to Set Up a Free Oracle Cloud VM for Web Development (2025 Guide)

Oleg Pustovit — Mon, 28 Apr 2025 08:26:32 +0000

As a web developer, having access to a persistent, virtual machine in the cloud is often useful for testing and development. While many cloud-based providers offer limited free tiers (e.g. AWS, GCP, or Azure), Oracle Cloud stands out by providing a true "always free" cloud VM.

In this article, we'll look into setting up Oracle VM (under their always free tier). There are multiple advantages to using it instead of limited free offerings from services like AWS.

It's always free without 1-year limits on usage (as of April 2025). However, Oracle may always change their policies around free virtual machines they provide, so it's a good idea to check if nothing has changed with free accounts.
The specs are very generous. You receive a 4 vCPU VM with 24 GB RAM and 200GB of storage. This makes it a compelling choice for a remote development workstation. The only catch? It runs on ARM. But considering that consumer desktops widely adopted ARM processor architectures in recent years, it’s hardly a dealbreaker.

Registering OCI account (and giving them your credit card)

Start by heading to the Oracle Cloud website and clicking “Sign Up.” In the account information section, enter your name, email, and country.

After email verification, you'll enter your password and set up "Home Region".

It's important to specify the region that supports Ampere ARM instances (there are ones that don't). I used France Central (Paris) for proximity (to have lower latency) and ARM support.

The next step would be verifying your identity by providing a payment method — enter your credit card information. You won't be charged; this is solely for identity verification. Make sure the resources you create in your Oracle Cloud account stay always within "Always Free" limits.

Setting up an instance

Once the account setup is complete, go to Instances in your Oracle Cloud portal and click "Create Instance". Choose a placement that supports Ampere (ARM) processors — otherwise, the Free Tier shapes won’t appear.

Selecting an operating system and instance shape

The next step would be selecting an operating system your VM will run on. Ubuntu is a safe bet for general-purpose development, but Oracle Linux works best with Oracle's ecosystem and general server workloads.

Below, choose your instance shape. This is where you specify your instance type, number of OCPUs, and RAM. The Free tier allows up to 4 OCPUs and 24 GB RAM (as of April 2025), so be sure to pick a shape that fits within those limits.

Optionally, you may provide an initialization script. This is similar to "User Data" in AWS EC2 instances (if you're familiar with those). Since this is the only instance that is going to be created for experimentation, you can always initialize and configure the instance manually.

Press "Next" once everything is configured, and the next step "Security" will be selected. You can freely press next and go to the Networking setup.

Networking setup and SSH

For simplicity’s sake, use the default virtual network interface card (VNIC). Next, configure SSH access by uploading your public key (.pub). This enables secure remote login to your VM.

The next step is to configure your storage. Oracle includes 200GB in the free tier. To avoid potential issues later, set a custom boot volume size to 200GB.

Finally, review all the settings and create the instance.

Operating newly created instance

The instance is created and you can see it in your list in the Cloud Portal. Once the instance shows a "Running", it's ready to use and it's possible to connect to it. Locate its public IP address and connect via SSH:

ssh <user>@<server IP>

Exposing additional ports

By default, ports 80 (HTTP) and 443 (HTTPS) are blocked, which prevents public access to web applications. There are 2 things that are necessary to perform to make sure there’s connectivity through additional ports (besides SSH):

Updating ingress rules in the security list of the Virtual Cloud Network (VCN).
Allow instance iptables rules that may be configured by default.

Updating ingress rules

Go to virtual cloud networks in your Oracle Cloud portal, select the default VCN that is used by the newly created instance. Then navigate to the Subnets tab and select the default created subnet. Click on the Security tab and navigate to the default security list that is created for that subnet. There it's necessary to open the "Security rules" tab and that's where it's possible to add new ingress rules. Let's create one for allowing incoming HTTPS traffic:

Once it's saved, you can test your connection by running a simple web app or simply by connecting with utilities like netcat (nc) or telnet:

nc -zv <IP address>443
# or
telnet <IP address>443

If it connects, then you're good; otherwise, let's look into iptables configuration.

Configuring `iptables`

In case the instance still blocks traffic (even after opening access to ports through Oracle VCN security list), it's necessary to look into internal firewall settings. This is where iptables comes in.

On Ubuntu, optionally it's possible to configure the firewall through ufw (Uncomplicated firewall), which works as a simplified interface for managing iptables rules. Without prior configuration, an instance may come with a pre-configured default restrictive rule set.

First, check if iptables is actively filtering traffic:

sudo iptables -L

If you don't see ACCEPT rules for port 443, you need to manually add it:

# Allow incoming traffic on port 443
sudo iptables -A INPUT -p tcp --dport443 -j ACCEPT
# Optionally, allow HTTP
sudo iptables -A INPUT -p tcp --dport80 -j ACCEPT
# Allow established connections (if not already allowed)
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow loopback interface (optional but recommended)
sudo iptables -A INPUT -i lo -j ACCEPT

Enter the following command to persist the rules:

sudo apt install iptables-persistent
sudo netfilter-persistent save

Alternatively, you can use ufw with an equivalent set of terminal commands:

sudo ufw allow 443/tcp
sudo ufw allow 80/tcp
sudo ufw enable

What it’s like using a free VM as your dev playground

I've been using this VM for nearly a year for development and running test web applications. I've accessed it from an iPad using Blink (with Neovim), and from a desktop via VSCode's Remote SSH extension. To make whole user experience smoother, I set up a Mosh server — this offers persistent terminal sessions even over unstable connections.

The biggest upside in this setup is that the same terminal is available from any machine (given the fact that there are credentials). Oracle's free VM is a solid playground for deployment tests, CLI experimentation and even lightweight app hosting.

Releated resources:

Deploying a Hugo Blog to GitHub Pages with Actions

Oleg Pustovit — Thu, 10 Apr 2025 14:58:04 +0000

After years of building software and writing technical documentation, I decided to create a blog to share my experience and help others on similar journeys. This article walks through how I set up my technical blog, aimed at those new to blogging or Hugo.

Choosing the platform

For me, it's important to have as minimal a solution as possible. While building my own Markdown-to-HTML publishing script is an idea for the future, my immediate priority was to get the blog online quickly.

Nowadays, I don't think there's a difficulty in creating a personal website. There is a wide variety of options that aid in this endeavor. I'll start with listing alternatives that come to my mind:

CMS (e.g. Wordpress, WordPress, Content Hub, Joomla, etc.): While platforms like WordPress are powerful, they felt excessive for a static content blog. I wanted something lightweight and flexible without being bound to a dynamic CMS stack.
Jekyll: This software looks to be perfect and widely used by other developers to host blogs, but due to my lack of experience with Ruby, I chose not to use this.
Hugo. Hugo is written in Go and uses the familiar syntax of Go templates (if you happen to code a lot in Go), while rendering pages in Markdown (similarly to Jekyll).
11ty, Astro, Hexo, and other Node.js-based alternatives. It's a matter of preference, but personally, I decided to minimize the usage of Node.js tooling. While there are many powerful tools, the Node.js ecosystem is notorious for rapidly changing, that often led me to not being able to run the old projects that naturally had many old dependencies.

Setting up Hugo

I chose Hugo as my blogging platform. Having produced a substantial amount of documentation on my past software-related projects, I feel very confident using Markdown and a terminal-based text editor for my writing.

Using a GitHub repository

Previously, I had already created a GitHub Pages website with placeholder files and connected a domain to it, so to populate files in an existing repo, you need to enter the following command:

hugo new site . --force

This will populate the current repository directory with files that are necessary to run the Hugo website. After that, it was necessary to set up the theme and other parameters in the hugo.toml file, and the site can run. After everything is set, it's possible to run the server by typing the command: hugo server

Running server in development mode

At this point, the website is available from localhost. Since I develop on a remote cloud VM, accessing the local Hugo server via localhost wasn't possible. It was necessary to safely expose the localhost instance to the outside world - for such needs, a reverse proxy is used.

While load balancers and reverse proxies like Nginx are quite common and popular, I chose Caddy to serve my dev website because it sets up SSL certificates (via Let’s Encrypt) with no effort. Configuring Caddy is done with Caddyfile, where for the domain of interest you write a reverse_proxy statement with the necessary port:

test-blog-domain.com {
    reverse_proxy localhost:1313
}

After starting caddy with the configuration above, the development website will be available from https://test-blog-domain.com (given that an A DNS record for test-blog-domain.com is filled with a public IP address of the VM).

Adding a theme

Hugo has a number of free themes that are publicly available on GitHub. What is necessary to do to install one is to clone a repository with a theme and then update the theme parameter in hugo.toml. I chose a theme called cactus. After installation, I've got a build error complaining that Google Analytics async template is not found:

Error: error building site: render: failed to render pages: render of "/" failed: "/home/user/projects/nexo-tech.github.io/themes/cactus/layouts/_default/baseof.html:3:3": execute of template failed: template: index.html:3:3: executing "index.html" at <partial "head.html" .>: error calling partial: execute of template failed: html/template:partials/head.html:47:16: no such template "_internal/google_analytics_async.html"
make: *** [Makefile:2: up] Error

A fix for such an issue could be found on github. The Hugo community is active, and many issues — including this Google Analytics error — have existing patches or discussions on GitHub.

After fixing other deprecation warnings, the site started working:

Deploying a website to CDN: GitHub Pages

There are numerous ways to deploy a static website, and in most cases, it's required to have a hosting or server. Usually, those are not free or have a restricted plan; nevertheless, there are exceptions to this, like GitHub Pages. It's possible to serve a static content from a particular branch of a GitHub repository or use pre-built GitHub actions that are based on creating build artifacts and deploying them in a custom way. Knowing that, personal GitHub accounts are very limited on storage artifact space, and it's tedious to manage that storage space, I opted for the simpler solution where static website assets will be updated in a pre-defined git branch (gh-pages). Luckily, there are actions specifically for Hugo exactly for this purpose:

actions-hugo by Shohei Ueda. A simple way to set up Hugo in a GitHub actions environment
actions-gh-pages Also by Shohei Ueda, this action pushes static assets to the specified branch.

Here's the code of a GitHub Actions workflow that will deploy Hugo to gh-pages. Note that if there's a need for a custom domain, a CNAME file needs to be copied to the public directory before running the gh-pages action. Furthermore, workflow permissions of your repository must be set to "Read and write" (could be found in Settings > Actions > General).

name: Build and Deploy Hugo
on:
  push:
    branches:
      - main  
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repo
        uses: actions/checkout@v3
      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: 'latest'
          extended: true
      - name: Build site
        run: hugo --minify
      - name: Add CNAME file
        run: cp CNAME public/CNAME
      - name: Deploy to GitHub Pages
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./public
          publish_branch: gh-pages

Once the deployment passes, the site should be uploaded to GitHub CDN. Be sure to set up GitHub Pages to the branch that contains built artifacts in case the website doesn't work.

With Hugo set up and deployed, I can now focus on what matters — sharing technical insights from my experience. I hope this guide helps others looking to build a simple and reliable blog for their work.

DEV Community: Oleg Pustovit

AWS Serverless: Still the Boring Correct Choice

The Hype Died, but did Serverless?

When NOT to use Serverless

The Stack

Presentation Layer

Compute

Background processing

Persistence

Observability

How to be successful with AWS serverless

Pick your IaC tool carefully

Why not Vercel or Cloudflare?

Vercel with Next.js

Cloudflare Workers

Firebase

Why I default to AWS

How to get started with it in 2026

References

In 2025, Apple still makes it hard to play your own MP3s, so I wrote my own app

Why I Built My Own Audio Player

What Apple (and Others) Offer Today

Apple's Built-in Apps

Third-Party Apps

Going Builder Mode: My Technical Journey

Trying React Native First

Switching to SwiftUI

App Architecture and Data Model

Three Main Screens

Backend-Like Logic Layer

Implementing Full Text Search with SQLite

Setting Up the FTS Tables

Creating the search index

Updating data reliably

Querying with Fuzzy Search

Working with iOS Files and Bookmarks

Building the Playback and UI

Metadata Parsing

Audio Playback with AVFoundation

Reflections: Apple, Developer Lock-In, and the Future

The Bad

The Good

Summary: Building Should Be Easier

Related Links

Microservices Are a Tax Your Startup Probably Can’t Afford

Monoliths Are Not the Enemy

But Isn’t Microservices “Best Practice”?

Where Microservices Go Wrong (Especially Early On)

1. Arbitrary Service Boundaries

2. Repository and Infrastructure Sprawl

Mitigating issues by using monorepos and a single programming language

3. Broken Local Dev = Broken Velocity

4. Technology Mismatch

5. Hidden Complexity: Communication and Monitoring

When Microservices Do Make Sense

Practical Guidance for Startups

If you go with a microservice-based approach

Conclusion

Related resources

How to Set Up a Free Oracle Cloud VM for Web Development (2025 Guide)

Registering OCI account (and giving them your credit card)

Setting up an instance

Selecting an operating system and instance shape

Networking setup and SSH

Operating newly created instance

Exposing additional ports

Updating ingress rules

Configuring iptables

What it’s like using a free VM as your dev playground

Releated resources:

Deploying a Hugo Blog to GitHub Pages with Actions

Choosing the platform

Setting up Hugo

Using a GitHub repository

Running server in development mode

Adding a theme

Deploying a website to CDN: GitHub Pages

Related resources

Configuring `iptables`