6 ms·

It would be quicker for me to run things locally - in my team we all have access to an AWS account each but to test my code remotely I need to compile code, bui

It would be quicker for me to run things locally - in my team we all have access to an AWS account each but to test my code remotely I need to compile code, build my container, push my container to ECR then deploy the container to ECS - that last step takes minutes.

scarface74 4y ago
The micro service I was testing locally connected to remote services either via an https end point or via service discovery. It didn’t have to run in a container at all or be run remotely. If it communicated via messages, it simply read from or wrote to the queue using local IAM credentials. If you’re developing locally to none public endpoints, use a VPN or develop within an IDE hosted on AWS behind a VPC. Why does the app you’re testing run differently in a container than outside a container? Standard disclaimer to expose my biases not to do the whole “appeal to authority thing”: I work in ProServe at AWS (cloud app development consultant). But I did the same thing when I was working in the real world. My specific job looks just like a senior enterprise dev + a shit ton of yaml, HCL, draw io diagrams and PowerPoint slides. The other bias I have is that I work for the only company where I never have to worry about an AWS bill and I can spin up ridiculous remote EC2 based development environments when needed. But I also didn’t have many constraints when I was the de facto “cloud architect” at a 60 person startup.
- jamesfinlayson 4y ago
  Unsurprising reasons for everything - security department would have been reluctant to allow development from inside AWS, and running in Docker was to ensure everyone (i.e. all developers, testers and TeamCity agents) were running on the same versions of runtimes etc (Docker was chosen as the easiest solution for this problem at the time).
  - scarface74 4y ago
    Damn, I first got into AWS not just to avoid administering systems. But to also avoid system administrators. That being said, how do you get on different versions if everyone uses the same package manager config file (requirements.txt/package.json/the wonderful system that Go uses/whatever Nuget/C# uses). I’m also spoiled because I’ve never been in a position where I wasn’t the developer and leading the “DevOps” initiatives since working with the cloud - not bragging, I only opened the AWS console four years ago for the first time. HN/Reddit is a good place to find out other peoples experience.
    - jamesfinlayson 4y ago
      It's more to make sure everyone is using Java 11.x, Java 17.x, Python 3.x, Node x etc - we're on Macs but TeamCity agents are Linux and Docker is easy way to pin the runtime on both operating systems. Docker also fixes the "I forgot to brew install a specific version" in this case.
chupasaurus 4y ago
> deploy the container to ECS - that last step takes minutes Either you wind up an instance for each container, it takes too long to start the app with less resources or the image size is in dozens of GB, everything could be avoided.

scarface74 4y ago

The micro service I was testing locally connected to remote services either via an https end point or via service discovery. It didn’t have to run in a container at all or be run remotely. If it communicated via messages, it simply read from or wrote to the queue using local IAM credentials. If you’re developing locally to none public endpoints, use a VPN or develop within an IDE hosted on AWS behind a VPC. Why does the app you’re testing run differently in a container than outside a container? Standard disclaimer to expose my biases not to do the whole “appeal to authority thing”: I work in ProServe at AWS (cloud app development consultant). But I did the same thing when I was working in the real world. My specific job looks just like a senior enterprise dev + a shit ton of yaml, HCL, draw io diagrams and PowerPoint slides. The other bias I have is that I work for the only company where I never have to worry about an AWS bill and I can spin up ridiculous remote EC2 based development environments when needed. But I also didn’t have many constraints when I was the de facto “cloud architect” at a 60 person startup.

jamesfinlayson 4y ago
Unsurprising reasons for everything - security department would have been reluctant to allow development from inside AWS, and running in Docker was to ensure everyone (i.e. all developers, testers and TeamCity agents) were running on the same versions of runtimes etc (Docker was chosen as the easiest solution for this problem at the time).
- scarface74 4y ago
  Damn, I first got into AWS not just to avoid administering systems. But to also avoid system administrators. That being said, how do you get on different versions if everyone uses the same package manager config file (requirements.txt/package.json/the wonderful system that Go uses/whatever Nuget/C# uses). I’m also spoiled because I’ve never been in a position where I wasn’t the developer and leading the “DevOps” initiatives since working with the cloud - not bragging, I only opened the AWS console four years ago for the first time. HN/Reddit is a good place to find out other peoples experience.
  - jamesfinlayson 4y ago
    It's more to make sure everyone is using Java 11.x, Java 17.x, Python 3.x, Node x etc - we're on Macs but TeamCity agents are Linux and Docker is easy way to pin the runtime on both operating systems. Docker also fixes the "I forgot to brew install a specific version" in this case.

chupasaurus 4y ago

> deploy the container to ECS - that last step takes minutes Either you wind up an instance for each container, it takes too long to start the app with less resources or the image size is in dozens of GB, everything could be avoided.