[TSTIL] Sandboxes

First published on

[ This is a part of "The Software That I Love", a series of posts about Software that I created or had a small part in ]

2014 - Sandboxes

Derek had a dream for the Mendix trial and he kept talking about it. Sandboxes. You could already try Mendix for free, create an app and run it on your own PC. But you couldn't share your apps to your colleagues. We needed a trial environment in the cloud. Derek was an excellent CEO because he had a clear vision which he kept repeating. He said what users needed and didn't micromanage the solutions. For all I know the higher-ups might have experienced a different side of him, but being at the bottom of the food chain this was my perspective. I have tremendous respect for him.

We could not have thousands of free apps running on our infrastructure, costs would go through the roof. Serverless didn't exist and the Mendix runtime was quite heavy. The only remaining solution was what Heroku did: stop the app when not active and resume it when traffic came in. I had learned a lot while building the Mendix Cloud and during the interview process at Facebook. Armed with this knowledge and Derek's vision, I had a spark and realized how we could copy Heroku's feature. We could send nginx traffic to a mini app that would start up the main app. When started we would rewrite the nginx config to send traffic back to the main app and trigger a reload. I spent the weekend thinking and tinkering, and at the end I had a prototype of an app that could be resumed when traffic came in. Stephanie didn't see much of me that weekend. It was awesome.

On Monday I was like an overly enthusiastic kid and told everyone that we had the final building block for a solution. Somehow it got on the roadmap. I had no idea how that roadmap process worked, to me it was all energy, inspiration and magic. Actually that building block was just one tiny step for the Sandboxes release. Because it was the only "magic" part I focused on that, but there was so much more. We still needed:
  • Cloud infrastructure that could support dynamic re-assignment of apps to virtual machines.
  • A "last request" counter in the runtime.
  • A deploy button in the Desktop Modeler.
  • A "your app is resuming" page.
  • A runtime license for the free apps.
  • An SSO service for inviting your colleagues.
  • MxBuild, a cloud based compiler for the apps (not sure why it was needed, but we did build it around this time).
The MxBuild project was interesting, Benny and I had built it on a research day once, and it was the best pair programming experience I've ever had. He was building the Mono executable, and I built the python code that called it. For some reason we were so well attuned to each other, that we would see the other side of the API being typed on the other person's screen, and typed the other side on our own screen. An error popped up on my PC and Benny would fix it on his without a word. With hardly any explicit communication the entire thing just spontaneously came into existence. Two minds working as one, it was really beautiful.

But back to the sandboxes release. We also needed more hardware! The co-location data center in Amsterdam was getting full so we needed to add a couple more servers with a lot of memory. For that we needed the CFO to sign off on a couple $100k in infrastructure costs. That was difficult because we knew we were going to the Cloud soon. Derek had been saying it for years. Why did we need more money now for hardware? Well, the "real cloud' would not be ready for about two more years. Thanks to Hans' and Pim's engineering we had a super cost efficient infrastructure in co-location DCs. Bert (the Head of Finance) asked us some questions and explained some financial models to us, that was enlightening. We figured this was actually a great investment and AWS was going to be very expensive. Oh well. It would still be making us money.

It's pretty cool how we engineered this mega feature with effort from so many R&D teams. IIRC the launch went great, but quite quickly the VMs we used were filling up. Within a month or two I needed to hack a script to delete unused sandboxes. We kept doing that until the launch of Free Apps, about a year later. The infrastructure behind Sandboxes was a stopgap solution until we had Mendix Cloud v4.






Comments

Post a Comment

Popular posts from this blog

"Security Is Our Top Priority" is BS

First published on
A couple of years ago I was asked to give a conference talk about software security. Well, actually I wasn't really asked, my company bought a sponsorship package with a speaker slot and I replied to the internal email asking for volunteers  🤣  Anyway, while preparing my talk, I realized a couple of important points about security that have not left my mind since: Security is limitless . You can always spend more effort to make things more secure. The same goes for quality, safety, employee happiness, etc. The needs of security are opposed to the needs of a convenient user experience . Improving one typically hurts the other. Now some organizations say "Security is our #1 priority". Really? You want to make something that has no limits your number one priority? I mean security is a good thing, but this seems a bit too simple? In fact, hollow marketing claims like that can make me a bit angry. In this post I'll help you understand what to make of statements like that...
Read more

AI programming tools should be added to the Joel Test

First published on
Here's a wake-up call to all CTOs: AI programming tools are getting freaking amazing and if you don't allow your teams to use them somehow, it will bite you in the ass in a couple of years. You will be slower and you will lose your best people. The infamous Joel Test is a list from the year 2000 of 12 things all great software companies do. Since then most companies have implemented Git and CI/CD, checking of three items, so we have some space left in the 2024 update ;) I believe "Do you allow your developers to use AI assisted development environments?" is a necessary addition. I get that you don't want your source code to end up on some OpenAI / Microsoft / Github server somewhere, sure, but find a way to use your own models or learn to live with it. Note that this is often not the same as "#9 - Do you use the best tools money can buy?" as blocking AI tools is about data security, not money. So why do I think developers need AI programming tools? I...
Read more

The long long tail of AI applications

First published on
Image
Last year multiple companies asked me for advice. " We are evaluating this AI powered product, but do you think it makes sense at all? It seems a bit niche and we think ChatGPT might make this entire thing obsolete soon. " Long tail - credit to Wikipedia My answer so far has always been: "No, bare LLMs are not going to compete with this product." I think that people are failing to understand the distinction between different classes of AI companies. I see it like this: Foundational AI - creating models like GPT-4 (text), Sora (video) etc. Applied AI - using existing models to create smart applications. Note that there are also companies not focusing on AI - they will start lagging behind, let's forget about them ;) There are orders of magnitude  (!)   more companies that will deal with Applied AI than Foundational AI, and they will be very busy for decades to come. Here's why: To get the most out of LLMs, you have to ask the right questions. LLMs have acc...
Read more