Å·±¦ÓéÀÖ

“The code that changes together, stays together.”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“Greenspun’s 10th rule states, “Any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp.â€� This has morphed into the newer joke: “Every microservice architecture contains a half-broken reimplementation of Erlang.â€� I think there is a lot of truth to this.”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“Resilience versus Robustness.
Typically when we want to improve a system’s ability to avoid outages, handle failures gracefully when they occur and recover quickly when they happen, we often talk about resilience. (�) Robustness is the ability of a system that is able to react to expected variations, Resilience is having an organisation capable of adapting to things that have not been thought of, which could very well include creating a culture of experimentation through things like chaos engineering.
For example, we are aware a specific machine could die, so we might bring redundancy into our system by load-balancing an instance, that is an example of addressing Robustness. Resiliency is the process of an organisation preparing itself to the fact that it cannot anticipate all potential problems. An important consideration here is that microservices do not necessarily give you robustness for free, rather they open up opportunities to design a system in such a way that it can better tolerate network partitions, service outages, and the like. Just spreading your functionality over multiple separate processed and separate machines does not guarantee improved robustness, quite the contrary, it may just increase your surface area of failure.”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“By breaking our application into individual, independently deployable processes, we open up a host of mechanisms to improve the robustness of our applications. By using microservices, we are able to implement a more robust architecture, because functionality is decomposed, that is, an impact in one area of functionality may not bring down the whole system, we also can focus our time and energy on those parts of the application that most require robustness, ensuring critical parts of our system remain operational.”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“All too often, I see people focus their work in embracing microservices purely on the server side â€� leaving the user interface as a single, monolithic layer. If we want an architecture that makes it easier for us to more rapidly deploy new features, then leaving the UI as a monolithic blob can be a big mistake.”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“It turns out that an organizational structure that worked well for a Swedish music streaming company may not work for an investment bank. In addition, the original paper showed a snapshot of how Spotify worked in 2012 and things have changed since. It turns out not even Spotify uses the Spotify model.”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“Microservice decomposition can cause issues with troubleshooting, tracing flows, latency, referential integrity, cascading failures, and a host of other things. Most of those problems are things you’ll notice only after you hit production.”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“If you create software that is packaged and shipped to customers who then operate it themselves, microservices may well be a bad choice...
The reality is that you cannot expect your customers to have the skills or platforms available to manage microservice architectures. Even if they do, they may not have the same skills or platform that you require.”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“You should be thinking of migrating to a microservice architecture in order to achieve something that you can’t currently achieve with your existing system architecture.”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“cohesion and coupling are concerns regarding modular software, and what is microservice architecture other than modules that communicate via networks and can be independently deployed”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“A monolithic architecture is a choice, and a valid one at that. It may not be the right choice in all circum stances, any more than microservices are—but it’s a choice nonetheless.”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“I urge people not to worry about size. When you are first starting out, it’s much more important that you focus on two key things. First, how many microservices can you handle? â€� Second, how do you define microservice boundaries to get the most out of them, without everything becoming a horribly coupled mess?”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“Making a change across a process boundary is expensive. If you need to make a change to two services to roll out a feature, and orchestrate the deployment of these two changes, that takes more work than making the same change inside a single service (or, for that matter, a monolith).”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“Importance of Incremental Migration If you do a big-bang rewrite, the only thing you’re guaranteed of is a big bang.”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith

“As developers, we often react badly when we see duplication. We worry about the extra cost of managing duplicate copies of information, and are even more concerned if this data diverges. But sometimes duplication is the lesser of two evils. Accepting some duplication in data may be a sensible trade-off if it means we avoid introducing coupling.”
― Sam Newman, Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith