White Paper: Modernize Existing Applications With Serverless

The purpose of this paper is to outline the opportunity for using Serverless to transform your application software and further benefit from lean cloud operations.

The audience for this paper is cloud leaders and execution teams who have already moved applications into the cloud and are considering what to do about the remaining software and existing code base.

This white paper is written in two sections - the first is an overview of the opportunity to rewrite existing applications with Serverless, and the second details modernization approaches and considerations for cloud practitioners. More experienced practitioners, who know why they want to modernize, can skip ahead to “The Business Case for Modernizing with Serverless”.

Why Modernize Your Software?

Nature has a process called Adaptation, which is the basis for all competition and is “the evolutionary process whereby an organism becomes better able to live in its habitat” [ 1]. The process of adaptation typically produces an optimum set of characteristics (an ideal “phenotype”) for an entity to thrive in a specific environment. Related to this paper, adaptation is the process where an organization fully embraces “cloud native” in its software architecture and team structures, and focuses on innovation to more effectively compete for customers and market share.

Application software is strongly influenced by the operating environment on which it is deployed, and software and infrastructure typically coevolve in tandem. As cloud providers continue to invest at a relentless pace, customers should update their software and adopt the most efficient technologies available. Each cloud provider makes hundreds of feature release announcements every year, driving many companies to continuously adapt and keep pace with the changes. The backlog of changes accumulates as technical debt if not budgeted, and in some cases can become overwhelming for teams that are unable to reduce operating costs or release new features fast enough.

In stark contrast, lean startups gain an advantage by naturally selecting technologies with the lowest staffing requirement and highest productivity. With cloud providers working hard to make technology a utility, startups are becoming real threats within the global marketplace against well capitalized companies. Entering markets as digital businesses, startups embrace the latest technologies and can stretch their payroll budgets further by building with Serverless. Companies, which adopt these lean approaches enjoy a lower cost of development and operations, release software faster, innovate quicker, and harness the latest capabilities of cloud to gain an advantage over competitors.

Established companies must become highly adapted to the cloud environment in order to thrive, and must keep pace with new service releases as both a competitive advantage and as a way of mitigating threats from leaner market competitors.

You moved your infrastructure to the cloud, shouldn’t your software also evolve?

A Serverless Solution Primer

Serverless is a new approach to developing software that abstracts away the complexity and effort of managing servers, infrastructure, and custom software stacks for an application. Serverless services are managed implementations of common application stacks, and deliver rich functionality via simple API calls.

Serverless services address the commonality in needs, and the duplication of effort expended across the cloud’s customer base. In the past, users were responsible for architecting, developing, managing, and maintaining their custom versions of application software stacks and infrastructure. In response to this opportunity for standardization, cloud vendors have packaged common solution components into on-demand, fully managed “Serverless” services, implemented with deep knowledge of the underlying software, and massive investments in simplification, reliability, and security.

Functions are the compute engine in a Serverless architecture, providing a fully managed and multi-tenanted implementation of common software language runtime environments, including Node.js, Python, Java, Go, and C#. User code is uploaded as a .zip file, and is executed in a managed container which activates, reads the event, executes the request, and becomes dormant for each application request. This function code acts as the integration glue between the Serverless services, implementing custom logic and initiating triggers between downstream services.

The Business Case for Modernizing with Serverless

Projects with goals to modernize existing applications usually aim to simplify software architectures and standardize workload implementations on Serverless cloud services. Among the various choices for modernization available, Serverless currently has the strongest ROI, mostly because it offers the most automated form of managed computing resources available, while maintaining control over application logic as a competitive differentiator. We see that applications and workloads migrating from data centers typically provide the strongest savings due to lower capital costs, but cloud users with instance-based or container-based deployments can also realize large savings when moving to Serverless.

The cost benefits of Serverless are typically categorized by reducing or removing:

Software runtime costs
Remove the full lifecycle of activities for developing and maintaining all software language run-time environments.
Custom stack costs
Remove the full lifecycle of activities for all custom software tier deployments in an application (typically 5-30 software tiers).
Development costs
Developing against well established, integrated, and tested services.
Software costs
Workloads built with Serverless technologies remove software licensing costs by using open source technologies.
Operations costs
Serverless delivers more with less responsibility for the customer overall with less administrative overhead and less resources required on-call.
Infrastructure costs
Cloud provides everything except code. No capacity to plan or manage. No patching except application package dependencies.
HA/DR/BC costs
Remove costs by not maintaining multiple infrastructures and environment configurations.
Capacity Management
Remove the cost and effort of planning, provisioning and scaling capacity, and move to an on-demand model aligned with usage.

Beyond cost reductions, other benefits of going Serverless include:

Faster time to Market
Lightweight application code is built and deployed faster than previously possible. Less moving parts to design, build, test, deploy, maintain, and secure. Code can be updated in real time.
Capture revenue from new service offerings by harnessing new technologies easily integrated with cloud native architectures.
Improved focus on ‘above the line’ activities like adding user features and squashing bugs. Reduce the effort performing undifferentiated activities, and time not focused on users.
Less operational burdens
Improve morale and retention by selecting technologies that remove the toil of manual repetition, and improve efficiency.

The Opportunity for Transformation

Developers are using Serverless services and open source libraries to replace existing applications, which is transformative both in terms of removing licensing costs and streamlining operating responsibilities. The transformation opportunity is for companies to reap the benefits as detailed in the previous section, by rewriting existing applications with Serverless, Functions, and event-driven architectures. Lean transformation is focused on creating value for customers while eliminating all identifiable waste. In the case of Serverless, transformative projects are those that eliminate unnecessary operational activities and effort. When rewriting applications with Serverless, the aim is to streamline architectures, skill sets and processes, and spend more time integrating new services and developing new customer capabilities.

The simple ROI calculation for the business case for modernizing might simply be expressed as:

Return on Investment = (  new revenue opportunities + annual cost savings - costs to implement )

Mode2 has a strategic partnership with Cloudability [ 2] to help companies better understand their true cost of cloud ownership, and to create and document the business case with specific data generated by proof of concepts and business case studies. The benefits received by rewriting software varies between implementations mostly due to the differences in scale and complexity between workloads.

For some companies, the business case for modernizing is centered on enabling new business opportunities, and for others, the focus of engagements is on saving cost and streamlining operations.

Approaches to Modernization

Next, it is important will consider how the approaches to modernizing workloads might shape projects in different ways. If companies are open to the benefits of modernizing with Serverless, what are some of the choices they must make? There are many implementation decisions, but the first question is usually where and how to apply Serverless as part of a lean transformation.

When considering how to modernize an application with Serverless, we offer several approaches, which offer a range of options with increasing levels of ambition and returns. At Mode2, we found Gartner’s 5 R’s [ 3] and the “6 R’s of Migrating Applications” by Stephen Orban [ 4] very useful for painting the migration big picture. In this section, we expand on four approaches we have selected, with the intent of defining terms for modernizing applications with Serverless. These options vary, based on the amount of the code to be rewritten, and the prioritization of new versus existing functionality in the first release of the new architecture.

Mode2 4 Rs of Serverless
  1. Replatform
    This migration involves updating infrastructure components in the architecture to use cloud managed offerings. An example of this approach would be swapping out a custom build and self-managed MySQL multi-region deployment for a managed cloud SQL datastore like GCP Cloud Spanner and AWS Athena.
  1. Refactor
    This approach involves restructuring parts of the existing solution to use Serverless services. Here we use the sidecar pattern where supporting features for an application are replaced with Serverless services within the architecture, maintaining a viable solution at each stage of the transition. Examples of where components are refactored are taking an application search cluster and migrating it to Elasticsearch, or moving from a custom self-managed RabbitMQ tier for messaging to using cloud pub/sub messaging.
  1. Rewrite
    The option to Rewrite as part of the migration requires a complete new architecture for the application, developing the workload from scratch using new code. This typically involves a like-for-like functional rewrite of the workload in a new technology, while minimizing project delivery risks by locking out new features until after the first release.
  1. Reimagine
    Building upon the approach to rewrite the entire application, some companies choose to revisit the workload requirements, and add new functionality not simply translating the application like-for-like. The approach to reimaging workloads focuses on innovation, streamlining and simplifying what the application does to focus on core value. Examples include adding new functionality, designing powerful user experiences, adding natural language interface capabilities, big data processing, and machine learning.

Replatforming and refactoring are incremental approaches to modernization, since they update only parts of the architecture, and continue to operate with the core software unchanged. The goals of these projects are to fix a specific issue such as database license cost or to address pain points in specific components of the architecture. Zhamak Dehghani of Thoughtworks published an excellent paper on “How to break a Monolith into Microservices” [ 5]. Refactoring is a useful tool for replacing problematic components relatively quickly, but retains the legacy architecture at the core, and delivers only partial benefits compared to a cloud native transformation.

