A code session on Microservices at Yotpo using Go, Consul & gRPC

1. Microservices
Code Session

3. ● Overview Of Microservices
● Service Discovery
○ Consul - Overview
○ Demo
● Protocol Buffers
○ Overview
○ Example
● gRPC
○ RPC - Overview
○ Google’s gRPC - Example
● Yotpo Services
○ Structure
○ Workflow of creating a new service
● Yotpo Service Utilities and The PB Project
● Deployment
○ Makefile
○ Travis
○ Testing
● Creating a new Service - Demo
Agenda

4. Microservices - Overview
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.

5. Attributes Of Microservices
● Componentization as a Service: bringing certain components together to make a customized service.
● Organized Around Business Capabilities: segregating capabilities for specific business areas like user interface and
external integrations.
● Development Process is Based on Products Not Projects: following Amazon’s “eat your own dog food,” developers
stay with the software for the product’s lifetime.
● Smart Endpoints and Dumb Pipes: each microservice is as decoupled as possible with its own domain logic.
● Decentralized Governance: enabling developer choice to build on preferred languages for each component.
● Decentralized Data Management: having each microservice label and handle data differently.
● Infrastructure Automation: including automated deployment up the pipeline.
● Design for Failure: meaning that more ongoing testing of “what if” has to occur to prepare for failure.

6. The Good
● Microservice architecture gives developers the freedom to independently develop and deploy
services
● A microservice can be developed by a fairly small team
● Code for different services can be written in different languages (though many practitioners
discourage it)
● Easy integration and automatic deployment (using open-source continuous integration tools such
as Jenkins, Hudson, etc.)
● Easy to understand and modify for developers, thus can help a new team member become
productive quickly
● The developers can make use of the latest technologies
● The code is organized around business capabilities
● When change is required in a certain part of the application, only the related service can be
modified and redeployed—no need to modify and redeploy the entire application
● Better fault isolation: if one microservice fails, the other will continue to work (although one
problematic area of a monolith application can jeopardize the entire system)
● Easy to scale and integrate with third-party services
● No long-term commitment to technology stack

7. The Bad
● Due to distributed deployment, testing can become complicated and tedious
● The architecture brings additional complexity as the developers have to mitigate fault tolerance, network latency,
and deal with a variety of message formats as well as load balancing
● When number of services increases, integration and managing whole products can become complicated
● In addition to several complexities of monolithic architecture, the developers have to deal with the additional
complexity of a distributed system
● Developers have to put additional effort into implementing the mechanism of communication between the services
● Handling use cases that span more than one service without using distributed transactions is not only tough but
also requires communication and cooperation between different teams
● Partitioning the application into microservices is very much an art

8. The Ugly

9. Yotpo Monolithic App
B2B
Widget
Analytics
API MySQL
Yotpo Microservices
B2B
Widget
Analytics
Router/Api
Mongo
MySQL
Redis
RethinkDB
Cassandra
Link
Service
Review
Service
Feature
Service
Account
Service
Purchase
Service
**General Concept

10. New Api - General Request Overview

11. Service Discovery
Service discovery is a key component of most distributed systems and service oriented architectures.
There are two sides to the problem of locating services. Service Registration and Service Discovery.
● Service Registration - The process of a service registering its location in a central registry. It usually register
its host and port and sometimes authentication credentials, protocols, versions numbers, and/or environment
details.
● Service Discovery - The process of a client application querying the central registry to learn of the location of
services.

13. Service Discovery Diagram

14. Consul
Key Features
● Service Health Checks
● Support for multiple Datacenters - Datacenter Aware
● Built in Key/Value store
● Query using DNS or HTTP
Installation is here

15. Consul Demo

16. Protocol Buffers
“Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing
structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be
structured once, then you can use special generated source code to easily write and read your structured
data to and from a variety of data streams and using a variety of languages.”
Why use Protobuffs?
● Validations and Extensibility and Saftey
○ No need for model validation
○ required, optional, repeated keywords
● Less Boilerplate Code
○ No Need to for Encoding/Decoding/Parsing Logic - this is handled by the class that was generated by the
proto file.
● Easy Language Interoperability
○ Generate proto file for the every language you need
● Very Dense data and Very Fast Processing

17. Example of Proto definition
Language examples and guidelines here

18. RPC - Remote Procedure Call
Remote Procedure Call (RPC) is a protocol for inter-process communication that allows
a computer program to cause a subroutine or procedure to execute in another address
space without having to understand network details.
RPC uses the client/server model. The requesting program is a client and the service-
providing program is the server. Like a regular or local procedure call, an RPC is a
synchronous operation requiring the requesting program to be suspended until the results
of the remote procedure are returned. However, the use of lightweight processes or
threads that share the same address space allows multiple RPCs to be performed
concurrently.

19. RPC Diagram

20. Google’s gRPC
In gRPC a client application can directly call
methods on a server application on a different
machine as if it was a local object, making it easier
for you to create distributed applications and
services. As in many RPC systems, gRPC is based
around the idea of defining a service, specifying the
methods that can be called remotely with their
parameters and return types. On the server side,
the server implements this interface and runs a
gRPC server to handle client calls. On the client
side, the client has a stub that provides exactly the
same methods as the server.

21. gRPC Example

22. The Yotpo Service
Motivation and guiding principles
● Using gRPC with Protobuf makes development easy - no need to take care of
server core code (connection pools etc) we generate the code in the
language of our choosing and implement our business logic.
● Code reuse and abstraction - Our Service code doesn't care which service
discovery we use - we can change it in the utils and it would be transparent
to other services - INTERFACES.

23. Creating a new Service
Client Server
Utils Service
Service
Discovery DB
Protobuf
EndPoints Messages
gRPC
Shared Code
Serialization
Compiled
Objects

24. Yotpo Service Utils
Is a project for common utilities that we would like to share between services.
Some of the things we implemented :
● Service Discovery - Interaction with Consul
● Logging
● Flags
● Signals
● Service Factory:
○ Database Clients - RedisConnection
○ Service Struct - Built from Service Config (host, port, type) and an interface of Service
Connector - all services must implemented the ping method so we could treat them all as
service connectors

25. Deployment
● Makefile
● Travis

26. Live Demo

27. Questions?

28. What’s Next?
Putting it all together
Router project