Brian Jackson - Fotolia
What are the pros and cons of serverless architecture? What common mistakes have early serverless adopters made? What considerations are vital before adoption? When technologies are still immature, these types of questions always linger around the minds of the enterprise software teams that might implement them.
In this Q&A, Gartner analyst Arun Chandrasekaran reviews the basic advantages and disadvantages of serverless architectures, addresses early criticisms of serverless computing and reminds potential adopters to understand how serverless was originally intended to run.
Editor's note: The following transcript has been edited for clarity and brevity.
To start, could you provide a quick rundown of the benefits a serverless architecture can offer?
Chandrasekaran: One primary benefit of serverless computing is that you abstract the infrastructure operations and provisioning from the consumer of the service. The consumer doesn't have to worry or care about the provisioning of the infrastructure, what goes underneath it or, in some sense, how it's operated. So, there are automation possibilities, particularly as it relates to the infrastructure.
The second benefit is that serverless functions are effective for event-based or event-driven processing, which means you can essentially call functions to execute against specific triggers that you've identified. Again, this benefit enables automation from a workflow standpoint. So, it allows you to react to things far more effectively and in a far more automated manner.
The third benefit of serverless -- and maybe this applies more if running in the cloud -- is that it can be cost-effective for some use cases. You're not running an infrastructure when your applications are not running, which means that you're running your infrastructure far more efficiently. That's always beneficial from a consumer standpoint. In a serverless environment, you truly pay for what you're using.
What are some of the potential drawbacks and pitfalls of serverless that developers and architects should watch out for?
Chandrasekaran: One of the changes is you have to rewrite application stacks to be more microservices-oriented or more functionally oriented when you are running serverless in the cloud. That requires a certain amount of understanding of how to write these micro-applications, and that could be challenging for a lot of organizations. Serverless architecture calls for some level of application rearchitecting and some level of rewriting. At some point, you need good code design practices from a developer standpoint to avoid a lift-and-shift outcome.
The second disadvantage is that serverless can be a bit of a black box, in the sense that you don't know what is underneath it. You're made to trust the cloud provider to make all the right decisions underneath it. While that's kind of the whole point of serverless, it can also be the con of serverless, particularly if you are in a regulated industry.
Finally, the other challenge of serverless is that it's still just a new concept. Because people are trying to really get their head around the concept of serverless, they often struggle to find the right combination of use case, products or accompanying technology to use with serverless. You could also argue that debugging and security capabilities are a little immature and still emerging in regards to serverless.
One of the main criticisms of serverless is that it has limited and simplistic uses and can't handle complex applications. And because the uses can be very niche, it should only play a minimal role in an organization's IT stack. What is your view on this criticism?
Chandrasekaran: I think the use cases for serverless are quite niche. And you can also argue that they're fairly limited, but it does do extremely well for those niche and limited uses. But the broader appeal of serverless is limited ... for many different reasons.
Serverless is an evolution of computing abstractions. For example, serverless architecture stands on top of containers and actually uses containers underneath the architecture. But it's not focused just on containers alone, because it exposes a completely different set of abstractions and APIs, too. So, essentially, the technology was specifically built to solve a certain type of problem from a use case standpoint.
And the ecosystem around serverless is nascent and evolving. If you compare that to, for example, [virtual machines], that technology's ecosystem is super mature. Most enterprise tools that are out there really integrate with your core hypervisor architecture, whether that's [VMware] vSphere or [Microsoft] HyperV. Even the container ecosystem evolved very rapidly in the last three to five years. But, beyond [AWS Lambda], I don't think there have been a lot of successful vendors, products or projects [for serverless] at this point in time.
What is the main piece of advice that you would advise people to think of before adopting serverless?
Chandrasekaran: Always know how to walk before you run. You need to have a certain level of sophistication in terms of just cloud infrastructure and service utilization, or cloud path utilization, which requires a lot of automation. You also need an understanding of what workloads can move there and how you can run it effectively, including cost monitoring or security governance. You should have tackled all of these challenges handily before you really jump into serverless. Maturity in your existing cloud processes and existing cloud skills, in terms of people and processes, is extremely critical for you to be successful with serverless.