Slide 1

Slide 1 text

Developing, testing and deploying microservices Tools, Platforms and Services Presentation By: Tobby Kuyinu

Slide 2

Slide 2 text

Developing microservices ➔ Components ◆ Programming Language ◆ Data storage ◆ Libraries, packages and frameworks ◆ Interfaces (API) ➔ Standards & Best practices ◆ Project structure ◆ Coding style ◆ Best practices ◆ Boundaries and limits

Slide 3

Slide 3 text

components

Slide 4

Slide 4 text

Components programming language

Slide 5

Slide 5 text

Components programming language

Slide 6

Slide 6 text

Components programming language

Slide 7

Slide 7 text

Components programming language

Slide 8

Slide 8 text

Components programming language

Slide 9

Slide 9 text

Components programming language

Slide 10

Slide 10 text

Developing microservices ➔ Components ◆ Programming Language ◆ Data storage ◆ Libraries, packages and frameworks ◆ Interfaces (API) ➔ Standards & Best practices ◆ Project structure ◆ Coding style ◆ Best practices ◆ Boundaries and limits

Slide 11

Slide 11 text

Components Data storage

Slide 12

Slide 12 text

Components Data storage

Slide 13

Slide 13 text

Components Data storage

Slide 14

Slide 14 text

Components Data storage

Slide 15

Slide 15 text

Components Data storage

Slide 16

Slide 16 text

Developing microservices ➔ Components ◆ Programming Language ◆ Data storage ◆ Libraries, packages and frameworks ◆ Interfaces (API) ➔ Standards & Best practices ◆ Project structure ◆ Coding style ◆ Best practices ◆ Boundaries and limits

Slide 17

Slide 17 text

Components Libraries, packages and frameworks Libraries and packages - Helps separate concerns (e.g. ORMs) - Helps devs focus on core functionality - You’ll write some yourself if need be Frameworks - Essentially needed for their ‘out of the box API’ features - For languages that usually have heavy frameworks, it’s best to find a micro version

Slide 18

Slide 18 text

Developing microservices ➔ Components ◆ Programming Language ◆ Data storage ◆ Libraries, packages and frameworks ◆ Interfaces (API) ➔ Standards & Best practices ◆ Project structure ◆ Coding style ◆ Best practices ◆ Boundaries and limits

Slide 19

Slide 19 text

Components Interfaces (api)

Slide 20

Slide 20 text

But really . . . the interface is just an api as you know it. You know, restful ;)

Slide 21

Slide 21 text

Developing microservices ➔ Components ◆ Programming Language ◆ Data storage ◆ Libraries, packages and frameworks ◆ Interfaces (API) ➔ Standards & Best practices ◆ Project structure ◆ Coding style ◆ Best practices ◆ Boundaries and limits

Slide 22

Slide 22 text

Standards & best practices

Slide 23

Slide 23 text

Standards & best practices Project structure - Nodejs use-case but applies to any stack

Slide 24

Slide 24 text

Standards & best practices Project structure ➔ Readme.md (absolutely compulsory) ➔ App ◆ Config ● Config.js, di.js, db.js ◆ Controllers ◆ Lib ● Oauth_helper.js, errors.js ◆ Models ◆ Repositories ◆ Routes ◆ Services ◆ Validations

Slide 25

Slide 25 text

Standards & best practices Project structure ➔ Readme.md (absolutely compulsory) ➔ App ◆ Config ● Config.js, di.js, db.js ◆ Controllers ◆ Lib ● Oauth_helper.js, errors.js ◆ Models ◆ Repositories ◆ Routes ◆ Services ◆ Validations ➔ *Bin (custom scripts? Docker?)

Slide 26

Slide 26 text

Standards & best practices Project structure ➔ Readme.md (absolutely compulsory) ➔ App ◆ Config ● Config.js, di.js, db.js ◆ Controllers ◆ Lib ● Oauth_helper.js, errors.js ◆ Models ◆ Repositories ◆ Routes ◆ Services ◆ Validations ➔ *Bin (custom scripts? Docker?) ➔ *Migrations/Schema (or equivalent)

Slide 27

Slide 27 text

Standards & best practices Project structure ➔ Readme.md (absolutely compulsory) ➔ App ◆ Config ● Config.js, di.js, db.js ◆ Controllers ◆ Lib ● Oauth_helper.js, errors.js ◆ Models ◆ Repositories ◆ Routes ◆ Services ◆ Validations ➔ *Bin (custom scripts? Docker?) ➔ *Migrations/Schema (or equivalent) ➔ Test ◆ Helpers ◆ Regression ◆ unit

