I am working on API Guidance with Fuse and Data Virtualization and have been thinking about splitting services into manageable microservices that expose APIs by function. I came across a site that discussed some microservice patterns:
One of the articles on the Pattern site discussed the Art of Scalability that describes how to solve scalability problems. This gives us good insight on how to split applications and services by function to achieve Scalability. We can achieve this by building APIs with microservices within containers.
The Art of Scalability book describes a really useful, three dimension scalability model: the scale cube. The microservice architecture is an application of Y-axis scaling on the scale cube. We will go through more detail of the Y-Axis but for further description of the X and Z Axis you can read more on the AKF Partner site.
As you can see from the graphic below, the AKF Scale Cube consists of an X, Y and Z axis. Each of the Axes addresses a different approach to scale a service. The Y-Axis highlights splitting services by function which we can split into Microservices that expose APIs by Function or Service.
From AFK Partners splitting services article:
The Y Axis of the cube represents a split by function, service or resource. A service might represent a set of use-cases and is most often easiest to envision through thinking of it as a verb or action like “login” and a resource oriented split is easiest to envision by thinking of splits as nouns like “account information”. These splits help handle not only the split of transactions across multiple systems as did the X axis, but can also be helpful in reducing or distributing the amount of memory dedicated to any given application across several systems. A recommended approach to identify the order in which these splits should be accomplished is to determine which ones will give you the greatest “headroom” or capacity “runway” for the least amount of work. These splits often come at a higher cost to the engineering team as very often they will require that the application be split up as well. As a quick first step, a monolithic application can be placed on multiple servers and dedicate certain of those servers to specific “services” or URIs. While this approach will help spread transaction processing across multiple systems similar to our X axis implementation it may not offer the added benefit of reducing the amount of system memory required by service/pool/resource/application. Another reason to consider this type of split in very large teams is to dedicate separate engineering teams to focus on specific services or resources in order to reduce your application learning curve, increase quality, decrease time to market (smaller code bases), etc. This type of split is often referred to as “swimlaning” an application.From microservices.io scale cube article:
Unlike X-axis and Z-axis, which consist of running multiple, identical copies of the application, Y-axis axis scaling splits the application into multiple, different services. Each service is responsible for one or more closely related functions. There are a couple of different ways of decomposing the application into services. One approach is to use verb-based decomposition and define services that implement a single use case such as checkout. The other option is to decompose the application by noun and create services responsible for all operations related to a particular entity such as customer management. An application might use a combination of verb-based and noun-based decomposition.
