Noticed that tech companies are continually changing up the technologies used to produce their offerings? If you’re sitting on legacy code, languishing in a legacy stack with components you’re sure have passed their sell by date but don’t know what to do about it without a huge overhaul/cash/talent injection then you’re not alone.
Back in software’s yesteryears (the 1980s and 1990s) if you went to work at a software house, you’d be given the technologies used and, if you stayed on in your role, you could expect to be working with the same technologies, 10-20 years into the future with, perhaps, a little bit of newer tech thrown in around the place by some forward-thinking colleagues or bosses.
Fast forward to 2017, and say you hit the ground running at a modern software dev shop with a solid stack. By the time that 2022 rolls around you’re going to expect that you’ll be working with maybe as little as half of it. For software developers and architects this means requiring the ability to think bigger picture and be able to pick up new tools and skillsets on the fly.
Let’s take a closer look at Twitter’s stack changes over the years to see how and why this rapid evolution is necessary for success…
Many web software products start off with a solution built with Ruby on Rails – the route that Twitter went down when it was released in 2006. It’s great for getting things up and running quickly, especially as a proof of concept. However, when you start to scale, it can become less efficient for a backend than other technologies built specifically with high load in mind. This is what’s known as technical debt – poor design choices in development to begin with, that require a redesign later. This may either be poor codebase design choices or poor infrastructure design choices. While we can refactor code to within an inch of its life, sometimes it simply isn’t enough.
Take, for example, the case of Ruby on Rails we outlined just now. Twitter, in 2010, ultimately switched out the backend Ruby to using the Java JVM with Scala. That’s just 4 years between major technology updates. Eventually, the frontend was also migrated to Scala, too. Unfortunately, it can be difficult to forecast the best toolset to use at the start of a project, and a better solution may not even have arrived at the time of production. We can either keep chipping away with an inferior solution and provide fixes (and thus increase our technical debt), or we can roll over to a new solution, even though this may be a drawn out process.
[One reason why the first option here isn’t clever: disgruntled devs]
Whereas back in the 80s and 90s, we followed the traditional software development pattern (i.e. the Waterfall model), agility is now revered – and you need to keep up with the Kardashians in 2017 instead of the Jones. As The New Stack put it, the three cornerstones of modern software are agility, resilience, and scale.
We need to be able to see new opportunities in technologies that address these three qualities better than our current codebase and architecture, and actually go in there and change it up to eliminate that technical debt.
The question now is how do we evolve a product to capitalize on the latest and greatest in technology? Or, more to the point, how can we do this without massive overheads, downtimes, and risk? If we already have aging legacy systems we want to modernize, how can we do so to ensure we can easily update our stack in the future?
Use Cloud Technologies Where Possible
If compute power, databases, and other services are not a part of your key product offering, then why are you managing them in house? Extract the areas of your system architecture that can be migrated to cloud services first.
Use Open Source Technologies
Proprietary is out, open source software (OSS) is in. If we are changing technologies every few years we can’t afford to pay for something new each time around, which we need to with proprietary packages. And hey, if an OSS feature set you need doesn’t exist yet, that’s what your devs are for – they can add to the project!
Using OSS components that already have a thriving dev community and regular package updates ensures that your codebase can take advantage of the latest features in the future. Look for a busy open source project because this will also offer more stability/security and less bugs than a less busy OSS project due to more eyes on the code. Software vendors should carefully check over OSS licensing agreement terms before diving in as some OSS requires fees to be paid depending on the distribution of your software incorporating the OSS.
GitHub can be your friend in these times of accelerating technical debt.
As your stack evolves, so the applications running on that stack may need modernizing to take advantage of the benefits on offer.
Automated code migration (whether 1:1 language translators or lift and shift approaches) and code wrapping are quick fix solutions to modernizing code that actually add to technical debt.
The Morphis approach is to [as far as possible] automatically transform legacy applications from their old language to a modern environment (Java or .NET based) while, at the same time, re-architecting to a cloud ready, MVC architecture. Incorporating new functionality to the application as part of the automated process is routine (responsive layout and integration with SSO are just two common examples).
More importantly, within the discussion of accelerating technical debt, is our ability to enable a constant refactoring/modernization process to occur after the initial modernization project through the provision of tools and frameworks.
If you need help modernizing your legacy applications then, don’t be shy, we’re only a click away. You know what to do.