Micro services old note

 

What is Micro Service?

Architecture style to build Autonomous, independently deployable services collaborate together to form an application.

You must have worked on and may be created applications without calling micro services.

How small it should be – depends

Why do we need micro service ?

Monolith – software typically all application is in a Single Codebase.

              Single Codebase – exist in a source repository where all developers collaborate each other.

Typically build artefact runs in a

              Single Process – build the artefact

              Single host -  runs on a single host.

              Single Database – persist to

              Consistent Technology – dev env, single programming language, sdk used

Benefits of Monolith

              Simplicity

              One codebase – easy to find

              Deployment – one application to replace

Nothing wrong. Then Why we need micro services? or You don’t Micro services, Yet

 

Problem of scale

              Many developers , many users, many data, code base grow- difficulty in maintain ( growing complexity and accumulation of technical debt) , entangled modules ( wired here and there, although u put an effort and build a modularised app)

 

 

Deployment – single line of change need to deploy the whole app

              Risky

              Usually requires a significant downtime

                             But some use modern level cloud services

Difficult to Scale – unless you make it stateless

              Horizontal scaling often not possible

              More possibility towards vertical scaling

                             Too expensive , add more hardware(memory, hard disk , processor etc)

              Whole application must be scaled

              Finally - Wedded to Legacy technology

                             Have to upgrade entire application to move to a newer frame work

                             Reduces agility – ability introduce new practices, take advantage of innovation

 

Distributed monoliths

You can argue my app is not a monolith. It has few services, just like CMP

SOA – service oriented architecture

System built as services, but

              Uses a single database

              Tightly coupled

              Everything must be deployed together (or few together)

              New features require, changes every where

 

This where you need to understand what micro services else you will end up building something worse than monolith or distributed monolith (SOA)

 

How are micro services better than Monoliths?

Small services

Can be owned by a team

Easier to understand

Size – small enough to be thrown away and rewrite

Technology Choice

              Adopt new technologies -  without upgrading whole application as Monolith

              Use the right tool – for specific task

                             One might use relational database where other document database

                             Object oriented programming language , other functional programming language

              Standardize where it makes sense – but no hard rules, common agreement like in REST

Individual deployment – cause of loose coupling

              Lower risk – no need to upgrade, deploy entire system in one go

              Minimize down time – zero downtime

              Frequent updates

Scaling

              Scale services individually

              Cost effective – compared to monolith

Agility

              Adapt rapidly – for changing business requirements

              Easier re use

 

 

Downsides – New Challenges – Not a free lunch -  whether micro services a good solution for you

Challenges

Developer Productivity

How can we make it easy for developers to be productive working on the system?

Do they have to download code for every single micro service?, run individually, configured them to talk to each other, That can be error prone and time consuming , way of easily working on a single micro service and as well as testing in the context of whole application

Complex Interactions

Take car to avoid inefficient, chatty communications between micro services

IF we brake application for dozens of micro services then interactions may be complicated.

Deployment

You will need to automate the process – you will have lots of micro services

Monitoring

We need to have a centralized place to check the logs and monitor  for problems – cause you cannot go to each service and find logs

 

These are just a few

So lots of challenges – good news- you have lots of patterns and technologies to help you to overcome these challenges

 

Micro services – Do not dictate on

              What technology

              What type of data base you use

              What type of communication – asynchronously or synchronously

              What authentication mechanism

Completely free to use your favourite| best programming language, tools

 

Micro services Architecture(wrap up)

-          Comparisons with monoliths

-          Benefits

-          Challenges

 

--

Build a new app using Micro services architecture or to migrate monolith to microservices

Need to make Important Architecture decisions upfront

You do not have start with a micro service, but possible to evolve existing app step by step

Evolving towards micro services

-          Micro services are autonomous – which means own its own data

-          Own their data

-          Independently deployable – clearly defined and backward compatible public interfaces

-          Identifying micro service boundaries – very tricky, breaking monolith, boundary to context

