Napptive: Deploy Kubernetes Apps on Scale

We recently participated in the WeMakeDevs<>Napptive hackathon, where we came across the Napptive Platform. Here are a few exciting things we learned over the weekend about cloud and Napptive -

What is Napptive?

Napptive is a cloud-native development platform where you can create environments, deploy, and manage cloud-native apps at speed and scale 🚀

Napptive helps developers and DevOps save time by streamlining the operations around infrastructure, allowing them to focus on the application instead of infrastructure.

Napptive saves DevOps time by consolidating the infrastructure and providing self-service methods to partition it and Developers save time by not having to wait for infrastructure to become available, and reduce their workload as they do not need to manage it

But, what makes Napptive unique? It's the Napptive's rich application Catalog, let's dive deeper into it

The Napptive Catalog

The Napptive catalog enables developers to rapidly deploy a set of predefined applications which can be reused by their team members and users to deploy, preview, and test application with a single click without worrying about the underlying configuration.

Uploading applications to the catalog is a very easy and quick process, developers just need to upload their application configuration files along with metadata for documentation.

This makes the task of distribution very quick and efficient for developers and also helps users quickly set up and preview the application.

A Win-Win-Win situation for DevOps, developers, users ;)

These applications deployed on Napptive Catalog are called OAM (Open Application Model) applications, let's understand the OAM standard and its significance.

OAM Applications

OAM (Open Application Model) is a specification for deploying and managing cloud-native applications on Kubernetes. It provides a way to define the entire application topology, including the components, their relationships, and their deployment requirements, in a declarative manner. This makes it easier to manage and scale complex applications in a cloud-native environment.

Overall, OAM aims to provide a standardized way to define and manage cloud-native applications on Kubernetes. This can help developers and operations teams to more easily deploy and scale complex applications, reducing the potential for errors and improving the overall reliability of the application.

OAM standard makes it possible to deploy applications independently of the underlying cloud provider.

Key Components of OAM

• Application Configuration

  OAM allows developers to define their applications using a simple declarative syntax, including components, traits, and scopes using a YAML script.

• Component

  The basic building block of an OAM application is a component that represents a single logical unit of an application, such as a microservice or a database.

• Trait

  Traits are additional behaviors that can be added to a component, such as auto-scaling, health checks, or encryption.

• Scope

  Scopes define how components and traits are grouped and managed within an application.

Benefits of OAM

• Simplified Application Management

  OAM provides a high-level, application-centric approach to deploying and managing applications, making it easier for developers to focus on their application logic rather than the underlying infrastructure.

• Portability

  OAM is designed to be platform-agnostic, which means that applications can be deployed on any Kubernetes-based platform, making it easier to migrate applications between different environments.

• Flexibility

  With OAM, developers can easily customize and configure their applications, thanks to the ability to add or remove traits from components.

• Improved Scalability

  OAM includes support for auto-scaling, which enables applications to automatically scale up or down based on demand, improving performance and reducing costs.

• Better Resilience

  OAM provides an easy way to define and manage application lifecycles, including updates and rollbacks, which helps ensure that applications are always available and functioning properly.

Let's see the practical use case with an example.

Let's Deploy an App Using OAM Standards

We'll be deploying Mattermost, an open-source version of Slack built with Go, TypeScript, and React, here's the configuration file for deployment -

apiVersion: core.oam.dev/v1beta1
kind: Application

metadata:
  name: mattermost-preview
  description: Mattermost Server

spec:
  components:
    - name: mattermost-server
      type: webservice
      properties:
        image: mattermost/mattermost-preview:latest
        env:
          - name: test
            value: "test"
        ports:
          - port: 8065
            expose: true
        resources:
          cpu: 0.5
          memory: 512i
      traits:
        - type: napptive-ingress
          properties:
            port: 8065
            path: /

        - type: storage
          properties:
            pvc:
              - name: data
                accessModes:
                  - ReadWriteOnce
                mountPath: /data/db
                resources:
                  requests:
                    storage: 1G

The script may seem complicated but it is very easy to understand, we are basically defining a component named mattermost-server that runs our app through the specified docker image.

We're using Napptive's pre-defined napptive-ingress trait to expose our app to the internet on port 8065 and the storage trait is used to attach persistent storage to our docker container.

Here's our app running on Napptive and deployed here -

We also uploaded this to the Napptive Catalog, you can try it by searching mattermost on Napptive Catalog or using the Napptive CLI with the following command-

playground catalog deploy prathamesh-mutkure/mattermost:7.8.1

In this example, our application only had one component as its docker image packed the front and back end into a monorepo.

For applications with a separate front end, back end, and database, we'll have defined all these components in the configuration file and also specify the relationship between them but the overall process is pretty same.

Why OAM Apps are a Big Deal?

Now that Mattermost has been converted to the OAM model, its developers no longer need to worry about infrastructure and can focus on the core application and its features.

OAM provides a standard way to describe applications, making it easier to deploy the same application across different Kubernetes clusters and cloud providers.

We can now deploy Mattermost to any Kubernetes cluster or cloud provider without breaking anything or modifying a single line of code.

In the future, OAM can be used to separate concerns between application developers and infrastructure operators. Application developers can focus on defining the application components, while infrastructure operators can focus on deploying and managing the application on Kubernetes.

Napptive with is out of box support for OAMs and its rich Application Catalog, takes everything to next level.

SUPERPOWER, isn't it?

---

Happy Hacking 🚀