How granular should your MicroServices be? That’s a loaded question. It’s probably best to start with a definition of a MicroService, and expand from there. In short, a MicroService is a style of building software where different components are broken down into autonomous packages communicating over a network. Robert Fowler says,
“In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”
When we look back historically as to how computers were optimized, it’s interesting that most of the current optimizations are based on physics. Think about when the Cray Super Computers were created. They were a super fast main frame system. What made them different from other main frame hardware was the physical configuration of the components. The components were arranged in a circle formation. This allowed the distance of the wires connecting the components to be much shorter, thus decreasing the time needed to move data from one component to the next. As a result, there was no point in developing MicroServices, because all of the software ran on a single very fast machine.
It’s amazing that we are getting speeds, using our current network technology, rivaling the buss speeds of the original single component systems. Today you can see the difference in the Cray brand, as it has evolved to using multiple small systems in multi-node configuration working as a single system. No longer are the constraints restricted simply to wire length. Now we have extended our buss to something external to an individual system. Take a look at http://www.cray.com/sites/default/files/resources/kyoto.pdf where one implementation is described.
Since we can now separate systems based on logical purpose rather than a single hardware system, and still obtain more than reasonable performance, this raises the question of how much to break up the services, or MicroServices. In theory, you could have a MicroService for a single method. On the other extreme, your MicroService could be as big as a functional area, or sub-system. How do you decide which path to follow?
Here are some things that are important to take into consideration:
- How are you going to deploy and manage these MicroServices?
- How are you going to manage the dependencies on the MicroServices?
- Who controls the contracts for communication between a MicroService and a client?
- What about scalability, disaster recovery, security and error handling?
- What about third party tools, and how does separation impact your licenses?
- Does a new service require a new OS license, and how much does that cost?
- How are you going to keep it current with evolving frameworks?
As a DBA you need to be aware of these kinds of architectural decisions because, if history continues, the database is usually the first consideration when system performance degrades. Many times, you end up being the person who provides the information for others to fix their issues, either by proving your system performance hasn’t changed, or being able to demonstrate how database clients are consuming your data poorly. I’ve had database issues occur simply because a client didn’t release database connections, relying on the network to terminate them at the one minute maximum inactivity network default. MicroServices could extend this issue.
Would you like to add your experience or thoughts to this conversation? We are now open for comments below. It’s time to share your insight with others when it comes to MiroService implementation.
Cheers,
Ben