Slide 28

Slide 28 text

Developing microservices ➔ Components ◆ Programming Language ◆ Data storage ◆ Libraries, packages and frameworks ◆ Interfaces (API) ➔ Standards & Best practices ◆ Project structure ◆ Coding style ◆ Best practices ◆ Boundaries and limits

Slide 29

Slide 29 text

Standards & best practices Coding style - Nodejs use-case but applies to any stack

Slide 30

Slide 30 text

Standards & best practices Coding style Proper documentation and (preferably) an autodoc builder or generator /** * @method: properDocs * @param {intelligence} commonSense It only makes sense to document properly * @param {awesomeness} goodDev Good devs document their codes * @return {awesomeness} goodCode - It’s impossible to go wrong with a * properly documented code base. Moreso, * new devs can catch up easily. **/ properDocs: (commonSense, goodDev) => { }

Slide 31

Slide 31 text

Standards & best practices Coding style Properly structured source code files according to responsibility Services - should contain business logic and straightforward functional tasks related to an entity. - should abstract data manipulation and retrieval but should not directly implement the data store. If a library isn’t being used, then create repositories for that

Slide 32

Slide 32 text

Standards & best practices Coding style Properly structured source code files according to responsibility Models - should do exactly what the name suggests: model entities and represent them as entities with interfaces that can be used by the services - is sometimes simplified by an ORM module/library (e.g. bookshelf.js) or your repositories if no library is used

Slide 33

Slide 33 text

Standards & best practices Coding style Properly structured source code files according to responsibility Controllers - should always be the entry point - should simply co-ordinate a sequence of activities to be done by the services and decide what point to return an API response

Slide 34

Slide 34 text

Standards & best practices Coding style Properly structured source code files according to responsibility - Service: function getUserData(userId) { userModel.getUser(userId) .then(userDetails => { If (userDetails) { userModel.getUserAddresses(userId) .then(addresses => { resolve({user: userDetails, addresses: addresses}); }); } else { reject(new Error(‘User not found’)); } }); }

Slide 35

Slide 35 text

Standards & best practices Coding style Properly structured source code files according to responsibility - Model: function getUser(userId) { Return this.repository.fetchUserById(userId) .then(userData => { resolve((userData.length() > 0)? userData[0] : userData); }); } Function getUserAddresses(userId) { Return this.repository.fetchUserAddressByUserId(userId) .then(addressData => { resolve(addressData); }); }

Slide 36

Slide 36 text

Standards & best practices Coding style Properly structured source code files according to responsibility - Repository: function fetchUserById(userId) { Return mysql.select(‘*’) .from(‘users’) .where({user_id: userId}); } Function fetchUserAddressByUserId(userId) { Return mysql.select(‘*’) .from(‘addresses’) .where({user_id: userId}); } See how easy it’ll be to switch the data store technology if the need arises?

Slide 37

Slide 37 text

Standards & best practices Coding style Always favor configurables, using a helper file for constants where necessary - You want to do this: - Function getSomeData(page, limit) { let constants = require(‘app/lib/constants’); limit = min(limit, constants.pagination.MAX_ALLOWED_LIMIT); let opts = { page: page, offset: (page - 1) * limit, limit: limit } . . . } - Rather than this: limit = min(limit, 50);

Slide 38

Slide 38 text

Developing microservices ➔ Components ◆ Programming Language ◆ Data storage ◆ Libraries, packages and frameworks ◆ Interfaces (API) ➔ Standards & Best practices ◆ Project structure ◆ Coding style ◆ Best practices ◆ Boundaries and limits

Slide 39

Slide 39 text

Standards & best practices Best practices

Slide 40

Slide 40 text

Standards & best practices Best practices Have a base service to extend

Slide 41

Slide 41 text

Standards & best practices Best practices Have a base service to extend Use linting tools to ensure code quality

Slide 42

Slide 42 text

Standards & best practices Best practices Have a base service to extend Use linting tools to ensure code quality Write unit and regression tests

Slide 43

Slide 43 text

Standards & best practices Best practices Have a base service to extend Use linting tools to ensure code quality Write unit and regression tests Protect your API (validate as much as you can)

Slide 44

Slide 44 text

Standards & best practices Best practices Have a base service to extend Use linting tools to ensure code quality Write unit and regression tests Protect your API (validate as much as you can) Dockerize your service

Slide 45

Slide 45 text

Developing microservices ➔ Components ◆ Programming Language ◆ Data storage ◆ Libraries, packages and frameworks ◆ Interfaces (API) ➔ Standards & Best practices ◆ Project structure ◆ Coding style ◆ Best practices ◆ Boundaries and limits

Slide 46

Slide 46 text

Standards & best practices Boundaries and limits

Slide 47

Slide 47 text

Standards & best practices Boundaries and limits A microservice must remain micro

Slide 48

Slide 48 text

Standards & best practices Boundaries and limits A microservice must remain micro Must be 100% responsible for it’s data

Slide 49

Slide 49 text

Standards & best practices Boundaries and limits A microservice must remain micro Must be 100% responsible for it’s data Must not be dependent on another service

Slide 50

Slide 50 text

Standards & best practices Boundaries and limits A microservice must remain micro Must be 100% responsible for it’s data Must not be dependent on another service Should preferably not be responsible for caching

Slide 51

Slide 51 text

Standards & best practices Boundaries and limits A microservice must remain micro Must be 100% responsible for it’s data Must not be dependent on another service Should preferably not be responsible for caching Must not have any unrelated models hanging around

Slide 52

Slide 52 text

Developing microservices ➔ Components ◆ Programming Language ◆ Data storage ◆ Libraries, packages and frameworks ◆ Interfaces (API) ➔ Standards & Best practices ◆ Project structure ◆ Coding style ◆ Best practices ◆ Boundaries and limits

Slide 53

Slide 53 text

Testing and deploying microservices ➔ Testing ◆ Components ◆ Coverage ◆ Environments ➔ Deploying ◆ Patterns

Slide 54

Slide 54 text

testing

Slide 55

Slide 55 text

testing components

Slide 56

Slide 56 text

testing components Helpers

Slide 57

Slide 57 text

testing components Helpers Mocks

Slide 58

Slide 58 text

testing components Helpers Mocks Fakers

Slide 59

Slide 59 text

testing components Helpers Mocks Fakers Seed

Slide 60

Slide 60 text

Testing and deploying microservices ➔ Testing ◆ Components ◆ Coverage ◆ Environments ➔ Deploying ◆ Patterns

Slide 61

Slide 61 text

testing coverage Against whatever you were told, test coverage isn’t a measure of quality. It’s simply to help find untested code

Slide 62

Slide 62 text

Testing and deploying microservices ➔ Testing ◆ Components ◆ Coverage ◆ Environments ➔ Deploying ◆ Patterns

Slide 63

Slide 63 text

testing Environments

Slide 64

Slide 64 text

testing Environments Option 1:

Slide 65

Slide 65 text

testing Environments Option 1: When running locally, stub out supporting technologies fakeSaveToDB(id, data) { Return ; } mockery.registerMock(database.saveToDB, fakeSaveToDB);

Slide 66

Slide 66 text

testing Environments Or...

Slide 67

Slide 67 text

testing Environments Wait for it ...

Slide 68

Slide 68 text

testing Environments

Slide 69

Slide 69 text

Testing and deploying microservices ➔ Testing ◆ Components ◆ Coverage ◆ Environments ➔ Deploying ◆ Patterns

Slide 70

Slide 70 text

deploying

Slide 71

Slide 71 text

deploying patterns

Slide 72

Slide 72 text

deploying patterns Multiple services per instance Pros: - Efficient resource utilisation - Relatively fast deployment and startup Cons: - No isolation of services - One service screws all - Complex deployment

Slide 73

Slide 73 text

deploying patterns Service instance per host (VM) Pros: - Services run in isolation - Fixed amount of CPU and memory - Easy deployments Cons: - Inefficient resource utilisation - Expensive - Slow deployment for new versions - Heavy lifting overhead

Slide 74

Slide 74 text

deploying patterns Service instance per host (Container) Pros: - Services run in isolation - Fixed amount of CPU and memory - Encapsulates tech used to implement - Easy deployments Cons: - Not as mature as VMs - Not as secure as VMs - Heavy lifting overhead - Provisioning costs

Slide 75

Slide 75 text

deploying patterns Just swinging by...

Slide 76

Slide 76 text

deploying patterns - worthy mention Serverless deployment - E.g. AWS Lambda - Package your service as a zip file and upload - Supply a metadata (and functions that handle ‘events’) - Automatically runs enough instances to handle requests - Services must be stateless - Limited to only a few languages

Slide 77

Slide 77 text

Testing and deploying microservices ➔ Testing ◆ Components ◆ Coverage ◆ Environments ➔ Deploying ◆ Patterns

Slide 78

Slide 78 text

No content