Nitric, a Cloud Portability Framework for Code

Cloud-managed services are emerging as the fastest way for anyone to build applications in the cloud. The benefits these services provide come with a tradeoff: vendor lock-in. It’s costly to move away from your provider if another solution becomes a better fit in the future.

I’ve been through it myself. Finding initial speed and success with the cloud services, fully utilizing their capabilities, and then running into cost increases and technical limitations. It seems inevitable to be stuck between two bad choices: migrate or absorb the drawbacks.

Nitric is an open source framework that enables teams to develop and manage a single code base that can be deployed to any cloud. We currently support Amazon Web Services, Azure and GCP and plan on expanding to others with community interest and involvement.

Portability for Proprietary Clouds

The idea for Nitric started taking shape as we researched the cloud providers for a project we were working on. We noticed that in this competitive market, the cloud providers have taken inspiration from each other and offer the same functionality with their base services.

The differences come into play with the interfaces, configuration and deployment of those services. Developing against these specifics contributes to lock-in, but the best practices are ultimately cloud-agnostic. We set out to take advantage of the commonalities to elevate the best practices into a reusable framework.

The beating heart of our framework is the Nitric Server, which includes cloud provider-specific plugins for each of the supported services. The Nitric Server is responsible for translating application requests into the format required by the appropriate cloud.

For example, a request to access a document collection in Nitric will translate into reading from DynamoDB in AWS. The SDK layer and the Nitric Server communicate over gRPC, leveraging the efficiencies of connection management in HTTP/2 using protocol buffers to optimize payload sizes.

The Nitric framework offers a consistent set of APIs exposing cloud resources including storage, documents, events, secrets and queues. These fundamental resources are at the core of many applications and are available to compute services which can be exposed as routes or methods in an API gateway. We’ve chosen key services to support in the Nitric framework, and with help from the community, we are aiming to grow this list (look out for “good first issue” tags in our GitHub repositories).

Nitric handles deployment by leveraging an open source tool from the cloud native community, Pulumi — an Infrastructure-as-Code platform. Our framework builds on their efforts toward cloud-agnostic deployments to provide developers with both the infrastructure and resources required to build their applications in a single deployment. We also address fundamental policy issues, e.g., applying the principles of least privilege for all resources which are deployed.

Vendor lock-in is not the only challenge with cloud development, and while we started with tackling the challenges of portability, our mission is to improve the cloud native development experience as a whole. Let me walk through two areas that are important focuses for us.

Eliminating Config

Apps deployed to the managed services are heavy on config, and when you throw additional technologies into the mix, e.g., Open API, the amount of config begins to affect productivity.

The first version of the Nitric framework required config files. Once we started using it for realistically sized projects, we saw that the effort involved was more than writing the code itself. We knew we had to improve on this as the lines of config were time consuming to write, error prone and hard to review.

One of the first ideas we considered was to place a UI in front of the config. At the very least we could minimize errors, but this seemed like a band-aid-style solution. Instead, we asked ourselves an important question: Are config files actually necessary? Brainstorming and researching this topic led to a new feature, which we call “Config-as-Code.”

The Nitric APIs eliminate a large portion of the configuration that developers need to write. On deployment, Nitric will automatically provision and set up permissions for things like collections, buckets, secrets, etc., by inspecting code and detecting resource declaration.

With just a few simple lines of code, we’re ready to provision:

• An API named “example” that exposes a get method on path “/welcome”.
• A storage bucket that can only be written to.
• A document collection named “example” that is ready for read/write.

import { topic, api, collection } from '@nitric/sdk';

const exampleApi = api('example');
const exampleBucket = bucket('example').for('writing');
const exampleCollection = collection('example').for('reading','writing');

// Implement a get method

exampleApi.get('/welcome', async (ctx) => {

...

});

Keeping the Framework Open

A great developer experience should be unrestricted, allowing developers to focus on problem-solving and writing code. Nitric’s APIs don’t limit the use of other frameworks; we’re here to join the ecosystem of amazing development frameworks.

In that vein, we’re appreciative of suggestions to help us build something useful for the community. If you’re interested in our work and itching to give it a go, the Nitric documentation is a great place to start. Check out all of our source code on GitHub and contribute or reach out with feedback!