Serverless Development: The Future Looks Bright

The recent news about Serverless Inc., the company behind the Serverless Framework, getting 10M$ Series A funding assured many that serverless is still growing since the inception of the term around 2014.

With many technologies, it is not only how well it works that makes developers use it. The confidence in the product is just as important.

In this article, I would like to provide a high-level overview of the promising products that have launched recently and how that affects the landscape of cloud providers.

So let’s start by pointing out the most common pitfalls of serverless solutions.

• Not suitable for every application (time-sensitive).
• Lack of tools/standards for the use with legacy systems.
• Troublesome testing in local development environments.
• Fear of vendor lock-in.

Serverless Platform value proposition

Some of the above concerns are clearly the target for the recently launched beta of Serverless Platform. It consists of two new applications: Dashboard and Event Gateway. The first one provides a clean dashboard for observing your cloud functions across multiple providers (Amazon, Google, Microsoft). It also allows for the simple management of access to the system, making it easier to allow developers to access logs that would otherwise require a lot of permission management.

Source: serverless.com

To use the platform, you need to create an account and configure your projects’ serverless.yml file. Deploying the changes will add your system to the Dashboard. From there, you can manage access and see your functions’ documentation.

Source: serverless.com

Using multiple cloud providers easily

The biggest benefit comes from the Event Gateway written in Go-lang. In simple terms, it’s a publish-subscribe messaging solution. You can also call it an event router. It is cross-cloud, so it allows responding to events that were created in a different cloud and even outside of the cloud landscape in some legacy system.

This can help you migrate to a different cloud or use many clouds at the same time. The expected trend seems to be that the differences in features and pricing across providers will make using multiple clouds a viable option for even more companies. Using one cloud for heavy computation, another cloud for storage and yet another for machine learning is already an option that reduces infrastructure costs significantly. The result is access to the best tools on the market from many sources instead of the one we have initially chosen for our application.

Using standard events to speed up development

Another benefit comes from the standardization of the events. CloudEvents.io focuses on providing a standard way of defining what happened. The events from the spec could be used in Event Gateway. This will allow for code reuse across cloud providers. What is more, having the main source of an event as a separate entity allows for easier and faster testing. This is because we don’t need to use, for example, the “real” Amazon API Gateway but we can use a local version instead. Lastly, a specification will make cooperating in large teams easier.

Platform roadmap

The Serverless framework has always helped developers establish best practices. It was built with support for many languages but has remained focused on Node.js, in which Serverless and its plugins are written. Now with the platform, it also helps with function discovery, testing and integrations. Another area of improvement will be better support for services like Amazon Step Functions. Using them gives more opportunities for code reuse and makes combining Lambda functions into workflows maintainable.

Development process

In the workflow itself, you first need to define events, then functions that will handle them, and, lastly, subscriptions that will route the events between functions. The next step will be to test the system on local versions of the services used. Then, the deployment will move our functions to cloud providers and inform the Event Gateway on how to distribute events.

We need to bear in mind, though, that this is only the BETA version of Serverless Platform. Paying close attention to the changelog is needed as some things we described here may be changed or postponed. So far, our experience with the framework and its creators has been great, and we are looking forward to more stable versions.

With less time spent on managing architecture and less money wasted on largely unused servers, we can focus more on developing business logic, preferably in Node.js. This means more time for the developers to solve actual business problems. We just need to pay attention to the limitations that are imposed on serverless services. Once you go serverless, you don’t have to think about servers but you still need to design and develop software.