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:

• A legacy system SME
• A legacy system architect
• A business analyst who can track requirements, epics, stories, and timelines
• An AWS architect or architects
• AWS Lambda developers who can code in your organization’s language of choice (NodeJS, Java, Python, etc.)
• Optionally, for new AWS environments: AWS admins who are familiar with Identity Access Management (IAM), account setup, and management on AWS

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:

• An internal process that only a few consumers are using
• A non-mission-critical API that allows access to data
• A greenfield interface or process that can be developed from scratch on AWS
• An initial entry point — like an API — that can help extend the life or the capabilities of an existing system. For instance, the entry point might help with throttling requests, security, or act as a centralized access point for the back end

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:

• Layout all of the requirements; this is especially important if you’ll be creating new functionality
• Design the process and interaction with the legacy system
• Create the architectural diagrams for the system interactions with AWS and the legacy system, as well as within the serverless cloud itself
• Create epics and stories if using an Agile methodology — Big Compass’s preferred tool for this is Jira
• Align the developers to the Jira stories
• Develop to the use cases defined
• Test with the legacy system SME and AWS architects to ensure end-to-end feasibility, including regression testing against the old system’s functionality
• Deploy to AWS
• Migrate the service’s consumers, if necessary, such as API consumers
• Measure new metrics in AWS
• Create consumable dashboards, such as CloudWatch Dashboards

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.