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.
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.
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.
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.