Introduction GitHub recently launched GitHub Actions which enable developers to develop workflows and execute them based on events in code repositories such as a push event or an issue creation. There are many Actions available on the Github marketplace which you can use for automating various tasks and workflows around development and deployment. In this tutorial we will use the recently launched Fission Action and build a simple workflow that deploys a Fission function to a Kubernetes cluster.

Introduction As the number of functions and their usage grows, it is crucial to monitor and manage them effectively. Fission already supports logs on CLI as well integration with external systems using Fluentd. Fission also has monitoring enabled using Prometheus and provides a great way to measure and track your functions automatically. Serverless functions can be part of a larger distributed system. For example, in the case of serverless applications that become more complex - spanning multiple functions, or in Microservices where functions are triggered between different services that talk to each other to process a single request or perform a business function.

Today we’re really excited to launch a set of new features for Fission, our open source Kubernetes-native serverless framework. These features are all designed to help you improve the quality and reliability of your serverless applications on Kubernetes. Serverless architectures have obvious productivity advantages. You can get your apps up and running quickly, reducing the total lead time to ship your new application. However, to make this “production ready”, serverless architecture needs to be not just about moving fast, but also about moving fast safely, and at scale.

Accelerating feedback loops are an important devops principle: the sooner you find a bug, the cheaper it is to fix it. While developing your application, you’re typically going through a cycle: write code, build, deploy into a test environment, run tests, fix, repeat. The build and deploy stages of this cycle are idle, unproductive time where you’re simply waiting. As a project grows, these stages get slower and slower. Once they’re slow enough, you end up context switching to another task, while waiting, and that makes it harder to get back into the right context and fix any bugs you find in testing.

Fission Functions are triggered by events. We’ve recently added a new feature that allows you to record these events into a database, examine these recordings, and replay them for testing and troubleshooting. Functions are often part of a larger, more complex system, that can take a while to test. Sometimes, tests might not be fully automated and require some human interaction. In both cases, you can record the events that trigger the function and simply use the same events to re-test the function.

Canary Deployments are a time-tested deployment strategy to reduce risk. The fundamental idea is that deploying software into a production cluster is different from releasing it to its users. With canary deployments, you deploy both old and new versions into a production environment, but send only a small percentage of traffic to the newer version. That way, if the new version fails, only a few users are affected rather than the application’s entire user base.

You can’t improve what you can’t measure. Visibility into metrics is a foundational requirement for much of software operations. Serverless metrics collection can be tricky. For one, there is no “uptime” to measure. Secondly, with a “pull model” like Prometheus, there is no long-lived service to scrape metrics from. By the time Prometheus scrapes your function’s running instance, it may already be terminated, since functions are short-lived. Though Prometheus has a push gateway, it doesn’t maintain history, which makes it hard to track metrics for multiple concurrent function instances.

Introduction At Part 2, we knew what’s real payload was passed to function and how to create a serverless guesbook. In the last post, we will go through the final bank sample and know how to deploy a application to different fission clusters. A Serverless Bank Application in Golang (Sample) In this section, we use a more complex bank sample to demonstrate how to use AJAX interacts with fission functions.

Introduction Part 1 we talked about the advantage of adopting fission as serverless framework on kubernetes, basic concept of around fission core and how to create a simple HelloWorld example with fission. In this post we’ll dive deeper to see what’s the payload of a HTTP request being passed to user function and learn how to create a guestbook application consists with REST functions in Golang. How Fission maps HTTP requests to user function Before we diving into code, we first need to understand what exactly happened inside Fission.

Introduction When users try to develop serverless applications, they often choose to start with Serverless services offered on public clouds, like AWS Lambda or Google Cloud Functions. However, users may encounter following problems after application development: Simulating the same environment on local machines is difficult Vendor lock-in prevents moving applications from one cloud provider to another Sensitive data that should not be sent outside an on-premises datacenter Fission is a serverless framework built on top of Kubernetes.