5 ms·

Aside from the alert point everything else is basically "I don't know how to do it proper so you shouldn't do it either": > Don't migrate an application from t

Aside from the alert point everything else is basically "I don't know how to do it proper so you shouldn't do it either": > Don't migrate an application from the datacenter to the cloud [..] Instead port the application to the cloud. You can certainly do it without an app rewrite if you have good infrastructure engineers with the support of a small competent dev migration team. The real questions is when and why you should do it. One valid scenario is: you want to sell the app and an AWS setup is a lot more appealing to a buyer than a custom self owned or collocated setup. > maybe even doing something terrible like connecting your datacenter to AWS with direct connect in an attempt to bridge the two environments seamlessly You can certainly do that too, and AWS can be used as a cold disaster recovery option. > Don't write your own secrets system [...] how do you keep from hitting this service a million times an hour but still maintain some concept of using the server as the source of truth Simple, you get the secrets very rarely: at deployment. If you need to change anything you redeploy that part which should be very easy and fast if you got your orchestration/config management in top shape. Why would you do it? To avoid paying the Vault enterprise license and still get a highly available, version controlled and even more simpler and stable service. > Don't write internal cli tools in python [...] Nobody knows how to correctly install and package Python apps. This one is particularly sad snapshot of the state of the industry expertise. Debian packages solve this easy and completely. Oh, you don't understand your distro packaging system? Stop wasting time on blog posts and start reading documentation!

frenchman99 5y ago
I've seen Python CLI apps for internal tooling being very maintainable and setting up a Makefile with an "install" task makes it easy for everyone in the team to get started. > Simple, you get the secrets very rarely: at deployment. Do you mean writing custom scripts to get secrets? Where do you store secrets in such a scenario? What if you need to change secrets at runtime. Vault is nice in that you can fine grain access: - ACLs which allow some team members to be responsible for setting secrets and other team members for using them, - temporary credentials for well known DBMSs which helps secure logs from leaks, - PKI Management, - temporary SSH keys. And more. Not sure how you'd get that with a deploy time script.
- trabant00 5y ago
  > Where do you store secrets in such a scenario? Anywhere basically, a HTTP server with directory listing is enough. You don't need to roll your own security management, you can just encrypt secrets with ssh or pgp keys. > What if you need to change secrets at runtime I certainly don't need that as an infrastructure engineer. If you want that for development be my guest, pay the exorbitant Vault license and don't come crying to me Vault is down. Vault is always down, you just introduced a critical runtime dependency on an immature solution. Your problem, I have the email to prove you took responsibility for this decision against my recommendation.
  - frenchman99 5y ago
    You can totally have multiple secrets' sources: one for development that takes secrets from a plain text local file and one for production that takes secrets from Vault. I don't see an issue here. Also, what's immature about Vault?
    - trabant00 5y ago
      Have you used in production at a decent scale for significant time? It's an SLA killer.
ordu 5y ago
> Oh, you don't understand your distro packaging system? Stop wasting time on blog posts and start reading documentation! I had read them, and I'd anything just to be able to not deal with that mess. I believe there should be special people with a proper mental constitution and a high salary to deal with it. Not me.
- trabant00 5y ago
  I don't want anybody to get the wrong ideea from your post. Linux package managers solved the software distribution problem 20 years ago and are the most stable, feature full and elegant way to ship into production. You have reproducible builds, dependency handling, clean removal, rollback, exepction handling, logs, automated upgrades, etc. The problem is complex so the solution is not one youtube view away from being understood. Deb packages helped Debian to ship tens of thousands of software packages with frequent updates for years and years with few maintainers. I am sorry to say this, but calling it a mess says a lot more about you than about the package formats.
  - ordu 5y ago
    You said it yourself: they solve a damn great heap of problems. The heap is so great that it cannot be explained clearly. You forgot to say, that it was not a single solution, but a long painful road, not every solution you mentioned was available 20 years ago. So it is a mess of a lot of solutions condensed over a period of 30 years. I did look into two of such package management systems (deb and ebuild), and I'm happy to use any. To keep my system up to date they are fine, but not for anything else. It needs a lot of domain specific knowledge to make a package. Knowledge that is useless outside of the world of packaging. Knowledge detoriates when not used, and every time like the first time. Grr. > I am sorry to say this, but calling it a mess says a lot more about you than about the package formats. You shouldn't feel sorry saying it. I said it already. Though I used different words, but it is essentialy the same idea: there should be special people to make .deb packages. Probably you tried to say that it is me who is special in that regard? Can I advise you to can check your intuition? How many developers bother with preparing .deb packages? Is it 10% or 90%? How many github repos contain .deb? Most of developers who doesn't prepare .deb packages are like me. They would use flatpack, or some other format allowing to capture an environment easily. But they wouldn't use deb.

