This document discusses technologies used for distributed systems and microservices including Golang, Protocol Buffers (Protobuf), gRPC, HTTP/2, Docker, and Kubernetes. It provides overviews of each technology, their uses, benefits, and how they enable building distributed systems through containerization and orchestration of microservices. When building distributed systems, these technologies help address challenges through a microservices architecture, horizontal scaling, language independence, and focusing on code deployment over servers.

1. golang, protobuf, gRPC, HTTP/2,
docker, kubernetes
High overview, how when and why to use them in distributed systems and
microservices

2. Golang
• The Golang (Go) is an open-source programming language sponsored by Google
• Go has gained popularity since 2009 and it’s now being used by many companies for a variety of
applications; Dropbox, Google, SoundCloud, CloudFlare, Docker, Cloud Foundry …
• It is fast. Not only in the sense that programs run fast; but also fast in the sense that its compiler
can compile projects fast
• It is a garbage-collected language
• It has built-in concurrency, which allows parallelism in an easier way. Go has the concept of
goroutines to start concurrent work and the concept of channels to permit both communication
and synchronization.
• Go has documentation as a standard feature, and rich standard library which covers a lot of areas
• Go’s built-in build system is both elegant and simple. No need to mess with build configurations
or makefiles

3. Golang
• Go is probably the only language that can claim to have a fully working Web
server as part of its standard library
• Go is relativity young language and has a very young ecosystem but it is growing
extremely fast and more and more users and companies start to use it
• Although Go is a high-level language, it still has low-level features such as
pointers
• Usually used for system and infrastructure programming
• It is not Object-oriented language
• Tools like Docker, etcd, Kubernetes and lot of other tools designed for distributed
computing are built using golang

