Edelweiss - Fotolia

Tip

Developers find cautious optimism for serverless platforms

Experts urge cautious optimism around serverless development. It has its benefits, but tools that don't work as expected and a developer learning curve can cause some problems.

Serverless application development remains a hot trend, and software developers get excited about a serverless platform's perks and, in particular, the ability to move some or all of their Java applications from traditional servers and containers to more ephemeral platforms, like AWS Lambda, Azure Functions or Google Cloud Functions.

A good architecture for serverless apps often includes a mix of backend as a service (BaaS) and function as a service (FaaS) elements. FaaS offerings, such as AWS Lambda, are often what developers largely consider as serverless, but they should also recognize the need for BaaS offerings for more seamless authentication and data management access. When combined, they make it easier to develop applications and automatically provision compute resources as code.

Plan for new problems

Developers can find opportunities with serverless platforms from financial and scalability standpoints, while they can also develop new skills within the platform. However, it's important to recognize that serverless is still the bleeding edge, which means users will sometimes bleed, cautioned Nathaniel Schutta, software architect at Pivotal.

Schutta expressed concern when one of his developers enthusiastically told him about a plan to refactor an entire application into serverless functions. "The challenge is: We wind up using hype-oriented reasons to use a new technology and then end up regretting it at some point in the future," he said.

I am amazed at how often people take a technology to places where it is not a good fit.
Nathaniel SchuttaSoftware architect, Pivotal

One challenge with serverless functions is that they aren't a good fit for a lot of use cases. Although serverless development can overcome some constraints of traditional server-based development, it can also add new challenges that developers are just learning to address. "I am amazed at how often people take a technology to places where it is not a good fit," Schutta said.

One such challenge is that many serverless tools don't work as expected. For example, one developer from Kiev, Ukraine, ran into some problems troubleshooting back-end orchestration issues between serverless functions on AWS. After a few frustrating months with AWS CloudFormation, that developer switched to Terraform and saw much better results. In theory, CloudFormation was better integrated with AWS Lambda, but in practice, their apps kept breaking in subtle ways. Terraform had much better tools to code the connections between serverless functions and troubleshoot problems that emerged.

Balance value, learning and safety

Mike Roberts, co-founder at Symphonia, a serverless and cloud technology consultancy, recommended that developers find the right balance of benefit, learning and safety before they decide where to implement serverless applications.

The main serverless architecture benefits for enterprises include a reduction in server and process maintenance, scalability and a better relationship between usage and costs. Serverless architectures are particularly useful to reduce the effort required to build and deploy new applications from scratch and quickly receive feedback.

The serverless app experimentation process can also provide a great learning opportunity. But developers can learn more by integrating multiple event-driven functions on a serverless ecosystem compared to coding simple serverless functions. Conversely, simple functions will provide more security for critical enterprise systems compared to a new serverless infrastructure rollout.

Good starting points

An easy way to get involved with serverless platforms is to develop operations-based apps that improve tools for app monitoring and automate scaling. These kinds of apps are typically built by operations teams and have minimal impact on existing application code. "When we think about goals, this is a safe approach for introducing serverless," Roberts said.

When a developer feels comfortable, the next step would be to implement serverless applications for offline tasks, such as cron jobs. This kind of approach can make it easier to separate one giant weekly cron job that might spin up 50 tasks into smaller jobs that can be controlled with more granularity. But be aware that many serverless functions have a maximum duration and might not be the best approach for lengthy batch jobs. A step like this is relatively safe and provides an opportunity to learn basic serverless logic flows, but it limits the opportunity to learn about event-driven programming.

Next, a developer could implement serverless activities that provide real-time components integrated with larger applications to learn more about event-driven programming paradigms. For example, a popular use case is to build messaging parsers to restructure incoming data for downstream application components. This level also provides an opportunity to experiment with serverless messaging tools, such as Amazon Simple Notification Service and Amazon Kinesis, and explore associated scaling issues when you connect serverless apps with something less scalable, such as a database.

Finally, the fourth level would be a full-blown serverless ecosystem for the enterprise.

For example, Bustle, an online media company, has adopted this approach for its back end. It provides developers the best opportunity to learn about the event-driven programming paradigm and promises the greatest value -- if implemented well.

But that is a big if. Serverless apps have different kinds of constraints and failure modes that developers may not be able to troubleshoot. A big concern for Roberts is, when something goes wrong, it can affect other areas of the organization, including nonserverless apps.

Dig Deeper on DevOps-driven, cloud-native app development