Micro-services 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 Google App Engine Focus on your code! Java Python Go PHP Managed VM Instances are health-checked, healed as necessary, and co-located with other module instances within the project Critical, backwards compatible updates are automatically rolled out to the underlying operating system Google Compute Engine Kubernetes A high performance, open source, general RPC framework that puts mobile and HTTP/2 first. Google Cloud Platform is used and trusted by over 4 million applications Micro-services - solution for process, governance, cost of operation and scalability issues, not a technology. We're building the ability to fix a typo on a prominent page of your large system within minutes without touching the rest of the system. We are promising the ability to maneuver an oil tanker as if it was a canoe, in a world full of oil tankers. Valentyn Shybanov olostan@gmail.com http://olostan.name Kudos to Dan North @tastapod, Dejan Glozic @dglozic,Martin Fowler @martinfowler and other great people who contribute in understanding and implementing micro-services. Special thanks to Google for their great products. Micro-services in Google Cloud Platform My name is Valentyn Shybanov. You can find more information on http://olostan.name/ There are three simple principles of micro-services. First one - isolated logical-bound components. Second - asynchronous messaging between services. But no single "enterprise service bus", let service decide the best way to communicate. HTTP/1, HTTP/2, REST, WCF... And last one - each service should store its own data. No single Database - that means no DB bottleneck, no single decision about relational vs not-relational databases, But what is "micro"? Does that mean that each service should be 100 lines of code? 1000? How to understand is service "micro" or not? I like how Dan North defined this. As long as you can fully understand bounds of service, understand all dependencies, that mean that it is good candidate for micro-service. So let's take a look what Google Cloud Platform can suggest: First and the most easiest is Google App Engine With GAE you can focus on code. Everything else is handled by Google. You write code, Google do building, deployment, health monitoring, load balancing - everything except writing code of your app! If you have, for example, Java app, all you need is to add single file that describes endpoints There are couple of restrictions: like set of languages, that could be used, not full SDK, access to system etc But if it not enough, you can use Managed VM: In this case you can use other languages (like Dart), full access to system resources etc. Still Google take care about lots of things like hearth checking OS is updated automatically giving reliable safe system But even if you are unsatisfied with Managed VM, you can use Google Compute Engine for running VMs. It is IaaS provided by Google. Even in this case Google can suggest you to use Kubernetes: easy way to automate management of Linux containers For example, with simple configuration file you can spawn MongoDB in cluster in reliable way Or you own application in scaled (replicas:2) way. Kubernetes will make sure that there will be at least 2 instances running. And for communication between services you can use GRPC - minimal overhead and bi-directional communication. Internally gRPC use Protobuf, so messages and services are specified in a very clean way Please feel free to contact me!