Chapter 3. Serverless Architecture and Patterns

To fulfill its purpose, software must be soft—that is, it must be easy to change. When the stakeholders change their minds about a feature, that change should be simple and easy to make. The difficulty in making such a change should be proportional only to the scope of the change, and not to the shape of the change.

Robert C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Pearson)

The first recorded use of the term architecture as it relates to software engineering was a 1959 memo written at IBM. The company was trying to sell a supercomputer that they had not yet built. So instead of describing the actual system, they described a logical model of the system: an architecture.

Engineering and architecture are both relatively nascent fields in software; as things are changing all the time and no one can be sure what the best answer is, because today’s best answer is yesterday’s production failure. It is hard to incorporate the unknown into planning. The future may involve not just scaling a system up and to the right, but changing its functionality entirely.

To architect is to design the space for the software to be built in, as well as its shape. Much in the same way that a company can outgrow an office, a system can outgrow its architecture, and a piece of software can outgrow its server. So how do you plan for such things? Through the architecture itself.

The architecture of a system is like ...

Get Learning Serverless now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.