From Aspiration to Action: Begin Implementing the Serverless Cloud

Moving to the serverless cloud is a process. In our previous post, From Aspiration to Action: Where to Begin Your Serverless Cloud Adoption, we covered planning your serverless cloud adoption from both a mindset perspective and the initial phases of moving to serverless.

The next step is turning those plans into action. We are now at the stage where you’ll mobilize your team, including your architects and developers, to quickly launch your move to the serverless cloud.

However, setting your plan in motion isn’t like pushing a rock down a hill — giving it a shove and letting it roll down its own self-defined path. To be successful, your actions to realize your first serverless implementation must still follow a charted course.

Having been part of many successful moves to the AWS serverless cloud, Big Compass has distilled that experience into a proven methodology. This framework takes our clients through a series of steps that move them from thinking about serverless to adopting it, and it’s a methodology that you can adapt to your journey.

The Steps to a Serverless Action Plan

Ensuring the success of your move to serverless and cementing support for continued migration requires following a set of clear, concise, and customizable steps.

Step 1: Mobilize and prepare your team

Your team will be the ones executing on your serverless plan, so you need to make sure you have the right skills in the room (or on Zoom) to complete the project.

Ideally, your serverless team would include:

Step 2: Ensure your prerequisites are in order

Several things will need to be in place before your team begins to migrate the first serverless component.

First, you’ll need to have your AWS account created. Part of this will be aligning your AWS IAM and account management with best practices and having those elements in place.

Second, you’ll need to ensure that any connectivity that is required is in place. Start with data connectivity design and make infrastructure and network teams aware of any network changes that will be necessary to allow network access from AWS. You may need to connect AWS to on-prem resources and can exercise options such as Direct Connect or VPN tunnel.

At the same time, you’ll want to design access to the legacy system that is part of your initial serverless project. Like your data connectivity for the project, your network and infrastructure teams should be made aware of any changes needed to allow systematic access from AWS to the legacy systems.

Step 3: Characterize your interfaces

Our previous blog on this topic directed that a serverless move requires an inventory of the existing components in your environment. That list will now be used to help you identify a good candidate for serverless.

At Big Compass, we use a table to list and calculate the best candidates for the initial implementations. Ideally, identify high-value, low-risk components to kick off the move to the AWS serverless cloud.

What does a good candidate look like? Here are a few examples:

Step 4: Deconstruct and engineer

Once the team is in place, the systems are set up, and the initial candidate is chosen, it’s time to deconstruct the monolithic application by moving the first piece.

Moving the entire mountain would defeat the purpose of breaking up the monolith into composable elements. Instead, it’s like taking a single Lego block from the larger Lego structure.

Once that single interface or process is identified, this small piece of functionality can become the mini-project for serverless implementation that can be achieved quickly.

Before you begin, you’ll also want to consider if you’ll be enhancing the system or simply migrating the component as is. For example, many companies use the move to the cloud to add to or improve the component’s functionality instead of simply recreating the same functionality. This decision will add time and complexity, but often adds tremendous value, such as enhancing visibility or stability of the system component.

Use the following process to define, design, and implement this single component:

Don’t fall for the temptation of cutting corners and ignoring the measurement piece. It’s essential to understand what has changed, what needs to change, and help evangelize the work being done.

Finally, repeat the process for each inventoried component of your system that is a good candidate to move to the serverless cloud. Along the way, your legacy system and AWS serverless cloud will co-exist, but that is expected. You may even choose to keep certain components of your legacy in coexistence with the AWS serverless cloud indefinitely. Often times though, when organizations begin to realize the benefits of the AWS serverless cloud, they adopt a cloud-native approach for their entire system.

Conclusion

The actions outlined in this post are the first steps to take in your move to the serverless cloud, along with the planning in our previous post. Once you have made the initial leap, each additional piece you move should adhere to the same process. That’s the natural beauty of this methodology and why Big Compass uses it with our clients over and over again — it’s repeatable for each component of your system and lowers the barrier to entry for serverless cloud adoption.

Are you Looking for additional ways to lower your serverless startup costs and effort even further? Check out Big Compass’s Serverless Starter Template, which will help you accelerate the deployment of your serverless environments by leveraging proven strategies and best practices.

Aaron’s passion for technology drives him to find innovative ways to help advance organizations through technology.