
Fighting vendor lock-in and designing testable serverless apps - slobodan_
https://vacationtracker.io/blog/big-bad-serverless-vendor-lock-in/
======
stickfigure
This is what I call _fake work_.

This company builds a team vacation tracker. As long as it's reliable, their
customers could not give a rat's ass whether it runs in AWS, Google, or
Joebob's House Of Ill Compute. Every engineer hour spent creating abstraction
layers and docker containers and whiz-bang multiplatform plumbing is an hour
that could have been spent working on something your _users_ actually care
about.

Switching clouds is a cost optimization. You have to be an enormous company
(or in a resource-intensive domain) before this is more productive than
building features. It means you've moved out of the growth phase and into the
"how do I milk what I've got" phase.

Vendor lock-in is something that engineers care about because they like
playing with tech. It's cool switching platforms or databases or whatnot
because it really feels like hard, sophisticated work! But it doesn't move the
needle.

~~~
theknarf
> Due to a change in how they report data usage, our monthly costs for
> Firebase, a SaaS provided by Google, has increased from $25 a month to what
> is now moving towards the $2,000 mark — with no changes to our actual data
> use. This change was made without warning.

ref
[https://news.ycombinator.com/item?id=14356409](https://news.ycombinator.com/item?id=14356409)

Vendor lock-in can make or break startups if you're not careful enough.

~~~
stickfigure
Perhaps this is the "exception that proves the rule"? That situation was
unusual enough that one of the Firebase founders reached out and gave them a
bunch of credits and helped them work through the issue.

There's certainly a continuum here. The most minimal risk mitigation strategy
is simply to use your own domain (as opposed to the vendor's domain), and that
requires nearly zero effort. Unfortunately the team in that article made that
mistake, and they're pretty honest about admitting it.

Assuming you don't make rookie mistakes at the beginning, you always _can_
move to another platform - it's just a question of how much work it will take.
Is it better to put that work in up front for the 0.01% chance you'll need it?
I think not.

~~~
dragonwriter
> Is it better to put that work in up front for the 0.01% chance you'll need
> it? I think not.

Over a sufficiently long time horizon, the chance is much greater than 0.01%
and the longer you go without doing the work, the more it costs to do the
work.

Sure, it's more a problem that bites you when you've become a big enterprise,
but it bites hard, and some of us work in big enterprises on systems that
could reasonably be operational for generations going forward (and perhaps
have been going backwards.)

~~~
stickfigure
I would happily accept that problem if skipping the extra work enhances my
chance of becoming a big enterprise in the first place.

~~~
dragonwriter
> I would happily accept that problem if skipping the extra work enhances my
> chance of becoming a big enterprise in the first place.

And that's the right choice in some cases. But the added up-front effort can
be a lot less than the added reengineering effort, and growing into a big
enterprise doesn't mean you are immune to disruption by more agile startups.

And, of course, those who are already in big enterprises have different
concerns (while premature adoption of the mitigations at issue can be
engineering resume padding in startups, deferring it with the hope that it
won't be a crisis until it's someone else's problem in exchange for short-term
metrics can just as easily be management resume padding in enterprises.)

~~~
JamesBarney
But how much less work is it do it up front, and continue to maintain and test
a multi-provider platform?

I don't think it's 100x or even 20x less work.

------
jwiley
I like the idea of multi-cloud very much, kudos to the author for pushing for
it.

One crucial issue that isn't addressed by a hexagonal architecture however is
data egress charges.

Data egress is the gravity of the cloud services world, and it's are an
insurmountable barrier for many services. The moment you start planning a
multi-cloud deploy, and start looking at shifting services that are tightly
coupled, or require data replication (databases, logs, storage) between
clouds, you're going from low or no cost data charges, to paying egress on
-both sides- of every transaction.

I know first-hand that these costs can quickly out weigh any disaster recovery
/ eggs in one basket argument you might put forward. It even dominates an
"this cloud provider will probably be our competitor in 2 years or is our
competitor right now" argument, and my guess is data egress has strongly
contributed to companies like Netflix continuing to use AWS.

~~~
regularfry
Once you're big enough you can start talking about having a direct
interconnect to the cloud provider, which helps.

------
giancarlostoro
I find it funny cause Microsofts serverless infrastructure and co source code
is on GitHub it may not be as pretty as a real Azure service but they let you
take the damn thing with you. Not sure about other cloud providers. How the
tables have changed. Hell I convinced my old boss to selectively use
Microsofts Azure Functions because they were open source and we needed a
slightly longer running process not part of our typical web service.

~~~
kylek
I didn't realize this was a thing and had to look it up.[0][1] This seems
pretty great if you were considering Lambda but had concerns over portability.

[0] [https://github.com/Azure/azure-functions-core-
tools](https://github.com/Azure/azure-functions-core-tools)

[1] [https://medium.com/@raduvunvulea/how-to-run-azure-
functions-...](https://medium.com/@raduvunvulea/how-to-run-azure-functions-on-
aws-and-on-premises-4bba4ba392ec)

~~~
giancarlostoro
You should of gone a little further, the core tools are for local testing if I
remember correctly, but the back-end is here:

[https://github.com/Azure/azure-functions-
host](https://github.com/Azure/azure-functions-host)

------
hota_mazi
Vendors have already come up with a way to fight the vendor lock-in dodging
that this article recommends: data egress charges.

Whenever you are trying to take your data out of one cloud into another one,
you're going to be charged heavily, and these costs will likely exceed the
costs of accepting vendor lock in and keeping your data housed in one
location.

The only realistic way to fight vendor lock in is to keep your code as
isolated from proprietary API's as possible (e.g. deploy containers, or use
interfaces to isolate proprietary calls in your app).

~~~
scarface74
And while you’re adding the extra complexity just to avoid lock-in, you’re not
adding features that can acquire customers or get your existing customers to
pay more.

No, your CTO is no more going to uproot your entire infrastructure from
AWS/Azure because you promised that it will be “seamless” than they are going
to replace their six figure Oracle installation with Postgres because you used
the repository pattern.

------
nailer
> This leads us to my favorite architecture for serverless apps: hexagonal
> architecture, alternatively called ports and adapters. As it’s creator,
> Alistair Cockburn, explains, the hexagonal architecture allows an
> application to equally be driven by users, programs, automated test or batch
> scripts, and to be developed and tested in isolation from its eventual run-
> time devices and databases.

[https://vacationtracker.io/wp-
content/uploads/2019/04/hexago...](https://vacationtracker.io/wp-
content/uploads/2019/04/hexagonal-architecture.png)

This seems like a new buzzword for an existing (but still very good) thing,
abstraction layers.

The original article
([http://alistair.cockburn.us/Hexagonal+architecture](http://alistair.cockburn.us/Hexagonal+architecture))
is down though, so it's entirely possible it was was written in the late 90s
when these practices started becoming widespread particularly with Java and
Gang of Four
([https://en.wikipedia.org/wiki/Design_Patterns](https://en.wikipedia.org/wiki/Design_Patterns)).

Edit: dzone says 'Hexagonal Architecture' was from 2005.
[https://dzone.com/articles/hexagonal-architecture-what-is-
it...](https://dzone.com/articles/hexagonal-architecture-what-is-it-and-how-
does-it) Make of that what you will.

~~~
adzicg
Hexagonal arch is a very old name, another popular name is “ports and
adapters”. Alistair’s article on the C2 Wiki suggests 2005 as the origin of
the name
([http://wiki.c2.com/?PortsAndAdaptersArchitecture](http://wiki.c2.com/?PortsAndAdaptersArchitecture)),
but that the pattern was identified in the 90s.

btw, wayback machine has a copy from 2009 of Alistair’s page:
[https://web.archive.org/web/20090122225311/http://alistair.c...](https://web.archive.org/web/20090122225311/http://alistair.cockburn.us/Hexagonal+architecture)

~~~
nailer
Yep, that's mentioned in the comment you're replying to. 2005 is still a long
time after the Adapter pattern became popular
[https://en.wikipedia.org/wiki/Adapter_pattern](https://en.wikipedia.org/wiki/Adapter_pattern).

I definitely do think one should avoid service provider lockin by using
abstraction, I'm just not going to use the awkward sounding name coined by
someone who doesn't seem to be adding much to the concept.

------
alexkavon
IMO, deciding to go “serverless” or not usually ends up with about the same
amount of work as far as writing code and configuration goes.

Things like “serverless” or firebase data stores or even html hybrid app
frameworks, for example, are designed more so for simple proof of concept
apps. As soon as you begin any sort of serious pipeline development, deep
configuration for special case, scaling, etc. you’ll find these easy to use
services and ideas limit your control overall. Vendor lock-in is just a
benefit of “configuration-free” systems which is a side effect of people not
willing to rtfm.

~~~
ryanmarsh
Serverless guy here. You’re on the right track. I’d just add that it’s more
about ops burden than anything else.

iRobot is a $3bn market cap company with 23 million robots in the wild. Their
entire IT estate for managing 23 million robots including the communication
and systems is $15k a month. They can see their costs down to the function,
they can see where every cent is spent and they do this with 10 engineers, 8
of which are in development, 2 in Ops.

 _shrug_

~~~
alexkavon
Until a rearchitecture is needed. Then you’ll either need all your developers
in ops or vice versa.

(Assuming your response implies iRobot uses serverless)

------
yani
Is vendor lock really an issue that needs to be solved? I am wondering if one
had to ever switch vendors in practice. It sounds like over optimization to
something that might not even be in the requirements. I remember a few years
ago when infrastructures were designed to be able to handle 1m+ requests per
second long before market validation. Keep it simple and focus on getting your
app to the market.

~~~
linuxftw
> Is vendor lock really an issue that needs to be solved?

I don't think so, not at this point. Workloads are more portable today than
they ever were, as long as you're not using XaaS from your cloud provider.

Compute has become entirely commoditized. I think in the next 10 years or so,
with lower power/instruction and ubiquitous 1G internet links, it will become
cheap enough to start running workloads in-house again.

------
janpot
For me, my main problem with "vendor lock-in" is not the switching cost. I'm
not planning to switch vendor any time soon. For me it's more about the black-
box nature of their solution. It's usually proprietary, closed-source
solutions that put you at their complete mercy when things go wrong. It's not
debuggable, I can't run it on my laptop, I can't look inside how it works, I
can't make changes to it, I can't run my own, slightly modified version of it,
etc...

~~~
scarface74
Out of all the open source code you use, how much of it have you ever
inspected and not treated as a “black box”?

Most of AWS’s proprietary services have a way that you can simulate running
them on your laptop.

~~~
janpot
Many.

100% of the times I've used one of those local versions, I've ran into
incompatibilities with the real service.

~~~
scarface74
Which ones?

~~~
janpot
Not sure what you mean here but OS projects that come to mind that we haven't
treated as a black-box at some point are kubernetes, docker, node, chromium,
rabbitmq, postgres and every JavaScript module we use. Two local services that
come to mind that we have used and that didn't work like the AWS equivalent is
dynalite and fake-s3.

~~~
scarface74
I mean have you actually inspected the source code and/or made changes to suit
your needs for infrastructure level resources where there is a managed
equivalent?

~~~
janpot
Yes

------
village-idiot
I still just don’t understand why I want serverless, especially as my main
request serving mechanism. Every investigation I’ve done into it revealed a
lot of issues around function management and latency that always seemed harder
to deal with than just writing a server in <language> and deploying it on ECS
or fargate.

~~~
notoverthere
Serverless backends tend to work quite well when paired with a Single Page
Application on the frontend – e.g. Vue.js or React. That way your frontend can
be served from a static host – e.g. S3 or GitHub Pages – almost instantly. And
so the perceived performance of your application isn't harmed (as much as
you'd think) by the latency of your backend, since other aspects of the
application's interface can load and continue to be responsive.

~~~
janfoeh
To me, that does not seem to describe anything specific to "serverless"?

You've always been free to serve your static assets in any way you like, so
I'm unclear as to how the way the backend is architected comes into play here.

~~~
james-mcelwain
I think they're suggesting that bad latency from a serverless architecture is
mitigated by a SPA, since the application can render and appear functional
while it's fetching data.

Still, not sure how damage control for poor performance is a "pro" of
serverless design.

------
fuball63
I created bigcgi.com largely in reaction to vendor lockin. I use the CGI
standard and open source the whole platform. It allows for serverless apps to
run locally, with or without the platform, because any valid CGI binary/script
(which communicates via stdin, env vars, and stdout) should run on the
platform.

~~~
dexen
Please don't take the following as personal slight.

Not sure if it's a joke or long term project... because the descriptions,
while perfectly true, feel a bit like snark and sneer. "CGI: We are the
original pranksters", right as it may be, doesn't exactly feel like an
enterprise sales pitch.

Other than that, and the single tier, tight RAM provision effectively
precluding any hosted language like PHP, I applaud the initiative.

~~~
fuball63
No offense taken. I see it as an exercise of tech minimalism and exploring the
boundaries of how much "obsolete" tech can really achieve.

I'm not really interested in enterprise customers (too much pressure and
liability). I envision it for students, side projects, and small operations.

It is also currently in invite only beta while I continue my experiments with
the platform. I have been meaning to work with the homepage; I do not want it
to seem snarky.

Thanks for checking out the site, I appreciate the feedback!

------
eeZah7Ux
"fighting vendor lock-in" by surrendering your data to one multinational out
of 4? Oh the sad, sad irony.

------
newaccoutnas
I was hoping to see the Serverless framework and possibly using the OpenFaaS
plugin thats in incubation - [https://github.com/openfaas-
incubator/serverless-openfaas](https://github.com/openfaas-
incubator/serverless-openfaas)

Big bad vendor locking is fine in some cases, perhaps smaller shops who don't
need multi-cloud or the time investment, but if it's greenfield, then perhaps
above worth considering (if not now, when matured)

~~~
nailer
Architect Serverless ([https://arc.codes](https://arc.codes)) is currently
AWS-only, but also avoids adding anything that's specific to AWS, so in future
your .arc file (that does all your API gateway, lambdas, queues, etc) will
work on Azure etc.

------
quantguy11959
There are a few vendors built on top of multiple cloud vendors however they
themselves become the lock in, zeit or Joyent are good examples of this.

------
ryanmarsh
Vacation Tracker hasn’t raised much money. What a way to waste what little
they’ve raised. I feel like someone should tell their investors.

------
leerob
To prevent vendor lock-in and still go serverless, you could look into using a
service like Now. Under the hood, it switches between AWS, GCP, and Azure
based on whichever edge is closest.

[https://zeit.co/now](https://zeit.co/now)

~~~
penagwin
Does Now support self-hosting? If not then you just vendor locked yourself to
Zeit :P

------
chapium
In summary:

If you depend on cloud services, a good idea would be to write tests when
planning the system so you can easily switch vendors later if the business
relationship sours. Poster thinks "hexagonal architecture" is flexible enough
to do this.

------
t0astbread
What if your main concern isn't switching cost but rather giving your users
the liberty to run their own instance of the service on a provider of their
choice?

------
js4ever
Website is down, not serverless I guess :)

~~~
slobodan_
It's up again. It's WP, and not serverless unfortunately haha

