Skip to content

Latest commit

 

History

History
134 lines (109 loc) · 5.28 KB

README.md

File metadata and controls

134 lines (109 loc) · 5.28 KB
Raw

#Microservices using Async Libraries and MongoDB

##Outline ###Agenda

  • Architecture definition
  • Dataset extrapolation
  • Services layout
  • Team Setup

###Abiding Laws

  • One verb per single function micro-service
  • One developer produces one micro-service
  • Each micro-service has it's own build
  • Statefull data access layer
  • Synchronization process is it's own micro-service
  • We store data into MongoDB
  • We expose services using Flask
  • Everything else is your choice

###Fundamentals

  • Versioning
    • we can have several different versions of the same service running
    • we don't need to shutdown previous
  • Deployment
    • We will be deploying in containers
    • Docker for the rescue
  • Separate Data Store for each service
    • we need to manage the synchronization of the master data
    • this will be a separate service!
  • Treat Severs as Stateless
    • don't worry about a particular server
    • just make sure you have enough to keep the service running and scalable

Architecture review

Microservices architecture generally follows the following schematics:

Architecture Diagram

Your Client Layer will push requests, orchestrated by a load balancer (like ELB) and then get served that request by a webserver. This webserver will know which micro-service to call for the different required services by checking the Service Registry (something like Zookeeper or Netflix Eureka).

And then you might have several different services that respond to a specific "one verb" kind of function of your overall application

What we are NOT going to be doing today!

For this exercise we are not going to put the complex Service Registry or Load Balancer in motion because (well, I'm a bit lazy) of time restrictions and because the overall exercise is around optimization of processes and Async sugar.

What we are going to be doing

Going to start with a monolithic web application:

  • Based on Flask that will allows us to do certain functions
    • search for reddit posts (and other datasources)
    • show recommended pots based on topics
    • tag those posts according with user preferences

Then we will migrate the code base from a pure monolithic approach to REST

  • Based on Eve
    • same type of functionality but replacing underlying calls to a Rest API
    • slowly decomposing the system into services and starting to integrate async

By the end of the exercise we should have completely decomposed into services

  • Each individual function will be running on a separate services
    • containerized
    • modularized
    • scalable

Workshop Resources

System Requirements

Optional

Workshop code

Monolithic Approach

We will keep it simple and use a pre-canned application that contains the bare minimum to get started:

Monolithic Architecture Diagram

This architecture offers lots of positive aspects:

  • Central point of concern
  • Simple code base and module organization
  • Straight forward development approach

but also comes with some limitations:

  • Not that composable
  • One single point of failure
  • All scales in the same way

With this approach you only have 3 different general points for scaling: storage layer | Web App Layer | Client Layer But if what you need is only to scale the list or search components then you are coupled across the application and will need to scale the 3 if only one small component actually requires to grow

Rest API Approach

In an effort of making our applications multi device and service oriented Rest API's architecture come to the rescue: REST Architecture Diagram

With this approach we get better equipped to manage our application with different leverage points that we can scale independently.

  • different services compose the full spec of features
  • a given service, once under stress, can be independently scaled from others (up and down!)

//end