This should be a pretty obvious one, but it needs to be written down. If you have a need for a feature that is provided by a tool that you do not want to develop in-house, you will not have much of a choice but to go with it and hope for the best. Luckily, in most cloud technologies and the tooling modules that supports them, there are usually at least two competing options fighting for the same users so things are not as dire as they may seem today even though just a single year back almost everything in this space had a version number below 1.0. As you evaluate how competing tools fit your needs, also keep in mind that not every tool is geared towards the same purpose even if they solve the same issues. If we take an example of current Kubernetes versus Marathon, even though they can both be used to solve the same service deployment problems, Kubernetes is mostly geared towards that single purpose but Marathon, for example, can also be used to do scheduling and cluster management as an additional functionality so we are in the proverbial sense really comparing apples and oranges.

In broad strokes, your service infrastructure needs will drive your tooling needs so you will not often end up dealing with your favorite programming language, having easy integration points, or working with a sane tooling codebase, but integrating a tool that will save you hundreds or thousands of man-hours is something not to be taken lightly. Sometimes it might be possible to completely skirt around a technological requirement by changing pieces of your system's architecture to avoid adding complexity to the system, but in my personal experience this was almost never easy to do so your mileage may vary.