COMPLEX APPLICATIONS ARE COMPOSED OF SMALL, INDEPENDENT PROCESSES COMMUNICATING WITH EACH OTHER USING LANGUAGE-AGNOSTIC APIS.[1] THESE SERVICES ARE SMALL, HIGHLY DECOUPLED AND FOCUS ON DOING A SMALL TASK,[2][3] FACILITATING A MODULAR APPROACH TO SYSTEM-BUILDING.[4] Wikipedia DEFINITION OF MICRO-SERVICES
of ALL THE THINGS ▸ Make sure you log the X-Request-Id of the source in all of the following interactions ▸ Logging SQL with /* service_name.filename.method_name /* in order to make sure which service is making which SQL calls ▸ Composing all logs to a central location to make sure you have the pipeline in place. ▸ Logging of messages received in order to follow faults: Service X sent the message, Service Y got it but failed to act on it etc…
KEY COMPONENT OF MOST DISTRIBUTED SYSTEMS AND SERVICE ORIENTED ARCHITECTURES. THE PROBLEM SEEMS SIMPLE AT FIRST: HOW DO CLIENTS DETERMINE THE IP AND PORT FOR A SERVICE THAT EXIST ON MULTIPLE HOSTS? OPEN-SOURCE SERVICE DISCOVERY · - JASON WILDER'S BLOG
OF PEOPLE--THE BEHAVIORS, BELIEFS, VALUES, AND SYMBOLS THAT THEY ACCEPT, GENERALLY WITHOUT THINKING ABOUT THEM, AND THAT ARE PASSED ALONG BY COMMUNICATION AND IMITATION FROM ONE GENERATION TO THE NEXT. tamu.edu CULTURE
SERVICE INTERFACES. TEAMS MUST COMMUNICATE WITH EACH OTHER THROUGH THESE INTERFACES. THERE WILL BE NO OTHER FORM OF INTER-PROCESS COMMUNICATION ALLOWED: NO DIRECT LINKING, NO DIRECT READS OF ANOTHER TEAM’S DATA STORE, NO SHARED-MEMORY MODEL, NO BACK-DOORS WHATSOEVER. THE ONLY COMMUNICATION ALLOWED IS VIA SERVICE INTERFACE CALLS OVER THE NETWORK. IT DOESN’T MATTER WHAT TECHNOLOGY THEY USE. ALL SERVICE INTERFACES, WITHOUT EXCEPTION, MUST BE DESIGNED FROM THE GROUND UP TO BE EXTERNALIZABLE. THAT IS TO SAY, THE TEAM MUST PLAN AND DESIGN TO BE ABLE TO EXPOSE THE INTERFACE TO DEVELOPERS IN THE OUTSIDE WORLD. NO EXCEPTIONS. Anyone who doesn’t do this will be fired. Thank you; have a nice day!