Microservices

© Equal Experts UK Ltd 2015
Microservices
Scaling Human Work
by Paulo Gaspar
@paulogaspar7

Does size matter?
(Why didn’t Jeff Bezos want to give more than two pizzas to each team?)

Large versus Small (Systems)
• Ever worked on both?
• Compare…
• Knowledge sharing / communication?
• Pace of progress?
• New technology adoption?
• Ease of technical debt elimination?
• Accountability (not throwing issues over the wall)?

But what are Microservices?

Fowler Description
§ The microservice architectural style is an approach to developing a single
application as a suite of small services, each running in its own process and
communicating with lightweight mechanisms, often an HTTP resource API.
These services are built around business capabilities and independently
deployable by fully automated deployment machinery. There is a bare
minimum of centralized management of these services, which may be written
in different programming languages and use different data storage
technologies.
http://martinfowler.com/articles/microservices.html

Fowler Description…
…says nothing about its WHYs

Why Microservices?
§Performance?
§Availability?
§Scalability?
§Because you like Docker and doing DevOps?

Why Microservices?
§Or is there a “non production time” reason?

My experience…

A NAIVE FIRST TIME…

The very First Time…
• Just because of Spring Boot
(and Spring Loaded!)
• We loved how fast and easy was running a service for development tests
• Naturally, services were split and kept being split by functionality
• We had different load requirements per service…
• We started everything by hand, with scripts
• We looked at Docker and several other tools for automation
• Size was kept small “just” because it helped dividingwork and keepingchurn out high

The First Time
Were this real Microservices?
…or just a SOA flavour?

2ND TIME
EXPERIENCED PARTNERS

The Dream Team - First impressions
• Very large overall project (a few hundred developers)
• Very senior team
• Real Agile, TDD, Reactive Programming, Scala, Pairing …
• So many services, but my laptop can run all I need for integration tests!
• Infrastructure of sharedtechnologies (messaging, database, monitoring…)
• Infrastructure restrictions on used technologies
• No management interferenceon technical decisions
• Management (P.O. and others) supports technical issue prioritization
• Management (P.O. and others) displays full trust on development team indications

The Dream Team – the line up
• Product Owner (P.O.)
• Scrum Master
• 8 Developers
• 2 QA (Quality andAssurance)
• A couple of B.A.s (BusinessAnalysts)
• Shared UX team (Design, User Experience, etc.)
• A couple of business monitoring elements

Second impressions– Technicalities
• Impressive churn out…
• Functional stories oftendone faster than I initially estimated
• Was this repeated across these many teams? (Scalability)
• Shocked: no Business Logic on Libraries!!!
• Shocked: not only do we pair, but pairs rotate twice a week
• Internal Open Source for technical code
• Each Microserviceis, at most, a few thousand lines big
• There are mechanisms to deal with distributed computingissues
(error propagation, latencies, cumulative latencies…)
• Improving monitoringand available metrics receives a lot of attention

Second impressions– Tribal team behaviour
• Programming intensity is very high - almost all the time (out of meetings) is spent coding
(Sounds normal to complete a medium size ticket in 2 to 4 days)
• Some tribal behavioursof the developer team:
• A whole team impromptu meeting is triggered if we find a production problem
• Impromptu meetings also when a structural decision must be taken when coding
(Yes, the code is own by the “tribe” as a whole)
• Working out of office hours dedicated to monitoring
• Developers report a large portion of the production issues
(often before they have impact)
• A lot of importance given by management to developers feedback
• Work pace is not affected after one of the most experiencedteam members leaves

Interactions separated by domain…
• Developers directly take care of solving technical issues
• Infrastructure teams send people to help and doctrine Microservice developers on the hows and whys of
their systems / services
• …and support Microservice teams into monitoring their own services
• Technical issues / doubts sorted out by direct developer contact with other teams
(Infrastructure, other development teams,architects,…)
• Technical code is shared (with all teams) as internal Open Source
• Business / management people directly take care of solving business related issues
• All Stories are defined by B.A.s and reviewed by Developer before considering them ready
• All remaining doubts about business related issues sorted out by B.A.s or P.O.s
• Developers do not directly go get information from domain experts just to sort out a story
• Only B.A.s or P.O.s bring information across from domain experts to developers

Customerfeedback
It was repeatedly mentioned by customer representatives
how the team had exceeded their productivity
expectations
(and how quality was kept high)

The Big Picture
• Developersown the code as a group
• Developerstake direct care of technicalmatters
• Managers/ B.A.s take care of business related matters
• Managerstrust developers(and vice versa)
• Scalability: other teams seem to be doing just the same
• Customer is happy with productivity + quality
(this team’sand overall)

