Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
© Equal Experts UK Ltd 2015
Microservices
Scaling Human Work
by Paulo Gaspar
@paulogaspar7
© Equal Experts UK Ltd 2015
Does size matter?
(Why didn’t Jeff Bezos want to give more than two pizzas to each team?)
© Equal Experts UK Ltd 2015
Large versus Small (Systems)
• Ever worked on both?
• Compare…
• Knowledge sharing / communica...
© Equal Experts UK Ltd 2015
But what are Microservices?
© Equal Experts UK Ltd 2015
Fowler Description
§ The microservice architectural style is an approach to developing a singl...
© Equal Experts UK Ltd 2015
Fowler Description…
…says nothing about its WHYs
© Equal Experts UK Ltd 2015
Why Microservices?
§Performance?
§Availability?
§Scalability?
§Because you like Docker and doi...
© Equal Experts UK Ltd 2015
Why Microservices?
§Or is there a “non production time” reason?
© Equal Experts UK Ltd 2015
My experience…
© Equal Experts UK Ltd 2015
A NAIVE FIRST TIME…
© Equal Experts UK Ltd 2015
The very First Time…
• Just because of Spring Boot
(and Spring Loaded!)
• We loved how fast an...
© Equal Experts UK Ltd 2015
The First Time
Were this real Microservices?
…or just a SOA flavour?
© Equal Experts UK Ltd 2015
2ND TIME
EXPERIENCED PARTNERS
© Equal Experts UK Ltd 2015
The Dream Team - First impressions
• Very large overall project (a few hundred developers)
• V...
© Equal Experts UK Ltd 2015
The Dream Team – the line up
• Product Owner (P.O.)
• Scrum Master
• 8 Developers
• 2 QA (Qual...
© Equal Experts UK Ltd 2015
Second impressions– Technicalities
• Impressive churn out…
• Functional stories oftendone fast...
© Equal Experts UK Ltd 2015
Second impressions– Tribal team behaviour
• Programming intensity is very high - almost all th...
© Equal Experts UK Ltd 2015
Interactions separated by domain…
• Developers directly take care of solving technical issues
...
© Equal Experts UK Ltd 2015
Customerfeedback
It was repeatedly mentioned by customer representatives
how the team had exce...
© Equal Experts UK Ltd 2015
The Big Picture
• Developersown the code as a group
• Developerstake direct care of technicalm...
© Equal Experts UK Ltd 2015
The Big Picture
Ownership
Accountability
Trust
© Equal Experts UK Ltd 2015
The Big Picture
I believe we were doing
REAL Microservices
© Equal Experts UK Ltd 2015
WHAT DO OTHERS SAY?
© Equal Experts UK Ltd 2015
Development on LARGE applications
• Steeper learning curve
• Higher CODE DRAG
• Throwing respo...
© Equal Experts UK Ltd 2015
Development on Microservices
• Smaller teams
• Less communication paths, lowercommunication co...
© Equal Experts UK Ltd 2015
Microservices – the WHYs…
Achieving
SCALABLE
high productivity
© Equal Experts UK Ltd 2015
Is this SOA
• “Traditional SOA” was dominated by vendors and the technologiesthey promoted
(e....
© Equal Experts UK Ltd 2015
MY 2 CENTS
© Equal Experts UK Ltd 2015
But I noticed that developing“with Microservices”…
Does NOT always work that well!
© Equal Experts UK Ltd 2015
Developing“with Microservices”…
Does not always work that well, because
Microservices are an e...
© Equal Experts UK Ltd 2015
Scaling high productivity=> high productivityon each Dev. Team!
© Equal Experts UK Ltd 2015
To have good results developing with Microservices…
Several roles must be well played
Several ...
© Equal Experts UK Ltd 2015
To have good results developing with Microservices…
Doing Agile well sure helps
(You know you ...
© Equal Experts UK Ltd 2015
The role of Developers…
• Is to code/producea maximum of business functionality
• It works bet...
© Equal Experts UK Ltd 2015
The importance of having team QAs…
• Acceptance tests and the dance of pushing to deployment h...
© Equal Experts UK Ltd 2015
The importance of a Scrum Masters or Delivery Manager,
Product Owners, BusinessAnalysts…
• Kee...
© Equal Experts UK Ltd 2015
Improving DRY(Don’t Repeat Yourself)
• Common vision + principles increase the opportunities f...
© Equal Experts UK Ltd 2015
The importance of good horizontal teams (improvingDRY)
© Equal Experts UK Ltd 2015
Horizontal Team – Business / Management (improvingDRY)
• A (Functional/Business)Vision
• A Pla...
© Equal Experts UK Ltd 2015
Horizontal Team – SystemArchitecture (improving DRY)
• Vision
• Overall high level (but well g...
© Equal Experts UK Ltd 2015
Horizontal Teams – Infrastructure (improving DRY)
• Means to effectively share knowledge acros...
© Equal Experts UK Ltd 2015
Coding -the importance of service SIZE…
• We are talking about MICROservices
• Not of Large or...
© Equal Experts UK Ltd 2015
Would you call this a Micro mammal?
© Equal Experts UK Ltd 2015
The importance of SIZE – remember, smaller code bases are…
• Easier to learn and faster to dev...
© Equal Experts UK Ltd 2015
Signs it is NOT a Microservice (just a service)…
• Lines of code count is high - into the 5 (o...
© Equal Experts UK Ltd 2015
Signs it is a good Microservice…
• Lines of code count is low (3 or 4 digits)
• Focus on busin...
© Equal Experts UK Ltd 2015
When you start
• Start small
• Learn the basics well andASAP
• Just the essential principles y...
© Equal Experts UK Ltd 2015
When you start (doing large scale Microservices)
• Embrace Devops
• Brace for networking relat...
© Equal Experts UK Ltd 2015
…remember the fallacies…
• The network is reliable.
• Latency is zero.
• Bandwidth is infinite...
© Equal Experts UK Ltd 2015
READING/STUDY MATERIAL…
© Equal Experts UK Ltd 2015
Some reading material
• Building Microservices, by Sam Newman
(O’REILLY)
• http://microservice...
© Equal Experts UK Ltd 2015
Historic Big Players
• Amazon
• Amazon Cloud
• Amazon’s Two-Pizza Team Rule
http://blog.idonet...
© Equal Experts UK Ltd 2015
Microservice frameworks
• Dropwizard
http://www.dropwizard.io
• Spring Boot
http://projects.sp...
© Equal Experts UK Ltd 2015
Monitoring
• Metrics
https://dropwizard.github.io/metrics/
• Grafana
http://grafana.org
• ELK ...
© Equal Experts UK Ltd 2015
Basic Resilience
• Netflix stuff
(discovery, client side LB, circuit breakers)
• http://netfli...
© Equal Experts UK Ltd 2015
Databases and Datastores
• Service databases
(one instance/schema per service family)
• Separa...
© Equal Experts UK Ltd 2015
Messaging
• Sophisticated Routing
RabbitMQ
https://www.rabbitmq.com
• High volume
Apache Kafka...
© Equal Experts UK Ltd 2015
Others
• Swagger
(service description)
http://swagger.io
• Docker
(virtualization)
https://www...
© Equal Experts UK Ltd 2015
Thank you!
Paulo Gaspar
@paulogaspar7
Upcoming SlideShare
Loading in …5
×

Microservices

2,418 views

Published on

Apresentação de Paulo Gaspar para o 24º encontro PT.JUG.

Published in: Technology
  • Be the first to comment

Microservices

  1. 1. © Equal Experts UK Ltd 2015 Microservices Scaling Human Work by Paulo Gaspar @paulogaspar7
  2. 2. © Equal Experts UK Ltd 2015 Does size matter? (Why didn’t Jeff Bezos want to give more than two pizzas to each team?)
  3. 3. © Equal Experts UK Ltd 2015 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)?
  4. 4. © Equal Experts UK Ltd 2015 But what are Microservices?
  5. 5. © Equal Experts UK Ltd 2015 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
  6. 6. © Equal Experts UK Ltd 2015 Fowler Description… …says nothing about its WHYs
  7. 7. © Equal Experts UK Ltd 2015 Why Microservices? §Performance? §Availability? §Scalability? §Because you like Docker and doing DevOps?
  8. 8. © Equal Experts UK Ltd 2015 Why Microservices? §Or is there a “non production time” reason?
  9. 9. © Equal Experts UK Ltd 2015 My experience…
  10. 10. © Equal Experts UK Ltd 2015 A NAIVE FIRST TIME…
  11. 11. © Equal Experts UK Ltd 2015 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
  12. 12. © Equal Experts UK Ltd 2015 The First Time Were this real Microservices? …or just a SOA flavour?
  13. 13. © Equal Experts UK Ltd 2015 2ND TIME EXPERIENCED PARTNERS
  14. 14. © Equal Experts UK Ltd 2015 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
  15. 15. © Equal Experts UK Ltd 2015 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
  16. 16. © Equal Experts UK Ltd 2015 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
  17. 17. © Equal Experts UK Ltd 2015 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
  18. 18. © Equal Experts UK Ltd 2015 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
  19. 19. © Equal Experts UK Ltd 2015 Customerfeedback It was repeatedly mentioned by customer representatives how the team had exceeded their productivity expectations (and how quality was kept high)
  20. 20. © Equal Experts UK Ltd 2015 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)
  21. 21. © Equal Experts UK Ltd 2015 The Big Picture Ownership Accountability Trust
  22. 22. © Equal Experts UK Ltd 2015 The Big Picture I believe we were doing REAL Microservices
  23. 23. © Equal Experts UK Ltd 2015 WHAT DO OTHERS SAY?
  24. 24. © Equal Experts UK Ltd 2015 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
  25. 25. © Equal Experts UK Ltd 2015 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
  26. 26. © Equal Experts UK Ltd 2015 Microservices – the WHYs… Achieving SCALABLE high productivity
  27. 27. © Equal Experts UK Ltd 2015 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?
  28. 28. © Equal Experts UK Ltd 2015 MY 2 CENTS
  29. 29. © Equal Experts UK Ltd 2015 But I noticed that developing“with Microservices”… Does NOT always work that well!
  30. 30. © Equal Experts UK Ltd 2015 Developing“with Microservices”… Does not always work that well, because Microservices are an enabler, NOT a guarantee
  31. 31. © Equal Experts UK Ltd 2015 Scaling high productivity=> high productivityon each Dev. Team!
  32. 32. © Equal Experts UK Ltd 2015 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!
  33. 33. © Equal Experts UK Ltd 2015 To have good results developing with Microservices… Doing Agile well sure helps (You know you can read about Agile elsewhere!)
  34. 34. © Equal Experts UK Ltd 2015 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
  35. 35. © Equal Experts UK Ltd 2015 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
  36. 36. © Equal Experts UK Ltd 2015 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.
  37. 37. © Equal Experts UK Ltd 2015 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
  38. 38. © Equal Experts UK Ltd 2015 The importance of good horizontal teams (improvingDRY)
  39. 39. © Equal Experts UK Ltd 2015 Horizontal Team – Business / Management (improvingDRY) • A (Functional/Business)Vision • A Plan • Well coordinated and well prioritizedflow of stories… • …consistent across all teams
  40. 40. © Equal Experts UK Ltd 2015 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)
  41. 41. © Equal Experts UK Ltd 2015 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
  42. 42. © Equal Experts UK Ltd 2015 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!!!
  43. 43. © Equal Experts UK Ltd 2015 Would you call this a Micro mammal?
  44. 44. © Equal Experts UK Ltd 2015 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
  45. 45. © Equal Experts UK Ltd 2015 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
  46. 46. © Equal Experts UK Ltd 2015 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
  47. 47. © Equal Experts UK Ltd 2015 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
  48. 48. © Equal Experts UK Ltd 2015 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
  49. 49. © Equal Experts UK Ltd 2015 …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.
  50. 50. © Equal Experts UK Ltd 2015 READING/STUDY MATERIAL…
  51. 51. © Equal Experts UK Ltd 2015 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
  52. 52. © Equal Experts UK Ltd 2015 Historic Big Players • Amazon • Amazon Cloud • Amazon’s Two-Pizza Team Rule http://blog.idonethis.com/two-pizza-team/ • Netflix • http://netflix.github.io
  53. 53. © Equal Experts UK Ltd 2015 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
  54. 54. © Equal Experts UK Ltd 2015 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/
  55. 55. © Equal Experts UK Ltd 2015 Basic Resilience • Netflix stuff (discovery, client side LB, circuit breakers) • http://netflix.github.io • http://cloud.spring.io/spring-cloud-netflix/ • Spring Cloud • http://cloud.spring.io/
  56. 56. © Equal Experts UK Ltd 2015 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/
  57. 57. © Equal Experts UK Ltd 2015 Messaging • Sophisticated Routing RabbitMQ https://www.rabbitmq.com • High volume Apache Kafka http://kafka.apache.org https://github.com/spring-projects/spring-integration-kafka
  58. 58. © Equal Experts UK Ltd 2015 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
  59. 59. © Equal Experts UK Ltd 2015 Thank you! Paulo Gaspar @paulogaspar7

×