Red Hat offers tips for enterprises ready for serverless architectures

As serverless architectures continue to emerge in the cloud application space, many have chosen to make the transition in the enterprise realm. And although having the drawback of heavy third-party dependence can be a pain, the benefits of a low-cost and efficient backend can be incredibly important for developers to scale out their platforms.

We talked with an expert in the field of serverless technology, Rich Sharples, ‎senior director, product management at Red Hat.

ADM: What is serverless, and what is the current market landscape? Is the momentum growing around serverless?

Sharples: Serverless is a technology that is gaining attention as a way to enable more cost effectiveness and efficiency from cloud deployments. Serverless is designed to reduce the amount cost of running applications in the cloud, by only paying for the execution of a single function call. Serverless allows the developer to focus solely on code - they don’t have to worry about standing up servers and middleware, handling network traffic or other infrastructure concerns - the serverless model can insulate the developer from having to care about any of that.

While some enterprises have introduced serverless environments, it is still very much on the rise in terms of becoming an enterprise norm. It may gain traction now that major cloud providers offer a Serverless service and the open source serverless solutions such as OpenWhisk. Red Hat has seen some initial interest for some very interesting use cases, especially on peripheral applications, including transforming website graphic images for use on mobile and single page applications that are specific to mobile platforms. Other use cases for early-day serverless computing that we at Red Hat have seen include using the technology to process web-hooks, scheduling specific tasks and also introducing intelligent chatbots into the enterprise fabric. As newer, more efficient technologies gain attention in the enterprise, serverless may gain attention from an economic and cost effectiveness perspective - it enables resources to be used more effectively which can reduce wasted time and money and allow developers to focus on code and move faster.

ADM: What is the biggest benefit for users introducing serverless?

Sharples: In the same way that having a DevOps practice in place should be a prerequisite for microservices, before serverless can be properly embraced the enterprise should have a clear-cut agile approach and understand and embrace the benefits of rapid change and deployment that agile can allow for. Enterprise applications are complex webs of interacting systems often created over decades with different generations of technology, and serverless can add some new and exciting options for developers building, extending and improving these systems.

Similar to containers, serverless functions are well-suited for quick running and low point-of-entry projects with low overhead. Serverless is not necessarily suitable for long-running tasks, such as risk analysis, or a CRM system, or ones that require a significant amount of memory. It can provide cost savings and reduce wasted time and resources. Serverless is also highly scalable and offers high concurrency and the singular use focus means that it can be easier to optimize and prioritize specific tasks. In short, serverless is a more simple execution model and can be a good fit for services that have a very tightly scoped input and output, limited resource requirements (memory, CPU, time) that need to execute at scale, and do not require complex flows of events and information. Currently - Serverless is not a convenient all-purpose programming model and developers need to understand where it can yield benefits and where other approaches are more appropriate.

ADM: How does serverless fit into containers and cloud strategies that already are being used in the enterprise?

Sharples: It can be a clean and compelling image to present Serverless as the most recent advancement in a long arc stretching from bare-metal, dedicated hardware, to virtualization, then containerization and finally serverless. It can also be a useful image to describe how serverless differs from other ways the industry has developed and deployed applications over the years. But it is wrong to interpret this image to mean that serverless has taken over and everything before it has been superseded. There are rarely clean transitions in technology - adoption by the mainstream often happens many years after the early adopters have moved on to the next shiny object.

Developing a microservice-based architecture using containers and a container orchestration layer (and in the future a service fabric like Istio) can give more flexibility and control to the developer in defining how their application is deployed and how it behaves at runtime. Under the covers, the serverless services provider needs to perform some complex orchestration of language runtimes, such as activation and passivation, pre-loading and warming to give the illusion of instant execution and enable low latencies. Typically that orchestration is going to be managed by an orchestration engine like Kubernetes. So even if the serverless developer does not have to think too much about container packaging and orchestration, they can indirectly benefit from advances in container technology.
        

ADM: What are your tips for end users who are thinking about implementing serverless?

Sharples: For those first setting out on a serverless journey, remember that serverless is still in the very early stages of mainstream development, so there is going to be some trial and error when it comes to first projects. While serverless is based on existing technologies and practices, many of its core tenants will be brand new. This can be an opportunity for organizations to both introduce new innovation and to expand the technology repertoire. Serverless is based off of the code, not the infrastructure or operations, which is a shift in thinking within itself. Right now, many of the use cases I have seen are fairly simple - basically handing off task execution to “worker functions”, but as serverless becomes ingrained in the enterprise and as orchestration of serverless becomes more mature, I expect use cases will become more complex.