-           

What if I have a monolith already?

-          Augment a monolith

o   Add new micro services

-          Decompose a monolith

o   Extract micro services

-          No need to start with a micro service

o   Hard to get the service boundaries at start

o   Benefits are not seen in small projects

o   Let the app grow a little and then segregate for micro services

Micro service Own data

Avoid sharing a data store – data store per service

Limitations

-          Data base joins – in two different databases

-          Transactions – cannot update two tables in two dbs,

o   Either use distributed transactions – very complicated or design our application to work in a ENETUALLY CONSISTANT manner

-          Eventual Consistency

o   May have to wait a while for overall state of the data to be fully consistent. What this means in practise, when a single business process requires to update more than one data source, there will be a small window of time when changes made in one data store, but not the other. So you need to design your applications in a such a way that it handle this Temporary Inconsistency.

o    

 

 

 

 

 

Summary

Evolving towards Micro service

Micro service own their data

May consist of multiple processes

Should be independently deployable

Avoid breaking changes – changing APIs

Identify “Bounded Context”  for micro service boundaries

Getting boundaries right – critical factor

 

 

Micro  Service Hosting Options

-          Virtual Machines

              VM per service – can be little costly , cause there are so many

              Few services in one VM – but can be messy as each MicroService has  its own requirements, frameworks, database, performance etc.( you can imagine with running few monoliths one machine)

-          Operational challenges

-          Service Discovery

Platform as a Service

Automatic Scale out

DNS address

Load balancing

Security

Monitoring

Serverless – nano services

Containers package up applications

Portable – run any where

Easily run locally

Docker compose

 

 

 

Use cloud – Paas – then you need invest more, cause as micro services grow – productivity of the developers drop

 Creating New MicroService

-          Source control  repository per micro service

o   Avoid tight coupling between services

-          Continuous Integration build

o   Run automated tests

Types of Tests

-          Unit Tests -fast to run, high code coverage

-          Service level test – Integration test, Test single service in isolation, Mock collaborators, Invest for Framework creating service level test

-          End to End Test – Production like env, Can be fragile,

Micro Services templates

Standardize

Logging – all logs in a same format

Health Checks –

Configuration –

Authentication

Build  scripts – use containers, docker

 

Increase Productivity

Developers focus on implementation of Business logic rather than plumbing infrastructure

 

Connected shared services – cloud services

 

 

Communicating between MicroServices

Asynchronous and Synchronous communication patterns

 

 

 

 

 

Calling MicroServices

Are there any rules, can any service can call each other

Web, Mobile etc allowed call MS directly.

There are no hard rules, but there are difficulties when allowing free flow access and call

-          End up making Tangled dependencies

-          Making cascading failures – one MS fail, causes to fail  others as well

-          Poor performance – call to one MS ends up with calling dozens of MS call call hops

-          Mispalce (service) boundaries

 

Better

-          Minimize call between MS – you can publish through event BUS, subscribe to services via BUS

-          Promote Asynchronous call between MS

-          Front end app, Single page app, Mobile – without coming directly use a pattern call API Gateway – will have several benifits

o   Authentication – API Gateway level, security can handle from single point

o   Front end apps needs to know how to call different MS

o   Decouple Front end apps with MS , backend APIs

o    

 

 

Micro Services do not call each other, Instead create events in Event Bus

 

Event Bus implemented in either RabbitMQ when we run locally or Azure Service Bus when running cloud

Messages are subscribed by MS and handled Asynchronously.

So use different communication patterns, suitably as shown.

 

API gateway for Each level

 

Synchronise Communication

Eg: Retrieve information from DB, select query

This is an Asynchronous call – customers do not want to wait.

 

 

HTTP

-          Industry Standard

-          Can take advantage

o   Standardize approach

o   Caching – standard error codes

o   Payloads -JSON {native format of javascript, support by many, easy}, XML

o    

 

-          Implement APIs as a set of resources (RESTful APIS)

