Continued from page 1.
When speaking to Steven Czerwinski, he mentioned their critical customer row space mapping data is replicated and separated in different ways due to its importance.
"Whereas the per shard information, that's in its own little partition. It sucks if it goes down because that portion of the customer population is not going to have their logs available, but it's only impacting 5 percent of the customers rather than 100 percent of the customers," Czerwinski explained.
Characteristic 5: A well-designed service is a single source of truth
The final characteristic to keep in mind is to design a service to be the single source of truth for something in your system.
To give you an example, when you order something from an eCommerce site, an order ID is generated. This order ID can be used by other services to query an Order service for complete information about the order. Using the pub/sub concept, the data that is passed around between services should either be the order ID, not the attributes/information of the order itself. Only the Order service has complete information and is the single source of truth for a given order.
Testing: Is Your Service Too Small or Improperly Defined?
During the testing and implementation phase of your microservice system, there are a number of indicators to keep in mind.
Look out for is any over-reliance between services. If two services are constantly calling back to one another, then that's a strong indication of coupling and a signal that they might be better off combined into one service.
Going back to the example Chris McFadden shared at the beginning of this chapter where he had two API services, accounts and users, that were constantly communicating with one another, McFadden came up an idea to merge the services and decided to call it the Accuser's API. This turned out to be a fruitful strategy:
"What we started doing was eliminating these links [which were the] internal API calls between them. It's helped simplify the code." McFadden informed me.
The second red flag is if the overhead of setting up the service outweighs the benefit of having it be independent.
Darby Frey explained, "Every app needs to have its logs aggregated somewhere and needs to be monitored. You need to set up alerting for it. You need to have standard operating procedures and run books for when things break. You have to manage SSH access to that thing. There's a huge foundation of things that have to exist in order for an app to just run."
Considerations for Larger Teams
For larger organizations, where entire teams can be dedicated to owning a service, organizational consideration comes into play when determining service boundaries. And there are two considerations to keep in mind: independent release schedule and different uptime importance.
"The most successful implementation of microservices we've seen is either based on a software design principle like domain-driven design for example, and service-oriented architecture or the ones that reflect an organizational approach," said Khash Sajadi, CEO of Cloud66.
Amazon is a perfect example of a large organization with multiple teams. As mentioned in an article published in API Evangelist, Jeff Bezos issued a mandate to all employees informing them that every team within the company had to communicate via API. Anyone who didn't would be fired.
This way, all the data and functionality was exposed through the interface. Bezos also managed to get every team to decouple, define what their resources are, and make them available through the API. Amazon was building a system from the ground up. This allows every team within the company to become a partner of one another.
I spoke to Travis Reeder, CTO of Iron.io, about Bezos' internal initiative.
"Jeff Bezos mandated that all teams had to build API's to communicate with other teams. He's also the guy who came up with the 'two pizza' rule; a team shouldn't be larger than what two pizzas can feed," he said.
"I think the same could apply here: whatever a small team can develop, manage and be productive with. If it starts to get unwieldy or starts to slow down, it's probably getting too big," Reeder told me.
Designing microservices can often feel more like an art than a science, and a lot of the advice out there is fairly abstract, leading to confusing discussions. To counter that tendency, here is a recap of the five characteristics of well-designed microservices according to some of our industry's top CTOs:
- It doesn't share database tables with another service
- It has a minimal amount of database tables
- It's thoughtfully stateful or stateless
- Its data availability needs are accounted for
- It's a single source of truth
These are five specific characteristics to look for when designing your next set of microservices. Next time you're tasked with drawing the boundaries for new services, I hope referring back to these helps make that task much easier.