The Big Picture
Ownership
Accountability
Trust

The Big Picture
I believe we were doing
REAL Microservices

WHAT DO OTHERS SAY?

Development on LARGE applications
• Steeper learning curve
• Higher CODE DRAG
• Throwing responsibilities over the wall
• Development tools and containers get overloaded
=> slower development
• Larger teams have higher communication costs / problems
• Must rebuild and redeploy a large volume of code for any small change
• Any change (functional or technologic) is harder and riskier
• Riskier and expensive changes happen less frequently
=> slower evolution

Development on Microservices
• Smaller teams
• Less communication paths, lowercommunication costs
• Services get developedand deployed independently
• Smaller and simpler code bases are
• Easier to learn and faster to develop on
• Less prone to dependency hell
• Faster + simpler to build and deploy
• Easier to compose and to replace
• Producing less code drag
• Change is simpler and risks more isolated
• Evolution is easier

Microservices – the WHYs…
Achieving
SCALABLE
high productivity

Is this SOA
• “Traditional SOA” was dominated by vendors and the technologiesthey promoted
(e.g.: some people thought that SOAhad to be done with SOAP)
• Microservices grew from practical needs and concerns, with no vendor/technology ties
• SOA done right?

MY 2 CENTS

But I noticed that developing“with Microservices”…
Does NOT always work that well!

Developing“with Microservices”…
Does not always work that well, because
Microservices are an enabler, NOT a
guarantee

Scaling high productivity=> high productivityon each Dev. Team!

To have good results developing with Microservices…
Several roles must be well played
Several things must be done right
…or you are just doing a SOA flavour!

To have good results developing with Microservices…
Doing Agile well sure helps
(You know you can read about Agile elsewhere!)

The role of Developers…
• Is to code/producea maximum of business functionality
• It works better if:
• Distractions and obstacles to play that role are kept to a minimum
• The business functionality to implement is well defined from the start of each task/ticket
• Stress is kept to the necessary minimum
• Team members rotate across all of the team’s Microservices
• Knowledge and decisions are (BOTH) shared
(Only with shared knowledge is decision sharing productive)
• All other roles and practices we talk about simply serve this purpose

The importance of having team QAs…
• Acceptance tests and the dance of pushing to deployment have high latencies
• The developer can transport the coding momentum to the next ticket
• The QA fills latencies better by juggling between multiple tickets
• The QA validates produced work better because:
• He/she is not biased by the development work, keeping an higher focus on specs
• Has a better overview overwhat is going on across tickets
• Their independence from development qualifies them better to produce good acceptance tests
• …and you can read a lot more about this role elsewhere

The importance of a Scrum Masters or Delivery Manager,
Product Owners, BusinessAnalysts…
• Keep the programming team’s focus
• And feed it with a well coordinated/ordered and uninterrupted
stream of clearly defined tasks/stories acrossteams
• This actually means many order tasks, defining and keepinga vision, like prioritizing work,
coordinating work across teams, handling the customer, keeping unnecessarypolitics away
from development work, etc.

Improving DRY(Don’t Repeat Yourself)
• Common vision + principles increase the opportunities for synergies
• Creating synergies demands coordination + steering
• …reducing redundant efforts and boring wheel reinvention
• …improving sharing and development speed
• Balance steering to give some room for experimentation -> evolution

The importance of good horizontal teams (improvingDRY)

Horizontal Team – Business / Management (improvingDRY)
• A (Functional/Business)Vision
• A Plan
• Well coordinated and well prioritizedflow of stories…
• …consistent across all teams

Horizontal Team – SystemArchitecture (improving DRY)
• Vision
• Overall high level (but well grounded) design
• Consistent design principles / values / philosophy
• Steering
• Gathering collective experience and sharingthe resulting knowledge
• (Interesting discussionabout this role on the Sam Newman’s book)

Horizontal Teams – Infrastructure (improving DRY)
• Means to effectively share knowledge across teams
• Means to support the sharingof “internal open source”
• Shared productionservices (databases, message queues, etc.)
• Other shared development support services
• Other means to share and reduce the cost of technical services

Coding -the importance of service SIZE…
• We are talking about MICROservices
• Not of Large or Extra Large services
• Not even of Medium Services
• Not even Small-ish or Mini Services
• The name is MICROservices!!!

Would you call this a Micro mammal?

