Nitric and the Rise of Infrastructure Automation in Platform Engineering
If you build an internal developer platform (IDP), do you make it low code and hire low-cost engineers, or do you make it for high-performance engineers? That kicked off a debate with Rak Siva, VP of engineering for Nitric, as we discussed the Venn diagram of low code and platform engineering, particularly for bootstrapped startups.
Yes, it’s 2023 and everybody in tech is trying to do more with less. But startups are having to reckon with it taking significantly longer to go from Series A to Series B. Add to this, many roles, including cybersecurity and DevOps engineers, are tough to fill, no matter what the economic climate, and still retain high salaries.
Now more than ever, you also want your application developers to get value to your end users faster.
Platform engineering — the sociotechnical discipline of reducing toil for both developers and operations engineers — actually presents a pretty compelling case to achieve all this. Plus, in this short-staffed time of tech layoffs, it’s a way to stave off developer burnout.
Leveraging low code development — or maybe just less code via infrastructure automation — within an internal development platform (IDP) presents as a more important solution than ever. And, as platform budgets are being cut along with the rest, abstracting out some of the complexity for overstretched platform engineers isn’t a bad idea either.
Low Code Platforms vs. Less Code Platforms
To start, a few baseline definitions for the sake of this discussion, wearing the lens of the IT department:
- What is no code development? Engineers don’t write code when something is repeated, like Webflow, Airtable and Bubble, which is especially good for prototypes and websites.
- What is low code development? Often a graphical user experience is built to solve singular tasks, which Siva remarks is good for prototyping. Low code examples include BigQuery, Tableau, and Looker 7.
- What is infrastructure automation? Frameworks and abstractions are used to enforce best practices via less code. Often housed behind an internal developer portal, developers still have the option to go off these golden paths. Infrastructure automation should ultimately result in engineers writing less code.
All three purport to help developers do more with less. But, as TNS’s Richard Gall already wrote, low code can mean more work for developers. And recent findings out of Purdue University have discovered that, while “annoyingly plausible,” ChatGPT’s code responses are wrong 52% of the time. Indeed, low code may be too nascent for anything more than experimentation. Or it may need to be trained on internal domain needs and workflows with a tool like Kubiya conversation AI for DevOps.
No code development can be interesting for citizen developers — those working for the business side of tech — but, for the IT crowd, Siva worries it comes with technical lock-in and “broken promises.” He argues that low code tools are typically brand specific, while less and low code development tools are typically more neutral, like cloud agnostic.
In addition, development teams can engage with a platform in different ways. Some may adopt the convenience of low to no code route for operations tasks, while wanting more control over steps that will be differentiating to the end user.
An internal developer platform should be like a car dealership, in which different app teams choose different vehicles, all with the same make and basic security, observability and networking. Every team should be able to look under the hood to know what’s going on, but operations will decide which teams can perform what actions automatically and which can take a manual way. They just may be driving at their own risk, if they do something not explicitly supported by the platform team.
As Syntasso’s Abigail Bangser put it, an internal developer platform should take care of the non-differential but not unimportant, repetitive work shared by multiple teams. So how developers do differential work will vary, perhaps within a company.
Nitric Cloud-Aware Application Framework
For example, Nitric is a “cloud-aware” open source framework, which, Siva explained, automates the runtime to execute that code via actions like events, queues, document storage and bucket storage. He said, “We infer the infrastructure directly from your code and automatically provision it for you.”
Nitric falls into that less code bucket, as an alternative to Kubernetes orchestration, at least at a smaller scale. “If you didn’t use Nitric, you would be writing a separate Terraform or any IaC [infrastructure as code] project manually,” Siva said. Nitric is built on top of IaCs Pulumi and some Terraform, in order to provide an automation framework for best practices for deployment to the cloud.
“I say ‘less code’ because when you abstract something, you’re basically taking [best] practices and you’re making them reproducible,” Siva explained. “At the end of the day, the end user writes less code because they’re leveraging your abstraction, and so repetition in their code base is stripped away.”
Nitric is built on an observed pattern across the big three cloud providers — Google Cloud, Azure Cloud and Amazon Web Services (AWS). Each has managed services, with an API gateway, compute, document store, buckets, Pub/Sub for events and queues, which function the same way. These functions are usually combined together via infrastructure as code (IaC), like Pulumi and HashiCorp‘s Terraform. Nitric is then built on top of these IaCs to allow developers to deploy to a bucket in the cloud — with rules and policies set by your operations or DevOps team.
Managed services are known as a best practice for organizations to optimize their cloud usage and thus cost — which is even more important during the global compute shortage. Cloud cost also remains the main proxy for environmental impact — more efficient, managed code has a smaller carbon footprint.
Also more compute efficient, Nitric allows developers to run their code on a local runtime experience that simulates the cloud, so developers can write and iterate on their code — without having to containerize and deploy to the cloud until ready to move to production.
Platform Tools Must Be Extensible
The role of the software developer has become more and more complex parallel to the complexity of the code stack. This is worsened by smaller teams having to do more with less. Suddenly a developer may need to know seven layers of the modern software stack, including Kubernetes, networking, observability, storage, security and deploying to the cloud. This distracts from their main purpose which is to deliver value to end users faster.
DevOps success nowadays is about abstractions, not obstructions and distractions. Guardrails not gates. This is why successful platform engineering must govern the basics while still being highly extensible. An internal developer platform and surrounding tooling should enable dev teams to move faster, not create artificial barriers. And, where gates are necessary, policy like requisition tickets should decide when they open or not.
The Nitric open source framework is very opinionated to start off with, Siva admits, “First version, we know what’s required so we’re just going to provision on your behalf,” but then any ops team can fork it, following the documentation on how to extend or completely change the provider and therefore the resources associated with it, changing how that bucket should be deployed to each cloud.
For example, the out-of-the-box version of Nitric is deployed as a containerized lambda that runs in a serverless way. But you can instead modify the underlying Pulumi code to change out the provider to run as an EC2 instance for AWS.
Platform engineering enables DevOps organizations to continue to flow as one, but puts back up a bit of a barrier between devs and ops tasks, so developers aren’t required to know that full stack.
“Effectively we are separating concerns. The developer says: I want this execution context to run somewhere in the cloud — and all I care is that it runs,” Siva said. “But the infrastructure team gets to determine how it’s run in the cloud and what resources are provisioned to make that happen. And by making that separation, we’re effectively allowing people to craft their own platform — if they want to.”
While it’s a framework within the world of platform engineering — which is more associated with a developer audience — Nitric is focused on the infrastructure team using less code for more control. “It allows them to consistently deploy the same resources the same way, regardless of which development team requested it,” Siva said. And, since not all app teams are the same, “We provide the configuration per deployment to determine whether or not you should be provided provisioning with a high amount of CPU or a low amount of CPU or a profile, and you can define those profiles as the configuration in Nitric.”
Less work for ops usually translates to less work for devs anyway.
“What you find is the developer team actually ends up participating in the provisioning of infrastructure, be it via support tickets or war room or whatever, they always get involved because their stuff just doesn’t always work in the runtime,” he said. With the right platform tooling, “they don’t really have to worry about the infrastructure because it’s just guaranteed to work,” because the platform team has enabled them “to consistently deploy the same resources the same way, regardless of which development team requested it.”
Can a Platform Tool Be a Stopgap for a DevOps Engineer?
Platform engineering is key for bootstrapped startups who are just kicking off their DevOps journey, but cannot find or afford to hire a DevOps person right now.
“We’re taking away low-level or repetitive activities that are required for startups, but, when true scale is established, and they actually get growth, they are going to need an ops person,” Siva said. “But that ops person won’t spend time on mundane activities. They’ll spend time on valuable activities for the organization.”
This can also be the case at companies of all sizes as they face the DevOps talent shortage, where developers are left compensating and doing two jobs — their regular work and the ops work, the latter of which for them becomes non-differentiating toil. That leaves a team not only down an operations worker, but a developer too. The right platform toolchain can ease the burden of both capabilities.
“I don’t think that this is a tool to eliminate the ops team,” Siva said of the Nitric framework. “We want to empower the ops team, and stop them from copying and pasting Terraform or doing repetitive tasks, and let them focus on things that are way more important, like ensuring that the apps are using the right tools, ready to scale, and are maintained and up and running.”
Finally, less code platform engineering options can help the platform team too, by abstracting out CI/CD and infrastructure provisioning. The evolution of the platform team can go from an operations focus to more of developer experience, where they are able to focus on business value drivers for their internal customers — both software development and operations teams.
