10 ms·

Fighting vendor lock-in and designing testable serverless apps

144 points by slobodan_ 7y ago

nailer 7y ago
> 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/hexagonal-architecture.png https://vacationtracker.io/wp-content/uploads/2019/04/hexago... 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-and-how-does-it https://dzone.com/articles/hexagonal-architecture-what-is-it... Make of that what you will.
- cgarvis 7y ago
  His page has been down for years unfortunately. It felt like it was start to again some traction in the ruby community years ago. Uncle Bob talks about in his Lost Years talk. Think that turned into Clean Architecture. Gary Burnhardt refers to it as “imperative shell, functional core”
- adzicg 7y ago
  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.cockburn.us/Hexagonal+architecture https://web.archive.org/web/20090122225311/http://alistair.c...
  - nailer 7y ago
    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.
- deleted 7y ago
  [deleted]
giancarlostoro 7y ago
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.
- imglorp 7y ago
  I agree, they've done a bang-up job pivoting the company towards driving traffic towards their cloud services. That said, they spent so many decades driving towards desktop OS sales that plenty of ruts and lane barriers remain. Those things were designed for lockin in terms of APIs, file formats, and with no interest in portability. Now, they're eroding but still enough to be a major irritant. Eg, good luck using Teams to have an actual meeting cross platform. Eg, dotnet has made progress but portability is still painful.
- quantguy11959 7y ago
  How is Azure functions still not a lock in? You can’t do anything with what they’ve open sourced.
- skohan 7y ago
  But how practical is it for anyone to really spin up cloud infrastructure based on those github repos? I'm skeptical that it's much more than a PR move.
  - giancarlostoro 7y ago
    Based on the GitHub issues for Azure Functions, I want to say people are using it. The way Azure Functions is implemented you literally just need to be able to run on IIS and thats IF you even need to run on IIS, I've not investigated it since I initially implemented our Serverless Functions two years back. Azure Functions are an extension / implemented on top of WebJobs iirc which is pretty much usable by anybody with IIS or their own Windows Server. Also the build system for Azure is open source, and I'm pretty confident it works. They share the core of the product which gets the Azure UI slapped on top of it, that's what you wont see, but you can see the same UI from the GitHub project on Azure if you really dig in through Azure. I've seen the "crappy UI" after looking further in Azure.
jwiley 7y ago
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 7y ago
  Once you're big enough you can start talking about having a direct interconnect to the cloud provider, which helps.
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
newaccoutnas 7y ago
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 7y ago
  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.
eeZah7Ux 7y ago
"fighting vendor lock-in" by surrendering your data to one multinational out of 4? Oh the sad, sad irony.
village-idiot 7y ago
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 7y ago
  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 7y ago
    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.
    - jerf 7y ago
      Well, there's very little (if anything) that "serverless" can do that other techniques can't accomplish. It's about costs & benefits, not whether or not you can do something. Though I tend to agree I'm yet to hear a really compelling description of why I should move very much into it. Some of this may be because I tend to write in a style that makes it fairly easy to mix & match bundles of application functionality anyhow, so to me adding some tiny function to a running app isn't that big a deal. (I don't use Erlang directly, but Erlang is where I learned this from.) If you're in an environment where deploying a single new REST handler or some recurring service is much harder, though, I could see where it comes in handy for certain things.
    - james-mcelwain 7y ago
hota_mazi 7y ago
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 7y ago
  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.
fuball63 7y ago
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 7y ago
  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 7y ago
    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!
