With the serverless community estimated to grow at a Compound Annual Growth Rate (CAGR) of 32.7 percent, serverless applications are becoming more widespread at an incredible pace. Such rapid growth in such a new technology leaves many people wondering when to go serverless and when to not.

It doesn’t have to be a question, however, of either/or for your entire application, as you can do pieces of your application with a server and other pieces serverless, depending on that piece’s need. There also may be an easy way of determining if your app would benefit from a serverless structure by looking at its current infrastructure — put simply, serverless for stateless.

“If you can describe your application as stateless, it is a good match for moving to serverless,” said Erica Windisch, founder and chief technology officer of IOpipes Inc., a serverless developer operations platform. “If you have a highly stateful application, then no; you’re not going to have an easy time migrating. But if you have stateless applications and stateless architecture, if you’ve already been going down that stateless rabbit hole, then serverless may not be as hard of a transition as you think it is.”

Windisch spoke with Stu Miniman (@stu), host of theCUBE, SiliconANGLE Media’s mobile livestreaming studio, at the ServerlessConf event in San Francisco. They discussed serverless applications, IOpipes’ services, Lambda, Azure and auto-tracing.

Understanding the code path with auto-tracing

Bugs without errors are the bane of any developer’s existence, but IOpipes is working on making those bugs easier to find and solve. Windisch pre-announced this functionality to theCube at the conference, and it would allow the developer to auto-inspect HTTP calls generated from functions in the code. IOpipes calls this “auto-tracing.”

“[Let’s say] you put a file into [Amazon] S3. Well, what file did you put into S3? How big was the file that you put into S3? What was its object name? You make other API calls and you’ll be able to see those and trace them — their timing, their parameters, their headers — automatically, out of the product,” Windisch said.

This would allow a developer to see exactly which path their code went down and what the end user saw. If the result was unexpected, it’s much easier to then see exactly where the path diverged, and from that, why it would have done so, according to Windisch.

Watch the complete video interview below, and be sure to check out more of SiliconANGLE’s and theCUBE’s coverage of the ServerlessConf event.

Photo: SiliconANGLE