o   Eg: Catalog Item, Order {Information as resources}

-          Use standard HTTP methods

o   GET to retrieve, PUT

-          Good use of HTTP status Codes

-          Media Type headers (Content Type)

 

 

Rest is a big Topic. This is just a little

 

Asynchronous Communication

When we cannot  expect user to wait until everything is finished.

Communication over HTTP

Send status code “Accepted” rather than “OK” – then user can check the status later

Callback – MS itself reports back when task is complete. Client can register for callback URL , on which they like to receive notification

 

 

 

Via Messaging

With registering to even BUS, others subscribe (rather than calling directly)

1.       Simply creates a message and sends to “Message Broker” – which acts as Intermediator.

2.       Other MSs subscribe to those messages

Act as an Intermediator , decouples micro services completely.

Advantage for scaling – eg:If unprocessed messages growing, you can simply scale out that MS with multiple instances.

Many “ServerLess” platforms does this automatically.

With containers also possible with configuring cluster of services| containers

 

Message Types

-          Commands

-          Events

Command is an request to performed on particular action eg: send a email

Events – something has happened, In Past Tense, several actions might need to occur as result of that event eg: OrderPlaced ( charging credit card, sending confirmation mail, checking on stock levels..)

 

RabbitMQ, Azure Service BUS

https://www.enterpriseintegrationpatterns.com/

Resilient Communication Patterns

We cannot expect service to be run 100% without error and failure

Implement retry with backoff

              First attempt fail, wait little while – If second fail wait for more … back off

              IF too many attempts made – their can be denial of service attacks

Circuit breaker

              Sit between client and server

              Passes call through (circuit breaker is “closed”)

              If enough errors are detected, blocks further calls (circuit breaker is open)

              After time out – allows some calls to through, to see the problem has been resolved.

                            If OK – circuit close else open

              Simple , but powerful – many have implemented – just use

 

 

Caching

Fallback to cache data, if service is unavailable

 

Messaging resilience ( Message Broker)

Inherent support for resilience

 

Idempotent

              If calling twice with same message will have same effect as call in once.

Eg: In e commerce sample app – we should have good check to make sure for a order process multiple times – make sure ship once, charge once for credit card

3.       You receive a message and partly processed and something happens. As a result you receive it again.

 

Service Discovery

To  MS to communicate with each other – each should have an address

How to find and keep track

Service registry

When you need to communicate to MS, ask service registry – where is that MS

Service Registry – typically distributed among all the machines in the cluster. Which makes easy to contact service registry.

 

 

Service Discovery – Alternatives

DNS

If you using cloud – you automatically get DNS and plus load balancing

If use Container such as Kubernetes

              Built in DNS – no need to know the IP address of each container , just need to know the name of the service you need to call MS. It willtake care of routing traffic to container you are running the service. Load balancing, if necessary.

 

So to handle challenges are much more easier – if you host MS in modern platform

 

 

 

 

 

Securing Micro Services

 

 

 

You may use HTTPS – (TLS – Transport Layer with certificates issues by trusted party), but it does not mean secure. You need to Authenticate the user.

Authentication Option

-          Basic Authentication – User name and pass

Problem is every MS need to securely store passwords – need best practises, better hashing etc

-          API key – (key per client , key management)

-          Client certificate (public key cryptography- prove caller identity, but quite difficult to keep install and manage)

 

Is there a better way, one of the most promising approaches – Identity server

Authorization server – takes care of the complexity of authentication and authorization

1.       Client Authenticate with identity server by sending credentials

2.       Identity server returns an access token (which got limited life time)

3.       Access token in authorization header – to MS (these are signed by public key cruptography helping the to verify )

4.       Verify Access token with Identity server

Here One service has the job of

              Authentication users and Managing their credentials securely.

              Cause IS implemented using Industry standard (OAuth 2.0 & OpenID connect) you don’t have to write. You can make use of a third party solution. Writing IS is a lot of work.