How Fission on Kubernetes Takes FaaS & Serverless From DevOps to NoOps

“The sheer number of concepts you have to learn for the container ecosystem was pretty large, and still is. It’s growing with time. Concepts such as deployments, services, image registries, the management of versions, how you make changes. What’s the whole flow from your laptop to the container cluster? Even today as someone who is getting into the system; that’s an area where every single user has to build it by themselves, so the ecosystem remains a some-assembly-required solution.”  – Soam Vasani (Creator of Fission @ Platform9)

Serverless Moves Into the Enterprise

For the last few months, I have been spending a lot of my time working with customers on their Function-as-a-Service (FaaS) implementations and strategy. Today, Serverless computing and especially FaaS has begun to garner a lot of interest from enterprises. Real world use cases (I will cover these in follow up blogs) are beginning to make their way into production. It also bears noting that almost all of my customers have standardized on Kubernetes as their container orchestration platform. 

The Convenience of FaaS

Thus, from a developers standpoint, FaaS can help achieve the highest degree of convenience and agility. The majority of enterprises are still finding it hard to adopt DevOps process at scale – FaaS may just be what their frustrated developers need in terms of delivering business applications or incremental functionality.

For the remainder of this article, we will consider the leading open source FaaS framework designed from the ground up to work on Kubernetes – Platform 9’s Fission. Soam Vasani who conceived of and founded the project was originally developing on Kubernetes when he felt the need to abstract developers from the complexity of containers and to help them quickly build full applications. Further, a clear trend he saw was the emergence of CloudOps/SREs on the operational side.

To that end, there are only three concepts in Fission –

• Functions – which are snippets of business logic
• Environments – which confer language and runtime capabilities on Functions
• Triggers – which map incoming requests to Functions that operate on them

Vasani and the Platform9 team then added on these concepts to support integrations with monitoring systems and the Service Mesh – Istio, and log aggregation systems. In that sense, Fission provides an opinionated stack for its developers. It bears mention that Fission can support a diverse range of workloads ranging from web applications, backend heavy applications, and cloud-native applications.

Accelerate DevOps to NoOps With Fission

Fission represents NoOps in some of its purest forms – developers can be productive on the very first day the Operations team installs their Kubernetes cluster and can continue to be so throughout their usage of the project. Let us consider how Fission vastly simplifies the DevOps Process. This is illustrated in the below diagram.

We will take the example of a generic and standard development methodology and consider how it can be accelerated from both a continuous quality and delivery standpoint using Fission.

1. 1. The first step is also the simplest – developers simply develop their business function in any language of their choice. The venue of the code execution and interaction with other parts of the infrastructure is simply not their concern. The only concern the developer has is to properly design their function as part of an overall application i.e leverage the proper set of inputs and outputs/actions the function emits or performs. The infrastructure team is charged with delivering the appropriate capacity in the form of kubernetes pods, network, storage & needed integration with API gateways and other sources of fission events such as Message Queues etc. From a developer standpoint, Fission promotes a declarative configuration model of resources. All Fission resources – Functions, Environments or Triggers are Kubernetes Custom Resources (CRDs), they can be stored as YAML/JSON files.  Thus, instead of having to invoke a series of CLI commands, developers can specify all of these in a set of YAML files. Doing this ensures that these can be versioned as well using Git etc and used for things such as Rollbacks. These files can be applied to specific clusters on an “as needed” basis and teams can collaborate on them. Thus Fission supports the notion of ‘GitOps’ from the get-go.
   2. From a testing standpoint, Fission supports “Live-reload” which means code is instantly deployed into a test system as soon the developer is saving their files. This keeps feedback loops short. Whenever the developer saves the file, fission deploys it to a test cluster automatically within 1-5 seconds. This also ensures incremental deployments onto a cluster thus mimicking a real deployment more closely thus providing realistic and fast feedback on whether their changes are correct.
   3. The function is deployed into a Canary deployment or an A/B deployment model based on either a business policy or infrastructure criteria. This is made possible using out of the box integration with tools such as Jenkins & Istio etc. Fission has built-in automated canary deployments for functions. Functions can be configured with properties such as – the fraction of traffic to send to the new version, the error rate that signifies a failure, the rate at which to “grow” the new version as long as it’s succeeding. The function is rolled back at any point if it does not succeed. Once the function has been deployed, the scaling of the function is handled by the infrastructure with no intervention by the developer. Functions typically subscribe to a horizontal scalability mechanism and parallel instances of the function are provided by the kubernetes Master running on infrastructure.
   4. Finally, when deployed on a public cloud, all if the underlying kubernetes infrastructure (masters, OS etc) are managed by the provider thus ensuring that things are abstracted away and simplified from the developers. From a monitoring and logging standpoint, Prometheus and the EFK (Elasticsearch, Fluentd and Kibana) stack are used to monitor metrics of execution and log management etc.
   5. From a Monitoring standpoint, Fission automatically tracks the number of requests (function call count), timing (execution time and overhead) and success/failure rate metrics, response size, and error codes for all functions. These are fed into Prometheus automatically, without adding any code to the functions. In addition, it adds contextual information (cold vs. hot starts) to these metrics to allow better interpretation. With systems growing ever more distributed, tracing across functions and containers is an important way to monitor application performance. By integrating with Jaeger and other OpenTracing-based tracing systems, Fission adds support for tracing across all functions. This helps the troubleshooting of performance issues.

Deployment and Operations

The moment of truth for every developer is deploying successfully to production.  While Blue/Green deployments have lately become preferred over full deploys due to the ability to rollback changes, Canary deployments which only permit a very small error rate and thus potentially impact a small subset of users are fast catching attention.  Fission takes support for Canary deployments a step further by automating them. Automated Canary deployments help both automate and manage the risk of defective deployments by sending only small an amount of traffic to the new version initially. As trust is gained, more traffic is pushed to the new version, ultimately removing older versions from the production roster. All of this is seamless to the operations team. Conversely, if it is found that the end-users are experiencing issues, Fission will re-route users to older, more stable code so the issue can be resolved. Fission has built-in support with configuration settings for the distribution of traffic between versions (and the shift over time), the threshold error rate, and the rollback threshold etc.

Conclusion

For developers, FaaS on Kubernetes via Fission simplifies the DevOps process into a NoOps process. This helps in reducing costs and delivering the agility that the business demands. From an innovation standpoint, it also enables a real-time feedback loop that delivers continuous improvement, accelerating development cycles further.  The long-term bet is that FaaS using technologies such as Fission will change how cloud and containers are adopted into the enterprise and foster an increased emphasis on a dynamic developer culture.

For infrastructure and operations, “Zero infrastructure to manage” – is the fundamental tenet with FaaS. Infrastructure in the context of this definition includes everything outside the core business logic itself – Physical Hardware, Operating Systems, Virtualization stacks, Container orchestration, Build, Deployment, Automation & Config Management tools etc. Leading serverless frameworks such as Platform9’s Fission platform even abstract away their underlying foundation Kubernetes. Developers should only focus on the actual business logic and delegate all of the infrastructure considerations to the infrastructure/cloud provider.  This is a key differentiator for the Serverless model as compared to a Paa S.It bears mention that Fission can support a diverse range of workloads ranging from web applications, backend heavy applications, and cloud-native applications.