“Technical debt” is a term that scares even the most experienced developers because they know, it’s something they will eventually have to deal with at one point in the future. It’s not a matter of if, it’s a matter of when. Paul Johnson put it very plainly in an article earlier this year.
*Today’s code is tomorrow’s technical debt *- Paul Johnson
The technical debt we’re talking about is the price you pay for choosing to go the faster route rather than to spend the extra time to write the code that would be more flexible and more manageable. The debt is the time it takes to rewrite and reiterate parts of your applications.
Just like financial debt, technical debts accrue interest over time. That interest is manifested in a number of ways and can be consequences.
An example would be the lack of inability to use certain npm modules because you worked with an outdated one and didn’t want to spend time making the upgrade with everything it involved. So you figured you’d keep it as is and deal with it later.
But now you are stuck with an old Hugo version and can’t upgrade because it will break your circleCI integration and you won’t be able to deploy to production and make all the other modules useless. And there’s the documentation that’s outdated just like everything else and now you are stuck in a hole that takes a lot of modification to make to the point you might want to start from scratch, but that ain’t happening because there’s no “budget for something like that”.
That. That is technical debt interest manifested into a little project that a “friend” of mine is dealing with.
Technical debt changed the way we build applications
I started working as a developer at a small company that didn’t really worry about technical debt(at first). We eventually ran into an issue where we had to swap out our entire application that was built on Action Script 3.0 and have it migrated over to a whole new Javascript-based application.
In that particular example we had to make the switch because Flash was dying fast but most of the time, technical debt comes in a more unexpected way. Even if you started out planning ahead for it, even if you took all the necessary precautions to avoid it, technical debt is going to bit you in, as the French call it, rear-end.
There are certain ways to mitigate the technical debt in an application, more or less effective. One of these solutions to this issue is serverless computing as an alternative to the traditional model of building applications.
Here are a few reasons why your development team should consider using serverless architecture in your next mobile app or web application in order to manage the technical debt.
A fully managed service will remove any infrastructure debt
That’s right! Services like AWS Lambda, Azure Functions, or Google Cloud functions are just a few of the function as a service options out there that will completely manage everything for you, which might not sound extraordinary to everyone but it’s amongst many others, a great reason to switch to a serverless architecture.
That means not having to worry about any orchestration, any hardware maintenance or upgrades of any kind. It basically allows developers to abstract the infrastructure altogether while being 100% sure this lack of involvement will not end up hurting them in the long run.
Serverless applications scale gracefully
Trying to meet demands with an application that wasn’t designed to scale is an absolute pain. Not being able to scale in order to meet user demand is more often than not a deal-breaker and will put any company at a huge disadvantage. Not being able to scale is more like a technical bankruptcy rather than just a technical dept.
Nevertheless, building your application using serverless will ensure that scaling is taken care of by the service provider who makes sure to spawn extra containers to meet demand.
Time to market and operational costs
Having that ever-impending deadline looming over you and your team will surely cause them to cut corners or skip certain steps resulting in something Dag Liodden likes to call “deliberate tech debt”. It basically happens when your software development team knows there’s a better way to write that particular function, module or service but for the sake of saving time or cutting costs chooses to go a different route, a quicker route. Check out this article on the different types of technical debt.
The way serverless handles these two pain points is by having the developer focus on the code and business logic and taking care of all the heavy lifting by provisioning, managing and scaling the infrastructure to fit the current neet.
Flexibility in choosing providers
Of course, we had to talk about vendor lock-in while talking about serverless. While there are lots of serverless benefits there are also a few things that might scare people from taking the serverless approach to building web services and applications.
Vendor lock-in is a problem that developers face but this too can be resolved by using platforms like the Serverless platform that allows you to move your infrastructure from one provider to another with relative ease.
Monitoring and debugging a serverless application can be very time consuming but there are solutions. Tools like Dasbhird take care of just that by facilitating that missing observability into your architecture in real time.
In conclusion
Technical debt is always going to be something we’ll have to deal with but while there’s no way to guarantee you won’t have to deal with it, serverless is proving to be a long term solution that many developers, as well as big corporations, are adopting so it stands to reason that there might just be something to this crazy new concept besides the hype that’s been surrounding this subject int he past few years.
I want to clarify one thing that might have been a bit misleading. When I was talking about how with serverless technology there's no need to upgrade or manage I was referring to the infrastructure itself and the code. That part is still up to you.
Top comments (0)