Explore proven strategies for modernizing your applications. Learn why you should modernize your applications and what factors to consider when modernizing.
Explore how ACGR in CxPortal extends Amazon Connect Global Resiliency by giving contact center operations teams a centralized, playbook-driven way to execute, manage, and monitor regional failover and recovery, reducing downtime and accelerating response during service disruptions.
Learn how to migrate from Amazon Pinpoint to Amazon Connect while preserving operational continuity and reducing risk to existing customer experiences.
Learn how we helped a major federal agency modernize its contact center by migrating to Amazon Connect in just 60 days.
Application modernization has grown to mean many things over the years, and rightfully so. There are so many different applications, different patterns, different use cases, and different business needs that make it impossible to have a one size fits all. Modernization needs an initiating issue – cost, application bugs, scaling issues, not enough developer velocity, or integrations are all common reasons we see in the industry. Once you determine your initiator, then you can start to build your path forward.
In this blog, we will describe some common modernization patterns. Even though there’s no one-size-fits-all method for modernization there are some proven strategies that can be implemented on a small or large scale based on your needs. We can help you evaluate and assemble the combination of patterns below and help you implement the best strategy to modernize your applications.
Modernized apps use modern languages, frameworks, architectures, interfaces, and cloud services. We can also define a modern application by looking at what it is not. The opposite of modern applications are generally referred to as legacy applications. Legacy applications are when the symbiotic relationship between a business and its technology starts to suffer. Legacy applications are generally a product of time and what was a cutting edge application yesterday might be preventing the business from advancing today. Whether it be cost to maintain, lack of features, inability to keep up with the market – times change, business needs change, and technology should change to keep up with those.
Regardless of the reason, when technology becomes parasitic to the business, then you have a legacy application. Let’s review a few of the most common issues legacy applications possess that can hold a business back and that modernization can help solve.
Painful deployments are by far one of the most common pain points and often companies and their engineers don’t realize how painful they are until they see the other side. These deployments might be defined by maintenance windows and have a manual, error-prone deployment process that requires a QA team on standby to check every few steps to ensure nothing goes wrong.
Another common pain point, and one that really affects the financials, is scaling. Legacy applications generally lack the ability to scale up quickly based on demand. Once they do scale up they rarely get scaled down. These legacy infrastructures are provisioned for 110% of max capacity to be ready for that spike, but they are provisioned at that scale 24/7, costing the business money and wasting resources.
A pain point often tied to scaling is an application’s statefulness. Statefulness requires users to always access the same server because their session information or maybe even their specific user information is stored locally on that server. With a stateful application any disruption in service or even a slight blip can lead to destructive failures where users are kicked out of the application and required to login again. User experience is increasingly becoming a driver that determines if a user will return to your application, and a legacy, stateful application will lead to poor user experience.
Modern applications generally possess the opposite of all of the above.
Modern applications solve painful deployments because they are deployed using automation in an extremely repeatable fashion. This deployment automation typically includes both the application source code as well as the underlying infrastructure as code using tools like Terraform, AWS Cloud Development Kit, or AWS CloudFormation. These deployments are also normally coupled with extensive automated testing which provides extreme confidence for a successful deployment.
Modern applications are cost-efficient not only in their approach to architecture but also in their approach to scaling. They solve the scaling problem by scaling up only when demand requires it and scaling back down during non-peak times, which enables the business to save money.
Modern applications are also stateless, allowing them not only to scale but also to fail gracefully should there be any hardware failures or unexpected issues.
This is a very short list describing a modern application, but it provides a view into what the possibilities hold.
Below, we will define a few of the most common strategies for modernizing your application. As stated above, there is no one-size-fits-all method or even necessarily a one-size-fits-an entire application method. Sometimes one application can take on a few different strategies for different parts of the application to allow for the best end result.
Rehost is often the path of least resistance to get into the cloud. This approach is often taken when datacenter renewals or hardware refreshes are on the horizon. Rehost is simply taking your current application and moving it onto a similar server in the cloud. One of the simplest examples of this is a data center running on Windows 2008 with expiring hardware leases, so your rehost might be moving to Amazon EC2 servers running a newer version of Windows.
In the example above you can clearly see some of the benefits to this approach. You get out of managing the hardware and are likely running on newer and faster hardware. You no longer are in the leasing hardware business and you get the benefits of scale when it comes to things like networking, redundancy, cooling, etc. However, with this approach, you generally bring all your “technical baggage” along with you into the cloud. If you had scaling problems on prem or struggled with developer velocity, those still exist in the new rehosted environment.
Rehost, unless you run some specialty applications that require a lot of resources (memory, compute, GPU, networking, etc), is not a great step into the cloud. You generally end up paying more for your cloud environment than you did in a datacenter. Also, we need to caution against the fallacy of using this as a “first step”. Too many people tell themselves that lie, but then once they are there other things take priority. Do yourself a favor and choose this method sparingly.
Replatform is similar to rehost, except you strategically make some updates to allow you to run more efficiently in the cloud. Some of the more common examples of this are migrating .NET Framework code running on Windows servers to .NET Core running on Linux servers. This type of effort allows you to save a lot on licensing costs, but does require some upfront investment in application changes and testing. Another common example is a migration from something like RHEL onto a free version of Linux.
Containerization is often another big win that falls within this category. Migrating from traditional VMs to a container based architecture generally results in cost savings and increased scalability.
While similar to rehost, and a strategy you should probably think beyond, this method is one by which you can reduce your cost in the cloud. Leaving licensing costs behind is a very intriguing modernization, but if you choose this option and also leverage some of the other methods below, you could reduce your costs even further.
Encapsulation would be the next sequential option if you are looking for ease of implementation, but still need to take steps forward in your modernization journey. In encapsulation you start to break up the code into independent running parts. The focus here is twofold – independent deployments and allowing your teams to work on an independent part. These two things often give you more developer velocity when your team starts to get large. This is usually the first step towards microservices, but doesn’t require rewriting much, if any, code. It leaves your end users with the exact same experience (same app) and your developers writing, troubleshooting, and debugging in a familiar environment.
Depending on your application, encapsulation could require a lot of work to pull apart tightly coupled services. It could also be rather easy if your application was never tightly coupled. Regardless of starting point, the benefits you see from an activity like this are really the start to a lot of modernization efforts. Strangler fig is a common approach to helping you decouple your application in bite sized chunks.
Refactor involves strategically rewriting functions within your application. When choosing which parts you are rewriting, there are a few things to consider. Sometimes you are choosing the simplest parts of your application as a precursor to an overall rebuild (see strategy below) or you are choosing the problematic pieces of your application in an effort to move your application forward. Regardless of the reasons why for this strategy, there is usually a large investment in developer time.
A few examples of this might include some background jobs that run on your current servers that are preventing you from scaling because those jobs would then run multiple times from every server. Refactoring those jobs to run in something like AWS Lambda not only saves costs, but also enables extreme scalability without the risk of the job running multiple times. Another example might be that you only support data created inside of your system and your customer are asking for connections to third party tools – maybe HR systems, ERP systems, management systems, etc, but your current data model does not allow this You might choose to refactor your entire data model and integrations to be more flexible of the data you can consume.
Rearchitect is similar in principle to a refactor, but rather than restructuring and optimizing application code it involves restructuring and adding new technologies to your architecture to enable new capabilities or improve performance.
As an example, it might be something like switching from using an FTP site for storing files to using Amazon S3. It could also be something like swapping out a homegrown authentication service to use something out of the box like Amazon Cognito. Choosing the right approach or feature for a rearchitect generally requires looking at the app holistically to ensure you aren’t going to break anything.
While planning for an application modernization, you can find yourself with a long list of features that you have determined need to be refactored and rearchitected. There is a point where the effort to refactor or rearchitect that many features is just not worth it, and it would be less effort to rebuild. A rebuild, by definition, is rewriting your application, starting from scratch, with the same features.
Rebuilds are the most time consuming strategy. If you are embarking on a rebuild it requires a lot of planning, but comes with the benefits of being able to remove any tech debt, integrate with 3rd party or cloud native services from the start, and sets up your application to be exactly what you want it to be.
Replace is discarding an application in exchange for another one. Replace doesn’t fall into traditional application modernization, but it does modernize the business portfolio by utilizing something more modern. This is often a good solution when you are trying to get out of the “managing homegrown software” business and can allow you to focus on your core business.
A common example of this might be if you are operating on a homegrown CMS solution, and your business grows too quickly or you can’t keep up with feature requests. At that point it might make sense to replace your homegrown application with one of the existing CMS platforms out there. Modernizing your overall tech stack is the outcome, but not because of work your developers are doing.
There are so many strategies to choose from and many of them start to overlap into each other. When choosing the modernization strategy that is right for you there are two factors that carry the most weight.
The first is to identify and rank your current pain points with the application or development process. This is often useful to do as a group exercise to get input from multiple teams or disciplines within the business. Once you do this you start to have an idea of the “why” you are modernizing. Often understanding the why will drive you towards a strategy.
Following that exercise you then need to figure out what kind of investment the business is willing to make. Almost all of the approaches above require development time. Replatform or rehost can often be done by a single/couple of developers dedicating some spare cycles over the course of a few sprints, while refactor, rearchitect, and rewrite more often than not require a lot more time investment and possibly coordination across multiple teams. Upfront discovery on any major modernization is extremely important to understand the level of effort and who it can affect.
Using these two pieces of information you can start to eliminate some strategies and create a roadmap for modernization.
Modernization can be a daunting task. As an AWS Premier Tier Partner Caylent has helped hundreds of customers modernize their applications. Working with a modernization partner, even just in the planning phase, will bring a level and depth of knowledge that is hard to get until you have done a modernization project. Developers and leaders who have completed modernization projects before know the challenges and pitfalls that come with roadmapping a development effort for any of these strategies.
Modernization can be a daunting task. As an AWS Premier Tier Partner Caylent has helped hundreds of customers modernize their applications. Working with a modernization partner, even just in the planning phase, will bring a level and depth of knowledge that is hard to get until you have done a modernization project. Developers and leaders who have completed modernization projects before know the challenges and pitfalls that come with roadmapping a development effort for any of these strategies.
Caylent generally approaches modernizations using a multi-phase model which aligns with the AWS Migration Acceleration Program (MAP). Phase one of MAP is an assessment. One of Caylent’s highly skilled Principal Architects will spend time with your teams and learn as much as they can about your application, automations, and systems including all of the related pain points and goals. The output of this assessment is a detailed roadmap to show you and your teams how to get from idea to reality with your modernization goals.
In the second phase, should you choose to continue, Caylent will deploy a team to work in tandem with your internal team to march towards the same, documented goals of modernization. With this full team in place, your developers will learn from and work directly with an experienced team, helping you steer clear of common pitfalls and mistakes.
If you are planning to modernize, we can’t stress enough how important an assessment is to understand the process. Let Caylent help your team liftoff into modernization today. As a Premier Tier AWS consulting partner and the AWS Innovation Partner of the Year, we are here to help you achieve great outcomes for your business.
We are forward thinking technical experts and we pride ourselves on true partnership with our customers. Being a partner means engaging together in a focused effort to solve your problems, drive your vision forward, and achieve measurable technical and business results.
We are all-in on AWS. We have deep expertise and knowledge, and your application modernization will be delivered by AWS certified architects and software engineers.
We are trusted and proven. We consistently achieve 9.5+ CSAT scores with our clients and we will bring this same level of excellence to your project.
We have broad industry specializations in the areas of SaaS, Healthcare, Life Sciences, Financial Services, Insurance, Education, and Transportation.
If you’re ready to set forth on your modernization journey with Caylent, get in touch with out experts!
Caylent Services
Innovate at the speed of light with modern applications powered by modular architectures running on purpose-built AWS services.
Caylent Services
From rehosting to replatforming to rearchitecting, Caylent will help you leverage AWS to its fullest potential to meet your business objectives.
Caylent Services
Quickly establish an AWS presence that meets technical security framework guidance by establishing automated guardrails that ensure your environments remain compliant.
Clayton Davis is the Director of the Cloud Native Applications practice at Caylent. His passion is partnering with potential clients and helping them realize how cloud-native technologies can help their businesses deliver more value to their customers. His background spans the landscape of AWS and IT, having spent most of the last decade consulting clients across a plethora of industries. His technical background includes application development, large scale migrations, DevOps, networking and technical product management. Clayton currently lives in Milwaukee, WI and as such enjoys craft beer, cheese, and sausage.
View Clayton's articles
Clayton Davis