Forem: Rob Myers

Microservices are Dead! Long Live Microservices

Rob Myers — Fri, 29 Aug 2025 11:58:27 +0000

The original article was published at: Build Microservices in Go - Microservices are Dead! Long Live Microservices

If you’ve scrolled through tech Twitter/X or reddit lately, you’ve probably seen people declaring:

Microservices were a mistake!
Microservices are dead!
Microservices are a scam!

but thats just a catchy ragebait lol

But here’s the truth: microservices are not dead. They’re very much alive, running inside almost every major tech company you use daily.

So why do people keep writing eulogies for them? And as a junior developer, should you even bother learning microservices?

Are Microservices Really Dead? (Ignore the Clickbait)

The “microservices are dead” claim usually comes from frustration. Teams move from a simple monolith to dozens of microservices, and suddenly their infrastructure feels like it’s held together with duct tape and YAML files.

They built systems that were overly complex, difficult to debug, and harder to maintain than a well-structured monolith would have been. When these projects inevitably became nightmares to work with, then frustration comes out.

Just because some people got food poisoning from poorly prepared sushi doesn't mean raw fish is inherently dangerous. It means you need to know what you're doing and choose the right context for your approach.

But that doesn’t mean microservices are obsolete. It means they are misused.

The Unpopular Truth: Most of the Industry Runs on Microservices

Here’s the reality:

Netflix, Amazon, Uber, and Spotify still rely heavily on microservices.
Kubernetes, Docker, and gRPC weren’t built for monoliths — they were built for distributed systems.
Most “microservices are dead” articles end up suggesting… modular monoliths. Which, ironically, is just a step on the journey toward microservices.

When you order food through DoorDash, you're interacting with dozens of different services.

User authentication service,
payment processing service,
restaurant management service,
delivery tracking service,
notification service

All work together seamlessly. Each service can be developed, deployed, and scaled independently by different teams.

This isn't because these companies enjoy complexity for its own sake. It's because microservices solve real problems that emerge at scale:

Team autonomy: Different teams can work on different services without stepping on each other's toes
T*echnology diversity*: Your payment service might be written in Java for its robust ecosystem, while your real-time tracking service uses Go for its excellent concurrency primitives
Independent scaling: You can scale your order processing service during dinner rush without scaling your user profile service
Fault isolation: If the recommendation service goes down, users can still place orders

Understanding the Evolution of Microservices

In the early days of web applications, most companies started with monoliths because they made sense. Small teams, simple requirements, and limited traffic meant that a single, well-organised application was often the right choice.

To appreciate microservices, you need to see the bigger picture of software architecture:

Monoliths – The classic “everything in one codebase.” Great for speed when you’re small.
Service-Oriented Architecture (SOA) – Larger systems are split into services, often with heavier protocols like SOAP.
Microservices – SOA’s younger, leaner cousin. Services are smaller, communicate over HTTP/gRPC, and are independently deployable.

Think of it like city planning:

A monolith is a single skyscraper with everything inside.
A modular monolith is a skyscraper with floors clearly divided for different tenants.
Microservices are like a neighborhood of buildings — each one specialized, independent, and connected by roads.

Common Use Cases for Microservices

Microservices shine when you’re dealing with large, complex systems where different parts of the business have very different scaling and reliability needs. Instead of one massive codebase, companies break down functionality into smaller, specialized services that can evolve independently.

How about a real-life example: yeah, you guessed it: Netflix.

Netflix is often the poster child for microservices. When you hit play on a movie, you’re not talking to one giant app. Instead, you’re hitting dozens of microservices working together:

A recommendation service that suggests what to watch next.
The streaming service that delivers video at the right quality for your connection.
And the billing service that makes sure your subscription is up to date.

Those are just a few of the services they run. The real architecture is much more complex than this.

By splitting these responsibilities, Netflix can update its recommendation algorithms without risking outages in video playback. Each part scales independently — streaming traffic during peak hours won’t overload billing.

As you see, microservices aren’t just a “tech trend.” They’re how modern enterprises like Netflix, Amazon, and Uber keep systems reliable, scalable, and resilient in the face of millions of requests per second.

When You Shouldn’t Use Microservices

Here’s the truth that rarely makes it into conference talks: most teams don’t need microservices.

Surprising take from someone who has a microservices course? It can be if I were trying to push you to use microservices for everything, but that's not the case.

Microservices are powerful, but they also come with heavy costs — deployments, networking, observability, and debugging across services. If you introduce them too early, you’ll spend more time managing infrastructure than building features.

There are plenty of situations where a modular monolith is usually the smarter choice:

Solo founders and early-stage startups

I once spent two weeks setting up a “proper” microservices architecture for a side project… that never got a single paying user. I would have been better off with a simple monolith and a Stripe button.

