I’ve spent the last several years of my career helping clients embrace cloud-native solutions for their use-cases. For clients with existing systems, the most arduous migration tends to be that of their databases, especially if they use Microsoft SQL Server. The difficulty lies not in the migration of the database itself, but in migrating the Swiss Army knife of other tools SQL Server offers. For every new toy AWS creates, a trusty SQL Server feature is already in place. You need to send emails with SES? Just use DB Mail! No need for PowerBI/Quicksight when SSRS is around! Why use AWS Glue when SSIS is so easy to use? Is a Lambda function like a stored procedure? Source control? Just deploy the code to the database!
The platforms upon which you build your IT systems are the ports where your ship can drop anchor. We select ports favorable for their supplies, good weather, or convenient location on our route. Maybe we found more even more than we had hoped, made some friends, and decided to stay awhile. But when the winds change or the local economy crashes, will we be ready to weigh anchor, head for calmer seas, and find greener pastures?
If SQL Server could serve web pages, I’m convinced IIS wouldn’t exist and AWS/Azure would be fringe movements in the industry. It is a powerful addition to an enterprise ecosystem and one hell of an RDBMS, but this power brought reliance and narrowing of vision. Many forgot of the world outside of SQL Server. Years went by, faithful SQL Servers chugging, but when the time came to upgrade, SQL Server started tugging. Customers found their systems tied to various pieces or specific versions of SQL Server. The familiar, safe harbor turned into a rusty old anchor.
Tale of Two Ships
As a captain or crewmember on the ship of enterprise IT, take after Theseus. Don’t be like Davy Jones; derelict in his demonic duties. Enterprise applications tend to become “legacy” they day they are released; many can be used for decades. The longevity of use is to be welcomed as a sign that the application has received much use and generated much revenue. But this application can then become the Leviathan monolith, a ghost ship full of rotting crew, or the rusty anchor.
Strive to craft a fast ship, not necessarily in motion, but in transformation. Use architectural patterns and planning to ensure that no one component of the enterprise grows too large to move or replace. Keep track of the catalog of systems that make up your enterprise, anticipating those that need replacement. Finally, when a component does reach its time, actually replace it, turn it off, and fully decommission it; don’t leave it around to rot. A component left to rot, long after its due will stay part of your ship, part of your crew.