4 ms·

Managed k8s or Heroku? I don't understand why people don't try to do AppEngine. It's the oldest "Serverless" platform out there and wickedly mature. If you're w

Managed k8s or Heroku? I don't understand why people don't try to do AppEngine. It's the oldest "Serverless" platform out there and wickedly mature. If you're worried about vendor lock in (and you should be) I have deployed AppEngine apps on the F/OSS AppScale unmodified.

ngrilly 8y ago
> I have deployed AppEngine apps on the F/OSS AppScale unmodified. How did you manage secrets on Google App Engine?
- nickbauman 8y ago
  In the flex environment you can inject secrets at container build time. In App Engine standard I've used a deploy wrapper around ansible vault to do it.
  - ngrilly 8y ago
    > In the flex environment you can inject secrets at container build time. Does it mean your secrets are stored in plain text in the container image? > In App Engine standard I've used a deploy wrapper around ansible vault to do it. What does the deploy wrapper do? Does it produces an app.yaml file with the secrets injected in it, after having been decrypted by Ansible Vault?
    - nickbauman 8y ago
      Q: Does it mean your secrets are stored in plain text in the container image? A: No. It means the secrets are stored as environment variables in the container. Q: What does the deploy wrapper do? A: It prompts the developer to input the ansible vault password , decrypts the vault and injects the secrets into the environment. Generally speaking, I follow the 12-factor approach: https://12factor.net/ https://12factor.net/
      - ngrilly 8y ago
        What do you mean by "injecting secrets into the environment"? You mean a section in your app.yaml like this one: env_variables: DB_PASSWORD: "this is a secret" As for as I know, in the Standard and Flex environments, app.yaml is the only way to define environment variables.
lugg 8y ago
Why should you be concerned about vendor lock in? I haven't heard a convincing argument why vendor lock in is a problem regarding the cloud. It can be a problem, but all solutions result in you avoiding the things you went there for in the first place. There is exceptions to this obviously but I find most people worried about vendor lock in are no where near big enough to bother running multi cloud.
- neop1x 8y ago
  because you have to agree with every change vendor make. If they double pricing, you pay twice. If they ban service type you host, you have to stop. If they make an incompatible change in some of the hosted parts, you have to adapt. If you grow too much they refuse to allocate you more resources or it is expensive for you to use them at your scale, it is difficult to migrate away. That is vendor lock in -> loss of freedom and choice.
- nickbauman 8y ago
  neop1x has a great response. A more concrete example would be a gaming company that started out with AppEngine for its server support for the game. Once the game has a proven revenue stream, the economics of moving from AppEngine to AppScale are a critical next step to maximizing ROI. You have all the code, now you just need to host it somewhere. Can't do that with any other serverless Platform. It's important to note that AppScale is an aPaaS, and API-platform-as-a-service, where you're guaranteed a consistent API with the ability to plug in different implementations. Something even beyond your typical openness in F/OSS software, too.

ngrilly 8y ago

> I have deployed AppEngine apps on the F/OSS AppScale unmodified. How did you manage secrets on Google App Engine?

nickbauman 8y ago
In the flex environment you can inject secrets at container build time. In App Engine standard I've used a deploy wrapper around ansible vault to do it.
- ngrilly 8y ago
  > In the flex environment you can inject secrets at container build time. Does it mean your secrets are stored in plain text in the container image? > In App Engine standard I've used a deploy wrapper around ansible vault to do it. What does the deploy wrapper do? Does it produces an app.yaml file with the secrets injected in it, after having been decrypted by Ansible Vault?
  - nickbauman 8y ago
    Q: Does it mean your secrets are stored in plain text in the container image? A: No. It means the secrets are stored as environment variables in the container. Q: What does the deploy wrapper do? A: It prompts the developer to input the ansible vault password , decrypts the vault and injects the secrets into the environment. Generally speaking, I follow the 12-factor approach: https://12factor.net/ https://12factor.net/
    - ngrilly 8y ago
      What do you mean by "injecting secrets into the environment"? You mean a section in your app.yaml like this one: env_variables: DB_PASSWORD: "this is a secret" As for as I know, in the Standard and Flex environments, app.yaml is the only way to define environment variables.

lugg 8y ago

Why should you be concerned about vendor lock in? I haven't heard a convincing argument why vendor lock in is a problem regarding the cloud. It can be a problem, but all solutions result in you avoiding the things you went there for in the first place. There is exceptions to this obviously but I find most people worried about vendor lock in are no where near big enough to bother running multi cloud.

neop1x 8y ago
because you have to agree with every change vendor make. If they double pricing, you pay twice. If they ban service type you host, you have to stop. If they make an incompatible change in some of the hosted parts, you have to adapt. If you grow too much they refuse to allocate you more resources or it is expensive for you to use them at your scale, it is difficult to migrate away. That is vendor lock in -> loss of freedom and choice.
nickbauman 8y ago
neop1x has a great response. A more concrete example would be a gaming company that started out with AppEngine for its server support for the game. Once the game has a proven revenue stream, the economics of moving from AppEngine to AppScale are a critical next step to maximizing ROI. You have all the code, now you just need to host it somewhere. Can't do that with any other serverless Platform. It's important to note that AppScale is an aPaaS, and API-platform-as-a-service, where you're guaranteed a consistent API with the ability to plug in different implementations. Something even beyond your typical openness in F/OSS software, too.