Of  Microservices  And  Monoliths

Stefan Priebsch, The PHP Consulting Company

Consultant

Consultant

Coach

Consultant

Coach

Author

Consultant

Coach

Author

University Lecturer

Consultant

Coach

Author

University Lecturer

Scalability Expert

Working on "Event Sourcing Explained"

Visit https://event-sourcing-explained.com/

Monolith = Antipattern?

In most cases, monoliths are the status quo.

The Distributed Monolith

The Distributed Monolith

Does a change to one microservice require changes to or deployments of other microservices?

Are your microservices overly chatty?

Do several microservices share a datastore?

Do my services scale dynamically?

https://blog.newrelic.com/engineering/distributed-monolith-vs-microservices/

The Distributed Monolith

Implementing one business feature requires touching multiple microservices

~ 30 Mio lines of PHP code

Interesting performance problems

HipHop: Cross-compile PHP to C++

50% less CPU

1.5 GB binaries

Deployment?

Local testing?

Compiler in production, interpreter in development

HHVM: JIT compiler for PHP

— Adam Bien, "Enterprise Architekturen"

⟫ ⟪Every architecture's number one enemy is the compiler.

Compile into monolith?

Single process vs. network latency

Deployment?

Scripting languages

Deploy source code into production

Load code dynamically

Request/Response

Static object graph

Short lifetime

External state

Serverless?

Boundaries

Boundaries

Decomposition

Boundaries

Decomposition

Coupling

Tight coupling starts in the business

Quote

Order

Invoice

Order::fromQuote(...)

Invoice::fromOrder(...)

Decouple

Abstract

...

$twitter= new TwitterAPIExchange($settings);

...

$twitter->buildOauth($url, $requestMethod) ->setPostfields($postfields) ->performRequest();

Still very technical!

Domain view?

$twitter->tweet(...);

$microblog->publishMessage(...);

"Abstractions should not depend upon details"

$remoteService->authenticate($credentials);$remoteService->sendRequest(...);

...

public function publish($message){ $this->microblog->authenticate(...); $this->microblog->sendRequest(...);}

...

— John V. Guttag

⟫

⟪

The essence of abstractions is preserving information that isrelevant in a given context, and forgetting information that is

irrelevant in that context.

Details:

API requires authentication

Resources have URLs

...

REST is an implementation detail

of the client-server communication

Why REST?

public function publishMessage($message){ ... $this->authenticate(...); $this->sendPostRequest(...); ...}

public function publishMessage($message){ ... $this->sendJsonRpc(...); ...}

public function publishMessage($message){ ... $this->sendXmlRpc(...); ...}

public function publishMessage($message){ ... $this->sendSoapRequest(...); ...}

Integrate client and server in one process?

Develop distributed, deploy monolithic

Facade API

The API is an interface (as in class implements interface)

Facade API

Tell to do something

Ask a question

Facade API

Send a command (e.g. "publish message")

Run a query (e.g. "show list of friends")

CQRS

CQRS

Use a REST API for queries

Use an RPC-style API for commands

Separate side e�ects

Separate side e�ects

Record the decision to publish a message. Deal with the side e�ects later.

Need-to-know principle

Push Model

More async, less sync

No temporal coupling

Vertical vs. horizontal separation

Self-contained systems

Self-contained systems

Each SCS is an autonomous web application.

Each SCS is owned by one team.

Communication with other SCSs or 3rd party systems is asynchronous wherever possible.

An SCS can have an optional service API.

Each SCS must include data and logic.

An SCS should make its features usable to end-users by its own UI.

To avoid tight coupling an SCS should share no business code with other SCSs.

Shared infrastructure should be reduced to increase availability and decrease coupling.

Slides: https://talks.thephp.cc

https://thephp.cc stefan@thephp.cc @spriebsch