6 ms·

Yeah, you need to do calculation of what you are doing right now vs AWS. If you already have a mature team that is doing well optimising the environment, you h

Yeah, you need to do calculation of what you are doing right now vs AWS. If you already have a mature team that is doing well optimising the environment, you have stable demand and no need to develop things rapidly then it is very likely that going cloud is poor choice. As to "cloud agnostic", don't believe this bullshit. In my opinion most projects fare much better by just letting go of this "cloud agnostic" and just getting tied and locked in to the vendor. It is not like there is a good chance Amazon (or Microsoft or Google for that matter) will suddenly pull a significant price hike or another move out of step with other vendors. Spending effort on trying to make your app "cloud agnostic" usually ends up with far higher development costs and a chance of failure for no benefit. Embracing one vendor in this case is usually best way to achieve smaller, leaner app that is using the platform well. It is the same story as with SQL. Trying to use frameworks to keep your app DBMS-agnostic but then nobody ever migrates their apps to another DBMS. And for various good reasons: you hired your staff for their expertise with X, they are used to it, so now going for Y will usually be far higher cost than the benefits.

pooper 4y ago
> It is the same story as with SQL. Trying to use frameworks to keep your app DBMS-agnostic but then nobody ever migrates their apps to another DBMS. A small nit, I think this is partly because we've been burned before. Same idea as backups, if you don't restore from backups, you don't know if you have good backups. Similarly, if you don't use certain code paths, you can't tell if those code paths are sufficiently bug free. I am thinking of Drupal. Pretty much everyone who uses Drupal uses MySQL/MariaDB as far as I know. I think Drupal supports Postgresql but nobody I know uses it because nobody they know uses Drupal with Postgresql. I don't know anyone who uses drupal with sqlite on production either.
ozim 4y ago
Cloud agnostic has its place if you have enterprise contract with cloud provider. If you have 100s of projects cloud agnostic infra is good. If for example Amazon buys your competitor and now you get "new contract coming up". That said I agree "most projects fare much better without" - a lot of people don't understand they are not in position where they would benefit from that.
- twawaaay 4y ago
  The issue here is that the contract terms might change iteratively by some percentage, while development costs are exponential -- adding requirements to the project increases cost exponentially.
