Build for Change, Not for Distribution

A lot of architecture discussions eventually become arguments about deployment models.

Monolith or microservices?

One database or many?

Synchronous or event-driven?

PHP or Go?

Containers or serverless?

Those are useful questions.

But I think they often arrive too early.

The Database Is Often the Hardest Part of Service Extraction

When people talk about extracting a service from a monolith, the conversation often focuses on code.

Move the controller.

Move the business logic.

Create an API.

Deploy it separately.

Done.

Except the difficult part is usually not the code.

It is the data.

You can move code in a day. Untangling data ownership can take months.

That is why I think service extraction should begin with the database question much earlier than most teams expect.

Evolve Audit: What Can You Learn About a PHP Application Without Running It?

Before modernizing an old PHP application, there is a question I think we should ask much earlier than:

“Which framework should we migrate to?”

The better first question is:

“What exactly are we dealing with?”

A mature PHP system can contain years of assumptions that are not obvious from looking at a few controllers.

Scalability Starts in the Code Before It Reaches the Infrastructure

When developers talk about scalability, the conversation often jumps quickly to infrastructure.

Load balancers.

More servers.

Redis.

Read replicas.

Kubernetes.

Queues.

CDNs.

Those things matter.

The Hidden Cost of Global State in PHP

Global state is convenient.

That is why it survives.

A static singleton is easy to reach.

A global helper saves a few lines.

A shared container gives you access to almost anything.

Observability Is Not Logging

A lot of systems say they have observability because they have logs.

They do not.

Logs are useful, sometimes essential, but they are only one part of understanding what a system is actually doing.

A system can produce thousands of log lines every minute and still be nearly impossible to diagnose when something goes wrong.

Why Frameworks Should Help You Leave Them

A framework is supposed to help you build faster.

Routing, dependency injection, database access, queues, validation, authentication, caching, testing support—good frameworks remove huge amounts of repetitive work.

But there is another question I think framework design should take seriously:

What happens when the application eventually needs to move beyond the framework?

That might sound strange.

Can a PHP Application Be Designed for 10–20 Years of Change?

Most applications are not designed with a ten-year lifespan in mind.

They are built to solve the immediate problem.

Ship the product.

Get users.

Add features.

Then, somewhere along the way, the application becomes important enough that replacing it is no longer simple.

When Should a Modular Monolith Become Microservices?

A modular monolith can take you surprisingly far.

You can have clear business boundaries, independent modules, explicit contracts, good tests, background workers, queues, caching, horizontal scaling and strong deployment automation without splitting the application into separate services.

So at what point should one of those modules actually become a microservice?

EvolvePHP 2 Reaches Its First Alpha — The Framework Is Becoming Real

This is a milestone I have been looking forward to for a while.

EvolvePHP 2.0.0-alpha.1 is officially out.

Until now, most of what I have written about EvolvePHP has focused on architecture: modular applications, execution isolation, long-running PHP, modernization, Bridge, service lifetimes and designing software for change.

With this release, those ideas are no longer only plans.

There is now a tagged, testable EvolvePHP 2 Alpha.