and test as it grows larger • Coupling between modules causes random bugs when changes are made • Steep learning curve for new team members • Deployments and upgrades require downtime • If the service crashes, your entire site goes down • Inefficient scaling • Difficult to incorporate to new technologies
separation promotes decoupled designs that have less bugs • There is a lot less to learn to become productive • Deployments don’t require downtime • If a microservice crashes, the rest of the system keeps going • Each microservice can be scaled individually according to its needs • Services can use different tech stacks
to the interactions between services • Complex database joins must be implemented by the application • Deployments have a lot of moving pieces • Lower performance when a request “pinballs” through multiple microservices
going forward • Strategy #2: Break pieces of functionality into microservices over time • Strategy #3: Refactor the entire monolith into microservices • In all cases, a base microservices platform needs to be put in place before refactoring work begins
balancer • While microservices come and go, the load balancer is the “switchboard” • Enables horizontal scaling of services • Enables very cool tricks ◦ Rolling upgrades ◦ A/B testing ◦ Green/Blue deployments ◦ Etc.
services • Must be redundant, highly available, and fast • Services make themselves known to the registry when they start • They are removed (and possibly replaced) when they end or crash • The load balancer is dynamically reconfigured when the registry changes
services • It is important to make these services robust to prevent data loss • Most storage solutions have clustering or mirroring options ◦ MySQL → Galera, Aurora (AWS) ◦ RabbitMQ → Native clustering and mirroring ◦ Etc.
stateless • They can start and stop at any time, without data loss • Horizontally scalable for free • Python microservices can be written as simple web APIs using any framework • Or you can use other mechanisms such as RPC to receive requests
with the service registry • The load balancer detects the change in the registry and updates itself to include the new microservice • The new service starts receiving traffic from the load balancer • If more than one instance of the service exist, the traffic is split among them • The service sends “keep-alive” signals, or responds to periodic health checks • When the service is stopped, or stops sending keep-alives, or fails a health check, it is removed from the registry, and in turn from the load balancer
WebSocket) • The service receiving the client request may need to invoke other services • Services communicate with each other in a variety of ways ◦ HTTP/REST ◦ Job or message queues ◦ RPC mechanisms • Payloads exchanged between services should use well known formats ◦ Pickle is not a good idea ◦ JSON, msgpack, protobufs are all good
(8GB recommended) ◦ Vagrant ◦ VirtualBox ◦ Everything is installed in an Ubuntu 16.04 VM (Windows, Mac, Linux laptops are all OK!) • Deployment commands: git clone https://github.com/miguelgrinberg/microflack_admin cd microflack_admin vagrant up # to create the VM or restart it after shutdown vagrant ssh # to open a shell session on the VM vagrant halt # to shutdown the VM (without destroying it) vagrant snapshot save clean # to save a snapshot with name “clean” vagrant snapshot restore clean --no-provision # to restore the snapshot vagrant destroy # to delete the VM