Nearly any custom-developed application written in the last decade—in any major programming language—can be replatformed. As owners of the source code, it’s possible for developers to find and change anti-patterns in code that prevent an application from running well in a cloud environment.

There are different levels of cloud and 12 Factor application design to arrive on, as shown in the maturity model below.

2

Choosing the right strategy for each application, or group of similar applications, is important for success.

What is Replatforming?

Replatforming involves upgrading an application from its existing platform and adhering to the minimum possible Twelve factors to get it to run on the cloud, while preserving existing functionality. Often it will also involve modernizing from vertically scaled technology like application servers and relational database management systems (RDBMS) to horizontally scalable datastores-as-a-service, lightweight open-source software (OSS) servers, and other cloud services versus on-premises. While this level of effort returns only the basic benefits of cloud computing, that’s perfectly fine for some applications because not all applications need the full benefits of being cloud-native.

”[Pivotal Cloud Foundry] improved our ability to deliver quickly... In the old way of doing things, we configured everything through Chef. We built servers. We had this dodgy build system. It really could take weeks to get the feature into production. Now with this tool set that we have along with this CI/CD capability, PCF has really accelerated that. We could push something in 5 minutes... It's been a dramatic improvement for us.”

Why Replatforming Matters

&FilledSmallSquare;

Lower CapEx and OpEx

Moving away from full-blown application servers that are expensive to license, operate, and administrate has been a consistent market trend since 2004. Lightweight servers that can be containerized in the cloud are now the norm, particularly in Java, where Apache Tomcat has dominated for many years.

&FilledSmallSquare;

Increased scalability, provider portability

Vertical scalability is inherently limited. Cloud platforms can horizontally scale up or down in seconds, dynamically—even auto scale. Open source platforms like Cloud Foundry are capable of running 250,000 containers in a single cluster. And why be locked into one infrastructure-as-a-service (IaaS) provider? Applications on modern platforms are portable across different IaaS providers, inside or outside of the firewall.

&FilledSmallSquare;

Optimize hardware resource usage, cost

Containerizing and virtualizing applications increases deployment density on the hardware or IaaS, ensuring maximum utilization of system resources, and deallocation or reallocation when idle.

&FilledSmallSquare;

Improved software licensing and delivery models

Cloud platforms are a major area of R&D investment by nearly all industry giants, major foundations, and users across many businesses. These platforms disrupt the traditional software license model with utility and subscription pricing. Also, cloud platforms reduce the number of point solutions required to run in the cloud.

&FilledSmallSquare;

Increased developer productivity without losing operational controls

In addition to powerfully simple and consistent developer tools across any programming language, many cloud platforms provide basic services out of the box as core platform elements, with an extensibility model. When developers can self service, instantly provisioning an environment that uses platform-wide access controls and audit trails, it’s a win for operations teams that can set consumption parameters. App stores then can be used to aggregate cloud services for developer consumption.

&FilledSmallSquare;

Enabling DevOps with common management and monitoring tools

Modern clouds provide agentless health management that streams an integrated, near real-time view of key application, services, and platform metrics. Developers and operators gain a shared understanding of the same system health and availability data in cloud environments.

Cloud-Native Maturity Model

Cloud-Native

Microservices architecture

API-first design

Cloud Resilient

Fault-tolerant and resilient design

Cloud-agnostic runtime implementation

Bundled metrics and monitoring

Proactive failure testing

Cloud Friendly

12 Factor App methodology

Horizontally scalable

Leverages platform for high availability

Cloud Ready

No permanent disk access

Self-contained application

Platform-managed ports and networking

Consumes platform-managed backing services

Considering Replatforming? Here’s What to Keep in Mind.

Commercial off-the-shelf software from the last decade was not originally designed for the cloud and cannot be replatformed by anyone other than the original vendor. While the cloud is clearly the ultimate destination for most applications being developed today, not every application requires a cloud-native architecture right out of the gate. The more business-critical or large scale the app, the more a cloud-native architecture makes sense. Conversely, there are plenty of non-business critical applications that deliver value, which can benefit from simply being replatformed. How do you choose the right strategy?

Embracing automation-centric, continuously delivered software requires an organization to change how it builds and delivers software. Teams that provide answers to the following questions can help make the case to replatform for cloud:

&FilledSmallSquare;

Business Drivers

How critical is your custom application to the business? What level of risk can be taken with the app, and how frequently does it change? Are domain experts available?

&FilledSmallSquare;

Economic Drivers

What amount of hardware and software investment does the app (or apps) merit? What sort of time window for a replatforming effort is appropriate given the expected outcome? What are the anticipated benefits or impact on revenue / cost savings?

&FilledSmallSquare;

Technical Drivers

Is it a suitable code base or is it riddled with twelve-factor violations? Does it use a suitable framework and runtime? What type of workload is it?

&FilledSmallSquare;

Organizational Change

Is your company ready to eliminate functional silos and build self-sufficient teams that build and operate their services? Is your change management process able to tolerate a deployment pipeline with little or no human involvement?

Becoming cloud-native requires adhering to most (if not all) of the twelve-factor principles. Replatforming effort offers less to the migrated application but is also less complex. The table highlights differences between a traditional enterprise application and a replatformed application.

How Replatformed and Traditional Applications Differ

Replatformed Application

Traditional Enterprise Application

Autoscaled. Infrastructure automation at scale eliminates downtime due to human error. Computer automation faces no such challenge, consistently applying the same set of rules across any size of deployment.

Right-sized capacity. A replatformed application benefits from dynamic allocation and reallocation of resources at deploy time based on the ongoing needs of the application.

Over-sized capacity. Traditional IT designs a dedicated, custom infrastructure solution (“snowflake”) for an application, delaying deployment of the application. The solution is often over-sized based on worst-case capacity estimates with little capability to scale beyond to meet demand.

Improved security. Replatformed apps can be patched with zero downtime at the application, app runtime, file system, and embedded OS levels. Rollback is simple and rapid.

Scheduled downtime. Responding to CVEs and applying patches can require coordination and scheduled downtime, frequently after operating hours. Changes often can be challenging to roll back.

Immutable infrastructure. By ensuring different environments are built reliably the same way every time, and aren’t alterable, application failure due to environment discrepancies are greatly reduced.

Unique environments. At scale, operators are slow to correctly diagnose issues and easily fail to correctly implement at scale due to the level of complexity. Hand-crafted automation recipes have the potential to hard-code human errors into the infrastructure.

Local OS. Apps run directly on the hardware’s OS or are virtualized. Servers are expected to be stateful and maintain their configuration. High availability typically is at the application runtime level.

At Pivotal, we help organizations assess and execute application replatforming—even operating the resulting applications on-platform for customers. Businesses of all sizes (from large enterprises to startups) across industries trust our software, services, and experience to lead them on their journey to the cloud—before, during, and after deployment.

&FilledSmallSquare;

Work with Pivotal to identify target applications for replatforming that match the level effort and benefit tradeoff needed for the business.

&FilledSmallSquare;

Take advantage of the Pivotal Labs approach, which uses Agile methodologies to gain results iteratively in 10-week sprints versus months of portfolio analysis before delivering value.

&FilledSmallSquare;

Quickly find the minimum viable number of the twelve factors that must be addressed before applications can run in the cloud.

&FilledSmallSquare;

Team with Pivotal to identify seams in the monolithic approach that can be extracted, migrating incrementally and keeping value flowing to the business as apps that need the full benefit of cloud-native design are replatformed.

&FilledSmallSquare;

Deploy and manage your applications with Pivotal Cloud Foundry—our cloud-native platform that accelerates time to value.

Momenti Pivotal

A top insurance company successfully replatformed, refactoring 10 logical applications of varying complexity during a 10-week engagement with Pivotal. The business also improved application quality by introducing automated testing.

A top healthcare company transitioned from JBoss to Spring Boot / Spring Cloud Config Server and containerized 12-factor applications. The organization eliminated app server setup, increased uptime with dynamic configuration, and increased scalability and 24/7 availability with blue-green deployments—all by only accomplishing approximately 50 percent of the 12 factors.

A top insurance company transitioned from JBoss, replatforming 8-12 simple apps so they could teach themselves how to replatform and later refactor—developing cookbooks for modernization patterns and sharing knowledge.