[phatbyte]

Maybe I'm old school, but I really hope developers give a serious thought before jumping into this vendor lock-in trap.

This is specially concerning if not scary, when you start to "outsource" the backend business rules to something like Firebase or other BaaS systems.

Using these as PoC or for an MVP, I'm 100% behind it, but using it on production ready products, it's a disaster waiting to happen, as it basically puts your company product under someone else's rules, and if those rules changes or worse, if these companies go bankrupt, migrating to another system could be the death of your product as well.

I'm not against BaaS, I think they're very useful, for prototyping, for micro-services that don't directly affect the main product business rules (image processing, chat app, etc..) but putting all your "gold eggs" into a vendor system should be taken after a serious thought of the pros and cons.

[cjsuk]

100% agree with you.

No one accounts for portability. The common mantra is that if portability becomes a problem you will be rolling in VC cash so you can just afford to restart everything from scratch and shrug it off. Basically defer the complicated decisions to later on.

That never accounts for the "grey phase" which a lot of products seem to slide into permanently which is where they are just about scraping by with no investment at all. At this point, the decisions affect your bottom line badly because scaling up customers means an instant cost and geopolitics can mean sudden revenue decreases.

You need to plan for a partial success and a partial success can't handle vendor lock in.

I'd argue, after spending the last 5 years working with AWS, that the learning curve for locking yourself into a vendor has a zero return as well. One product change and start again.

IaaS yes. Anything else, no thanks.

Edit: also some of the IaaS providers make standard services that compete with their own products difficult. Look at SES. If you run IaaS in AWS you have to jump through a lot of hoops to run an outbound mail relay. Their solution: just use SES; it's really easy! It's not!

[dankohn1]

The message of the cloud native software stack, most often built around Kubernetes, is that cloud portability enables you to avoid vendor lock-in.

A look at the stack: https://raw.githubusercontent.com/cncf/landscape/master/land...