frenchman99 5y ago

I've seen Python CLI apps for internal tooling being very maintainable and setting up a Makefile with an "install" task makes it easy for everyone in the team to get started. > Simple, you get the secrets very rarely: at deployment. Do you mean writing custom scripts to get secrets? Where do you store secrets in such a scenario? What if you need to change secrets at runtime. Vault is nice in that you can fine grain access: - ACLs which allow some team members to be responsible for setting secrets and other team members for using them, - temporary credentials for well known DBMSs which helps secure logs from leaks, - PKI Management, - temporary SSH keys. And more. Not sure how you'd get that with a deploy time script.

trabant00 5y ago
> Where do you store secrets in such a scenario? Anywhere basically, a HTTP server with directory listing is enough. You don't need to roll your own security management, you can just encrypt secrets with ssh or pgp keys. > What if you need to change secrets at runtime I certainly don't need that as an infrastructure engineer. If you want that for development be my guest, pay the exorbitant Vault license and don't come crying to me Vault is down. Vault is always down, you just introduced a critical runtime dependency on an immature solution. Your problem, I have the email to prove you took responsibility for this decision against my recommendation.
- frenchman99 5y ago
  You can totally have multiple secrets' sources: one for development that takes secrets from a plain text local file and one for production that takes secrets from Vault. I don't see an issue here. Also, what's immature about Vault?
  - trabant00 5y ago
    Have you used in production at a decent scale for significant time? It's an SLA killer.

ordu 5y ago

> Oh, you don't understand your distro packaging system? Stop wasting time on blog posts and start reading documentation! I had read them, and I'd anything just to be able to not deal with that mess. I believe there should be special people with a proper mental constitution and a high salary to deal with it. Not me.

trabant00 5y ago
I don't want anybody to get the wrong ideea from your post. Linux package managers solved the software distribution problem 20 years ago and are the most stable, feature full and elegant way to ship into production. You have reproducible builds, dependency handling, clean removal, rollback, exepction handling, logs, automated upgrades, etc. The problem is complex so the solution is not one youtube view away from being understood. Deb packages helped Debian to ship tens of thousands of software packages with frequent updates for years and years with few maintainers. I am sorry to say this, but calling it a mess says a lot more about you than about the package formats.
- ordu 5y ago
  You said it yourself: they solve a damn great heap of problems. The heap is so great that it cannot be explained clearly. You forgot to say, that it was not a single solution, but a long painful road, not every solution you mentioned was available 20 years ago. So it is a mess of a lot of solutions condensed over a period of 30 years. I did look into two of such package management systems (deb and ebuild), and I'm happy to use any. To keep my system up to date they are fine, but not for anything else. It needs a lot of domain specific knowledge to make a package. Knowledge that is useless outside of the world of packaging. Knowledge detoriates when not used, and every time like the first time. Grr. > I am sorry to say this, but calling it a mess says a lot more about you than about the package formats. You shouldn't feel sorry saying it. I said it already. Though I used different words, but it is essentialy the same idea: there should be special people to make .deb packages. Probably you tried to say that it is me who is special in that regard? Can I advise you to can check your intuition? How many developers bother with preparing .deb packages? Is it 10% or 90%? How many github repos contain .deb? Most of developers who doesn't prepare .deb packages are like me. They would use flatpack, or some other format allowing to capture an environment easily. But they wouldn't use deb.