quantguy11959 7y ago
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.
stickfigure 7y ago
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.
- dexen 7y ago
  To push back a bit, without going into the abstract of portability: - performance is a feature - reliability is a feature - security is a feature - and lastly, cost-effectiveness is a feature If the app is to be used through wide range of regions, you want geographically close datacenters for low latencies. If the app is to be used for mission-critical purposes, and contain sensitive data, you want high assurance and privacy[0]. And lastly, the cheaper the app is to run and maintain - and that includes not just the infrastructure bill, but also availability of engineers who know the platform well[1] - the better you can develop the same app within the given budget & time. [0] there are some legal compliance requirements for handling medical data [1] one of the reason Windows apps are rather cheap and plentiful - there's wide availability of engineers who know the platform well. Likewise for certain popular web stacks.
  - JamesBarney 7y ago
    But I feel like it's way easier to hire for Azure,AWS, or Google than all three, or the in-house cross provider solution.
  - jimmychangas 7y ago
    Better yet, the things you listed are qualities. They encompass every feature in the product. I think parent is generalizing too much on his assumption that only mature companies should spend time in optimization. Early stage startups can sometimes make mistakes, and optimizing early on can help them save the precious resources needed for them to survive another six months.
yani 7y ago
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 7y ago
  > 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 7y ago
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...
- skohan 7y ago
  Yeah I am currently working on a project which leans pretty heavily on AWS components, and can be very time consuming when something doesn't work the way it should. Even the paid support isn't that great either: a lot of times you end up chatting with someone who provides you the same links you just googled which didn't solve your problem, and more often than not the end result is a ticket being created somewhere, which will be addressed in who-knows-how-long if ever.
- scarface74 7y ago
  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 7y ago
    Many. 100% of the times I've used one of those local versions, I've ran into incompatibilities with the real service.
    - scarface74 7y ago
      Which ones?
      - janpot 7y ago
        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.
alexkavon 7y ago
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 7y ago
  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 7y ago
    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)
- nilkn 7y ago
  I view these serverless cloud offerings as more of a business/staffing decision than an engineering one. It may not be less work overall, but it tends to outsource traditional ops work and replace it with work that ordinary developers can do. Instead of having an extensive in-house ops staff to support your development team, you can have a much smaller ops staff and grow your development team more quickly.
chapium 7y ago
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.
js4ever 7y ago
Website is down, not serverless I guess :)
- slobodan_ 7y ago
  It's up again. It's WP, and not serverless unfortunately haha
ryanmarsh 7y ago
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 7y ago
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 7y ago
  Does Now support self-hosting? If not then you just vendor locked yourself to Zeit :P
t0astbread 7y ago
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?

144 points by slobodan_ 7y ago

> 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/hexagonal-architecture.png https://vacationtracker.io/wp-content/uploads/2019/04/hexago... 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-and-how-does-it https://dzone.com/articles/hexagonal-architecture-what-is-it... Make of that what you will.

cgarvis 7y ago
His page has been down for years unfortunately. It felt like it was start to again some traction in the ruby community years ago. Uncle Bob talks about in his Lost Years talk. Think that turned into Clean Architecture. Gary Burnhardt refers to it as “imperative shell, functional core”
adzicg 7y ago
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.cockburn.us/Hexagonal+architecture https://web.archive.org/web/20090122225311/http://alistair.c...
- nailer 7y ago
  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.
deleted 7y ago
[deleted]

giancarlostoro 7y ago

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.

imglorp 7y ago
I agree, they've done a bang-up job pivoting the company towards driving traffic towards their cloud services. That said, they spent so many decades driving towards desktop OS sales that plenty of ruts and lane barriers remain. Those things were designed for lockin in terms of APIs, file formats, and with no interest in portability. Now, they're eroding but still enough to be a major irritant. Eg, good luck using Teams to have an actual meeting cross platform. Eg, dotnet has made progress but portability is still painful.
quantguy11959 7y ago
How is Azure functions still not a lock in? You can’t do anything with what they’ve open sourced.
skohan 7y ago
But how practical is it for anyone to really spin up cloud infrastructure based on those github repos? I'm skeptical that it's much more than a PR move.
- giancarlostoro 7y ago
  Based on the GitHub issues for Azure Functions, I want to say people are using it. The way Azure Functions is implemented you literally just need to be able to run on IIS and thats IF you even need to run on IIS, I've not investigated it since I initially implemented our Serverless Functions two years back. Azure Functions are an extension / implemented on top of WebJobs iirc which is pretty much usable by anybody with IIS or their own Windows Server. Also the build system for Azure is open source, and I'm pretty confident it works. They share the core of the product which gets the Azure UI slapped on top of it, that's what you wont see, but you can see the same UI from the GitHub project on Azure if you really dig in through Azure. I've seen the "crappy UI" after looking further in Azure.

