Microservices - Scaling Development and Service

© Equal Experts UK Ltd 2015 1

Microservices

Scaling Development and Service by Paulo Gaspar


What are Microservices?


Large(-ish) Systems

•  Ever worked on one?

•  Which roles did you play?

•  How do you rate its… •  Knowledge sharing / communication? •  Pace of progress? New technology adoption? •  Ease of technical debt elimination? •  Accountability (not throwing issues over the wall)?

•  Did your team feel they owned the project?


Small Systems

•  Ever worked on one?

•  Which roles did you play?

•  How do you rate its… •  Knowledge sharing / communication? •  Pace of progress? New technology adoption? •  Ease of technical debt elimination? •  Accountability (not throwing issues over the wall)?

•  Did your team feel they owned the project?


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


MY OWN EXPERIENCE (A cautionary tale?)


The First Time®!

•  Just because of Spring Boot (and Spring Loaded!)

•  We loved deployments!

•  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 tools


2nd, with an experienced team... First impressions

•  Very senior team

•  Agile, TDD, Reactive, Scala, Pairing, Q&A, …

•  So many services, and they run ok on my machine!

•  Infrastructure restrictions on used technologies

•  No management interference on technical decisions

•  Management SUPPORTS technical issue prioritization!


2nd, with an experienced team... Second impressions

•  Shocking: no Business Logic on Libraries!!!

•  Distributed computing like issues (error propagation, latencies…)

•  Internal Open Source


2nd, with an experienced team... Second impressions

•  Something tribal about the developer team, like: •  We would trigger a whole team impromptu meeting if we found a production problem •  And we would do the same to take a structural decision about code we were working on

•  Devs would sometime work out of office hours, but mostly monitoring!

•  Devs reported a large part of the production issues

•  A lot of importance was given to Devs feedback


2nd, with an experienced team... Contact with the other teams

•  Infrastructure teams would send us people to help us and doctrine us on the hows and whys of their systems

•  We were supported into monitoring our services

•  There was an ongoing effort to allow us to deploy our own services


2nd, with an experienced team... The Big Picture

•  Did I tell you there were hundreds of developers on the whole project?

•  Was the management behaviour Microservice related?

•  Was the development team behaviour Microservice related?

•  Was the infrastructure teams behaviour Microservice related?


2nd, with an experienced team... The Big Picture

Ownership

Accountability

Trust


3rd time is a charm?

•  Microservice wise, a less mature customer team

•  Moving functionality from a large monolithic system to Microservices

•  A colleague’s proposal: •  Before / instead of migrating, just break the old system into Microservices!


WHAT DO OTHERS SAY?


Development Scalability on large applications

•  Steeper learning curve

•  Development tools and containers get overloaded => slower development

•  Larger teams have higher communication costs / problems

•  Must rebuild and redeploy everything for any small change

•  Any change (functional or technologic) is harder and riskier

•  Riskier and expensive changes happen less frequently!


Development Scalability on Microservices

•  Services get developed and deployed independently

•  Smaller, simpler code bases •  Easier to learn and faster to develop on •  Less dependency hell •  Faster + simpler build and deployment •  Easier to compose and to replace

•  Smaller teams •  Less communication paths, lower communication costs

•  Change is simpler and risks more isolated


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?


Historic Big Players

•  Amazon •  Amazon Cloud •  Amazon’s Two-Pizza Team Rule

http://blog.idonethis.com/two-pizza-team/

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


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


…remembering the falacies…

•  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.


When you start

•  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


SOME STUDY REFERENCES…


Reading material

•  Building Microservices, by Sam Newman (O’REILLY)

•  http://microservices.io

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

•  Distributed computing (search about these topics) •  CAP Theorem (read the paper) •  Eventual Consistency (read the Dynamo DB paper) •  Idempotency •  Consensus •  Causality


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://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 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

•  NGINX (networking infrastructure)

https://www.nginx.com

•  Zookeeper (consensus, presence, other coordination)

http://zookeeper.apache.org

•  Docker (virtualization)

https://www.docker.com

•  DEIS (Docker based PaaS) http://deis.io


CI and Delivery + Security

•  There is so much to add about these themes!!!


Thank you!

Software

Microservices - Scaling Development and Service