How Jit Builds a Platform Engineering Mindset in the Cloud

Platform engineering is an emerging tech industry trend that typically has a team dedicated to building and integrating whatever developers need to build and run services in the cloud — without having to become experts in the often arduous art of cloud computing. But what if a cloud native, serverless-first company adopts a platform engineering mindset and discipline — in lieu of a dedicated team?

We talked to David Melamed, the CTO and one of five co-founders of the Jit DevSecOps orchestration platform, to learn how they built a platform engineering organization from Day One.

Developing a Platform Engineering Discipline

“One of the goals of platform engineering is to promote self-service to enhance developer velocity and free them from being dependent on people and processes to do their job,” Melamed observed.

When cloud native Jit was born, the cybersecurity startup hadn’t heard of platform engineering being named as such, but, from the start, “We built our own capabilities as part of the work of the engineers who were building the product. We figured out that was the only way to provide the whole group with enough velocity,” he said.

Jit is built on “Infrastructure as Code (IaS) in the fullest,” meaning that “In a matter of an hour, you can spin up a whole new environment that can serve any developer or team,” Melamed told The New Stack.

From the start, the Jit team also worked to automate as much of service creation as they could. The company is built with microservices architecture, which is why they added a CI/CD pipeline into their first service. But then, for the second service, the CI/CD was forgotten. That was when they came up with “the concept of building something centralized so developers don’t even think about it,” Melamed said. It’s also when they built a central CI/CD system for anyone who builds a new service.

Then they began to identify other microservices patterns, recognizing an inherent need for standards and guidelines.

“Because that’s one of the drawbacks of microservices — if you have a lot of them, if you don’t have enough principles and guidelines and standards, you have drift,” he explained. Therefore they built a microservice generator so that all services follow the same pattern. And then, “because we have centralized CI/CD — we have a strong base in how we build our services, both in how they’re structured and how they’re tested.”

Founded in August 2020, Jit was cloud native from the get-go. The in-house microservice generator, at its core, is a series of AWS Lambda functions that are running in the cloud, built on the serverless framework. Access to each service is based on the principle of least privilege.

“We identified a set of similarities between our microservices. Based on that, we wanted to be able to create a boilerplate for each service that helps bootstrapping a new service very easily,” he explained.

Each of Jit’s microservices is based on a simple YAML file defining the extent of the service including plugins for monitoring, A/B testing and packaging. Each service also is spun up with linters, unit tests and integration tests baked in.

“A single structure for all these services is why we built this skeleton microservice generator,” Melamed said. In addition, there is a central continuous integration pipeline that is visible to all users. “We didn’t need developers to think about adding new pipelines for each repository.”

Their event-based platform includes some simple and shared infrastructure to collect metrics from any service and send it to a dedicated analytics service which includes dashboards to evaluate the usage and to monitor both new and existing features. So, any developer and any service, with just a line or two of code, can define metrics that are shown automatically. “That allows our dev teams to have very simple KPIs for each feature that they release because they can very easily add new metrics all the time,” he said.

Similarly, they have built-in capabilities for end-to-end testing.

Finally, they dogfood their own product for their own security coverage. “Based on the principle that developers get automatically a quick feedback loop to know the security of the code they are writing in the pull request. Devs get visibility into any vulnerability introduced into the PR,” he said because Jit automates the security into what their internal developers are building, just like it does for its external users.

Gates, Not Guardrails

What distinguishes Jit from the other platform engineering teams we’ve spoken to is that they don’t have a dedicated team. Instead, with about three-quarters of the company working as developers, they build on the go when needs and pains are identified.

Of course, so far, this is more of a gates-than-guardrails situation. “If someone would like to create a new service that would not use the same programming language or have some specific needs or wouldn’t follow the same pattern, that would be fine,” Melamed said, but they haven’t come to that bridge yet. He predicts a service going a bit off these rails would still kick off with the microservice generator, and “Then, if you want to change some things because you need to, you can. There’s no enforcement of these guidelines at the moment.”

He emphasized, “We all want to build things according to the same principles, but it’s not enforced in a rigid way. But it works so far.”

While Jit is a cloud native company, they’ve decided to further increase speed by testing and developing services on local environments — “to have a very quick feedback loop.” Melamed continued that they have invested in the ability to do local testing, and host in the cloud using projects like LocalStack, in order to provide faster feedback for developers, so there is no need to deploy every code change. He explains that this enables them to run their testing environment inside a simple container.

“You could have your whole cloud chain triggering several services inside AWS inside a single container because everything is mocked. And each service team is building their own mocks with very quick unit and integration tests, [which] help us ‘mock’ interactions with multiple cloud services and provide us with a great baseline for fast and cheap integration tests that do not require real cloud communication. But you are still doing your E2E [end-to-end] tests on the real services deployed in the cloud.” he said. Melamed emphasized that this increases team velocity because each of their currently four teams — of five to eight people each — needn’t depend on the knowledge of what another team is doing.

While the Jit founders didn’t realize platform engineering was a thing, Melamed observed, “I think we did that because once you’re using the cloud, you know you can iterate and do things very quickly, deploying things several times a day.” In order to achieve that, he argues, you need to have clear standards, principles and engineering hygiene, “especially when you’re using microservice-based architecture because otherwise it can be very messy and have a big overhead in terms of management.”

The upside is, once you’ve put in the platform engineering work upfront, Melamed said, “You can really build a product that is scalable by design on microservices, and you can build and develop for the cloud, helping your developers move faster by removing all the headache of things that are really standard.”