SpringOne 2GX Conference: Managing and Migrating Monoliths of Mud
We often talk about the new stack, or stacks, as though they were great palaces, utopian palaces, the ultimate destinations of every data center in the world. Strangely though, despite their monikers, software has always lasted longer than hardware. The applications upon which businesses rely, and for many have always relied, are not going away, and perhaps never will.
Our journey to this palace in the cloud will only take place if we bring our baggage with us. For most every major organization that has contemplated a move to the cloud, its executives hope and expect they can transplant their applications onto the new platform, where they will take root and flourish.
Inventory
Usually it’s a consulting firm that’s the first to tell these people that’s not how it works.
“Accenture’s discovery phase is designed to grasp the number of applications you are running, how often you use them, who uses them, when they were written and in what language,” reads an Accenture company brochure [PDF] describing the application migration services it offers companies. “We establish an assessment framework, discover and audit applications in the portfolio, and determine application disposition.
“After we establish a tailored assessment framework,” the brochure continues, “we can help you determine the appropriate migration path for each application. We weigh critical factors such as security, scalability, your growth plan, high-priority business initiatives and risks, and regulations. Our assessment tool generates an impact analysis chart to determine migration-readiness. From there, we can discern the most appropriate target cloud deployment option … and the appropriate level of remediation.”
“That is the old-school way of migrating the monolith,” proclaims Pivotal advisory architect Rohit Kelapure, pointing to a “customer journey” chart taken directly from the Accenture brochure. “Our way is different from the old-school way. Our way is, to just push the app. You already have the cloud platform, and you’re already migrating your app to the cloud. So just push the app to the cloud and see what breaks.”
Kelapure may be one of the least conventional developers we’ve ever encountered. The fault for that may be ours alone: His job for Pivotal is to answer its clients’ pleas for migrating their existing applications to a cloud platform, by doing precisely that. His entire occupation is making the old stuff continue to work, so that clients may have the hope of enjoying the benefits of new platforms.
Organizations can’t even begin doing all the wonderful things we talk about here on a daily basis (for instance, containerization) until they can make their existing information systems, and the sources of their livelihood, co-exist with those things. That won’t happen, he believes, so long as organizations plague themselves with analysts and inventory takers who build huge planning spreadsheets, and whose end products are PowerPoint presentations.
Breaking Things
For obvious reasons, Kelapure’s PaaS platform of choice is Cloud Foundry. Since he spoke last Tuesday at the SpringOne 2GX conference in Washington, D.C., it should be clear that one of his tools of choice is the Spring framework, although he defaults back to Java EE if and when he must.
But in a way, those are immaterial points. Kelapure embraces a model he calls “extreme programming,” although what he describes appears to evolve somewhat from the model first conceived for it in 1996.
It’s an evolution driven by the practice of re-programming, or as he refers to it, “re-platforming and refactoring.” The first part is actually somewhat simple and may be made simpler by Cloud Foundry, which he describes as being designed from the beginning to be open to traditional methods as well as new ones.
From there, Kelapure’s “extreme refactoring” involves breaking things. Old apps are going to break once ported to new platforms. So the best way to find where the seams are, he professes, is to speed up the process and break things right away.
“When it does break, write a test for it,” he tells developers at SpringOne 2GX. “Write a test that covers that particular function, fix that particular aspect of the app, and then scrub and repeat. Start with one thing; start small. Just push the app.”
Re-platforming, as he describes it, is the act of taking the application to the new platform in the minimum number of steps.
“Do the bare minimum that is necessary to fulfill the function of the app. You should not make any changes that don’t get the app running on the cloud. That is your mandate here.”
Refactoring, depending upon the objective, does not take the same minimalistic approach. The example Kelapure gave attendees officially had 14 steps, although some of those appeared to have been made up of smaller steps that were glued together.
A great deal of that refactoring process, however, may actually take place in production, where everyday users have plenty of opportunity to break the app on developers’ behalf. Here, re-developers look for the breaks in the app and the cracks in the seams. These cracks may actually be natural, says Kelapure, invoking an image from geology. They may actually be indicators of where an old, monolithic application wants to be subdivided — where, in the future, the dividing lines between modules may be.
The re-developer may spend more time writing tests than writing production code. This is to be expected, says Kelapure. Tests will uncover the logic behind how and why code behaves differently on its new platform, possibly having something to do with the fact that cloud platforms are not the comfortable, reliable confines of an old server with a fixed amount of RAM and dedicated storage with fixed drive letters.
These tests may reveal that, in order for the app to work, the re-developer will need to make certain changes, the nature of which Kelapure doesn’t even try to cover up with a pretty euphemism.
“As you do re-platforming, you will have to make certain hacks to the app. Your app is not going to be perfect,” he advises. “You will do certain ugly things. You create a backlog of technical debt that you will resolve later.”
That backlog will accumulate all these hacks that were necessary to make the relocated application operational, and behave as expected. The result of re-platforming will not be pretty, but then again, it’s not the final state of the application.
Beautifying Mumbai
The actual composition of new, permanent code is what Kelapure calls “modernization.” This takes place during the refactoring process, where new technology models might come into play, such as containerization. Kelapure appeared mildly interested in Docker, and sees some benefits in it, but by no means pushed it as a vital tool for implementing a refactored application.
It was a recurring theme of Kelapure’s session that monoliths are nowhere near as daunting as the moniker implies. Sharing an unflattering picture of thousands of compressed, makeshift mud huts in one sector of his old hometown of Mumbai (he admitted to having grown up in a nicer neighborhood that actually had wood stoves), he said,
“Most of our enterprise applications, after a certain amount of time, start looking like this. There’s development sprawl, there’s code modules everywhere, there is no center of design. A lot of it has been patched up, based on what requirements have come in and the fixes we have done for our customers.”
Shanty-towns serve their purpose in Mumbai, he said, because, without them, the people who clean and otherwise maintain the nicer, multi-story buildings would have no place to live. Likewise, old applications have a place and serve a function.
That said, they’re not very pretty. And perhaps in an effort to expunge the shanty-town mentality at least from the enterprise, if not from the place he grew up, Rohit Kelapure built an almost psychological model of refactoring monoliths. First, he declares that they are made of mud — perhaps a half-century’s worth of cobbled-together patches, cover-ups, and fixes.
Then he depicts changes to these “Big Balls of Mud” (his words) as clumps being removed from them, like lumps of clay, and “anti-corruption layers” (again, his words) tacked to either side of the gaps left when those little balls are removed.
The new balls of mud are like connectors to code modules. Some of those modules may literally be “broken” shards of old code, separated by virtue of the breaking and testing process. These old code connectors provide a “legacy context” for old code modules to continue communicating with their old hometowns, to continue the analogy. The second type provides “new context” for any modernized components that may need to be fashioned, using whatever tools developers see fit to use.
In some cases, an old version of a component and a new version may need to co-exist for a time. Kelapure describes a process whereby a fence or “façade” is placed around the old ball of mud, giving the outside world the appearance of integrity. (Again, Mumbai seeds his analogies.) The abstraction layer provides a single point of contact that translates this façade into separate interfaces. Kelapure calls this part of the process “strangling the monolith.”
“When you see a portion of the app that changes very often, you fence off that portion of the application,” he tells attendees. “Then you create version 2 of the same part, that’s much better and nicer. Now you have fenced the old part of the app that has violated all the constraints, and you have basically two versions of the same interface.”
When testing certifies that the new component fulfills the same semantic purpose as the old version, the abstraction layer may then be instructed to route calls to the new version. Then once it’s safe, “you get rid of the ugly part.”
Many object-oriented code architects would perceive the creation of two (or more) interfaces as a violation of principle. But as Kelapure points out, so is the construction of the Big Ball of Mud in the first place.
At one very telling point in his presentation, the IBM veteran cited Conway’s Law: the notion that applications are modeled after the companies for which their designers work.
“The most important point here is, you change your organization to mirror what application architecture you want. You do a deliberate refactoring of organization structure to get your application architecture.”
Docker, IBM and Pivotal are sponsors of The New Stack.
Cover image: “Dharavi India” by YGLvoices – Flickr. Licensed under CC BY 2.0 via Commons.
