How to Start Small in the Cloud and Modernize Incrementally

As a corporate IT leader, you are under continuous pressure to reduce cost, improve stability, and mitigate risk. To accomplish these ambitious goals, you are constantly evaluating cloud adoption and other means of modernizing IT services.  

But along with modernization comes a few considerations:

• How do you minimize disruption to existing services? 
• Will you need to reskill traditional IT staff to build cloud-native applications and instill a DevOps culture? 
• How can you demonstrate quick wins to justify continued investment? 

Key Players: Efficiency, Security, Cost, Skillset  

Improvements in efficiency and security are a few of the key drivers for companies migrating to the cloud. Successful IT leaders enable more efficient ways to work; e.g., replacing manual workflows with automated workflows and dynamically matching infrastructure spending to demand. And half of IT executives are also looking to improve security posture by investing in automated, continuous compliance, and governance processes common to cloud environments.  

Despite these long-term benefits, IT managers identify two top roadblocks to modernizing IT operations: budget concerns and a skills gap. When two-thirds of IT budgets are tied up simply maintaining existing services, stakeholders must be prudent about the technology initiatives they launch with their remaining budget.  

How to Start: Keep it Small

While every company’s cloud adoption journey is unique, many corporations share common motivations and constraints for their cloud initiatives. Here are some patterns and best practices we have identified:

• Select a pilot project. The project should address a highly visible business need to establish immediate benefit, such as resolving a critical issue with an existing service or building a new, high-value business capability.
• Keep the project scope small. This way, it can deliver value quickly. However, it must still be large enough to allow IT staff to develop the foundational skills for cloud-native DevOps while tightly focused on enabling rapid delivery.
• Consider building a new business capability. Because a new capability is simply an additive, there’s lower risk of disrupting existing services. This is a great approach when a project is available that meets the other criteria.  

 A pilot project to build a new batch data processing application is ideally suited to leverage a serverless architecture for cost efficiency. This batch data process could be used to build new business reports on a schedule. Or, it could be triggered by another external event. 

For example:
A medical device manufacturer receives purchase orders (PO) from a hospital. The manufacturer has a report set up that compares the purchase orders to their current inventory to anticipate what items will need to be manufactured. The report includes a list of raw materials needed to make the goods. It also identifies which distribution centers have these materials available with minimal shipping cost. 

What you get:
A process that automatically matches the incoming PO (external event) with raw material inventory in warehouses. 

With serverless architectures, organizations do not need to purchase, provision, and manage backend servers. Instead, companies only pay for the compute time used while processing data, so weekly reports that require 5 minutes of processing incur only 5 minutes of charges. Similarly, serverless communication and storage technologies enable companies to only pay for what they use, without the ongoing operational overhead of provisioning and managing servers. 

How to Remediate: Use the Strangler Pattern 

While the scenario above is ideal for companies starting from a clean slate, often organizations begin their cloud adoption journey because they need to fix issues with existing technology services or infrastructure. In this case, a pilot project to fix or improve a current service should use the Strangler Pattern. This minimizes the risk of service disruption or project failure. The Strangler Pattern is a well-established strategy for incrementally updating existing web applications.  

For example:
The medical device manufacturer provides a catalog search for users to find the items they want. The manufacturer’s site uses an old search tool, though, and results take longer than their users expect now. The team identifies a new search tool and creates a new implementation that solely targets the catalog search function for their first modernization effort.  

What you get:
When a user types a desired term into the search bar, the user is unknowingly routed to the improved version while all the other requests continue to be handled by the original web application.  

This process is repeated, one endpoint at a time. Eventually, the original system can be decommissioned. Each improvement uses a phased rollout strategy — sending a fraction of the endpoint’s traffic to the improved implementation until stakeholders have confidence in it.  

This is the Strangler Pattern in action. It minimizes the risk of service disruption by limiting the “blast radius” of any errors or failures to only the updated endpoint. When necessary, implemented rollbacks direct the endpoint’s traffic back to the original service.  

Remember, a pilot project for cloud adoption should focus on only one or two endpoints, keeping the scope small. Consider the medical device manufacturer. They focused on areas that are part of their application’s critical workflow — like the inventory report. They also targeted areas that suffer from high latency or error rates — like the slow search function. These are good candidates since improving their performance and reliability is likely to impact the business in a direct and positive way.  

Leveraging a cloud partner, such as SPR, can dramatically improve the outcomes of your pilot project. Cloud partners work alongside your team to accelerate staff learning. They help your pilot project avoid common pitfalls and apply their expertise to reduce risk and improve ROI.