September 4, 2019

Good Bye Turbo.net

I left my work at https://turbo.net this month, taking a break before looking for a new opportunity. Some reflection of over 6 years working there.

Turbo-lent Years: Heavy Evolution of the Product

When I joined Turbo.net it was known as Spoon.net. It could launch sandboxed Windows apps and provided a Dropbox liked sync service. During my time we introduced Turbo.net application containers. Think of Docker containers for Windows desktop apps.

After the Desktop containers system was running, we started to implement cloud remote applications. That allows you to launch Windows apps on your iPad, Mac, Windows and any HTML5 capable browser. Turbo.net provisions and manages Windows machines for you to run the apps on and uses the app containers to move apps onto the blank Windows machines. Your organization doesn’t need to manage Windows machines. You launch the app and use it.

Turbo.net History
Figure 1. Turbo.net History

Turbo Development

With the evolution of the product, I worked on tons and tons of different areas. We worked on a crazy amount of different ideas, prototypes, and features. The team at Turbo.net is the most productive team I ever saw. I mostly worked on the backend services, but since Turbo.net is a small team I touched nearly every piece over the years. Some of my favorite pieces:

Sync Engine

The sync engine allows to incrementally sync changed files of apps across machines. When I joined it behaved like Dropbox and synced user files one file at a time. Over time we made the syncing got faster and added extra features like encryption, local caches, CDN support and so on.

With the introduction of containers, we changed the sync mode. Instead of behaving like Dropbox the sync takes consistent, atomic snapshots of a directory. Think of Git commits.

Turbo.net Sync
Figure 2. Syncing containers

Storage

The storage backend used for the syncing and apps stores deduplicated blocks of files. It was in place when I arrived and it is a great base architecture. I worked on improving the indexing of the blocks, improved the performance by improving the access patterns etc.

Also, we introduced distributed block storage to store the blocks on different machines. It did its job and survived dead servers. As ZFS for Linux matured we replaced the replication with a rock-solid ZFS pool.

Block Storage
Figure 3. Storage

More Storage

Yes, there is more storage. Besides the block storage, there is a 'structured' storage system, basically a hierarchical file system with pointers to the block storage. During my time we extended it and made it more solid. We added a permissions, quota support, improved the performance etc.

The Container Support

I mostly worked in the backend but for for a while I worked heavily on the command line client running turbo containers. We added dependency support to share common pieces of software like .NET or Java across app images. Integrated the client with the Turbo.net hub for images and container state. And many more features.

Containers
Figure 4. Containers

The Cloud

I didn’t enjoy working on this part that much. Mostly because it involved tons of automation of Windows installations and Azure provisioning which I do not enjoy. However, I’m still proud that we pulled this off.

Of course, there are also enjoyable pieces to this. The actual handling of the requests, app launches, and RDP sessions is fun.

Cloud
Figure 5. Cloud

Network Tunnel

One great features of the Turbo.net cloud is bridging an app to your local network on a per-app basis. So you can launch let’s say IE with Flash on the Turbo.net cloud and open a legacy webapp on the companies intranet.

We didn’t spend a lot of time working on it, because it just works. However it’s a awesome feature and nice to work on.

Network Tunnels
Figure 6. Network Tunnels

Tons and Tons more

I had the joy of working on many more features. From analytics, authentication, billing, machine keys and all the things if forgot.

Lessons Learned

Well, I first had to adapt to the fast pace. I moved from a database vendor which focuses on stability, correctness and backward comparability to a startup. I learned that months of hard work maybe wasn’t the right direction, but we can take the pieces which worked and start over. Well, now Turbo.net is on the way to get more stable as the product matures =)

Turbo.net uses a wild mix of technology, so you get to meet experts in different fields. The people creating app images, having a 6th sense what files, DLL and registry are needed to make an app work. The VM team will guide you through the Win32 jungle with an extra tour of DLL hell, COM-munist partying and registry-GUID-ing. The web-frontend guys will tame browsers and node.js. .NET people are getting Shh---Stuff done in web APIs and Windows clients. And people are getting RDP to work on every platform, from HTML5, iOS/Mac and Android. You won’t stop learning.

Turbo.net Team
Figure 7. Turbo.net Team

I also moved from a unit test friendly code base to code base without test automation. So I learned a lot how to get that code under test. With mixed success. However, I really like to test at a system boundary now, like at the REST API level, assuming the tests still run quite fast.

And of course, I learned tons of technology stuff: Ansible, .NET/Windows, Scala, introduction to the Node.js ecosystem, Powershell and so on.

Tags: turbo.net