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).