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!

Second impressions
•  Shocking: no Business Logic on Libraries!!!
•  Distributed computing like issues
(error propagation, latencies…)
•  Internal Open Source

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

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

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?

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

Microservices - Scaling Development and Service

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (18)

Ähnlich wie Microservices - Scaling Development and Service

Ähnlich wie Microservices - Scaling Development and Service (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Microservices - Scaling Development and Service