Sage advice on how to deal with a monolithic application

There are plenty of ways to avoid service-orienting large applications, but eventually they're going to hit the ceiling.

In a world being overrun by cloud and demand for more cloud, it's easy to forget that the world has actually already been long overrun by monolithic applications. They're never installed as monoliths, of course -- they usually start out at some point as simple and basic but gradually ballooning into large, unwieldy configurations with lots of users and a database bursting at the seams.

Building-Messe-Hannover Germany-photo by Joe McKendrick
Photo: Joe McKendrick

A service oriented architecture breaks out important components of these applications as standardized, highly digestible and flexible services. Jake Gordon, computer programmer extraordinaire, just published an excellent guide of why SOA is needed, what it is, supportive standards, and reference materials.

The key takeaways:

You can learn to live with the monolith and avoid SOA. This can be accomplished, Gordon writes, by scaling vertically by upgrading hardware, measuring and optimizing the hotspots in applications, or pro-active performance testing. From a development standpoint, SOA can be postponed by defining concrete boundaries within the monolith, extracting libraries, gems and packages, doing code reviews, and doing a lot of documentation.

SOA is needed to making scaling possible. Maintaining a monolithic application is unsustainable. End users are going to eventually break down your doors, demanding high performance and rapid access without a single, overloaded database bottling up the process. Developers are going to be screaming for greater flexibility and more ability to innovate and make changes without freezing up the entire infrastructure.

The sooner a large application can be broken into manageable services, the better. "If we let our monolith grow unchecked it will become very costly to refactor later, but if we take care to build it with well defined boundaries in mind and refactor as we go then we should find the migration to an SOA a natural progression," says Gordon.

He defines SOA as follows: "A Service encapsulates a cohesive set of features from our business domain; an Application uses services to provide an interface to our business domain (e.g. a UI or public API); an SOA is a collection of applications and services that combine to implement our complete business domain."

Gordon also provides some excellent overviews of how SOA is implemented in follow-up posts: