SlideShare a Scribd company logo

Yotpo microservices

•Download as PPTX, PDF•
•
R
Ron Barabash

This document outlines the agenda and content for a code session on microservices. It will cover: - An overview of microservices architecture and attributes - Service discovery using Consul and a demo - Protocol Buffers for data serialization and an example - RPC and Google's gRPC with an example - The structure of services at Yotpo and the workflow for creating a new service - Shared utilities for services including service discovery and logging - Deployment using Makefiles and Travis - A live demo of creating a new microservice

1 of 29
Microservices Code Session
Yotpo microservices
● 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
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.
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.
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
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
The Ugly
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
New Api - General Request Overview
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.
Yotpo microservices
Service Discovery Diagram
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
Consul Demo
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
Example of Proto definition Language examples and guidelines here
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.
RPC Diagram
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.
gRPC Example
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.
Creating a new Service Client Server Utils Service Service Discovery DB Protobuf EndPoints Messages gRPC Shared Code Serialization Compiled Objects
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
Deployment ● Makefile ● Travis
Live Demo
Questions?
What’s Next? Putting it all together Router project
Yotpo microservices

More Related Content

Yotpo microservices

  • 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
  • 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.
  • 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
  • 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.
  • 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.
  • 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
  • 28. What’s Next? Putting it all together Router project

Editor's Notes

  1. How would services know to communicate with each other? no need for config files
  2. Service discovery is the concept of separating how processes and services find and communicate with one another. Typically this involves each service/node announcing themselves, some form of storage of the name and host/port of the service, and the ability to query (discover) this data from other services. In effect and in short, decoupling services.
  3. http://demo.consul.io/ui/
  4. Protocol Buffers offer several compelling advantages over JSON for sending data over the wire between internal services. While not a wholesale replacement for JSON, especially for services which are directly consumed by a web browser, Protocol Buffers offers very real advantages not only in the ways outlined above, but also typically in terms of speed of encoding and decoding, size of the data on the wire, and more. - Simple installation using brew
  5. Proto3 - New version of proto now in beta stage protoc -I . lib/no_rpc/review_no_rpc.proto --go_out=plugins=grpc:. protoc -I . lib/with_rpc/review_with_rpc.proto --go_out=plugins=grpc:.
  6. Building on the HTTP/2 standard brings many capabilities such as bidirectional streaming, flow control, header compression, multiplexing requests over a single TCP connection and more. These features save battery life and data usage on mobile devices while speeding up services and web applications running in the cloud.