Lecture 5 Notes - Randy Shout Conference Presentation

Overview

Lecture 5 of Enterprise Computing focuses on a conference presentation by Randy Shout, emphasizing the importance of starting with a monolith architecture before transitioning to microservices. Shout's presentation provides valuable insights from industry experts at companies like eBay, Google, Stitch Fix, and WeWork.

Introduction to Randy Shout's Presentation

Randy Shout is an experienced developer who has worked at eBay, Google, Stitch Fix, and WeWork.
Shout's talk emphasizes that there is no one perfect architecture for all scales, phases of evolution, and problem domains.
Startups often seek advice from experts on how large companies like Google and eBay operate, but Shout advises against implementing those strategies immediately.
The architecture suitable for a five-person company differs significantly from that of a 50,000-person company.

eBay's Architecture Evolution

eBay始于一个周末项目，创始人利用 Labor Day 周末构建了第一个 eBay 版本，使用 Pearl 语言编写，每个商品都是一个文件。
eBay's second iteration (V2) was a monolithic C++ DLL that plugged into Microsoft Internet Information Server.
The V2 monolith grew to 3,400,000 lines of code.
Developers were hitting compiler limits on the number of methods per class (16,000 methods).
The next iteration (V3) broke the monolith into Java mini applications, with separate applications for search, selling, and buying, all aggregating data from shared databases.
Modern iterations of eBay's architecture use microservices, with Java, Spring, and Spring Boot.

Amazon's Architecture Evolution

Amazon started in 1995 with a monolith called Obidos, a Pearl and Mason front end over a C language back end.
The application was 4 gigabytes in size, leading to memory swapping issues.
Amazon was restarting the service every 100 to 200 requests due to memory leaks.
Releases occurred only once a quarter.
From 2001 to 2005, Amazon migrated to services (microservices), using languages like C++ and Java.
Jeff Bezos mandated no shared databases.
After the service migration, AWS launched, marking Amazon's expansion in online retail.

Key Takeaways from Amazon and eBay

Both companies started with monoliths.
No one starts with microservices, but past a certain scale, everyone ends up with microservices.
Most companies never reach the scale where microservices are necessary.
If early technology decisions are not regretted, it indicates over-engineering.
Starting with microservices can lead to building a distributed system that customers don't care about, causing the company to miss the market.

Phases of Products and Companies

Idea Phase

The primary question to ask is: "What problem are we trying to solve?"
It's crucial to determine if someone is willing to pay for the solution and if there's a product-market fit.
Building the wrong thing is the biggest waste in software development, as emphasized by Mary and Tom Popovic in Lean Software Development and in The Lean Startup.
A problem well-stated is a problem half-solved (Charles Kettering, head of research at GM).
Everything is a prototype in this phase.
The goal is to explore the potential problem space rapidly and cheaply.
The focus is on finding a business model, product-market fit, and acquiring first customers.
Rapid iteration is key, and the initial technology may be discarded.
Ideally, there should be minimal technology involvement; paper prototypes or fake Google ads can be used.
The original implementation of Stitch Fix's algorithm was an Excel spreadsheet.
Engineering is about solving problems, not always by writing code.
Business processes should be aligned holistically, and changing business processes can be better than changing software (reverse Conway's Law).

Starting Phase

Characterized by a small team (around five people) and a short time horizon (three to six months of runway).
The architecture should be "just enough architecture" to meet near-term customer needs cheaply and simply.
The goal is rapid learning and improvement, prioritizing team productivity over scaling.
Just enough software meets current customer needs without anticipating future problems.
Validating the product is essential, and a simple solution helps determine if the product will succeed and what changes are needed.
The best code written now might be discarded in a couple of years (Martin Fowler).
Simple, familiar technology should be used to prioritize expressive power and ease of use for developers.
Rapid prototyping frameworks like PHP or Ruby on Rails are suitable.
A monolithic architecture is appropriate: single application, single database, and minimal infrastructure using Platform as a Service.

Trade-offs of Monolithic Architecture

Pros: Simplicity, in-process latencies, single build and deployment unit, and resource efficiency at small scale.
Cons: Coordination overhead with team growth, poor enforcement of modularity, limited horizontal scaling, and a single point of failure and performance bottleneck.
The cons are less relevant in the starting phase because these problems occur at scale.

Recommendations

Buy and reuse existing software instead of building from scratch.
Leverage cloud infrastructure.
Prefer open-source technologies.

Scaling Phase

Involves multiple growing teams and a longer time horizon, justifying investment in longer-term approaches.
Magic Number: Only about 1% of companies that build a monolith successfully transition to microservices.

Warning Signs That the Monolith Is Failing

Decreasing feature velocity: the ability to release new features slows down.
Teams step on each other's toes, hindering independent development.
Difficulty for new engineers to become productive.
Vertical scaling of the monolith runs out of steam (adding more resources to a single machine).
Parts of the system need to scale independently.
The monolithic release is too slow, complicated, or risky.

Re-architecting as a Sign of Success

Rebuilding the system indicates that the initial architecture is no longer adequate due to growth and usage.
Focus on incremental, small changes to the system.
Choose a part of the system and rebuild it in the new way (pilot project) to optimize learning and demonstrate feasibility.
After a successful pilot, maximize ROI by prioritizing the highest revenue-generating parts of the system for migration, even though it's riskier.
Ensure that new feature development continues in parallel, but each release should either be a feature change or a migration change, not both.

Optimizing Phase

Occurs when a product line flattens, and investments are shifted to other areas.
Characterized by fewer teams and a longer time horizon.
Architectural changes focus on stability, sustainability, efficiency, and maintainability.
Improvements are incremental, and operational efficiency is prioritized.
Teams may be consolidated.

Characteristics

The business is successful and well-understood.
The company seeks to optimize efficiency and may redeploy resources to more exciting ventures.

Conclusion

It is generally better to go to microservices, but start with Randy Shout.
Microservices will be discussed in the next lecture.