Hello, Vino
An application platform honed by attackers
--
I’ve been heads down for a long time and I’m finally able to come up for air. World, meet Vino Technologies, Inc. We’re building a composable application platform. A platform that gives back what you put in and makes us all faster the more we use it.
I started Vino with a former colleague, Bei Zhang, because we wanted to make building global software more accessible to everyone. Building applications that meet modern expectations is expensive, slow, and riddled with hidden costs. Doing everything yourself means burning cash to re-solve solved problems, while depending on SaaSes, PaaSes, or AaaSes is a race to realize value before bills come due. Neither encourages healthy, steady growth.
We wanted a platform that treated generic functionality as a commodity. Where you could drop in or swap out code with ease. We wanted applications that scaled and tested themselves. We wanted to “get it done” with enterprise quality and we wanted it cheap. So we built Vino.
The crux: waste
In any given application, what percentage of code do you wager is unique business logic vs boilerplate, integration, tests, or otherwise? 50%? 25%? As low as 5%? All that overhead produces no differentiable value yet costs real money and increases the surface area for friction and security vulnerabilities. That’s just the code, it doesn’t even account for configuration. Add YAML and the wheat vs chaff ratio drops like a rock.
Much of what we build amounts to todo-lists of public best practices anyway. When the choice is do it the right way or do it the wrong way, it’s not really a choice is it?
If you’re following my blogs then you’re technical. You already feel this. You know that features like user authentication aren’t that different between every site. How many ways can you really store a user record? There are a handful of indistinguishable “right” ways and thousands of wrong ways. If our code was more portable then we’d simply reuse one of the right ways. We wouldn’t have to build it ourselves or pay a SaaS monthly. Complete functionality would be portable and work anywhere.
It’s not idealistic to think of code that “just works” with other code, we reap the benefits of it daily. The web browser you’re reading this on still renders pages made in 1991. We don’t refactor the entire web when Chrome updates or reconfigure the browser for every site. We attach mice, video game controllers, network adapters, printers, and even monitors daily because the USB protocol makes hot swapping black boxes of logic trivial. Reliable, durable software relies on concrete protocols to insulate the effects of change. They’re never perfect, but the value they guarantee makes up for their flaws.
Vino adds protocols to code.
How Vino works
Vino standardizes logic into black box containers of WebAssembly that communicate over ports. Not network ports, code ports. Think of them like named streams that represent any possible parameter or return value. It doesn’t matter if a component is asynchronous or synchronous, if the data is finite or infinite, partial or whole. It all transports the same way. Output ports connect to like input ports on any other component. You then build up functionality into pipelines (“schematics” in Vino lingo) with data flowing from one end to the other.
Schematics have ports as well and can connect alongside components to nest functionality deeply. If you consider components as analogous to software libraries (i.e. npm modules, rust crates), schematics are ready-to-use implementations. Applications then become collections of schematics. Schematics and components are completely reusable so share and remix like it’s TikTok. Want to update or test new functionality? Replace schematics with anything that has the same ports. Want to monitor a schematic? Tap into a port. Integration test? Pipe input from production to your new schematic and assert the output matches.
Vino’s schematics are code and translate to a flow-based GUI. Standard protocols make smart UIs easier across the board. Build internal management UIs without compromising your engineering roadmap.
To scale you have to delegate. Each of us gets the same 86,400 seconds every day. No one gets more. Vino consolidates heavy engineering into components and makes applications an act of composition that can happen at multiple levels.
How you code a Vino component is up to you. You just need to compile to WebAssembly. Make it look as functional or procedural as you want and keep using the IDEs and tools you’re used to today.
These concepts have roots in the way we already build applications today. Message queues, functional programming, event emitters, and even piping processes together on the Linux command line all use these concepts. They’re different ways of transporting data asynchronously in one direction.
This foundation of components, schematics, and ports is the start. Protocols allow us to build bolder. We can make smarter, more capable systems. Schematics let us share complete functionality and build applications that know how to scale themselves. Have a bottleneck somewhere? Automatically scale a component to multiple threads, servers, or even clouds. We’re doubling down on WebAssembly so you can make one application that distributes itself across server, edge, and client.
How attackers helped build Vino
Our frustrations aren’t new. This excellent presentation from Bret Victor describes these concepts dating back decades.
Our solutions aren’t new either. Bei and I along with countless others have applied these ideas since the dawn of computing. What’s different now is that we’ve seen all the ideas come together in action.
I worked with Bei for seven years at Shape Security. Shape sold protection against attacks that cause millions in fraud losses. These types of attacks don’t have a permanent solution, attackers target the applications themselves. You have to detect and deflect motivated criminals 24/7. It was a hard problem made harder because Shape was a critical hop in Fortune 500 networks. A minute of downtime could lead to millions in losses. Changes required layers of approval and months of lead time.
Shape had to win a battle of speed and adaptability while operating with the red tape and risk aversion of large enterprise. We had to be correct 100% of the time, never break anything, and absorb Starbucks level traffic for every customer we added. All while dynamically fighting bad guys across web, iOS, and Android. Every customer was a unique snowflake and every attacker defied our expectations.
It was an unwinnable battle in an unfair, hostile arena. Yet we won, time and time again. We didn’t do it by building a security product. We won by building a general application platform that could adapt, safely to anything across any platform in seconds. We built an airplane while flying with duct tape and glue, but it worked and it landed. F5 bought Shape for $1,000,000,000 dollars in 2020.
Shape wasn’t the birth of Vino’s ideas, it was an incubator for extreme experiments. Shape targeted a valuable problem that Google tried to solve but failed. We had the freedom to be bold. We spent seven years testing ideas in the most inhospitable environment I could imagine and ended it with a success story. A lot of people contributed to Shape’s success, but the platform is what gave Shape the flexibility to safely adapt at the drop of a hat.
Now we’re combining those lessons with modern technology to build Vino.
Where we are now
We’ve knocked over every technical hurdle that we identified as a deal breaker. We are now opening up to talk to companies who want to outsource development that we’ll build on Vino. We want to partner with companies that fit our direction while we iron out the experience. If that’s you, send me an email!
We’ll open up to beta users when we get to a steady state. Stay tuned here, @vinodotdev on twitter, and at vino.dev for information.
Until then, we’re dedicated to boostrapping you into the WebAssembly ecosystem with content and tooling, starting with an introduction to waPC. Next week we’ll go over compiling your first WebAssembly guests followed by a tutorial on building a waPC host in nodejs.
Special thanks
The WasmCloud and waPC teams have been instrumental in helping us get to a reality. When we started building a distributed, WebAssembly-based platform, there wasn’t much precedent to look to. We were glad to commit to WasmCloud (then name wascc) early when we saw their roadmap overlapped with our own plans. The engineering lead, Kevin Hoffman, has been on the bleeding edge of scaling applications and microservices for years and is someone you should follow too!
