Цитаты из книги Building Microservices: Designing Fine-Grained Systems

I have seen some people put all their eggs in one basket, relying on the gateway to handle every step for them. And we all know what happens when we have a single point of failure…

The easiest way you can mess updata encryption is to try to implement your own encryption algorithms, or even try to implement someone else’s.

When operating in a zero-trust environment, you have to assume that you are operating in an environment that has already been compromised—the computers you are talking to could have been compromised, the inbound connections could be from hostile parties, the data you are writing could be read by bad people. Paranoid? Yes! Welcome to zero trust.

We all make mistakes, and computers can let us make mistakes faster and at larger scale than ever before. Given that mistakes are unavoidable (and trust me, they are), then it makes sense to do things that allow us to limit the impact of these mistakes.

No matter how it looks at first, it’s always a people problem. —Gerry Weinberg, The Second Law of Consulting

You won’t truly appreciate the potential pain, suffering, and anguish caused by a microservice architecture until you have it running in production and serving real traffic.

Before you do anything else to build out your microservice architecture, get a log aggregation tool up and running. Consider it a prerequisite for building a microservice architecture. You’ll thank me later.

In the world of the single-process monolithic application, we at least have a very obvious place to start our investigations. Website slow? It’s the monolith. Website giving odd errors? It’s the monolith. CPU at 100%? Monolith. A burning smell? Well, you get the idea.

We replaced our monolith with micro services so that every outage could be more like a murder mystery

If it ain’t broke, don’t fix it.

In short, avoid content coupling.

Arguably, with microservices we have made a decision to prioritize high cohesion of business functionality over high cohesion of technical functionality.

There are only two hard things in Computer Science: cache invalidation and naming things.

So you can see Kubernetes as a generous contribution from Google to the wider IT industry, or as an attempt by Google to remain relevant in the fast-moving public cloud space. I have no problem seeing both things as equally true.

As we’ll discuss more in Chapter 16, don’t let the fear of lock-in keep you trapped in a mess of your own making.

If logic has a place where it can be centralized, it will become centralized!

I’ve met multiple people for whom the term monolith is synonymous with legacy. This is a problem. A monolithic architecture is a choice, and a valid one at that.

I am a strong believer that great software comes from great people. If you worry only about the technology side of the equation, you’re missing way more than half the picture.

Caching adds complexity, and we want to add as little complexity as possible. The ideal number of places to cache is zero.

2PC can be a quick way to inject huge amounts of latency into your system, especially if the scope of locking is large, or if the duration of the transaction is large.