Slide 1

Slide 1 text

Python in the MicroServices world @harikrishnan83

Slide 2

Slide 2 text

About me Full Stack Dev Tech Consulting for Startups Java, .Net, JavaScript, Python, Ruby Concurrency, High Performance Applications, REST @harikrishnan83

Slide 3

Slide 3 text

Why this talk?

Slide 4

Slide 4 text

“Microservices are a more concrete and modern interpretation of service-oriented architectures (SOA)” - Wikipedia MicroServices by Definition UI Core BI DB Admin and Dashboard API DB Booking Service API DB Payment Service API DB Notification Service API DB API DB API DB Message Bus UI

Slide 5

Slide 5 text

Why all the Buzz?

Slide 6

Slide 6 text

Small, Composable, Maintainable, Independently deployable etc.

Slide 7

Slide 7 text

Have we not seen this before?

Slide 8

Slide 8 text

JEE EJB (Message Driven Beans) MSG Queue MSG Java EE Server MDB Instances EJB Container Application Client

Slide 9

Slide 9 text

OSGi

Slide 10

Slide 10 text

Why is MicroServices architecture any different?

Slide 11

Slide 11 text

Do not put all your eggs in one basket

Slide 12

Slide 12 text

How does Python Stack up?

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

All Python MicroServices App?

Slide 16

Slide 16 text

Before we start

Slide 17

Slide 17 text

Your First MicroService

Slide 18

Slide 18 text

Monolithic Application Search by Country and State

Slide 19

Slide 19 text

Monolithic Application Search by Country and State API DB View Layer

Slide 20

Slide 20 text

Monolithic Application Search by Country and State API DB View Layer Key Value Store

Slide 21

Slide 21 text

Okay, there we have a MicroService. Now let us build some serious Features on the Monolithic App.

Slide 22

Slide 22 text

Monolithic Application Search by Country and State API DB View Layer Key Value Store New Feature API

Slide 23

Slide 23 text

A typical MicroService 1. API 2. Logic 3. Data 4. Dependencies 5. Automation 6. Admin 7. Monitoring 8. ...

Slide 24

Slide 24 text

Discipline 1. Iterative Development 2. Continuous Integration and Delivery 3. Release Pipelining and Build Promotion

Slide 25

Slide 25 text

Motivations to slice

Slide 26

Slide 26 text

Technical 1. Additional Infrastructure 2. Increasing Resilience 3. External Facing vs Internal Facing APIs

Slide 27

Slide 27 text

Business 1. A product by itself 2. Need to monitor the ROI of the feature in isolation 3. A/B testing 4. Build vs Buy

Slide 28

Slide 28 text

Organisational 1. Conway’s law organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations — M. Conway 2. Team size

Slide 29

Slide 29 text

Distributed Problems

Slide 30

Slide 30 text

Identity

Slide 31

Slide 31 text

Booking Service Payment Service Notification Service View User Service Auth And Auth Book Ticket User Details Send SMS Process Payment Anonymous Access Anonymous Access Back Office Dashboard

Slide 32

Slide 32 text

Service Traceability

Slide 33

Slide 33 text

Booking Service Payment Service Notification Service View User Service Auth And Auth Book Ticket Booking Ref No Send SMS Process Payment Booking Ref No Booking Ref No

Slide 34

Slide 34 text

Reconciliation

Slide 35

Slide 35 text

Distributed Transactions 1. Rollbacks are expensive and quite hard 2. Eventual Consistency

Slide 36

Slide 36 text

User Signup Wizard User Service Queue Failed Messages

Slide 37

Slide 37 text

Project Management

Slide 38

Slide 38 text

What happens to Sprints? 1 To Do Doing Done To Do Doing Done 1 To Do Doing Done 1 Payment Service Booking Service Notification Service Feature: Book Ticket

Slide 39

Slide 39 text

API

Slide 40

Slide 40 text

Sealing the Contract We had to get the stories to go in Parallel So we agreed on the API boundaries and started coding to Apiary However it did not quite work out Many details became clear only after we started building the feature

Slide 41

Slide 41 text

What do we do? 1. Follow the data 2. Understand Non Functional Aspects 3. Every time we add an API call, think if it belongs there

Slide 42

Slide 42 text

API 1. Synchronous - Simple Request Response 2. Asynchronous - Fire and Forget - Queues 3. Callbacks - Webhooks

Slide 43

Slide 43 text

Branch and Merge Strategy 1. Single Repository was not working for us a. Initially it was great because we just did feature branches b. Most of us make several small commits 2. Internal Open Source a. Service Owner b. Feature Owner c. Business Owner

Slide 44

Slide 44 text

Thank you @harikrishnan83