By Jack Wang
As you might have seen, last week we officially announced our investment in Profian. We here at Project A are super excited and grateful to be invited along for the adventure with Mike Bursell, Nathaniel McCallum and the amazing founding team in an oversubscribed $5m USD seed round along with our friends Illuminate Financial, Olivier Pomel (CEO of Datadog), Tyler McMullen (CTO of Fastly), Till Schneidereit (Chairman of the Bytecode Alliance) and Sarah Novotny (Board Member of The Linux Foundation).
Following a great piece from Rezso Szabo last week on the opportunities within the enterprise confidential compute market, below I will share a bit about Project A’s story as to why we decided to back Mike and Nathaniel on their journey.
We all have seen this before.
Going back in time at the start of the cloud native evolution, I was a junior software engineer in a big Australian investment bank. The devops tech-stack were pretty enterprise standard from the late 2000s — SVN for code repository, Cruise Control for CICD, lots of hacked up BASH scripts in between and we had an entire infrastructure team to make sure our Windows NT and Linux servers in the basement were running. For every new project I hopped onto, it took me at least 1 to 2 days to set-up my environmental variables switching and matching between server virtual machines and my laptop. Then another 1 to 2 days on debugging issues caused by environmental variables per month. On top of that there were also dev and prod environments, which depending on our infrastructure team’s luck — were sometimes the same.
Separately, like any good developer back then, my former class mates and I were watery eyed about the gold rush that were iPhone apps. To give you a benchmark, the most popular app back then was the one that let you pretend to drink beer (iBeer?). Naturally we tried developing our own apps in the hopes of getting rich fast, and we played around with the earlier versions of GitHub, CircleCI and AWS. Despite being nearly “cloud native” and hosting on AWS, our team of 3 to 4 still had constant issues getting our app to sync and run between various development and testing AWS instances and ultimately the end production instance. That was until we found Docker Containers.
I won’t go into depth regarding what a Container is, but this new level of virtualisation solved a lot of our devops related problems mentioned above by unifying our application environments at a micro service level. Today, containers together with Kubernetes is a hygiene factor for any cloud native development.
And we will see it again.
Today, for a developer looking to build microservices / applications that requires absolute security in compute then the developer experience is a time warp back to the pains I described previously. Intel, AMD, ARM, NVIDIA and IBM have invested heavily into their respective hardware solutions for confidential compute which created a layer of specificity and lock-in at the bottom of the tech stack. Furthermore cloud providers like AWS, Azure and GCP have taken on solving this problem awkwardly — by virtualisation and requiring developers to use their SDKs, which of course locks them into their respective cloud platforms. Then there is the requirement to support different programming languages.
Mike and Nathaniel created Enarx during their time at Red Hat to solve this exact problem. Enarx is the Container for anything confidential compute — CPU agnostic, cloud agnostic, program language agnostic. Enarx is open source like Container and can be orchestrated by Kubernetes. Profian is the custodian of the Enarx open source project and the company everyone look towards for commercial relationships with Enarx. Unlike Containers, Enarx is ultimately a security middleware and has a labyrinth of cryptography around the virtualisation layer. This is also one of the key reasons the project is open source as “audibility” is key with anything enterprise security related.
I will also not go in too deep around the use cases for confidential compute, Mike does a great job at this in his blog which I frequent. It is our vision that Enarx will be used for anything from keeping private keys safe in compute by cryto-exchange to computing secure patient medical data for analysis. We hope that some day soon, a developer can simply tick a box in their CICD tool to switch between Containers for microservices using normal CPUs and Enarx for those requiring confidential compute.
Of course, we are ultimately backing the team.
For those readers that are plugged into the confidential compute ecosystem, Mike and Nathaniel’s reputation speak for themselves — in fact during our independent reference checks it was quite difficult to find someone who haven’t heard of them. While their technical expertise are second to none for this endeavour, I wanted to share a bit of thinking from our side as to why we ultimately believed in this pair of amazing founders.
Something taken for granted is that enterprise security software engineers are often not young in age. Outside of the whitehat blackhat penetration testers (hackers), usually an enterprise security software engineer would’ve started their expert track after 5 to 7 years of general software experience. So founders in the deeper tech security software category tend not to fit the 2 years out of FANGA engineer profile that VC investors naturally gravitate towards that tends to start “No-code” and “Low-code” abstraction layer start-ups (which are also cool).
We ultimately decided to back Mike and Nathaniel because despite both of them at the top of their corporate ranks, along with financial responsibilities that comes with mid-career professionals, Mike and Nathaniel both felt so passionate about the Enarx project to embark on the wild adventure of founding a start-up and risk it all. This motivation, combined with Mike and Nathaniel’s unequivocal expertise was more than enough to convince Project A to join their adventure and we are grateful for them having chosen us as their investment partner.
If you are building a “Lots-of-code” start-up and what you liked what you read, please do reach out to [email protected] as I would love to speak with you!