joshstrange 4y ago
> As to "cloud agnostic", don't believe this bullshit. > It is the same story as with SQL. Trying to use frameworks to keep your app DBMS-agnostic but then nobody ever migrates their apps to another DBMS. I agree, I can't tell you how many hours I've wasted trying to keeps something (theoretically) cloud or DBMS agnostic, how many problems it's caused, and at the end of the day we could never "easily" move to a different cloud or DBMS without large rewrites. I built on top of the Serverless Framework and I am constantly kicking myself for doing so (eventually I'll move off it for my main project). It's the worst of all worlds and in the Serverless Framework docs they even have sections for "GCF" vs "Lambda", if I have to write my functions/declarations differently then why am I using your layer on top? I know you get a few things for "free" with the Serverless Framework but once your project grows you run into all sorts of issues that are a PITA to work around. The truth is I'm not leaving AWS Lamda for GCF or whatever Azure has, I quite enjoy my "walled garden" and using an abstraction layer only means I get the lowest common denominator or a headache when trying to do something that is normally easy if you've fully bought in.
- guhidalg 4y ago
  But why would you try to build something cloud-agnostic to run on the most cloud-aware tier: serverless? Computers don't come forth from the ether, your code is always running _somewhere_ and serverless means your provider makes a ton of choices for you. The lowest common denominator across clouds is a VM. If you can run your applications and your databases on VMs, you can run them on any cloud AND on-premises. If you can't run CosmosDB or AWS Whatever on a VM, your choice of DBMS/ORM doesn't affect that you're tied to that cloud provider.
  - galaxyLogic 4y ago
    I wonder could micro-services be the solution? Run some of your micro-services on AWS and another on Azure etc. A given micro-service then might be highly dependent on AWS but the part of your application that uses those micro-services would not know anything about internals of AWS etc.
    - 4y ago
spoiler 4y ago
> As to "cloud agnostic", don't believe this bullshit. A notable exception to this is of you have clients whose IT departments require you to work on specific cloud providers. Although, there's tools that help abstract deploying infrastructure to different cloud providers (eg terraform, pulumi), but they still require some familiarity with the providers. With all that said, overall I agree with your sentiment
- twawaaay 4y ago
  When you build software for a client that is a completely different game. I divide this into two completely separate areas: * advisory -- you advise your client on what is prudent in their circumstances, * software development -- you produce software to client specifications, regardless of what they asked. You can advise them all you want but then you do what they asked and that's it -- they are always right.
deltarholamda 4y ago
>It is the same story as with SQL. Trying to use frameworks to keep your app DBMS-agnostic but then nobody ever migrates their apps to another DBMS. And for various good reasons: you hired your staff for their expertise with X, they are used to it, so now going for Y will usually be far higher cost than the benefits. Yeah, I never got this. If actual, for really real SQL is necessary for your application, then you need an actual, for really real DBA. If it's just a really nifty flat-file interface that "just werks," go with whatever DB engine your framework is most tested/used on. I get that sometimes you're interfacing two different things, one of which is on one DB engine, and you'd like to use the same software. That's fine. But DB agnosticism has a cost like anything else. If you can be truly cloud-agnostic, then there is a high probability you can be cloud-free.
speedgoose 4y ago
Not being cloud agnostic forces you to use one single cloud provider, that is not necessarily the best in everything.
- twawaaay 4y ago
  It is a tradeoff. Whatever you choose will have its costs. You need to know the tradeoff you are making but what I am saying is that, in most cases, it costs more to spend so much effort up front to be "cloud agnostic" than any benefits of maybe being able to switch cloud environment in a hurry.
  - speedgoose 4y ago
    I agree. I have switched cloud environments at work in the past, and it required a lot of efforts. However we switched towards standard Kubernetes to have more flexibility in the future. Also sometimes you don't want to minimise the cost but use the best services or reduce the risks. Let's say I go full on Azure, but after a year or two GCP offers a much better product for my use case. I will have to ignore it because it's too expensive to switch. Or if I go full on GCP/Firebase but suddenly the pricing model changes and it becomes overpriced. I will have to eat the cost for some time. However, if I'm careful to avoid vendor lock-ins from the start, it will probably cost a bit more on average, but the maximum cost is much lower and I don't risk being stuck with a bad service. In practice I will for example avoid to write code specific to the proprietary Azure Blob Storage API, but use an S3 compatible object storage instead. I will also rather have an abstraction layer than using AWS SQS or GCP pub/sub directly.
    - deleted 4y ago
      [deleted]
KronisLV 4y ago
> It is not like there is a good chance Amazon (or Microsoft or Google for that matter) will suddenly pull a significant price hike or another move out of step with other vendors. I feel like a variety of other circumstances can come to pass, which would negatively affect business continuity, here's what a lazy search turned up: "My Google Cloud was suspended too" https://news.ycombinator.com/item?id=32571055 "Google suspended our domain out of the blue" https://news.ycombinator.com/item?id=32798368 "Tell HN: Google Cloud suspended our production projects at 1am on Saturday" https://news.ycombinator.com/item?id=32547912 "AWS account was permanently closed because it was suspended for 90 days" https://news.ycombinator.com/item?id=31571538 (probably happens with Azure and other smaller platforms as well, e.g. Hetzner, DigitalOcean, Vultr, Scaleway and so on) That said, most people won't care to put in the work for a multi-cloud/cloud-agnostic setup, since most projects just aren't as important to warrant that much effort. And the ones that are can probably also just talk with the cloud providers through some representative anyways due to spending $$$. I'd argue that it's good to build on common standards, like OCI containers and the wire protocol of some common DBMS like PostgreSQL or MySQL/MariaDB: so that you can replicate certain parts of what a managed service does in a container locally, for development and testing. In most cases it won't matter that the managed cloud offering has some clever engineering underneath it and scales better, as long as you can check whether your SQL executes as it should and none of your seeded/anonymized test data breaks. I actually had this project with Oracle DB that ran horribly when the instance was remote and you really couldn't do migrations well without breaking things for anyone using it, because the apps using it were written in a way where hundreds if not thousands of SQL queries were done just to load some data to display a page. Which is passable (if you don't care) when the DB is running in the same data centre as the apps, but absolutely horrible when these many smaller SQL queries have the full network round trip between them, especially when the app initializes data sequentially (N+1 problem). Ergo, the only way to work with something like that is to setup a local database (e.g. Oracle XE) and work with it, after importing a baseline migration/doing automated migrations. The same largely applies to any other DB with sub par application architectures, as well as many other services (e.g. MinIO/Zenko instead of S3, so you don't need to actually upload 100 MB files to test whether attachment logic in your app works, if you can run them locally). As for software that should be compatible with multiple DBMSes: sometimes it makes sense (e.g. something that could be used by your customers in a self-hosted setup across numerous different setups, like Zabbix or Nextcloud), but most of the time it would negatively impact how easy it is to develop code for your app (e.g. having to rely on ORM and their abstractions like JPQL) and testing everything would usually take more effort.
minhazm 4y ago
The SQL example is a great one. I worked on a project where we used MySQL but then used SQLite for unit tests and integration tests. We technically wanted to be able to swap out the RDBMS to something like Postgres but in practice it was never going to happen. Over time it started getting complicated as some stuff we used in MySQL wasn't supported in SQLite. Eventually I just ditched SQLite and changed our testing to start a real MySQL server and destroy it after testing is complete.

pooper 4y ago

> It is the same story as with SQL. Trying to use frameworks to keep your app DBMS-agnostic but then nobody ever migrates their apps to another DBMS. A small nit, I think this is partly because we've been burned before. Same idea as backups, if you don't restore from backups, you don't know if you have good backups. Similarly, if you don't use certain code paths, you can't tell if those code paths are sufficiently bug free. I am thinking of Drupal. Pretty much everyone who uses Drupal uses MySQL/MariaDB as far as I know. I think Drupal supports Postgresql but nobody I know uses it because nobody they know uses Drupal with Postgresql. I don't know anyone who uses drupal with sqlite on production either.

ozim 4y ago

Cloud agnostic has its place if you have enterprise contract with cloud provider. If you have 100s of projects cloud agnostic infra is good. If for example Amazon buys your competitor and now you get "new contract coming up". That said I agree "most projects fare much better without" - a lot of people don't understand they are not in position where they would benefit from that.

twawaaay 4y ago
The issue here is that the contract terms might change iteratively by some percentage, while development costs are exponential -- adding requirements to the project increases cost exponentially.

joshstrange 4y ago

> As to "cloud agnostic", don't believe this bullshit. > It is the same story as with SQL. Trying to use frameworks to keep your app DBMS-agnostic but then nobody ever migrates their apps to another DBMS. I agree, I can't tell you how many hours I've wasted trying to keeps something (theoretically) cloud or DBMS agnostic, how many problems it's caused, and at the end of the day we could never "easily" move to a different cloud or DBMS without large rewrites. I built on top of the Serverless Framework and I am constantly kicking myself for doing so (eventually I'll move off it for my main project). It's the worst of all worlds and in the Serverless Framework docs they even have sections for "GCF" vs "Lambda", if I have to write my functions/declarations differently then why am I using your layer on top? I know you get a few things for "free" with the Serverless Framework but once your project grows you run into all sorts of issues that are a PITA to work around. The truth is I'm not leaving AWS Lamda for GCF or whatever Azure has, I quite enjoy my "walled garden" and using an abstraction layer only means I get the lowest common denominator or a headache when trying to do something that is normally easy if you've fully bought in.

guhidalg 4y ago
But why would you try to build something cloud-agnostic to run on the most cloud-aware tier: serverless? Computers don't come forth from the ether, your code is always running _somewhere_ and serverless means your provider makes a ton of choices for you. The lowest common denominator across clouds is a VM. If you can run your applications and your databases on VMs, you can run them on any cloud AND on-premises. If you can't run CosmosDB or AWS Whatever on a VM, your choice of DBMS/ORM doesn't affect that you're tied to that cloud provider.
- galaxyLogic 4y ago
  I wonder could micro-services be the solution? Run some of your micro-services on AWS and another on Azure etc. A given micro-service then might be highly dependent on AWS but the part of your application that uses those micro-services would not know anything about internals of AWS etc.
  - 4y ago

spoiler 4y ago

> As to "cloud agnostic", don't believe this bullshit. A notable exception to this is of you have clients whose IT departments require you to work on specific cloud providers. Although, there's tools that help abstract deploying infrastructure to different cloud providers (eg terraform, pulumi), but they still require some familiarity with the providers. With all that said, overall I agree with your sentiment

twawaaay 4y ago
When you build software for a client that is a completely different game. I divide this into two completely separate areas: * advisory -- you advise your client on what is prudent in their circumstances, * software development -- you produce software to client specifications, regardless of what they asked. You can advise them all you want but then you do what they asked and that's it -- they are always right.

deltarholamda 4y ago

>It is the same story as with SQL. Trying to use frameworks to keep your app DBMS-agnostic but then nobody ever migrates their apps to another DBMS. And for various good reasons: you hired your staff for their expertise with X, they are used to it, so now going for Y will usually be far higher cost than the benefits. Yeah, I never got this. If actual, for really real SQL is necessary for your application, then you need an actual, for really real DBA. If it's just a really nifty flat-file interface that "just werks," go with whatever DB engine your framework is most tested/used on. I get that sometimes you're interfacing two different things, one of which is on one DB engine, and you'd like to use the same software. That's fine. But DB agnosticism has a cost like anything else. If you can be truly cloud-agnostic, then there is a high probability you can be cloud-free.

speedgoose 4y ago

Not being cloud agnostic forces you to use one single cloud provider, that is not necessarily the best in everything.

twawaaay 4y ago
It is a tradeoff. Whatever you choose will have its costs. You need to know the tradeoff you are making but what I am saying is that, in most cases, it costs more to spend so much effort up front to be "cloud agnostic" than any benefits of maybe being able to switch cloud environment in a hurry.
- speedgoose 4y ago
  I agree. I have switched cloud environments at work in the past, and it required a lot of efforts. However we switched towards standard Kubernetes to have more flexibility in the future. Also sometimes you don't want to minimise the cost but use the best services or reduce the risks. Let's say I go full on Azure, but after a year or two GCP offers a much better product for my use case. I will have to ignore it because it's too expensive to switch. Or if I go full on GCP/Firebase but suddenly the pricing model changes and it becomes overpriced. I will have to eat the cost for some time. However, if I'm careful to avoid vendor lock-ins from the start, it will probably cost a bit more on average, but the maximum cost is much lower and I don't risk being stuck with a bad service. In practice I will for example avoid to write code specific to the proprietary Azure Blob Storage API, but use an S3 compatible object storage instead. I will also rather have an abstraction layer than using AWS SQS or GCP pub/sub directly.
  - deleted 4y ago
    [deleted]

KronisLV 4y ago

> It is not like there is a good chance Amazon (or Microsoft or Google for that matter) will suddenly pull a significant price hike or another move out of step with other vendors. I feel like a variety of other circumstances can come to pass, which would negatively affect business continuity, here's what a lazy search turned up: "My Google Cloud was suspended too" https://news.ycombinator.com/item?id=32571055 "Google suspended our domain out of the blue" https://news.ycombinator.com/item?id=32798368 "Tell HN: Google Cloud suspended our production projects at 1am on Saturday" https://news.ycombinator.com/item?id=32547912 "AWS account was permanently closed because it was suspended for 90 days" https://news.ycombinator.com/item?id=31571538 (probably happens with Azure and other smaller platforms as well, e.g. Hetzner, DigitalOcean, Vultr, Scaleway and so on) That said, most people won't care to put in the work for a multi-cloud/cloud-agnostic setup, since most projects just aren't as important to warrant that much effort. And the ones that are can probably also just talk with the cloud providers through some representative anyways due to spending $$$. I'd argue that it's good to build on common standards, like OCI containers and the wire protocol of some common DBMS like PostgreSQL or MySQL/MariaDB: so that you can replicate certain parts of what a managed service does in a container locally, for development and testing. In most cases it won't matter that the managed cloud offering has some clever engineering underneath it and scales better, as long as you can check whether your SQL executes as it should and none of your seeded/anonymized test data breaks. I actually had this project with Oracle DB that ran horribly when the instance was remote and you really couldn't do migrations well without breaking things for anyone using it, because the apps using it were written in a way where hundreds if not thousands of SQL queries were done just to load some data to display a page. Which is passable (if you don't care) when the DB is running in the same data centre as the apps, but absolutely horrible when these many smaller SQL queries have the full network round trip between them, especially when the app initializes data sequentially (N+1 problem). Ergo, the only way to work with something like that is to setup a local database (e.g. Oracle XE) and work with it, after importing a baseline migration/doing automated migrations. The same largely applies to any other DB with sub par application architectures, as well as many other services (e.g. MinIO/Zenko instead of S3, so you don't need to actually upload 100 MB files to test whether attachment logic in your app works, if you can run them locally). As for software that should be compatible with multiple DBMSes: sometimes it makes sense (e.g. something that could be used by your customers in a self-hosted setup across numerous different setups, like Zabbix or Nextcloud), but most of the time it would negatively impact how easy it is to develop code for your app (e.g. having to rely on ORM and their abstractions like JPQL) and testing everything would usually take more effort.

minhazm 4y ago

The SQL example is a great one. I worked on a project where we used MySQL but then used SQLite for unit tests and integration tests. We technically wanted to be able to swap out the RDBMS to something like Postgres but in practice it was never going to happen. Over time it started getting complicated as some stuff we used in MySQL wasn't supported in SQLite. Eventually I just ditched SQLite and changed our testing to start a real MySQL server and destroy it after testing is complete.