X
Innovation

A serverless journey begins with several first steps, actually

AWS serverless expert explains what you need to know before launching a serverless pilot.
Written by Joe McKendrick, Contributing Writer

The best way to start on a serverless journey is with a serious pilot project that delivers real business benefits and can scale quickly as it shows results. That's the word from Matt Brayley-Berger, global business development manager for Serverless Compute at Amazon Web Services. In a webcast published ahead of the most recent AWS Reinvent, he outlines the best path to take when launching a serverless computing pilot project.

building-with-lights-windows-cropped-photo-by-joe-mckendrick.jpg
Photo: Joe McKendrick

"Digital businesses must innovate as rapidly as possible," he says. "You need your teams focusing on building applications, and not managing the underlying infrastructure behind them." Serverless computing is made possible by microservices architectures hosted and managed through the cloud.

Serverless technologies enable a team to "begin an application by focusing in the business logic in the code, rather than the underlying infrastructure. That not only gives us additional time to market agility, but it allows us to innovate more as a team."

The best ways to launch and sustain a serverless imitative include the following:

Set goals. The serverless pilot is not just a one-off demonstration project, it is an actual first step into the serverless process.  So the pilot should be addressing an on-the-ground business need. "Are there specific timelines or levels of effort that we're actually looking to demonstrate with the pilot itself?" Brayley-Berger asks.

Recruit team members committed to serverless. Serverless is a step into the DevOps realm. "They're technically savvy, but they have an understanding of both development and operations at the high level," Brayley- Berger says. "One of the things you're doing in serverless is the actual development of the application will now encompass operational deployment as well. So you are making your developers deploy things into production effectively at the same time, and so having folks on the pilot who understand operations and security in addition to development is very important."

Secure executive buy-in. "In a lot of cases when service pilots are successful, process change and organizational change may follow," says Berger. "Having executive buy-in is very important in order to make those follow-on actions fruitful." 

Ensure the scope of the pilot is broad enough, but no too broad. The serverless pilot "should be a significant-in-scope project, but not something mission-critical," Brayley- Berger advises. "You're going to be learning an awful lot from this pilot, so you want to avoid impacting a very significant production workload. But you  do want something that's important enough that team members will give it the dedicated support and the interest that may be required to in order to make it function properly." Don't make things too simple, either, since this risks not being seen as representative of pressing business problems.    

Establish workable metrics. Berger advises that while "objective metrics are very helpful, but "make sure that you're capturing qualitative feedback. These types of pilots have a tendency to change how organizations work, meaning that team members may be doing things very differently. There are lots of great educational opportunities and skill-growing opportunities. We want to make sure that we're taking those into account we're looking at the overall metrics." Brayley- Berger also advises not focusing "too heavily on the infrastructure cost in saving as the primary driver for success typically things like a serverless architecture," as spinning up and down functions in the cloud equates to a different cost structure and opportunity costs. 

Include documentation. It's important for the pilot project to "make sense for the organization and team members, in order to make sure this scales moving forward," Brayley-Berger says. "We're taking some of these lessons learned -- things like quality and security constraints, and how to actually navigate those. We want to make sure we're documenting this stuff and be very factual as well."

Editorial standards