Hacker News Reader

Comment by beat | Hacker News Reader

But it's not on a proprietary Amazon language! The three most common/dominant languages in the back end app development world are already covered. Why are you inventing a problem that doesn't even exist to complain about?

For that matter, any number of proprietary languages have been successful over the years. If it solves a problem, and solves it better and faster than reinventing the wheel, most businesses will use it. Time-to-market is a much bigger deal than abstract concerns about future platform change. I've been in this industry for 20-odd years, and the only things I've seen last are Unix and SQL. Everything else is new since I started. I sometimes work with bleeding edge, and I'm not afraid.

View on HN

I didn't say there is a proprietary language. I just said that the current trend leeds to total lock-in. After BaaS,the programming language is the only open piece of your stack. I hope you can see the difference between licese per core and cloud services. The cloud vendor can render your code/business useless at any time. You control nothing on your stack. Some are comfortable with that but I don't think it's a good thing for the industry or society. Proprietary software is sometimes a necessary evil but it's not really the case with BaaS. At leat not in the current form.

Since the language isn't proprietary, there's nothing keeping me from moving the functionality to a new environment but laziness. Take the business logic encapsulated in the serverless function and wrap it into a microservice, and run it anywhere. Not that hard.

That sounds easy but in reality you end-up rewriting 90% of the code. BaaS/serverless by its very nature is tightly coupled with the environment(in this case proprietary ecosystem). I think you also underestimating the effort required to migrate a "system". Migrating a service it's not the same as migrating 90 of such things. You need to make them cooperate in the new environment(authentication, communication API etc) not only to perform their task(i.e. crunch some data or update an entity). The only signifiant thing that you have from the previous system is perhaps the specification(hopefully you have a such thing).It has nothing to do with laziness. It's just a waste of time and energy. You could use that time to improve the current system not to migrate it to a different platform. You end-up with a rewrite. You will see it when it hits you. I've been all for managed services but lately I've started to change my opinion.

I've done far more exotic ports than that - wholesale platform rearchitectures (mainframe batch jobs to J2EE SOA, anyone?). I've dealt with obsolescence in some seriously painful ways. Nah, moving a bunch of serverless business logic in Python or JavaScript to a Flask or Node.js host? That's trivial. Authentication? APIs? Write a shim!

If infrastructure is really 90% of your code work and you can't salvage business logic in a platform change that doesn't require a new language, the problem isn't the serverless architecture.

It depends how tightly coupled is your code to the platform. You can't get more coupled than BaaS and thus the reason why I think proprietary BaaS is such a bad thing.

90% of the code is locked to the vendor?

I've been using lambda lately and perhaps 5% of the code in my Lambdas is AWS-specific; the vast majority was rapidly extracted from existing projects, wrapped in a simple Lambda interface, and done.

While I don't advocate Lambda for everything, there's almost nothing there to lock you in - its a simple function that accepts two parameters. Even coupled with API Gateway, its just moving my routes definition to a slightly different layer. I could easily port any of this work back to any common Web framework with almost zero effort. I won't, because Lambda solves actual problems for me now.

There's a great assessment. Lock-in risk would be negligible in that case.

Reply on news.ycombinator.com