Runing TurboFloat Server in a container

Hey Jonathan,

No, you can't run the TurboFloat Server inside docker containers and we have no plans to add support for doing that.

[Note for other customers reading this thread: your can run *your app* using the TurboFloat Library inside Docker and every other container/VM type -- that is fully supported].

>> "We have a customer who has a mandate to run absolutely everything inside a container (no bare servers allowed). "

Oh, boy. Well, that's interesting. Hopefully they aren't doing it for security reasons (because if they are, they're in for a world of hurt -- Docker can best be described as a poor-man's VM with none of the security benefits of a VM but all of the pain of a VM).

The solutions:

1. Ship them an ARM version of Linux on a USB stick, put the latest Linux on it, and install the TurboFloat Server on it. Computer on a stick.

2. Run TFS instances from your own infrastructure or from hosted infrastructure that you control.

3. Wait for our hosted version of the TFS (coming late 2017 / early 2018 -- no hard date yet). The customer themselves will be able to spin-up TFS instances in the cloud and have full control over them.

You're right about Docker, of course, but as you're probably aware it's in the part of the hype curve where it's getting implemented everywhere without careful examination of the tradeoffs.

Unfortunately this particular customer runs disconnected from the internet (so #2 and #3 aren't viable), and is unwilling even to spin up a small server (let alone attach one of unknown provenance to their network). I'm not sure we'll be able to get licensing to work for them.

Appreciate the guidance, at any rate!

I'm the customer...

Oh boy, I just want to point out where you are wrong on a number of levels.

Docker for security? Are you having a laugh? We're doing it to drive down the operations costs of running snowflake hardware servers running shitty license servers. You know, when you're in the game of running production systems doing important tasks such as running a bank, there's such things as ops costs and we like to reduce these so we can stay competitive.

We just had a scenario where the license the software provider sold us (basically your license) became invalidated because we re-imaged the base cluster node. We may want to do this a lot. Because we like CI/CD.

But what would you guys know about that. You're all about "getting paid" right?

>> Docker for security? Are you having a laugh?

Im truly glad to hear I was wrong about that speculation. There are so many breathless articles about docker and usually the first feature these articles and comments wrongly tout is the security offered. Im glad you didnt fall for that.

>> But what would you guys know about that. You're all about "getting paid" right?

I know quite a bit about it both technically and practically. But I sense you were being rhetorical. And yes, getting paid for our work is important. But more specifically making it so our customers get paid for their work is the raison d're of LimeLM.

There are a number of options available to you. The cheapest option is running the TurboFloat Server instance from a real server in your control. Its incredibly fast, small, and efficient. Not to mention well documented: https://wyday.com/limelm/help/turbofloat-server/

I just said I don't want to deploy dedicated physical hardware. What if every software vendor required us to do that? How many snowflake physical servers do you think I would need to deploy? It's 2017. We run a modern computer cluster, with services described in code. So if you want me to deploy your licensing server, then ship it in docker and fingerprint the container, not the physical node. If not, your customer is not going to get paid. The cost of us deploying physical servers is greater than their license cost.

I get that you're frustrated with licensing in general, so I have a feeling you'll reject every option that doesn't neuter the entire point of licensing to begin with.

Long story short: putting a "floating license server" (whether ours, a competitors, or a home-grown implementation) on a docker container or a VM neuters the floating license server. The fact that there are software companies that don't properly implement licensing does not surprise me (I've seen some very poor implementations of licensing -- and I'm not just talking about in-house implementations).

But I digress.

So, you have the few options I listed above:

1. Run the TFS on real hardware. It doesn't need to be beefy hardware. The TurboFloat Server is incredibly efficient. The sheer number of development hours we've put into it and continue to put into it to make it fast, small, and efficient are reflected in the quality of it.

In short: you can run it from a $5.00 raspberry pi and it will hum along nicely. No need for a 64-core Xeon machine. Just a simple single core ARM board will work nicely.

2. Have Jonathan's company run the TFS instance from his infrastructure.

3. Wait for our hosted version of the TurboFloat Server to come out. You'll be able to spin up and instance on our infrastructure, control who has access to it (both to manage it and to get leases from the floating license server). This is coming late 2017 / early 2018.

Nope. Not frustrated with licensing at all. We actually procured the license early in the process so we can leverage support and kick start a professional relationship. I've worked in presales and know that an early sales win actually pays dividends down the track.

As I said, we operate a bank. We get audited, a lot. We cannot run core services unlicensed. There are entire departments dedicated to making sure we have the correct licenses. We don't like getting sued, it's not good PR.

As we work in a bank, we have spaghetti infrastructure, which is costly to manage. We are reducing that cost by containerising all our services, so they are portable. Portability gives us options in the future so we can move our services to different cloud providers.

To achieve this, we have to be opinionated about the services we deploy. The hard rule is that they absolutely need to run in a container. No exceptions. Exceptions get us back to spaghetti infrastructure and we haven't moved forward (I'm just relaying the rules to you, they are not dictated by me, but for me.)

For this reason, I cannot deploy a standalone physical hardware to run this service.

Your license server was actually running fine in Docker, in privileged mode which we pinned to a dedicated host. I'm ok to have these trade offs. What I can't have is a situation where re-imaging that base node invalidates the license. The team that manage our PaaS service need to be able to move their stack forward and the services running on that platform need to be able to tolerate updates. This puts us in a situation where the service can become offline at any point and the only solution is to reactivate the license, which is a manual process. This situation is entirely dumb ass.