The responses I provided to a media outlet on August 8, 2017:
Media: How to Explain Microservices in Plain English.
My responses addressed the more detailed questions as follows:
Media: How do you define microservices succinctly?
Gfesser: A microservice can be described as an independently running application that is responsible for a specific domain (often referred to as a "bounded context"). For example, a health insurance firm is likely to consider domains such as claim, provider, and client, and to create a microservice for each. Another application that needs claim presentation, logic, or data should make use of the claim microservice because it is responsible for this particular domain, rather than make use of one or more other applications elsewhere in the enterprise.
Media: How do you explain its benefits?
Gfesser: When presentation, logic, and data about a specific domain is made available from a single location, there is no question as to where to obtain this information, as there can otherwise tend to be redundancy in the enterprise. In addition, lack of dependencies between microservices can help enable DevOps teams to develop, test, deploy, and maintain each separately from one another, leading to decreased time to market.
Media: What are the common misunderstandings about microservices?
Gfesser: There are three common misunderstandings that immediately come to mind. The first is that use of microservices is the same as a circa-2005 practice called SOA (service oriented architecture). One of the key distinguishing factors between these two is that use of SOA tried to reuse as much code in the enterprise as possible. However, extensive reuse tends to mean that significant dependencies also exist. The second is that use of microservices is a silver bullet. While well designed microservices have much to offer the enterprise, it can be difficult to initially determine boundaries between different domains. Additionally, introducing independently running microservices brings complexity to the enterprise, especially when communication needs to take place between two or more microservices.
And this leads to a related third misunderstanding, namely that development of new systems should make use of microservices from the start. Generally speaking, while microservices can help enable decreased time to market in the long-term, in the short-term it can make sense to make use of well-designed traditional applications (often referred to as "monoliths") which can be broken up into microservices at a later point, especially when domains become better understood. Oftentimes, it is difficult to predict how new functionality will be used and to what extent in terms of traffic volume. Prematurely making use of microservices, for example, can increase unnecessary developer workload at an early stage.
See all of my responses to media queries here.