Refactor vs. Rewrite

Rewriting an application from the ground up with serverless delivers the benefits that come from fully optimizing for cloud, ceasing all infrastructure activities, reducing monthly costs and freeing time to perform more important tasks. Applications that are rewritten for the cloud are said to be “cloud native”, since they are fully adapted to their environment, optimized, and aligned with cloud roadmaps. This new software repository provides a platform upon which to deliver new functionality quickly, while streamlining team operations and improving reliability for users.

Recommendations For Modernizing Applications

When considering the four approaches to modernizing as discussed above, Mode2 recommends a combination of the rewrite and reimagine approaches, balancing the needs to support existing users, deliver cost savings, simplify processes, and introduce innovation. Mode2 prefers to initiate a full rewrite of the software rather than refactoring a single component, since the realization of benefits is tied to stopping doing some types of activities, and rebalancing staffing budgets to maintain the application going forward.

Mode2 recommendations for modernizing applications

The approach outlined here aims to generate a win-win for both the users and the application team, quickly replacing the existing application with new Serverless code, and creating a new application architecture which is capable of quickly integrating new cloud services. The strategy is to start with a a simplified initial release with a new serverless core, and aims to reimagine the application by layering on new capabilities until highly evolved.

Mode2 application modernization phases
Phase 1 - Plan & Define

The first phase of the rewrite concentrates on planning and defining the important project activities, getting clear on priorities and communicating key goals, such as whether to focus on cost reduction or enabling revenue growth. We review the application and compile a list of requirements, evaluating existing user interfaces, processes, code, and data.

The list of requirements are translated into a set of user stories, and a domain model begins to emerge, shaping new boundaries in the application architecture. Before beginning the prototype, it is important to review the backlog of stories and sanity check the plans by asking a few important questions:

  • Are we making the most of this opportunity for transformation to cloud native and lean?
  • Are we simplifying, standardizing and streamlining processes?
  • Are we injecting new thinking and innovations to better compete?
  • Are we creating compelling new user experiences?
  • Does the design meet the needs of the customer during each phase of the modernization [ 6]?

Only when able to check all five boxes with conviction should we move forward into the Prototyping stage.

Phase 2 - Prototype

Once the goals and requirements are understood, attention shifts towards mitigating the technical risk and validating the plans before committing resources to the build. This second phase involves architecting solutions to support the rewrite, and validating the solutions through a series of prototypes to prove fit for purpose. This phase also includes the creative process, working through the user experiences, visual designs, and the style components needed to enable developers to start building.

Phase 3 - Rewrite

Using the momentum acquired in building the prototypes, developers attack the backlog of stories, and rapidly rewrite the application with a low risk of implementation failure. The aim is to release a first version to a beta user group for feedback, and continue to evolve the solution until the majority of the high priority backlog items are complete.

Phase 4 - Innovate

Once the application is rewritten with serverless and the replacement rolled-out to users, the priorities of development sprints shift towards innovation and experimentation. Sprint themes prioritize user stories that enable new revenues and add new capabilities like machine intelligence to automate tasks.

Teams performing a legacy rewrite should aggressively groom and prioritize the backlog with the goal of simplifying all processes in the application, driving out complexity as the enemy of the transformation. Once the new streamlined core of the application is available, the emphasis should move on to building user stories that integrate advanced cloud services, and that are dependent upon a strong cloud native foundation.

Important Considerations For Building With Serverless

The increasing abstraction of a Serverless solution requires organizations to update their operating models, requiring users to take different approaches and select different tools to manage these new deployments. The Serverless community is working hard to improve the following considerations.

Networking in Serverless is abstracted by the cloud into Events and Triggers, removing any access for users beyond which is provided in environment variables. Functions run in multi-tenanted containers, which incur a high overhead to bind to private network interface. Event-driven architectures have a big impact on networking, and we recommend Cloud managers consider how to access data currently residing in VPC-based deployments, and how to optimize architectures for Serverless workloads.

Security is also impacted by the move from networks to Events, where existing security tools like NIDS and WAF’s rely on inspecting networks and packets, which are not present in Serverless. Functions are typically daisy chained together with other services and resources - how to manage the combinations of events and services - and block execution paths that are not permitted? Best practices are to apply per-Function least privilege access policies, which must be managed and updated as new service calls are added to code releases. We recommend a proof of concept to evaluate threats and new tooling.