Lesson learned: Don't be one of those startups that build “enterprise-grade” architecture before having a single paying customer — and collapse under the weight of their own complexity.

Small Engineering Teams

A company with fewer than 10 engineers rarely needs microservices. Why? The complexity will slow you down. A cleanly structured monolith can support years of growth before you hit real scaling limits.

Don’t treat microservices as a badge of “serious engineering.” Treat them as a tool — one you reach for only when your monolith truly starts holding you back. Until then, keep it simple.

Why Learning About Microservices is Important for Developers

If you’re aiming for a serious career in tech, understanding microservices is no longer optional — it’s a core skill that will set you apart in the job market.

When I started interviewing for senior roles, I noticed a pattern: nobody asked if I could build a CRUD app. They asked: “How would you handle failures between services?” or “How would you design payments to be reliable?” Understanding microservices thinking gave me an edge.

I built my course because I couldn’t find anything that resembled what I saw in production environments. Most tutorials stop at “hello world” — I wanted to show how to wire up REST, gRPC, and events into something you’d actually see in a tech company.

Conclusion

Microservices aren’t dead. They’ve simply matured. Just like cloud computing or containerization, they’ve moved past hype and into the “boring but essential” stage.

As a developer, your job isn’t to chase buzzwords.

It’s to understand the trade-offs — when to use microservices, when to avoid them, and how to keep them from becoming a tangled mess.

And don't worry, you'll still see plenty of "microservices are bad" articles and rants, but guess what? They aren't going anywhere.

Golang API Structure for Beginners

Rob Myers — Mon, 11 Aug 2025 12:35:04 +0000

If you are new to Go, or just want to get started with Go, I am sure you have asked yourself this at least once.

How do I structure my go project?

That question brings nightmares to new go devs or ones that have lots of experience with other languages like Java. Go likes to do things its way, so your previous experience is not helpful. Hell, they probably are an antipattern in Go world.

So what do you do? You go online and type "how to structure web app project in go" and then you get 100s of different opinions. The confusion never ends...

Don't worry, my friend, the rescue is here. In this guide, I'll show you a battle-tested Go API structure that combines Clean Architecture principles, Domain-Driven Design, and real-world maintainability.

What's a good project structure?

The key elements of a good project structure are:

Separates core business logic from external concerns (databases, APIs, frameworks).
Groups related features together so you’re not hunting through unrelated folders.
Enforces a logical flow — from incoming HTTP request to business logic to data persistence.

Context switching is expensive. That's why if your services follow the same logical structure, you'll be able to work on any of them and be productive in no time.

Step-by-Step: Beginner-Friendly Golang API Folder Layout

Let’s walk through the layout piece by piece so you know exactly how it works and why it exists.

user-service/
├── cmd/                 # Entry point(s)
├── internal/            # Core application logic
├── infrastructure/      # External systems
├── Makefile             # Simple build/run commands
└── openapi.yaml         # API contract documentation

Looks simple enough, right?

Let's see whats going on here:

cmd/ — Your app’s front door. This is where your HTTP server (or other apps like workers/CLI tools) live.
internal/ - Your private workspace. Anything in here is for this project only.
infrastructure/ - Where external systems (like databases or third-party APIs) live—kept separate so swapping or upgrading is smooth.
Makefile — One command to make run or make test. Way more satisfying than long go commands. openapi.yaml — Your API’s contract. Great for docs, client SDKs, or keeping consistent behavior when working with others.

2. cmd/ – Your Application Entry Points

The cmd/ directory is the front door to your application. Each subfolder here starts an independent instance of your app. The app will share its internal logic, but it'll be accessed in a different way.

This is where you keep entry points—thin layers that:

Load configuration.
Initialize dependencies.
Start a specific type of application (HTTP server, gRPC server, event consumer, cron job, etc.)

cmd/
├── http/               # Main REST/HTTP API
│   └── main.go
├── grpc/               # gRPC API server
│   └── main.go
├── events/             # Event consumer (Kafka, NATS, RabbitMQ)
│   └── main.go
└── worker/             # Background jobs/cron tasks
    └── main.go

You want to keep the entry points as simple as possible, example:

func main() {
    cfg := config.Load()
    deps := dependencies.Init(cfg)
    server := http.NewServer(deps)
    server.Start()
}

Load the config, intitalize dependencies, and start the transport layer, that's it. KISS (Keep It Stupid Simple)

Many new Go developers start with one main.go and then try to fit everything together: HTTP, gRPC, background jobs, and event processing all into the same process. This leads to bloated code and makes scaling harder.

But if you work on a solo project, and crazy scaling is none of your concerns, then that's fine.

infrastructure/ – Where External Worlds Live

If internal/ is your private home, then infrastructure/ is the garage, driveway, and cables connecting you to the outside world.