jwiley 7y ago

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 7y ago
Once you're big enough you can start talking about having a direct interconnect to the cloud provider, which helps.

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

newaccoutnas 7y ago

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 7y ago
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.

eeZah7Ux 7y ago

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

village-idiot 7y ago

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 7y ago
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 7y ago
  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.
  - jerf 7y ago
    Well, there's very little (if anything) that "serverless" can do that other techniques can't accomplish. It's about costs & benefits, not whether or not you can do something. Though I tend to agree I'm yet to hear a really compelling description of why I should move very much into it. Some of this may be because I tend to write in a style that makes it fairly easy to mix & match bundles of application functionality anyhow, so to me adding some tiny function to a running app isn't that big a deal. (I don't use Erlang directly, but Erlang is where I learned this from.) If you're in an environment where deploying a single new REST handler or some recurring service is much harder, though, I could see where it comes in handy for certain things.
  - james-mcelwain 7y ago

hota_mazi 7y ago

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 7y ago
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.

fuball63 7y ago

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 7y ago
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 7y ago
  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!

quantguy11959 7y ago

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.

stickfigure 7y ago

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.

dexen 7y ago
To push back a bit, without going into the abstract of portability: - performance is a feature - reliability is a feature - security is a feature - and lastly, cost-effectiveness is a feature If the app is to be used through wide range of regions, you want geographically close datacenters for low latencies. If the app is to be used for mission-critical purposes, and contain sensitive data, you want high assurance and privacy[0]. And lastly, the cheaper the app is to run and maintain - and that includes not just the infrastructure bill, but also availability of engineers who know the platform well[1] - the better you can develop the same app within the given budget & time. [0] there are some legal compliance requirements for handling medical data [1] one of the reason Windows apps are rather cheap and plentiful - there's wide availability of engineers who know the platform well. Likewise for certain popular web stacks.
- JamesBarney 7y ago
  But I feel like it's way easier to hire for Azure,AWS, or Google than all three, or the in-house cross provider solution.
- jimmychangas 7y ago
  Better yet, the things you listed are qualities. They encompass every feature in the product. I think parent is generalizing too much on his assumption that only mature companies should spend time in optimization. Early stage startups can sometimes make mistakes, and optimizing early on can help them save the precious resources needed for them to survive another six months.

yani 7y ago

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 7y ago
> 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 7y ago

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...

skohan 7y ago
Yeah I am currently working on a project which leans pretty heavily on AWS components, and can be very time consuming when something doesn't work the way it should. Even the paid support isn't that great either: a lot of times you end up chatting with someone who provides you the same links you just googled which didn't solve your problem, and more often than not the end result is a ticket being created somewhere, which will be addressed in who-knows-how-long if ever.
scarface74 7y ago
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 7y ago
  Many. 100% of the times I've used one of those local versions, I've ran into incompatibilities with the real service.
  - scarface74 7y ago
    Which ones?
    - janpot 7y ago
      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.

alexkavon 7y ago

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 7y ago
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 7y ago
  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)
nilkn 7y ago
I view these serverless cloud offerings as more of a business/staffing decision than an engineering one. It may not be less work overall, but it tends to outsource traditional ops work and replace it with work that ordinary developers can do. Instead of having an extensive in-house ops staff to support your development team, you can have a much smaller ops staff and grow your development team more quickly.

chapium 7y ago

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.

js4ever 7y ago

Website is down, not serverless I guess :)

slobodan_ 7y ago
It's up again. It's WP, and not serverless unfortunately haha

ryanmarsh 7y ago

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 7y ago

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 7y ago
Does Now support self-hosting? If not then you just vendor locked yourself to Zeit :P

t0astbread 7y ago

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?