(Disclosure: I'm the executive director of CNCF and helped make this image.)

[gaius]

Using cloud as a glorified hypervisor isn't really getting the benefits. To be cost effective you really do need to be using the value-added or layered features, and those are proprietary.

[dankohn1]

I disagree (obviously). There are huge advantages to using the data stores from your cloud provider, but you can pick Postgres or similar options that avoid lock-in. If you use DynamoDB or Spanner, you can work to avoid non-portable features. Many other services like SNS can be replicated with software like NATS.

That said, switching from one cloud to another will never be trivial, so it may be worth using some proprietary services up front if it gets you to market faster. The key thing is to have your eyes open about the choices you make, to ensure you have the ability to switch (or, perhaps more importantly, threaten to switch) in the future if you need to.

[gaius]

Sure, but if you restrict yourself to lowest-common-denominator features so you can migrate between Spanner and CosmosDB then you are paying for features you aren't using and are at a competitive disadvantage to those that can leverage them.

[tracker1]

Agreed, at the very least, anything I've made in the last year can be containerized and retargeted pretty easily from there.

[jazoom]

I learned this lesson very early on in my dev experience. My app's database was Parse. Parse no longer exists as a service. Before that it was based on StackMob, from which I moved to Parse because StackMob was shutting down. Parse gave a hell of a lot more notice, but I was done with this project at that point.

Now a feature of the app just doesn't work. I won't be rewriting it for another backend.

Guess who doesn't use Firebase. This guy.

As a side note, I currently use RethinkDB. RethinkDB shut down last year. That has had no negative effect on my current project, which could run for a very long time on the last stable version of RethinkDB. Since it was open source, now it is even under development again.

[Can_Not]

I've seen a tutorial for "make your own self hosted firebase with feathersjs", have you considered just finding a self hosted alternative to parse and altering your application or writing a wrapper?

[jazoom]

It is my understanding that Parse itself is now open source, so I could self-host the genuine article. The reason I don't is that I really am done with that project. In fact, I'm done with Android apps altogether. I currently am working on a much better project (website).

[chii]

> it basically puts your company product under someone else's rules, and if those rules changes or worse, if these companies go bankrupt, migrating to another system could be the death of your product as well.

This is basically where standards has to come in. Imagine if electricity was not standarized - you'd have to buy into one frequency or another. Then you'd face the same problem as with using BaaS!

I say, there needs to be standardization, so that commodities can be commodities. Companies like to pretend they are some special snowflake that sells something unique and un-replicable. That's not at all the case, and i wish that more people call them out on it. Making sure that standards exists for a particular commodity offering (e.g., apis, or via some sort of RFC), or don't use them at all.

[mcherm]

> Imagine if electricity was not standarized - you'd have to buy into one frequency or another. Then you'd face the same problem as with using BaaS!

Ever tried traveling around the world (or even just around Europe) with an electric device? Now... once you picked up an adapter at the hardware store, how difficult was it? "Not much of a problem" for most folks, somewhere between "a moderate pain" and "ruined my device" for the few with special issues.

[user5994461]

A lot of power supplies are strictly 110V or 230V. They will fry when plugged in a different country, with the adapter.

[dzhiurgis]

GCP is kind of a good guy here, pretty much every documentation links to RFC or a standard definition.

Yet also, believing you can standardise everything is a fairytaile. Is your own infra standardised?

[breerly]

Cloud services don't save you money, they buy you focus.

There are very little companies today that need custom buildouts, but that doesn't mean we shouldn't keep an eye on portability.

[dalbasal]

to play devil's advocate...

The article seems to be written in the context of small startups.This is an inherently risky (and risk tolerant) environment.

The biggest risk is usually internal. Fail to make a good product, or the product isn't popular... If your chance of total failure in the next 3 years is alread 25% or 90%, then adding 2 or 10% risk can be reasonable. This is an abnormal situation.

A related concern from a few years ago was FB & Twitter "as a platform". In some cases, the risk paid off. Take Tinder, for example. Tinder doesn't work at all without FB and plan-B is probably terrible.

That's not a risk an existing business could take. Tinder could because they were a startup. Using FB profiles avoided the empty profile problems most upstart social networks have.

Dating is a network-effects problem. So, a 50% (or whatever) increase in profile completion rates could have been the difference between success and failure.

If "NoOps" can genuinely reduce the area of competence a startup needs, and let them focus on application building (or whatever)... that can be an edge. Taking risks to gain an edge is something a risk tolerant startup can do.

Of course, small companies become big companies and these decisions leave a legacy.

[seanwilson]

> Maybe I'm old school, but I really hope developers give a serious thought before jumping into this vendor lock-in trap.

What vendor lock-in do you mean though? If you're using AWS, Google or Heroku, they all support Node, Python and PHP for instance and have several options for file storage, SQL and NoSQL. Migrating away is always going to be painful (although you can make this easier for yourself with abstractions in your code) but you can still host on cloud services in ways that don't tie you in.

I agree if you start heavily relying on features that only one company provides you might be in for some trouble but hosting + coding it all yourself carries significant risk as well.

[scaryclam]

I get the feeling the OP was talking more about things like Firebase than EC2 or Cloud Compute. Of course, GCP and AWS will allow you to do things that lock you in, but as you stated, you don't have to do that to use their other products.

The idea that some people are using other companies backend systems to build their own company that completely relies on those systems creeps me out.

If I hire a backend developer who creates an API that talks to my DB, then that developer walks away, at least I can continue with my business while I run around finding a new developer. I don't need a new codebase and I don't need to shutdown operations. If a hosting company goes under but I host my own code there, at least I can redeploy elsewhere and get on with life. If I use a BaaS company and they go under/discontinue my hosting/etc then I can neither move, or hire another company to continue the work. I have to start again, and for anything significant, that's probably going to kill my company first.

[dzhiurgis]

Salesforce has been running essentially a BaaS for nearly two decades and they show no sign of slowing down.

IMHO their platform is garbage compared to something like Firebase, but no businesses seem to be worried about portability. In fact most are doubling down on building teams to build and support Salesforce.

[yellowapple]

"In fact most are doubling down on building teams to build and support Salesforce."

I'd sooner attribute that to Stockholm syndrome, in much the same way that Oracle shops tend to double down on Oracle products - not because Oracle products are actually good, mind you (they're absolutely abysmal, in my observation, and even the ones acquired from Sun are rotting corpses at this point, Java being perhaps the sole exception), but because it's cheaper to keep buying in than to break out of the vendor lock-in.

[seanwilson]

Sounds like we agree then! I'd rather stick to generic technologies so I can migrate away if needed. If the service being offered gave a big advantage but didn't have any realistic migration paths then I'd be very cautious. All I mean is that between the major cloud providers there's a decent overlap of common services you can use such that the advantages are hard to ignore. I think we're at the stage where doing everything yourself with some generic VPSs or your own machines isn't economical or productive if you value your time in a lot of cases.

[gaius]

really hope developers give a serious thought before jumping into this vendor lock-in trap

... and these are the people who refuse to write SQL incase they get locked into a particular database...

[HeroOfAges]

I thought solutions like Cloud Foundry and adhering to the "Twleve-Factor App" methodology help eliminate the risk of vendor lock-in.