I am thrilled about our launch announcement and partnership with AWS. But I'll resist the urge (just for a bit) to dive into talking about the service we announced today.

I'll spend a few moments to share our beliefs, and where we're headed with Katanemo.

The team at Katanemo has operated at the intersection of cloud infrastructure and modern SaaS applications for over 20 years (each).  We are deeply inspired by builders who help others harness their full potential through software, but frustrated with the state of innovation on behalf of developers. To cite a few sources:

• Flexera 2022 State of the Cloud Report: This report found that 67% of developers find cloud infrastructure to be complex and difficult to manage.
• Cloud Complexity Index 2022 by New Relic: This index found that the average cloud complexity score is 4.5 out of 5, with 5 being the most complex.
• Cloud Native Computing Landscape 2022 by Cloud Native Computing Foundation (CNCF): This report found that 63% of developers are using multiple cloud providers, which can make it difficult to manage and secure their infrastructure.‍

The developer world is littered with more infrastructure choices, more “workshops” about infrastructure, and more confusion. Having chatted with hundreds of developers as part of Katanemo’s journey, I am convinced that the future of infrastructure, is no infrastructure. Stay with me, I’ll explain this more in detail.

‍

‍

A quick note about us and why we are passionate about developers. We recently left AWS, Microsoft, Meta and Lyft with decades of operating experience at the intersection of large-scale infrastructure platforms and SaaS applications. We have been fortunate to build planet-scale services like S3, Dropbox, and the infrastructure that enables Lyft rides to arrive on time, every time. We have built the cloud, and on the cloud - a unique vantage point that gives us empathy and a perspective on what the world could look like on behalf of our peers. We are now compressing our experience in a platform squarely aimed to delight developers building modern SaaS applications. 

How did we go from Amazon S3 to this?

‍
Today, developer services that inspire us are Netlify with JAMStack for front-end development, CloudFlare for workloads at the edge, and emerging start-ups like Vendia that are thinking about smart APIs. But given this teams’ first-hand experience in building Amazon S3, it's worth talking about the service that started it all. With simple http APIs, developers store trillions of objects and serve them to customers across the globe in seconds. Amazon S3 didn’t impose itself on developers, and didn’t take developers outside their playground: the IDE. Nothing about it felt like “infrastructure”. The ethos of Amazon S3 guides us daily.

But somewhere along this cloud infrastructure journey, the spirit to delight developers seems to have died. The cloud infrastructure world is littered with primitives, without a clear vision on how to simplify this growing complexity.

I recently came across this picture of Ameerpet, Hyderabad. A hub for training software professionals about tools and technologies they need to be successful in the workplace. Much like anyone walking those streets won’t be able to make sense of what tracks to pursue, similarly developers around the globe share with us a growing frustration with cloud infrastructure. They wish to return to simpler days and escape today’s world flush with complexity, vendor noise, and technologies that feel like a “cluster ….” - pun intended.

‍

‍

Belief #1: Unified experiences over fragmented primitives
‍

Our core belief is that we can’t continue to approach developer innovation with primitives, and must certainly fight the temptation to introduce new ones. This playbook worked well back in 2006, where a tight coupling of application code to infrastructure created headwinds for platforms like Google App Engine. AWS won, and everyone followed their investment vector since: build primitives, deploy navy-seal architects and win workloads. We must (as a community) escape this thinking and boldly innovate on behalf of each other.

To truly delight developers we must approach innovation with unification in mind, without having developers retool or create new operational muscle. We will seek opportunities to compress development workflows so that developers can stay focused on what matters most to their business: building features and innovating on behalf of their customers.

‍

Belief #2: An obsession with open standards

‍
You are probably thinking how does Katanemo intend to replace decades of infrastructure innovation with a new approach without missing critical functionality? We believe that we are at the cusp of a critical inflection point in technology thanks to open standards: Open Container, OpenAPI, OpenTelemety, OpenTracing, OpenID, etc. Developers should be able to express meaningful business outcomes and have a system intelligently manage the underlying infrastructure without exposing the configuration or operational muck to developres.

We also have a firm conviction about the serverless mindset. But our belief is that “serverless” falls short of truly delighting developers. It's a great start, but requires upstream tooling trade-offs (functions vs. containers?), imposes non-functional concerns like cold starts on application developers, etc. It's not enough because there are other pieces of infrastructure you must still deal with: networking VPCs, security groups, certificates, control plane vs. data plane identities, etc. Our belief is that the future is not serverless, it's infraless (no infrastructure). This notion may sound cheeky at first, but our hope is that we delight enough developers that it will be a rallying cry for developer-focused innovation in the future. And I hope you join us in this journey to make it a reality. 

‍

Belief #3: Purpose-built for use cases and market segments

‍
Because we are a start-up, we must focus on a set of developer personas that have expressed unbearable pain with infrastructure. These are open source projects looking to offer a cloud service, mid-market ISVs that want to punch above their weight class, and every enterprise app company transitioning to true API-first SaaS businesses. Innovation on behalf of SaaS developers seems to be trailing at least ~5 years behind from what consumer application developers enjoy today. Our approach to software will be purpose-driven and hence our software will be purpose-built. We are very motivated by the cohort of (SaaS) developers and have made it our mission to help them ship delightful, enterprise-ready applications in minutes. 

To be fair, there is a lot to unpack in calling something “enterprise-ready” or “enterprise-grade”. We’ll explore this a bit more in our next post, but our offerings must serve a clear business purpose. For example, developers express a great deal of anxiety in having to build the on-boarding infrastructure where enterprise customers can seamlessly subscribe to services, author rich access control mechanisms in self-service ways and provably audit access to achieve compliance attestations in minutes. These developers are looking for an easy button for product-led growth, and are left to their own devices to construct an experience that is simple to interact with, seamlessly scales, and is strictly accurate and secure. 

‍

Belief #4: Delta 4

‍
You might be thinking that for a blog post labeled “future of cloud infrastructure?”, how come there is no mention of “Multi-Cloud”, “Platform Engineering”, or Kubernetes. In full disclosure, we are big fans of the container orchestration work pioneered by Kubernetes, and inspired by the community around it. But we feel that the industry has fallen into a cycle where the soul of a project or the spirit of invention has started to feel incremental, or worse serves the wrong purpose. For example, to some Kubernetes is cloud lock-in prevention, and for others it is a means to standardize teams on a common set of abstractions so that those teams don’t have to learn AWS and Azure constructs separately.  

We are motivated by this notion of Delta 4, where our existence must create at least a factor of 4 efficiency. To use cloud computing as an example, the original manifesto had these (and I paraphrase) beliefs: just-in-time provisioning, paying for what you use, illusion of infinite scale, and moving from CapEx to OpEx, etc. When we think about building a new development platform on behalf of developers we ask ourselves how we can offer new efficiencies that are markedly different from the incremental innovation happening today. We'll talk about the specifics of our Delta 4 approach in later blog posts, but today close with this notion that we must create developer delight and efficiencies that don't feel incremental.

Lets Build!

‍
Coming back to our launch announcement and partnership with AWS, we began the re-invention process today on behalf of developers via our powerful identity and fine-grained permissions service - enabling developers to instantly build internet-scale prviacy features and unlock great collaboration; two simultaneous transitions happening in the SaaS industry. Our first service represents a critical part of the stack we are re-imagining at Katanemo, and the team is tirelessly building out the other portions that deal with infrastructure orchestration, instrumentation, and extensions.

‍

‍