Up until the 2010’s, people tended to choose a monolithic stack architecture by the language of their choice. For instance… 

• Django and Flask web stack for Python developers. 
• Rails web stack for Ruby developers. 
• Or Node/ExpressJS/SPA frameworks for JavaScript developers.

Scaling the Application

What I’ve noticed recently is that people are now willing to go out of their comfort zone, if doing so solves the problem with a higher return. They try new languages or even tackle a language they used to hate. They look for any new frameworks or code patterns with the goal of writing better software. It all comes down to the problem they are solving: scaling the application.

Medium.com uses Node for their main application but it also utilizes a separate fleet of Go servers for images and text snippet processing. Instagram used to rely on Django, but now its architecture runs on additional components such as Solr, Gearman, and Cassandra. 

Yelp had to completely overhaul its architecture in order to improve its success rate in distributed application updates. Moreover, the improved architecture can handle massive incoming traffic far more gracefully. From my Python meetup experience, a guy from Yelp had a presentation which enlightened me with the following wisdom: 

You need to throw away everything you learned as the application scales.

The application being scaled needs a mixture of multiple languages and frameworks to function. As the application scales, its architecture is getting compartmentalized and granular. Due to the mixed nature of technologies, your prior architecture knowledge may no longer be applicable. At some point, adding more servers or increasing server hardware throughput will not contribute to faster performance. 

You would need to wear many hats to see a different view at each architecture component/layer. For building scalable apps, the tech stack is no longer dictated by your favorite language. It’s now about a set of modular approaches to solve each problem individually.

Consider the following to improve your traditional MVC tech stack… 

1. Create a standalone software service to replace tedious data processing in the application
   
2. Use a dedicated queue system to increase demand intake
   
3. Scale your data storage by multiple NoSQL instances with scheduled migration to a cloud data warehouse
   
4. Use a cloud computing platform to run intensive computations
   
5. Send cached static responses with a CDN or static page generator
   
6. Configure the application server to improve load balancing

By considering the suggestions above, you have a great opportunity to scale your knowledge. Your perspective on building architecture will become more comprehensive and your software approach will now take architectural components into consideration. 

Each approach is based on different technologies, and you have to dive into new technical learning in order to fully leverage the benefits. All of a sudden, you won’t be limited to a traditional MVC web app schema. 

Practically, you will obtain the fluency of a new framework/language. Holistically, you will have improved the architectural approach and become more capable of planning a solid technical design. To summarize; your definition of application structure and practices evolves as your involvement gets more mature.

Conclusion

I tend to see any software or apps today as a monolithic lego miniature. From the big picture, the lego miniature looks massive. When you look at it meticulously, the miniature is composed of countless purposed lego components, each lego component is built differently and contributes to the miniature’s integrity in a unique way. Comprehensively, they are all integrated and work collaboratively. 

Everyone starts from building a simple lego artwork like a 3-story miniature lego building. If you have successfully scaled your miniature to 100-stories, your idea of building lego pieces will have successfully scaled as well.