Name: Security in times of Docker & K8s; tech debt; & embedded integration frameworks
Rating: 3.9 (4825 reviews)
Author: mohanarpit

TL;DR style notes from articles I read today.

Don't run binaries as root as that creates a privileged user and higher risks. In a Docker container, use the RUN command to create a user & then use the USER command to make it the default user whenever an image is run as a container. For K8s, use the pod and container security context to force containers to run as non-root.
Run containers with a read-only file system alone. You should not need to write anything more than a temporary file or cache within a container.
Terminating encryption (SSL/TSL) at the load balancer is another security risk. If using a Kubernetes cluster, move the TLS termination into the cluster and then encrypt all traffic within the cluster.
Protect your host CPU and memory against DDOS attacks by setting resource limits on your containers.
Use the Kubernetes network and pod security policies to control the capabilities of containers.

Full post here, 9 mins read

Define a technical debt budget - the maximum debt you can take on without affecting the business bottom line or your customers. If your tech debt balance sheet is in the red, take the time to pay back some of it; if it is in the green, take more risks to try and beat competitors.
Identify areas in the codebase where you will want to pay back your tech debt immediately - usually where debt gets in the way of the company’s current objectives. Examples are weak file ownerships and those with low cohesion and high coupling. Prioritize files that check all three boxes.
If it is not critical or is too complicated or does not need to be improved in the next few months, acknowledge it as debt and let it be.
Decide what you will work on this sprint, month or quarter and see what part of your tech debt overlaps with that roadmap.
From the list of files, thus, see which files are going to be needed for the roadmap ahead. Target these for refactoring.

Full post here, 6 mins read

Define target personas & use cases of developers who are your potential platform users. Prioritize the platform for one target persona over another only after gathering feedback to determine the right direction for their platform.
Establish a good experience with your framework that encourages users to not just make requests but to play around and hack the service to do what they want. Treat this as actionable feedback and prioritize these improvements.
Make integrations as powerful and simple as possible. Instead of asking a partner for a URL to embed, Twitch allows developers to host their front-end code on Twitch itself.
Build tools on top of APIs to cover common use cases. Include native elements that stay the same across integrations.
Use event-catching to capture the context around the app environment and automate the app to fine-tune the experience accordingly.

Full post here, 7 mins read