12 Things to consider when deploying HTTP Services
Rather than putting all domain logic into a single application monolith, modern software architectures tend to split functionality into multiple applications and services. There are definitely pros and cons of either design; and it is not the goal of this article to go into the details of what is better and why. However, it is generally agreed upon that one of the detractors of using services is the increased complexity that it brings to the table. Specifically, there are many more points of failure, and building a robust system means expecting that nodes of your system may fail at any given point in time. These failures cannot be ignored and you cannot expect to be able to wait until your nodes are all green to operate normally. In order to address some of the added complexity that services introduce, I’ve compiled a checklist of important elements to consider: