These are the questions Mark Shuttleworth asked me and my replies.
What are the key customer problems to solve?
We aim to be the aggregator of multi-cloud world by creating an open framework that facilitates truly define once and operate everywhere. We don’t want laughable solutions that simply transpose cloud-specific variables into domain-specific-language which meant to define a subnet; you’ll have to repeat the almost-identical, yet-slightly-different keywords for AWS, Azure, and GCP. It’s what Terraform does, and what I’m proposing is what Terraform wants to be. An example would be like a Java VM or .net common runtime that translates print() into each platform, but the programmer would need to know only print(). What I’m proposing is a cloud compiler that translates cloud language like subnet() into different vendor code without human repeating.
What are the open source initiatives that we should pay attention to, participate in and build on?
I don’t think the above cloud compiler is available yet. All the open-source DevOps toolings are very rigid. Puppet/Chef/Ansible/Saltstack all had static and difficult-to-extend modules. What I’m proposing is a community-driven, yet commercially-maintained model where Canonical uses its resources to maintain the translation table, i.e. what subnet() means in AWS, Azure, GCP. At the same time, the tool is written with the community for constant feedback, and most importantly, open-sourced. We should also embark on collaborating with the cloud providers to define a discovery API much like swagger, but hopefully more intelligent where the services exchange XML definitions so that when AWS decides to define aws.subnet() differently, our cloud compiler can do the same.
How will Kubernetes operators evolve and how should Canonical work with those communities?
K8s operator is an interesting concept, but, it is still ultimately a multi-situational flow chart like a decision tree. It’s akin to an automation script that the operator keeps on adding scenarios. I believe K8s operators will be hugely successful for some time, then, everyone will start complaining about its limitations. I propose we participate with the operators’ community, and potentially transplant JuJu’s GUI which everyone loves to K8s. However, a separate stream that aims to fundamentally solve the problem, by using AI/ML to enable machines to learn from human operators’ actions, e.g. keystrokes, and work out the desired state on its own, to solve this problem fundamentally. I call this Operation Compiler.
How should Canonical work with public and private cloud providers to facilitate multi-cloud devsecops?
Cloud providers are frenemies. All of their business development executives are planning to bring out products that will hopefully give them the monopoly, and they ain’t cheap. Azure Security Center is US$18 per resource, and that’s easily a US$1 million per year cost to my last employer. Built-in to the Cloud Compiler, there’ll be an internal DevSecOps pipeline, again, our customers would call SAST(), and the Cloud Compiler would translate it to aws.SAST(), and with similar collaborations mentioned above, it would mean different things in different cloud providers. If we land on a new cloud, we can have a statically-linked ELF to provide community SAST scanning. I guess there isn’t many open source community SAST tool, except for Python from http://security.openstack.org.
Who are our primary competitors, what are their strengths, and how would we win?
Our primary competitors are both traditional vendors like Palo Alto, F-Secure, Nessus, and newish comers like Aqua Sec, Twistlock (acquired by Palo). Also, cloud-native SecOps/DevSecOps tools are our secondary competitors. They’re deeply rooted in enterprises, and while enterprises pay for them begrudgingly, they cost pretty pennies. However, unless there’s only one cloud, our community-driven, open-sourced multi-cloud solution will always be preferred by individuals, and from individuals, they influence teams, and then enterprises. Effectively, I’m proposing we create a blue ocean and leave the much crowded red ocean behind.