Matthew A. Titmus - Cloud Native Go

The story of networked applications is the story of the pressure to scale.

The late 1950s saw the introduction of the mainframe computer. At the time, every program and piece of data was stored in a single giant machine that users could access by means of dumb terminals with no computational ability of their own. All the logic and all the data all lived together as one big happy monolith. It was a simpler time.

Everything changed in the 1980s with the arrival of inexpensive network-connected PCs. Unlike dumb terminals, PCs were able to do some computation of their own, making it possible to offload some of an applications logic onto them. This new multi-tiered architecturewhich separated presentation logic, business logic, and data ()made it possible for the first time for the components of a networked application to be modified or replaced independent of the others.

Figure 1-1. A traditional three-tiered architecture, with clearly-defined presentation, business logic, and data components.

In the 1990s the popularization of the World Wide Web and the subsequent dot-com gold rush introduced the world to the software-as-a-service (SaaS). Entire industries were built on the SaaS model, driving the development of more complex and resource-hungry applications, which were in turn harder to develop, maintain, and deploy. Suddenly the classic multi-tiered architecture wasnt enough anymore. In response, business logic started to get decomposed into sub-components that could be developed, maintained, and deployed independently, ushering in the age of microservices.

In 2006 Amazon launched Amazon Web Services (AWS), which included the Elastic Compute Cloud (EC2) service. Although AWS wasnt the first infrastructure-as-a-service (IaaS) offering, it revolutionized the on-demand availability of data storage and computing resources, bringing Cloud Computingand the ability to quickly scaleto the masses, catalyzing a massive migration of resources into the cloud.

Unfortunately, organizations soon learned that life at scale isnt easy. Bad things happen, and when youre working with hundreds or thousands (or more!) of resources, bad things happen a lot. Traffic will wildly spike up or down, essential hardware will fail, upstream dependencies will become suddenly and inexplicably inaccessible. Even if nothing goes wrong for a while, you still have to deploy and manage all of these resources. At this scale, its impossible (or at least wildly impractical) for humans to keep up with all of these issues manually.