This paper describes the opportunities for using serverless to transform your application software and to further benefit from lean cloud operations. The audience for this paper is cloud leaders and development teams who have already moved applications to the cloud and are considering what to do about the remaining software and existing code base.
We have drawn on our experiences in using serverless to transform our customers’ applications and operations to produce this paper, which discusses:
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 organizations to continuously adapt and keep pace with the changes. This backlog of changes accumulates as technical debt if not budgeted for, 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 that 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 if they want 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?
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. These cloud services have been 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 implementation of common software language runtime environments. Code is uploaded as a .zip file, and is executed in a managed container that 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.
Projects that include 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, mainly because it offers the most automated form of managed computing resources available, while maintaining control over application logic as a competitive differentiator. 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 can be categorized as reducing or removing:
Beyond cost reductions, other benefits of going serverless include:
Organizations can reap the benefits detailed in the previous section by rewriting existing applications with serverless, functions, and event-driven architectures. Lean transformation is focused on creating value for users while eliminating all identifiable waste. Thus, 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 to spend more time integrating new services and developing new customer capabilities.
The simple ROI calculation for the business case for modernizing can be expressed as:
Mode2 has a partnership with Cloudability [ 1 ] to help companies better understand their true cost of cloud ownership, and to create and document to help companies better understand their true cost of cloud ownership, and to create and document their 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 organizations, the business case for modernizing is centered on enabling new business opportunities. For others, the focus of engagements is on saving money and streamlining operations.
Next, it is important to consider how the approaches to modernizing workloads will shape projects in different ways. Mode2 found Gartner’s 5 Rs in “Gartner Identifies Five Ways to Migrate Applications to the Cloud” [ 2 ] and the “6 Strategies for Migrating Applications to the Cloud” by Stephen Orban [ 3 ] useful resources for understanding the migration big picture.
If organizations are open to the benefits of modernizing with serverless, what are some of the choices they must make? There are many implementation decisions to be made, but the first question is usually to answer is where and how to apply serverless as part of a lean transformation.
Mode2 offers several approaches to modernizing applications with serverless, each of which offers a range of options with increasing levels of ambition and returns. For understanding the migration big picture, this section expands on the four strategies that Mode2 has found to be most successful. The suitability of these options vary, based on the amount of the code to be rewritten and on the prioritization of new versus existing functionality in the first release of the new architecture.
1. Replatform
This migration strategy involves updating infrastructure components in the architecture to use cloud-managed offerings. An example would be swapping out a custom build and self-managed MySQL multi-region deployment for a managed cloud SQL datastore like GCP Cloud Spanner or AWS Athena.
2. Refactor
This approach involves restructuring parts of the existing solution to use serverless services. The sidecar pattern is used; this is 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 include 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.
3. Rewrite
The option to rewrite as part of the migration requires a completely 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.
4. Reimagine
Building on the rewrite approach, some organizations choose to revisit the workload requirements and add new functionality, rather than translating the application like-for-like. eimagining workloads focuses on innovation to streamline and simplify what the application does. In other words, to focus on core value. Examples include adding new functionality, designing powerful user experiences, or adding natural language interface capabilities, big data processing, and/or machine learning.
Replatforming and refactoring are incremental approaches to modernization, because they update only certain 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” [ 4 ]. Refactoring is a useful tool for replacing problematic components relatively quickly while retaining the legacy architecture, but delivers only partial benefits compared to a cloud native transformation.
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, because they are fully adapted to their environment; they are optimized for, and aligned with cloud roadmaps. This new software repository provides a platform on which to deliver new functionality quickly, while streamlining team operations and improving reliability for users.
Of the four approaches to modernization that were discussed in the previous section, Mode2 recommends a combination of the rewrite and reimagine approaches. Doing so balances 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, because the realization of benefits is tied to stopping doing some types of activities and to rebalancing staffing budgets to maintain the application going forward.
The approach outlined here aims to generate a win-win for both the users and the development team, quickly replacing the existing application with new serverless code and creating a new application architecture that 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 then to reimagine the application by layering on new capabilities until highly evolved.
The first phase of the rewrite concentrates on planning and defining the important project activities, understanding priorities, and communicating key goals, such as whether to focus on cost reduction or on enabling revenue growth. Mode2 reviews the application and compiles a list of requirements, evaluating existing user interfaces, processes, code, and data.
The list of requirements is translated into a set of user stories. 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 key questions:
Only when all five boxes can be checked with conviction can the Prototyping stage be started.
Once the goals and requirements are understood, attention shifts toward 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 style components needed to enable developers to start building.
Using the momentum acquired in building the prototypes, developers attack the backlog of stories in this phase, and rapidly rewrite the application with a low risk of implementation failure. The aims are to release a first version to a beta user group for feedback and to continue to evolve the solution until the majority of the high-priority backlog items are complete.
Once the application is rewritten with serverless and the replacement has been rolled out to users, the priorities of development sprints shift toward innovation and experimentation. Now user stories that enable new revenues and add new capabilities, like machine intelligence to automate tasks, can be prioritized.
Teams performing a legacy rewrite should aggressively groom and prioritize the backlog with the goal of simplifying all processes in the application, because complexity is the enemy of the transformation.
The increasing abstraction of a serverless solution offers organizations the opportunity to update their operating model, and requires adopters to update approaches, roles and tools to manage these new deployments. At this stage of the adoption cycle, we find that organizations are interested in discussing how serverless has impacted the areas of roles, development processes, operations and networking, observability, security and event loops.
Team roles evolve when moving to serverless: with much less infrastructure to manage, the balance of time budgets shift toward additional feature developments, and shared Site Reliability Engineer (SRE) responsibilities. The SRE role expands DevOps team structures to also embrace coding application-level improvements and bug fixes during shifts and sprints. This process becomes a virtuous cycle: SRE activities act as a flywheel for long-term reliability improvements in code, and reduce the operational support required for a well-instrumented and automated workload.
Testing code in a serverless solution also requires changes in approach. The Function code may be simple, but the interactions between many functions, services, and events in a highly distributed stateless system are complex. Best practices are for functions to perform a single purpose and to be written as a few hundred lines of code, so unit testing becomes relatively 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.
Debugging in serverless architectures has been removed, and replaced with events and triggers in event-driven architectures. This continuing abstraction removes access to that layer, and invalidates many tools used today. Mode2 recommends that organizations consider how to access data currently residing in VPC-based deployments, and how to optimize service calls for serverless workloads.
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.
Observability in serverless solutions is the process of creating detailed insights into the operational health and end-to-end processes, and becomes increasingly important in serverless operations. Public cloud logging is eventually consistent, with delays of seconds to several minutes for access to the 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.
Security is also updated by the move from networks to events. Existing security tools like NIDs and WAFs rely on inspecting networks and packets, which are not present in serverless. Functions are typically daisy chained together via other serverless services, which raises questions such as, “how can the combinations of events and services be managed”? and, “how can execution paths that are not permitted be blocked”? Best practice is to apply least privilege access policies to each Function; these policies must be managed and updated as new service calls are added to code releases. Mode2 recommends a proof of concept to evaluate the simplicity available from new partner tooling.
Event Loops are when developers accidentally create infinite loops between invocation events, where triggers cause code to continuously execute. A common example is when event sourcing from a datastore: a Function writes to the table, which triggers a stream to emit a new event, which triggers the initial Function to run and infinitely loop [ 6 ]. Serverless adopters must actively test for event loops, activate billing alarms, and establish a circuit breaker for a deployment to buy time to debug and release code fixes.
Mode2’s 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 customers have followed these basic steps:
1. Familiarize the team with the fundamentals of software modernization with serverless
2. Start with a proof of concept project and use it to explore serverless architectures
3. Improve the team’s knowledge of domain modeling and application boundaries
4. Create an internal business case for a serverless rewrite
5. Aim for the first win with a rapid discovery and prototyping project
6. Rewrite the first application and evaluate the benefits
7. Operationalize a serverless workload
8. Consider migrating groups of applications to fully realize the benefits of going serverless
This entire process typically takes three to six months, but consists of many motivating wins along the way to mark the team’s progression. Mode2 has something to offer every step of the way, customized to the specific needs of each of our customers. See the list of our services here, or contact us so that we can tailor our assistance to your project.
Cloud customers are embracing serverless because of its obvious benefits, with 82% of respondents to a recent survey saying they use serverless at work, with 53.2% of the serverless users saying it is critical for their job [ 7 ]. While organizations are primarily developing new workloads with serverless to build knowledge and experience, they should also consider reviewing existing applications and workloads with the lens of removing technical debt and streamlining operations with lean software.
Mode2 sees a strong business case for modernizing existing applications, which rewards cloud teams with reduced labor costs, improved development velocity and time, and a streamlined foundation on which to innovate new capabilities and user experiences.
Thank you for reading this white paper. If you have adopted similar strategies, have tried something different, or want to discuss our approach in detail, Mode2 would love to hear from you at hello@mode2.com.