O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
When building and maintaining large applications in a world that is rapidly evolving, keeping up with changing requirements and non-functionals over time is a huge challenge. Architecting your application in a modular way and loosely coupling modules using micro services provides you with a nicely decoupled system that still works very efficiently. Designing, evolving and versioning a micro service architecture is not easy, and over time, several design patterns and best practices have evolved that help you. Code examples can be found here: https://bitbucket.org/marrs/javaone-2014-microservices
The term "Microservice Architecture" has sprung up
over the last few years to describe a particular way
of designing software applications as suites of
independently deployable services. While there is no
precise definition of this architectural style, there are
certain common characteristics around organization
around business capability, automated deployment,
intelligence in the endpoints, and decentralized
control of languages and data.
• Should be leading when splitting an application
• Different from more traditional technology driven
“layering” (UI, application logic, database)
Conway’s Law: Any organization that designs a
system will produce a design whose structure is a
copy of the organization's communication structure.
Melvyn Conway, 1967
Component owns Data
• Each service manages its own data
• Can lead to polyglot persistence
• Leverage Domain-Driven Design: bounded context
often maps naturally to components
• Use transaction-less coordination between
services: build for eventual consistency and have a
reversal process to deal with mistakes
• Make the team responsible for the whole life cycle
of a product or component
• Brings developers closer to the customers
Amazon:”You build it, you run it!”
• Provide a public, versioned contract for a
• Have their own life cycle, so they can be
• Hide all implementation details
Design for Change
• How to break a system into components? Consider
rate of change, high cohesion, low coupling, …
• Version your services, and make them tolerant to
• Stay flexible!
The only constant is change.
Design for Failure
• Applications need to be able to deal with failures
• Services can always fail or become unavailable
• Monitoring is an important aspect
Netflix: Chaos Monkey to
introduce random instance failures
Michael Jordan: I’ve missed more than 9000 shots in
my career. I’ve lost almost 300 games. 26 times, I’ve
been trusted to take the game winning shot and
missed. I’ve failed over and over and over again in
my life. And that is why I succeed.
What is OSGi?
• Provides components that can be easily deployed
• Hides implementation details and leverages a
service registry that allows components to publish
and consume services
• It’s the de-facto module system for Java: proven
technology, works on all Java versions, usable from
embedded to enterprise
What is Amdatu?
Amdatu is an open source community effort focussed on
bringing OSGi to the cloud. It contains components to create
RESTful, scalable and distributed web applications that use
NoSQL data stores, transparent multi-tenancy and much more.
• Modular design based on OSGi
• Fast deployment using Bndtools
• Git fork/merge based workflow
• Extensive Atlassian tool support
• Apache ACE integrated with build servers
• Gradle based build
• …explored modularity and micro services
• …introduced OSGi and Amdatu
• …seen how to develop and run a modular
• …seen how OSGi allows you to be flexible in how
you group and deploy components