Waking up in weeds of microservices. How to

diagnose your first bug?

LICENSE

• Creative commons attribution-

noncommercial- 3.1 unported

• https://creativecommons.Org/licenses/by-

nc/4.0/

WHO AM I • Senior Software Engineer at Adobe Inc.

• Interested in open-source, cloud and technology

evangelism

• Experienced in various Full stack technologies (UI

to backend with DevOps added latest in armory)

• OS Contributor to various open source and Apache

products (eg: Hystrix, Spinakker, Spring etc.) and

reviewer in various JSRs

• President, founder and member of various

organizations/groups

• Sunnyvale Java User Group

• San Francisco Java User Group

• Google Developer Group (SF Edition)

• Java Community Program

OUR OBJECTIVE

• To get you excited about some aspects which are not covered while switching to microservices

• To make microservice architecture more manageable

Is:

• branding/forcing to us any particular tool Isn’t:

AGENDA

• Let’s go to microservice

• They say, “GREAT POWER COMES WITH GREATER

RESPONSIBILITY”, is it?

• Are you ready to take the bluepill (hype driven development]

• Traditional world: I need more control beforehand

• Overcoming the challenges

• Time to see results

• Next steps

LET’S GO TO MICROSERVICES

• I heard about microservices

• Good architecture pattern

• Polyglot persistence

• Easy to maintain (supposedly)

• Scalable and resilient

• Atomic components, that are decoupled

YAY J

OK, I guess then we should implement this.

THEY SAY “GREAT POWER COMES WITH GREATER RESPONSIBILITY”, IS IT?

• I am done with breaking my architecture from monolith to

microservices. What next?

• I do not know where it will sit.

• It still takes so much time to deploy.

• Failure of one still affects another

ARE YOU READY TO TAKE THE BLUEPILL (HYPE DRIVEN DEVELOPMENT]

• Containers

• Container Orchestration

• Circuit breakers/resiliency

• Service discovery

• Automated deployment and Testing

• Spinnaker and Self Service capabilities

• More Observability and monitoring****

TRADITIONAL WORLD: I NEED MORE CONTROL BEFOREHAND

• Traditional monitoring model are pull based where before pulling

the data you need to tell controller where they are sitting.

• This fails once you go to microservice container architecture as

ports and host are assigned dynamically.

EC

S

OVER COMING THE CHALLENGES : AN ATOMIC APPROACH

… API n

EC2

API 1

… API 2 API n

EC2

ECS

Pulls metrics

data from SQS

Pushes metrics

data to SQS

API 1 API 2

ECS

Note: Only one way is subscription is shown here.

However we can subscribe/use metrices into different

mechanisms, viz Kafla, RabbitMq etc.

SAMPLE RESULTS

OK, WHAT DID WE LEARN?

• Microservice architecture brings some known tradeoff with

implementation

• Can be reduced using best practices like automated deployment,

circuit breakers, automated testing and better devops

• Monitoring is a first class citizen in Microservice architecture

• Make sure you monitor all factors consisting your architecture

starting from infrastructure to every living line of code

• More insight means more control

• Catch anomalies as soon as possible and take action

IMPORTANT LINKS

• Dropwizard : https://www.dropwizard.io/1.3.5/docs/

• Micrometer: https://micrometer.io/

• Docker metrics:

https://docs.docker.com/config/containers/runmetrics/

• Grafana: https://grafana.com/

• influxdb: https://www.influxdata.com/

• Kafka: https://kafka.apache.org/

• Rabbitmq: https://www.rabbitmq.com/

THANK YOU !

• https://twitter.com/mukteshkrmishra

• https://www.linkedin.com/in/mukteshkrmishra/

Please do not forget to rate this talk. J