The typical monolith application is actually a distributed system. The application typically interacts with a data store and often sits behind some kind of reverse proxy. Both these systems involve a two-way network connection with a monolithic app.
Typically in monolithic app development the main advantage we are getting is effectively benign neglect of the reality of the underlying infrastructure set up. We assume that our framework will handle a failure to interact with a datastore or an upstream proxy with a certain amount of grace.
For a developer they can effectively treat the entire execution of a handler as atomic and idempotent. Web frameworks though rarely provide features such as resource constraints, rate limitation and other handy features. With microservices you always need to handle these explicitly but in monolithic webapps these concerns tend to get pushed onto the front proxy which typically handle basic request timeouts (execution time constraints) and session and volume management.
In this respect only carefully coded, low volume applications do not have to care about distributed system concerns. All other "monoliths" inevitably require solution thinking that is very similar to that for microservices.
Thanks to Sam Newman for articulating this paradox so clearly.
Top comments (0)