4. Protocol buffers - protobuf
• Protocol buffers are a language-neutral, platform-neutral extensible
mechanism for serializing structured data
• Like XML, JSON, but smaller, faster, and simpler
• It is Binary format instead of textual like XML, JSON
• Optimized for the wire
• User define how data need to be structured once using DSL, than
generate source code for specific language (go, python, java, c#, …)
• Generated source code can be easily write and read structured data
to and from a variety of data streams and using a variety of languages

5. Protocol buffers - protobuf
• We can add new fields to our message formats without breaking
backwards-compatibility; old binaries simply ignore the new field
when parsing.
• So if we have a communications protocol that uses protocol buffers as
its data format, we can extend our protocol without having to worry
about breaking existing code
• We can even update our data structure without breaking deployed
programs that are compiled against the "old" format.

6. Protobuf banchmark

7. gRPC
• gRPC is an open source high performance RPC framework that can
run in any environment.
• It can efficiently connect services in and across data centers with
pluggable support for load balancing, tracing, health checking and
authentication
• It is also applicable in last mile of distributed computing to connect
devices, mobile applications and browsers to backend services
• It is not REST framework
• REST is more data oriented, RPC is more operations oriented

8. 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 (referred to as just a client in some
languages) that provides the same methods as the server.
• Services are defined using DSL, then code for specific language is generated

9. gRPC
• Support standard request-
response model
• Support one-way streaming
• Support bidirectional streaming
• Use protobuf as its transport
data structure
• Use HTT/2 as transport protocol

10. HTTP/2
• HTTP/2 will make applications faster, simpler, and more robust
• Even better, it also opens up a number of entirely new opportunities
to optimize applications and improve performance!
• The primary goals for HTTP/2 are to reduce latency by enabling full
request and response multiplexing, minimize protocol overhead via
efficient compression of HTTP header fields, and add support for
request prioritization and server push.
• To implement these requirements, there is a large supporting cast of
other protocol enhancements, such as new flow control, error
handling, and upgrade mechanisms

11. HTTP/2
• HTTP/2 does not modify the application semantics of HTTP in any way
• All the core concepts, such as HTTP methods, status codes, URIs, and
header fields, remain in place
• Instead, HTTP/2 modifies how the data is formatted and transported,
both of which manage the entire process, and hides all the
complexity from our applications within the new framing layer
• As a result, all existing applications can be delivered without
modification

12. Docker
• Docker is a tool designed to make it easier to create, deploy, and run
applications by using containers
• Containers allow a developer to package up an application with all of the
parts it needs, such as libraries and other dependencies, and ship it all out
as one package
• Developers use Docker to eliminate “works on my machine” problems
when collaborating on code with co-workers
• Operators use Docker to run and manage apps side-by-side in isolated
containers to get better compute density
• Enterprises use Docker to build agile software delivery pipelines to ship
new features faster, more securely and with confidence for both Linux and
Windows Server apps

13. Docker
• A container image is a lightweight, stand-alone, executable package of
a piece of software that includes everything needed to run it: code,
runtime, system tools, system libraries, settings
• Available for both Linux and Windows based apps, containerized
software will always run the same, regardless of the environment
• Containers isolate software from its surroundings
• for example differences between development and staging environments and
help reduce conflicts between teams running different software on the same
infrastructure.

14. Docker
• In a way, Docker is a bit like a virtual machine
• Unlike a virtual machine, rather than creating a whole virtual
operating system, applications to use the same Linux kernel as the
system that they're running on
• Applications requires to be shipped with things not already running
on the host computer
• This gives a significant performance boost and reduces the size of the
application
• Docker is open source

15. Docker
• Docker containers are small in
comparison to the traditional vm
• Fast to run, kill, restart, …
• Use less space
• Can pack more on same
hardware in comparison to the
traditional vm’s
• Google use containers for more
than 15 years

16. Kubernetes
• Kubernetes is an open-source system for automating deployment,
scaling, and management of containerized applications
• It groups containers that make up an application into logical units for
easy management and discovery
• Kubernetes builds upon 15 years of experience of running production
workloads at Google, combined with best-of-breed ideas and
practices from the community
• Designed on the same principles that allows Google to run billions of
containers a week, Kubernetes can scale without increasing your ops
team.

17. Kubernetes
• Kubernetes runs on few concepts:
• Pod is the basic building block of Kubernetes–the smallest and simplest unit
in the Kubernetes object model that you create or deploy. A Pod represents a
running process on your cluster or set of containers.
• ReplicationController ensures that a specified number of pod “replicas” are
running at any one time. In other words, a ReplicationController makes sure
that a pod or homogeneous set of pods are always up and available. If there
are too many pods, it will kill some. If there are too few, the
ReplicationController will start more
• Service is an abstraction which defines a logical set of Pods and a policy by
which to access them - sometimes called a micro-service. The set of Pods
targeted by a Service is (usually) determined by a Label Selector

18. Kubernetes
• Horizontal scaling, Scale your application up and down with a simple
command, with a UI, or automatically based on CPU usage
• Automatic binpacking, Automatically places containers based on
their resource requirements and other constraints, while not
sacrificing availability. Mix critical and best-effort workloads in order
to drive up utilization and save even more resources
• Self-healing, Restarts containers that fail, replaces and reschedules
containers when nodes die, kills containers that don't respond to
user-defined health check, and doesn't advertise them to clients until
they are ready to serve

19. Kubernetes
• Rollouts and rollbacks, Kubernetes progressively rolls out changes to
applications or its configuration, while monitoring application health
to ensure it doesn't kill all your instances at the same time. If
something goes wrong, Kubernetes will rollback the change. Take
advantage of a growing ecosystem of deployment solutions
• Secret and configuration management, Deploy and update secrets
and application configuration without rebuilding your image and
without exposing secrets in your stack configuration
• etc.

20. How, when and why to use them
• Building distributed systems is not an easy task
• They come with a lot of problems
• Traditional approaches are not good…
• We must sacrifice something - CAP theorem
• A lot of choices scale horizontally or vertically, which database to use,
RPC or REST,…
• VMs or containers

21. How, when and why to use them
• Microservice architecture propose that every function is a service
• One time is responsible for only that service (develop, test, deploy,…)
• Easier to scale (horizontally)
• If every service is packed inside container we got all the benefits (and
problems) that containers brings us
• Service is easier to deploy, if show poor performance just kill him and
run new one
• Pats vs cattle principle

22. How, when and why to use them
• This type of architecture is not a silver bullet
• Bring it’s own problems and challenges
• Good enough for distributed systems
• Based on architectures used in Google, Netflix, Amazon, Facebook,…
• Used in really big systems
• Easier to scale
• Easier to maintain
• User can choose best language for service, language independent

23. How, when and why to use them
• Containers , orchestration engines and cloud computing lead to serverless
computing
• Focus on code, not servers
• Serverless computing allows building and running applications and services
without thinking about servers
• Serverless computing is an event-driven application design and
deployment paradigm in which computing resources are provided as
scalable
• Serverless computing is more cost-effective than renting or purchasing a
fixed quantity of servers, which generally involves significant periods of
underutilization or idle time