The problem I see is that the OPS code has outgrown your actual application code. This application code you own, and can be open software. But the deeper you go into the cloud/serverless landscape, the less of your actual product you own and the more you're locked into someone else's. I guess I could be considered old-timer by now and although I can see benefits in the New Way, better ways of doing some things, it's the conditions as currently imposed by business models I've got a problem with. There's a smell when you think you're writing software but are really assembling an Amazon App (tm).

You're tying your own software into somebody else's all-encompassing and potentially hostile (to your business goals) framework instead of preferring the library way with clearly defined and exchangeable interface boundaries.

Doesn't bode well if your OPS tools have one company's name in them.

Sort of like unlearn a man to fish, and he'll be depending on you forever.

> You're tying your own software into somebody else's all-encompassing and potentially hostile (to your business goals) framework instead of preferring the library way with clearly defined and exchangeable interface boundaries.

We experienced that recently, moving our ETL jobs away from a Hadoop cluster managed by a sister company that was having some issues (as in "all our data engineers resigned half way through a long overdue cluster upgrade, now nothing works")

Our data science team found Amazon Glue and fell in love with its ease and simplicity...

...and then spent three months trying to figure out why everything kept breaking. TL;DR - Glue's DynamicFrames come with a bunch of caveats and mousetraps, and a severe lack of documentation or source code.

Oh sure, you can read the Python source code for a DynamicFrame... ...source code that promptly delegates computations to a Java class you can't get the source code for.

After a few months of our experienced data engineers (myself included) saying "Just write a Spark job and run it in EMR", they finally did, and now everything's fine.

But the initial simplicity of Glue got them hooked, and they threw good money after bad on it. And as for those goddamned Glue crawlers...

TL;DR - things like Glue are great for early prototyping, but they tie you down to the AWS APIs and infrastructure. At least with EMR the Spark job you're running could be easily switched to another provider's infrastructure or your own infrastructure without any heavy refactoring.

As a small-timer I don't think I'll ever cloud up. Managing a few servers isn't too bad, is easy to maintain (from both a developer and "dev-ops" standpoint).The cloud abstractions would have been great before Ubuntu's LTS 8-10 year schedule, Nginx and Systemd. But now it's just so simple using those and my existing architecture to launch new web services.

Yeah, going into the cloud has great benefits that cost a shit ton.

We're migrating from a traditional DC into AWS because a) our current DC provider makes stupid mistakes that impact us severely and b) it's pretty easy to spin up the same K8s cluster in two availability zones to ensure we're (very nearly) always up.

Stupid mistakes list - "Oops, one of the disks in a machine in your Couchbase cluster had to be replaced, and we replaced the wrong one!"

"Oops, we lost your machine. It's responding to pings, but we can't find it, so we're going to have to go through the DC pulling plugs to figure out where it is"

"Oops, our sys-admin accidentally deleted your OpenStack deployment because he was testing something in the wrong window."

And this is the best DC we've managed to find in Europe over 12 years of operating there.

Going into AWS will nearly double our infrastructure costs, but our business is willing to pay for it for the reliability factor. No point having a self-healing k8s cluster if the underlying machines disappear because someone typed a command in the wrong window.

And when you want to change from AWS, you are completely locked in, no?

If you use one of the open serverless frameworks such as OpenFaaS (which is what this article is about) then no you're not locked in.

BTW my team has investigated OpenFaaS to be able to share code between the cloud and local installations, and if we do OpenFaaS looks promising. The architecture is well documented and makes sense.

Using OpenFaaS on AWS doesn't exactly alleviate all of the lock-in. It locks you in to a larger spend. This is because OpenFaaS is heavily dependent on, generally, a k8s cluster that is going to be chewing through bill time 24/7. I think that's the trade-off: you pay to not be locked into Lambda. Personally I don't think that's a bad thing, but I've seen plenty of times where customers would balk because their initial serverless trials cost $5, $10, $15 a month but when running something that would be better for them longer term it would initially be 4-8x that in opex. So they go the "easier" (cheaper) path and build everything around that lock-in tooling.

I think serverless framework and openfass are trying to make it so its not so locked. But yes you are locked with aws.

I suppose, in my experience, the amount of code you need to write to get all that stuff to happen without manual intervention is usually much greater and more complex than just creating a couple instances and ansibling your code onto them. The "you don't have to manage infra!" wave is technically true, but it's not that you have to manage less, just what you manage is different.

Okay so, serverless means that "I don't manage the servers that my stuff runs on."

Why don't they just call it "Sysopless" or something?

Because lots of companies have been hosting infrastructure elsewhere, with real managed servers or complete racks as unit. Now you supposedly don't have to know or care anymore that there actually are real servers and real infrastructure beneath your software.

Yeah, it's the supposedly bit that gets me.