In my time s working in the software realm I have worked on projects of various sizes. Local bands wanting a web presence, user generated content upload sites, college assignments, financial industry video services, national health care web applications, on board ship systems, social media aggregation, US domestic distributor for foreign sourced video content, and currently a software security and end user system monitoring service. Some projects were small, some large, some simple, some complex.
Start ups are well known and sometimes even idolized for their ability to take an idea from concept to production in a very short about of time. In the world of business having a small
time to market can mean the difference between success and ruin.
Larger organizations are often scoffed and or even shrugged off due to the exact opposite. However, the larger organizations typically have systems that a dozen startups would get lost inside of. Many times these system have had a dozen or more teams operate and iterate on the system. Knowledge applied, knowledge lost, knowledge incorrectly documented. But at the end of the day bringing the business revenue. Money talks, bulls*** walks.
These two different types of entities have different constraints, different pressures, and different driving factors. Not every org. can be, nor want to be, Google, or Twitter, or Instagram. Then again, not everyone wants to be the DoD, Wells Fargo, or General Electric.
Ever do something in bash and wish you could do it in parallel? Checkout this excellent article by Bash Prompt. One use case I can think of right now is running suites of unit tests in parallel. Take that 2 to 3 minute suite down to seconds.
Did this during the afternoon at work, since they use Terraform (TF) pretty heavily I am getting familiar with it as much as possible. Enjoy!
Over at stayclassyinternet Thomas did a write up on the AWS pricing over time; specifically focused on S3 as it has been a consistent service available for the longest time. It is an interesting quick read.
This image was shared in the Suncoast Developers Guild slack group yesterday. I found it an interesting visualization of the practices and operational patterns that are leveraged to enable a desired release schedule. What do you think about it?
Docker Images, everyone says
smaller is better but how do you do this but still maintain functionality and debugging ability? Well, here is how I did it.
Docker Multi-stage building: https://docs.docker.com/develop/develop-images/multistage-build/#name-your-build-stages
Google Distroless Images: https://github.com/GoogleCloudPlatform/distroless/blob/master/examples/nodejs/Dockerfile
Docker-Puppeteer-Jest (Headless Chrome + Jest testing image): https://hub.docker.com/r/davidjeddy/docker_puppeteer_jest/
What we need to do:
Here is where we start, a 800Mb+ size image just to run headless Chrome and Jest. Ouch.
So lets apply the multi-stage build paradigm and use the Google Distroless NodeJs Image:
Now we rebuild the image using the `build . -t davidjeddy/docker_puppeteer_jest` command and we end up with a ~ 400MB images. 50% Savings!
Now remove the old busted and bloated image `docker rmi davidjeddy/docker_puppeteer_jest`.
Run the image command as normal and observe the same expected output as before. Unfortunately for the example project herein more work is needed as the original image did not keep dependences within the app dir.
After building your service image, make an addition step that plops it into a distroless base image. Boosh, easy win.