Application Architectures - The Practice of Cloud System Administration - page 91

4.7.2 Support
SOAs have benefits at the people management level, too. As a system grows, the team that
develops and operates it tends to grow as well. Large teams are more difficult to manage
than smaller, focused teams. With an SOA it is easy to split up a team every time it grows
beyond a manageable limit. Each team can focus on a related set of subsystems. They can
even trade subsystems between teams as skills and demands require. Contrast this to a
large,tightly coupled system that cannot beeasily divided andmanaged byseparate teams.
Splitting Teams by Functionality
AtGoogle,GmailwasoriginallymaintainedbyonegroupofGooglesitereliab-
ility engineers (SREs). As the system grew, subteams split off to focus on subsys-
tems such as the storage layer, the anti-spam layer, the message receiving system,
the message delivery system, and so on. This was possible because of the SOA
design of the system.
4.7.3 Best Practices
Following are some best practices for running an SOA:
• Use the same underlying RPC protocol to implement the APIs on all services. This
way any tool related to the RPC mechanism is leveraged for all services.
• Have a consistent monitoring mechanism. All services should expose measure-
ments to the monitoring system the same way.
• Use the same techniques with each service as much as possible. Use the same load
balancing system, management techniques, coding standards, and so on. As ser-
vices move between teams, it will be easier for people to get up to speed if these
things are consistent.
• Adopt some form of API governance. When so many APIs are being designed, it
becomes important to maintain standards for how they work. These standards often
impart knowledge learned through painful failures in the past that the organization
does not want to see repeated.
When a tightly coupled system becomes difficult to maintain, one option is to evolve it
into a loosely coupled system. Often when systems are new, they start out tightly coupled
with the justification, real or not, of being more resource efficient or faster to develop. De-
coupling the components can be a long and difficult journey. Start by identifying pieces
that can be spilt out as services one at a time. Do not pick the easiest pieces but rather the