I like it, this is clearly very enterprisey and solution focused, but I would like to suggest a couple of amendments if I may?

• Namespaces We should make full use of namespaces. Make the structural tags be in a language specific namespace (to be referenced in every function spec, obviously) but change the in an out params to use the parameter name as the tag, namespaced to the function they’re for, with a type attribute.

• In memory message queues Have all function invocations be marshaled as xml documents posted to an in memory message queue. Said documents should use a schema that validates the structure and a function specific schema to validate the types of arguments being passed. Namespace everything.

I reckon we could power a medium sided country if we could generate energy from the programmers despair.

It’s the same problem with a drive like this, or any long term archive, you either store the data unencrypted and rely on physical security, or make sure you store the encryption key and algorithm for the same length of time, in which case you still need the physical security to protect that instead. In both cases you need to make sure you preserve a means to read the data back and details of the format its in so you can actually use it later.

Paper is actually a pretty good way of storing a moderate amount of data long term. Stored correctly it’s unlikely to physically degrade, the data is unlikely to suffer bitrot and it can be read back by anything that can make an image in the visible spectrum. That means you can read it, or take a photo and use OCR to convert it into whatever format is current when the data is needed.

That’s the thing, ‘cloud’ is just another tool in your toolbox. It’s the right tool for some workloads and the wrong one for others. The fact they’ve shifted the work to their own servers and kept the ops team suggests it was the wrong sort of workload to be in the cloud in the first place.

For a while there was an obsession with moving everything to the cloud, and that was always going to be an expensive mistake in a number of different ways. Hopefully, as the hype dies down more nuanced decisions will be made. There’s a whole gamut of options between all in the cloud and all in the data centre, and when people jump straight from one end to the other I’m put in mind of Hamlet’s quote “There are more things in heaven and earth, Horatio, / Than are dreamt of in your philosophy.” Understand your workload, understand your business’ future plans and their needs, and then make a plan, considering all the tools at your disposal.

That’s the thing, ‘cloud’ is just another tool in your toolbox. It’s the right tool for some workloads and the wrong one for others. The fact they’ve shifted the work to their own servers and kept the ops team suggests it was the wrong sort of workload to be in the cloud in the first place.

For a while there was an obsession with moving everything to the cloud, and that was always going to be an expensive mistake in a number of different ways. Hopefully, as the hype dies down more nuanced decisions will be made. There’s a whole gamut of options between all in the cloud and all in the data centre, and when people jump straight from one end to the other I’m put in mind of Hamlet’s quote “There are more things in heaven and earth, Horatio, / Than are dreamt of in your philosophy.” Understand your workload, understand your business’ future plans and their needs, and then make a plan, considering all the tools at your disposal.

It currently depends on which client you’re using. The devs are working on building it into the server side, but at least ‘connect for lemmy’ on android allows you to block instances yourself.