FOUR common pitfalls to avoid when defining your DevOps solution:
1. Keep a “prime” instance in a symmetric/elastic cluster. This common happens for
singular periodic tasks, special file/api servers, cluster managers. This pattern goes
against elasticity and holds back the development in many cases, in addition to being
hard to track in production. There are several solutions here, depending on the
specific starting from breaking to two clusters (singleton and elastic) to message queues
and other approaches.
2. Keeping the configuration for prod/test/dev/int in the same source control as the
deployed operation. This is very comfortable for small early stage teams and cripples
the ability to adjust in production when needed (not to mention security aspects).
3. Putting Cloud credentials in SCM or on the machines them selves. Other than being a
security problem this complicate changes to the system.
4. Unfitted access control to the production/cloud systems: either prevent access for fear
of damages or absorb downtime b/c of unsupervised access. One approach is to create
canned remote access and operations to the system that permits every employee to get
the data they require but cap the potential damage by creating automated remote
access to execute those operations only.