microservices

© Equal Experts UK Ltd 2015

Microservices

Scaling Human Workby 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 dividing work and keeping churn out high


The First Time

Were this realMicroservices?

…or just a SOA flavour?


2ND TIMEEXPERIENCED PARTNERS


The Dream Team - First impressions

• Very large overall project (a few hundred developers)

• Very senior team

• RealAgile, TDD, Reactive Programming, Scala, Pairing …

• So many services, but my laptop can run all I need for integration tests!

• Infrastructure of shared technologies (messaging, database, monitoring…)

• Infrastructure restrictions on used technologies

• No management interference on 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 and Assurance)

• A couple of B.A.s (Business Analysts)

• Shared UX team (Design, User Experience, etc.)

• A couple of business monitoring elements


Second impressions – Technicalities

• Impressive churn out…

• Functional stories often done 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 Microservice is, at most, a few thousand lines big

• There are mechanisms to deal with distributed computing issues(error propagation, latencies, cumulative latencies…)

• Improving monitoring and 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 behaviours of 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 experienced team 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


Customer feedback

It was repeatedly mentioned by customer representatives

how the team had exceeded their productivity

expectations

(and how quality was kept high)


The Big Picture

• Developers own the code as a group

• Developers take direct care of technical matters

•Managers / B.A.s take care of business related matters

•Managers trust developers (and vice versa)

• Scalability: other teams seem to be doing just the same

• Customer is happy with productivity + quality(this team’s and 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, lower communication costs

• Services get developed and 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 technologies they promoted(e.g.: some people thought that SOA had 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 productivity on 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/produce a 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 over what 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, Business Analysts…

• Keep the programming team’s focus

• And feed it with a well coordinated/ordered and uninterrupted stream of clearly defined tasks/stories across teams

• This actually means many order tasks, defining and keeping a vision, like prioritizing work, coordinating work across teams, handling the customer, keeping unnecessary politics 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 (improving DRY)


Horizontal Team – Business / Management (improving DRY)

• A (Functional/Business) Vision

• A Plan

• Well coordinated and well prioritized flow of stories…

• …consistent across all teams


Horizontal Team – System Architecture (improving DRY)

• Vision

• Overall high level (but well grounded) design

• Consistent design principles / values / philosophy

• Steering

• Gathering collective experience and sharing the resulting knowledge

• (Interesting discussion about this role on the Sam Newman’s book)


Horizontal Teams – Infrastructure (improving DRY)

• Means to effectively share knowledge across teams

• Means to support the sharing of “internal open source”

• Shared production services (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 functionality included 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 consistency problems)

• No duplicate business logic with 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 and ASAP• 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 Rulehttp://blog.idonethis.com/two-pizza-team/

• Netflix• http://netflix.github.io


Microservice frameworks

• Dropwizardhttp://www.dropwizard.io

• Spring Boothttp://projects.spring.io/spring-boot/https://github.com/spring-projects/spring-loadedhttps://spring.io/blog/2015/06/17/devtools-in-spring-boot-1-3http://projects.spring.io/spring-hateoas/

• Play Frameworkhttps://www.playframework.com

• Netflix Karyonhttps://github.com/Netflix/karyon


Monitoring

• Metricshttps://dropwizard.github.io/metrics/

• Grafanahttp://grafana.org

• ELK – ElasticSearch, LogStash, Kibanahttps://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://netflix.github.io• 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 RoutingRabbitMQ

https://www.rabbitmq.com

• High volumeApache Kafkahttp://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

Technology