Production-oriented development

#todayilearned #architecture #programming

TL;DR notes from articles I read today.

Let the engineers who write the code also be responsible for operating it in production: deploying, instrumenting and on-call for monitoring.
If you can avoid building something new, do so. Writing code is the most expensive way to solve any problem that doesn’t address a core business need, especially when there are open-source and hosted solutions for small/medium companies that deal with git repository hosting, observability tooling, managed databases, alerting etc., and even infrastructure for Kubernetes clusters and load balancers.
Make deployment frequent and unexciting: engineers should be able to deploy with minimal manual steps and you should minimize code freezes or blackout periods like ‘don’t deploy on Fridays’.
Switch from manual QA gates to automated testing for the deployment pipeline. Have a team for continuous testing in production, and do away with pre-production environments.
Choose ‘boring’ technology over bleeding edge tech. It is least likely to be unpredictable and is backed by the most expertise when you do have to debug, unlike ‘unique’ systems.

Full post here, 11 mins read

In data-oriented architecture (DOA), systems are still organized around small, loosely coupled components as in services-oriented architecture with microservices. However, the components are always stateless and component-to-component interaction is minimized so that they interact through a data layer instead.
Common examples that approximate DOA include those using data monoliths where all or most data is persisted in a single store, such as knowledge graphs or GraphQL.
If you are worrying about scaling your architecture horizontally, you can consider a data monolith at its center and base your decision on these factors:
1. Service-to-service APIs are not necessarily ad hoc, but it is easier to pass parameters in direct component-to-component communication.
2. Beware if your system has integration as a bottleneck, as it will affect growth.
3. Think hard about data ownership: multiple writers might have to modify the same record so you need to partition write ownership.
4. Carefully plan the shared global schema because inter-component APIs are encoded in the data.
5. If services call others with a direct address (like an IP) and know where to reach a particular service from command-line parameters, you need to wrap those better to construct the right flags, depending on the environment (say, structuring each service under a path routed by one server).

Full post here, 10 mins read

DEV Community