If you’re in the software industry, the concept of technical debt will come up at some point. Agile software development’s popularity has spread this concept to teams who aren’t actively practicing Agile methodologies. Unlike the financial debt it was named after, technical debt isn’t characteristically bad and can be useful at times. However, too much can be debilitating to an organization. Here’s how technical debt affects products, development teams, organizations, and customers.
Moving your software development teams from working on operational to strategic goals is essential to your company's innovative future. However, the best developer’s time is too often occupied working on existing business solutions, which greatly hampers their ability to work on future business. Even if you had an unlimited budget to hire new resources, without an infusion of the tribal knowledge diffused among your existing teams, those new hires might have too much to learn about your environment to be immediately productive.
Life was good – your SaaS app was humming along, customers were happy, and business was booming. Then one day, it happened – a customer’s data is corrupt and needs to be restored ASAP! Or maybe a runaway job locked the database and brought the app to its knees, or a diligent customer demanded a more secure, isolated data store. You realize all your proverbial data eggs are in one basket, but you don’t want to maintain tens or hundreds of databases. Multi-tenancy is the solution to your problem!
Serverless applications are becoming more and more popular, but developers quickly find themselves asking, “How do I manage all of these functions?” Serverless Framework is a (relatively) painless way to develop and deploy your serverless application to AWS, Azure, Google Cloud, and other providers. However, getting started isn’t always easy. Here is an overview of how to get started with Serverless Framework using AWS and some common mistakes to avoid.
As software ages, eventually and inevitably, it’s going to become out of date and misaligned with organizational goals and objectives. Here are four steps for determining the health of your legacy applications and whether or not they are ready for modernization or retirement.