Observability in Serverless solutions is the responsibility of the end user to create detailed insights into the operational health and end-to-end processes. Public cloud logging is eventually consistent, with delays of seconds to several minutes to get access to operational data required to understand and fix issues. Functions run in highly restricted environments with common performance tools removed, so adopters must consider Function-specific monitoring solutions to provide operational insights.

Debugging of production Function code and live data collection is essential for developers and site reliability engineers working to improve customer experiences. Public cloud Functions execute as multi-cloud containers, and require logging of data state at key code breakpoints. New tools are required to provide streaming logs and insights into data state and metrics in running Functions.

Testing code in a Serverless solution also requires a change in approaches, with simple Function code but complex interactions between many functions and services and events in a highly distributed stateless system. Best practices are for Functions for perform a single purpose, and are written as a few hundred lines of code, so unit testing becomes relatively very simple. Outside of the Function, there are combinations of events, data, workflows and service interactions to be tested. The emphasis of serverless testing shifts from code units to end-to-end calls for chains of events across a set of distributed services.

Team roles evolve when moving Serverless, where the focus of the team shifts away from managing infrastructure deployments, and increases the amount of time the team can spend on feature development and Site Reliability Engineering (SRE) activities. The SRE role is an evolution beyond the DevOps transformation where operations engineers spend shift time coding application improvements and fixing bugs in real-time, rather than ensuring infrastructure uptime. This process becomes a virtuous cycle, where SRE’s act as a flywheel for long-term reliability improvements in code, and reduce the operational support required for a well instrumented and automated workload.

Runaway costs are when developers accidentally create infinite event loops between invocations, where triggers cause code to continuously execute. A common infinite loop is event sourcing from a datastore, where a Function writes to the table, which triggers a stream to emit a new event, which in-turn triggers the initial Function to run and infinitely loop [ 7]. Serverless adopters must actively manage concurrency limits across all services, activate billing alarms, and establish a circuit breaker for a deployment to buy some time to debug and release code fixes.

Getting Started With A Serverless Rewrite

Our project experience shows that Serverless is already transforming organizations into leaner businesses, and its adoption is growing quickly. To manage such a transformation, our most successful clients have followed this general path of steps:

  1. Familiarize your team with the fundamentals of software modernization with serverless
  2. Start with a proof of concept project and explore serverless architectures
  3. Improve your knowledge on domain modeling and application boundaries
  4. Create an internal business case for a Serverless rewrite
  1. Aim for the first win with a rapid discovery and prototyping project
  2. Rewrite your first application and evaluate the benefits
  3. Operationalize a Serverless workload
  4. Consider migrating groups of applications to fully realize the benefits of going Serverless

This entire process typically takes 3 - 6 months, but with many motivating wins along the way to mark your team’s progression. Mode2 has something to offer every step of the way, customized to the specific needs of your company. You can find the list of our services here or just contact us for something tailored to your stage of progress.


Cloud users are embracing Serverless because of the obvious benefits, with 82% of respondents to a recent survey using Serverless at work, with 53.2% saying it is critical for their job [ 8]. While companies are primarily developing new workloads with Serverless to build organizational learning and POCs, companies should now consider reviewing applications and workloads with the lens of further simplifying, standardizing and streamlining with lean cloud operations.

Mode2 sees a strong business case for modernizing existing applications, rewarding cloud teams with streamlined labor costs, improved development velocity and time, and a streamlined foundation on which to innovate new capabilities and user experiences.

We appreciate you taking the time to read this white paper, and we hope you got some value from our insights. If you have adopted similar approaches, have tried something different, or want to discuss our approach in detail, we would love to hear from you at finance@mode2.com.


  1. Definitions of Evolutionary Terms
  2. “Mode2 and Cloudability sign a strategic partnership to deliver cost saving using Serverless solutions”
  3. “Gartner identifies five ways to migrate applications to the Cloud”, by Richard Watson
  4. “6 Strategies for Migrating Applications”, by Stephen Orban
  5. “How to break a Monolith into Microservices”, by Zhamak Dehghani
  6. “Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable” by Henrik Kniberg
  7. “Lambda programming errors that could cost you thousands of dollars a day”, by Asankha Perera
  8. “2018 Serverless Community Survey”, by Andrea Passwater and Serverless.com
  9. “How to migrate existing monoliths to serverless”, by Yan Cui