Here we'll stuff all the code that interacts with external parts of our system. DB, Cache, Event Brokers, External APIs and anything else you can think of.
If you have to call somebody else to handle the job, it goes here.

infrastructure/
├── db/                 # Database layer
│   ├── migrations/     # SQL schema changes
│   ├── models/         # DB-specific structs with tags
│   └── repos/          # Repository implementations
├── cache/              # Caching layer (Redis, Memcached)
│   └── redis.go
├── events/             # Event broker clients (Kafka, NATS, RabbitMQ)
│   ├── publisher.go
│   └── consumer.go
├── externalapi/        # Third-party API integrations
│   └── payment_client.go
└── storage/            # File/object storage (S3, GCS)
    └── s3_client.go

Why do you want to do that?

Isolation from your business logic – Your core modules shouldn’t know if data comes from Postgres or Mongo, Redis or Memcached, Kafka or NATS.
Easy swaps – Change providers or services without rewriting your whole codebase.
Testability – Replace real implementations with in-memory mocks during tests.

internal/ – Where your app lives

It’s the main home for your application logic, and Go’s compiler makes it private, so no one outside your repo can import it.

This is exactly the structure we use in one of the microservices in the Build Microservices in Go course, so you’re looking at a proven, real-world example.

/internal/
  ├───config/
  │   ├───config.go
  │   └───utils.go
  ├───dependencies/
  │   └───dependencies.go
  ├───http/
  │   ├───server.go
  │   └───health/
  │       ├───router.go
  │       └───useCases/
  │           └───healthReady/
  │               └───controller.go
  ├───models/
  │   └───user.go
  └───modules/
      ├───auth/
      │   ├───module.go
      │   └───useCases/
      │       ├───login/
      │       │   ├───controller.go
      │       │   ├───dto.go
      │       │   └───service.go
      │       └───registerUser/
      │           ├───controller.go
      │           ├───dtos.go
      │           ├───events.go
      │           └───service.go
      └───profile/
          ├───module.go
          └───useCases/
              ├───getProfile/
              │   ├───controller.go
              │   ├───dto.go
              │   └───service.go
              └───updateProfile/
                  ├───controller.go
                  ├───dto.go
                  └───service.go

This is an example structure of /internal folder of our user service.

Now, let's break it down, what's inside each folder.

config/ — Centralized Configuration

This is where you define how your app loads environment variables, config files, or any setup parameters.

config.go holds your main config structs and parsing logic.
utils.go might contain helpers for validating config or converting env values.

Having a dedicated config package keeps your settings organized and easy to maintain.

dependencies/ — Dependency Injection Hub

Dependency injection can feel complex at first, but having a single place to wire all your dependencies makes your app easier to manage and test.

dependencies.go is where you create and inject instances for DB connections, external clients, validators, and repositories.
This means your main.go stays clean — it just calls into this package to get a ready-to-go app.

http/ — HTTP Server Setup & Routes

This folder is responsible for setting up your HTTP server and routing incoming requests to the right handlers.

server.go bootstraps the HTTP server, sets up middleware, and starts listening.
The subfolder health/ is a great example of how to organize feature-specific routes (in this case, health check endpoints), including their own router and use cases.

This keeps HTTP concerns separate from your business logic inside modules/.

models/ — Your Domain Models

Here you define your plain Go structs representing core business entities — for example, user.go holds your User model.

These structs don’t know anything about the database or HTTP — they’re just pure representations of data in your domain. This separation makes your code easier to test and refactor.

modules/ — Organize by Business Features

This is where your actual business features live, grouped by domain for clarity and scalability.

Each module (like auth/ or profile/) has its own:

module.go for wiring the module, registering routes, and initializing use cases.
useCases/ folder that contains all the individual workflows related to that feature, each with their own clear separation of concerns:
- controller.go for HTTP request handling.
- dto.go (or dtos.go) for data transfer objects to validate and transfer data.
- service.go for the business logic itself.
- Optionally, events.go for publishing domain events triggered by this use case.
- Or even their own repo if that's necessary.

For example, the auth module’s login use case handles everything related to logging users in — controllers translate HTTP requests, services do the core work, and DTOs handle validation.

Why this structure works so well for beginners and pros alike

Clear boundaries: You always know where to add a new feature or fix a bug.
Scalable: Adding a new domain or use case is as simple as creating a new folder inside modules/.
Testable: Isolate business logic in services and DTOs, separate from HTTP handlers.
Maintainable: Group related code together so your codebase doesn’t turn into a mess.

Ready to build your own scalable, maintainable Go APIs?

This folder structure isn’t just theory — it’s the foundation of real-world microservices I teach in my Build Microservices in Go course. If you want hands-on guidance, step-by-step project, and expert tips on building production-ready APIs and microservices, check it out.

Start structuring your Go projects like a pro and take your skills to the next level today!