In a previous post we discussed about how we can leverage PodSpec in the environment pods to enable the functionalities like tolerations, nodeSelectors, volumes, security and a lot others. That functionality was only supported in the environment pods, but now we can provide the podspec in the builder pods as well. The details about what PodSpec is and the functionalities that it enables are described in the mentioned post.

Some exciting updates to ingress host path, annotations, and TLS support. In Fission version 1.6.0, which was released on Friday 11 October 2019, new features arrived. This blogpost covers the exciting updates to ingress host path, annotations, and TLS support. Fission previously supported ingress. However, it lacked support for TLS, host field, and ingress annotations. Now with version 1.6, all three are supported. In this blog post, we will cover all three of the new features.

There are features which enable a specific new functionality and then there are features which enable a whole new class of functionality in a product. I am excited to share that PodSpec is now available in Fission. Fission functions can be extended to do many things with PodSpec - such as tolerations, volumes, security context, and more. Previously, Fission had support for “container specs” - which allowed you to add environment variables, etc.

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.