Multilingual Microservices
What is Microservice?
Componentized - Microservices should be very small with a single responsibility and be out of process. This is very different from a typical library where components are assembled in process.
Message Driven - Microservices should be driven by asynchronous messaging where the intelligence is left up to the microservice implementation and not provided by the messaging fabric
Decentralized Data - Each service should manage its own data. You can think of this model as the OO concept of data encapsulation. No service can access the database of another service.
software that fits in your head.
Dan North, @tastapod
Can we do everything with one tool?
O'REALLY?
Use right tool!
Be together, not the same!
Could be applied also to micros-ervices.
Server-Web Client communication (JavaScript)?
NodeJS
Writing buisness logic (complex structures,relations)?
Java / C# / Dart
Parallel computations, data manipulation?
C++ / Go
...you tell me!
Erlang, Scala, Python
Each Language/Platform has own
SDK
Packages
Builder
Containers!
Container
Management System
Swarm
is a Docker.. Simple to use, hard for complex scheduling
Fleet
Low-level and simple orchestration tooling
Low-level, battle-hardened scheduler
Kubernetes
Opinionated orchestration tool that comes with service discovery and replication baked-in
Opiniated by Google
14 Data Centers
How many servers there are?
1837440
Google Spanner
~10^6 to 10^7 machines, ~10^13 directories,
~10^18 bytes of storage, spread at 100s to 1000s of
locations around the world, ~10^9 client machines
Let's Build!
Kubernetes
Serve HTML templates, accept user requests [frontend]
Get request form front-end and pass to renderer [dispatcher]
Render actual picture requested [renderer]
Test locally
Dockerize
Deploy to Cloud
Demo
Valentyn Shybanov
olostan@gmail.com
http://olostan.name
Kudos to Dan North @tastapod, Dejan Glozic @dglozic,Martin Fowler @martinfowler, Google, and other great people who
contribute in understanding and implementing micro-services. Special thanks to Google for their great products.
Using different programming languages in microservice architecture
and deployed on Google Cloud Platform
My name is Valentyn Shybanov, olostan.name. I am
Software Architect in Twinfield.
Let me mention some main properties of microservices:
One of the most discussed question is how big microserive should be. 100 LoC? 1000? My most
favourite answer is Den North's definiting: Software that fits in your head
But can we do everything with using same tool?
May be we can have universal "swiss knife"
that we can use to develop all our multiservices?
Try to hit nail with swiff knife
Especially when there is tools designed for that
There is a slogan from Android that can be applied to microservices
Here are samples of tools that can suite much better for solving specified problems
But each of platform bring own problems
Each of them have own SDK, Package System, Builders, Compilers, Linting, etc
Good solution for these problems is to use containers.
Tehy looks like a great solution for the first view - inside is wrapped all
complexity, all dependent components, it is easy to run on any system with just "docker run".
But when there are 2 containers, you need to think how to manage them. Deploy in the
way that will not ruin your system.
When there are more you need to think about possible dependencies between them
And it becomes horrow when new and new containers appears
Solution for that can to to use container management system that will take over
deployement, assembling containers to the system. There are couple of them:
Swarm is really Docker-oriented. For complex solutions you need to implement own way
of managing these containers.
CoreOs' Fleet give a very fine control over cluster where containers could be run, but
it is quite simple and primitive. Again for complex scenarios you need to implement own extra layer of management
Mesos is the olderst, and it is not exactly container oriented. It is good for managing cluster,
but not well suited for managing container-based solutions
Kubernetes from Google has own concepts (Pods, Replication Controllers) that are
quite opiniated, but gives fool control over the cluster and containers. It handles name resolution, container dependecy resolving etc
Ti is opiniated by Google. Can we trust Google that their solution is good enough?
Google has 14 datacenters whole over the world. how many servers they operate?
There is no public information, but we can estimate at least approximately (using Google Maps and
calculate number of servers that could be fir inside area occupied by Data Centers
Another approximation could be done from Jeff Dean's preseentation about Google Spanner that
is designed to operate on 10^6 to 10^7 servers
Let's build sample application using multiple languages
We'll use NodeJS for frontend because it use same platform as client (JS), Java
for buisness logic and Go for manipulation with data. gRPC for communicate between them.
We'll use Kubernetes to orchestrate these containers
And we'll deploy to the cluster running on Google Cloud Platform
First we need to define contract using Protobuf definition. The most important
part here - "service" part where we define what is exposed by our server
For Java we can use grpc grandle plugin that will generate Java interfaces that needed
to be implemented and classes that can be used for exposing services using Netty server
Just implemented generated interfaces you can expose service. You can use generated
classes to form response and send it back
As for Go service we should define same contract (protobuf definition does not depend
to language that is going to implement it or usee it as client).