The importance of SIZE – remember, smaller code bases are…
• Easier to learn and faster to develop on
• Less prone to dependency hell
• Faster + simpler to build and deploy
• Easier to compose and to replace
• Producing less code drag, therefore being easier to
• Replace
• Refactor
• Evolve, independently, at the most convenient pace

Signs it is NOT a Microservice (just a service)…
• Lines of code count is high - into the 5 (or more) digits
• Covers multiple (worse if disparate) functional topics
• Big volumes of technical code included - e.g.: an audit servlet filter
(But you can have their functionalityincluded in libraries)
• A lot of developers working simultaneously on the same service
Maybe you are doing some other SOA flavour

Signs it is a good Microservice…
• Lines of code count is low (3 or 4 digits)
• Focus on business logic code
• Covers one functional topic
(although you might end up dividing it in sub-topics forever…)
• No business logic in libraries
(since it produces version management and functional consistencyproblems)
• No duplicate business logicwith other services
(DRY, functional consistency)
• Meaningful volumes of reusable technical code are placed in libraries to
• Keep focus on business logic
• Ease future splits
• Share (i.e.: reduce overall) technical cost

When you start
• Start small
• Learn the basics well andASAP
• Just the essential principles you need for your scale
• …inclusive about REST, if you use it
• …and CQRS (Command Query Responsibility Segregation)
• Don’t be in a hurry to divide services
• Take your time to learn each piece you add
• Lear about the “new” types of error you are exposed to, like:
• Fallacies of distributed computing
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

When you start (doing large scale Microservices)
• Embrace Devops
• Brace for networking related problems
• Latency across a call stack
• Manage timeouts
• Cascading failures
• Circuit breakers,bulkheads,isolation
• Start monitoring
• Collect metrics
• Good logs and a log repository
• Tracing

…remember the fallacies…
• The network is reliable.
• Latency is zero.
• Bandwidth is infinite.
• The network is secure.
• Topology doesn't change.
• There is one administrator.
• Transport cost is zero.
• The network is homogeneous.

READING/STUDY MATERIAL…

Some reading material
• Building Microservices, by Sam Newman
(O’REILLY)
• http://microservices.io
• Netflix stuff
• http://netflix.github.io
• Distributed computing
(some topics to search for…)
• CAP Theorem (read the paper)
• Eventual Consistency (read the Dynamo DB paper)
• Idempotency
• Consensus
• Causality
• Serializability and Linearizability

Historic Big Players
• Amazon
• Amazon Cloud
• Amazon’s Two-Pizza Team Rule
http://blog.idonethis.com/two-pizza-team/
• Netflix

Microservice frameworks
• Dropwizard
http://www.dropwizard.io
• Spring Boot
http://projects.spring.io/spring-boot/
https://github.com/spring-projects/spring-loaded
https://spring.io/blog/2015/06/17/devtools-in-spring-boot-1-3
http://projects.spring.io/spring-hateoas/
• Play Framework
https://www.playframework.com
• Netflix Karyon
https://github.com/Netflix/karyon

Monitoring
• Metrics
https://dropwizard.github.io/metrics/
• Grafana
http://grafana.org
• ELK – ElasticSearch, LogStash, Kibana
https://www.elastic.co/webinars/introduction-elk-stack
• Twitter Zipkin (tracing)
http://twitter.github.io/zipkin/

Basic Resilience
• Netflix stuff
(discovery, client side LB, circuit breakers)
• http://cloud.spring.io/spring-cloud-netflix/
• Spring Cloud
• http://cloud.spring.io/

Databases and Datastores
• Service databases
(one instance/schema per service family)
• Separated report database (usually relational)
• Database variants
• Relational, document based, key-value, etc.
• Notable databases / data stores
• MongoDB, PostgreSQL, Redis, ElasticSearch
• http://projects.spring.io/spring-data/

Messaging
• Sophisticated Routing
RabbitMQ
https://www.rabbitmq.com
• High volume
Apache Kafka
http://kafka.apache.org
https://github.com/spring-projects/spring-integration-kafka

Others
• Swagger
(service description)
http://swagger.io
• Docker
(virtualization)
https://www.docker.com
• Kubernetes
(Cloud deployment)
http://kubernetes.io
• NGINX
(networking infrastructure)
https://www.nginx.com
• Zookeeper
(consensus, presence, other coordination)
http://zookeeper.apache.org

Thank you!
Paulo Gaspar
@paulogaspar7

Microservices

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Microservices

Similar to Microservices (20)

More from PT.JUG

More from PT.JUG (17)

Recently uploaded

Recently uploaded (20)

Microservices