Efficiently 
building 
and deploying 
MICROSERVICES
Bart Blommaerts 
Me 
• bart.blommaerts@hp.com 
• @DaggieBe 
HP Enterprise Services 
• EMEA Java SME 
• Technical Lead at Flemish Government 
Web 
• https://github.com/bart-blommaerts/ 
• http://www.daggie.be
MICROSERVICES
Why? 
Monoliths … 
• Don’t scale easily 
• Are difficult 
– To understand 
– To maintain 
– To test 
– To deploy 
• Make it difficult to adopt new technology 
A monolithic application is like a house of cards ...
Small 
Do 1 thing well 
• 1 responsibility 
• About use case / business capability 
Not about LOC 
Stateless
Small 
Decomposition 
• A monolitic application has disadvantages 
• Decompose the monolith into microservices
Smart endpoints and dumb pipes 
Loosely coupled 
• Make the service smart. Keep the communication dumb. 
• Favor coarse-grained over fine-grained communication.
Smart endpoints and dumb pipes 
Synchronous 
• HTTP request / response
Smart endpoints and dumb pipes 
Synchronous 
• HTTP request / response
Smart endpoints and dumb pipes 
Asynchronous 
• Lightweight messaging
Smart endpoints and dumb pipes 
Asynchronous 
• Event-driven
Decentralized governance 
API interface 
• Language agnostic 
• Multiple versions allowed / encouraged 
• Publish anything of interest. Don’t wait to be asked. 
• Evolutionary 
Disposable
Decentralized data management 
Polyglot persistence 
• Each service owns it’s data storage
Decentralized data management 
Eventual consistency 
• Transactions impose coupling 
• Synchronizing databases might be needed 
Do 1 thing
Design for failure 
Self-monitoring 
• Application will use services as components: many moving parts 
• Any service can fail (or be unreachable): 
– Detect quickly 
– Restore automatically (if possible)
Automation 
Infrastructure (deployment) 
• Large number of services will require automation 
– Use existing solutions (eg. Jenkins, Bamboo, ..) 
• Automation as an enabler for microservices
Recap 
Small 
Smart endpoints and dumb pipes 
Decentralised governance 
Decentralised data management 
Design for failure 
Automation
building 
and deploying
Building: Synchronous 
Person 
• Spring Boot 
• Tomcat 
@ComponentScan 
@EnableAutoConfiguration 
public class PersonApplication { 
public static void main(String[] args) { 
SpringApplication.run(PersonApplication.class, args); 
} 
}
Building: Synchronous 
Address 
• DropWizard 
• Jetty 
@Override 
public void run(AddressConfiguration configuration, Environment environment) { 
final AddressResource resource = new AddressResource(); 
final AddressHealthCheck addressHealthCheck = new AddressHealthCheck(); 
environment.healthChecks().register("address", addressHealthCheck); 
environment.jersey().register(resource); 
}
Building: Synchronous 
PersonAddress 
• DropWizard 
• Jetty 
• Calling Person and Address service, using Jersey. 
@Override 
public void run(PersAddrConfiguration configuration, Environment environment) { 
final Client client = new JerseyClientBuilder(environment).using( 
configuration.getJerseyClientConfiguration()).build(getName()); 
final PersonAddressResource resource = new PersonAddressResource(client); 
…
Building: Asynchronous 
Person Publisher 
• Spring Boot 
• Tomcat 
• Rabbit MQ 
@Autowired 
RabbitTemplate rabbitTemplate; 
… 
rabbitTemplate.convertAndSend(QUEUE_NAME, repository.getAllPersons()); 
…
Building: Asynchronous: Person Publisher 
@Bean 
Queue queue() { 
return new Queue(QUEUE_NAME, false); 
} 
@Bean 
TopicExchange exchange() { 
return new TopicExchange(TOPIC_EXCHANGE); 
} 
@Bean 
Binding binding(Queue queue, TopicExchange exchange) { 
return BindingBuilder.bind(queue).to(exchange).with(QUEUE_NAME); 
}
Building: Asynchronous 
Person Listener 
• Spring Boot 
• Tomcat 
• Rabbit MQ 
Application: 
@Bean 
private MessageListenerAdapter listenerAdapter(PersonListener listener) { 
return new MessageListenerAdapter(listener, "receiveMessage"); 
} 
… 
PersonListener: 
public void receiveMessage(Map<Integer, Person> message)
Building: Sample 
Address Publisher
Deploying 
Automation 
• Simple sample application: 5 servlet containers, 1 messaging queue 
• Configure a deployment pipeline 
• Use deployment automation from the start 
• Consider a PaaS 
– Cloud Foundry, OpenShift, ...
Efficiently
Efficiently 
Synchronous vs Asynchronous 
• Decide early 
• Rule of thumb 
– Reading: synchronous 
– Updating: asynchronous
Decentralised governance 
Service templating 
• Microservices are language agnostic 
– But don’t change technology because you can. Change because it makes sense. 
• Start with a common technology stack 
Modularity 
• Services can be modules of the system 
– Own life cycle 
– Independently deployable 
– But .. “Options” in regard to re-use
Deploying 
DevOps 
• Own your service 
– Eat your own dog food 
• Monitor the monitoring .. 
– Use the monitoring to make the service self-operational 
• Log everything
Efficiently 
Tracking 
• Microservices will be using other microservices 
• Keep track of 
– a correlation id between services 
– The ‘age’ of the data / response
Efficiently 
Tracking: CorrelationId 
Publisher: 
protected Message createMessage(Object object, MessageProperties 
messageProperties) throws MessageConversionException { 
messageProperties.setCorrelationId(correlationId.getBytes()); 
return super.createMessage(object, messageProperties); 
} 
Listener: 
protected Object extractMessage(Message message) throws Exception { 
byte[] correlationId = message.getMessageProperties().getCorrelationId();
Efficiently 
Free Lunch? 
• Complexity 
• DRY 
• Latency and marshalling 
• Versioning 
• API Interface 
• Architect security in from the beginning 
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
Thank you

JavaOne: Efficiently building and deploying microservices

  • 1.
    Efficiently building anddeploying MICROSERVICES
  • 2.
    Bart Blommaerts Me • bart.blommaerts@hp.com • @DaggieBe HP Enterprise Services • EMEA Java SME • Technical Lead at Flemish Government Web • https://github.com/bart-blommaerts/ • http://www.daggie.be
  • 3.
  • 4.
    Why? Monoliths … • Don’t scale easily • Are difficult – To understand – To maintain – To test – To deploy • Make it difficult to adopt new technology A monolithic application is like a house of cards ...
  • 5.
    Small Do 1thing well • 1 responsibility • About use case / business capability Not about LOC Stateless
  • 6.
    Small Decomposition •A monolitic application has disadvantages • Decompose the monolith into microservices
  • 7.
    Smart endpoints anddumb pipes Loosely coupled • Make the service smart. Keep the communication dumb. • Favor coarse-grained over fine-grained communication.
  • 8.
    Smart endpoints anddumb pipes Synchronous • HTTP request / response
  • 9.
    Smart endpoints anddumb pipes Synchronous • HTTP request / response
  • 10.
    Smart endpoints anddumb pipes Asynchronous • Lightweight messaging
  • 11.
    Smart endpoints anddumb pipes Asynchronous • Event-driven
  • 12.
    Decentralized governance APIinterface • Language agnostic • Multiple versions allowed / encouraged • Publish anything of interest. Don’t wait to be asked. • Evolutionary Disposable
  • 13.
    Decentralized data management Polyglot persistence • Each service owns it’s data storage
  • 14.
    Decentralized data management Eventual consistency • Transactions impose coupling • Synchronizing databases might be needed Do 1 thing
  • 15.
    Design for failure Self-monitoring • Application will use services as components: many moving parts • Any service can fail (or be unreachable): – Detect quickly – Restore automatically (if possible)
  • 16.
    Automation Infrastructure (deployment) • Large number of services will require automation – Use existing solutions (eg. Jenkins, Bamboo, ..) • Automation as an enabler for microservices
  • 17.
    Recap Small Smartendpoints and dumb pipes Decentralised governance Decentralised data management Design for failure Automation
  • 18.
  • 19.
    Building: Synchronous Person • Spring Boot • Tomcat @ComponentScan @EnableAutoConfiguration public class PersonApplication { public static void main(String[] args) { SpringApplication.run(PersonApplication.class, args); } }
  • 20.
    Building: Synchronous Address • DropWizard • Jetty @Override public void run(AddressConfiguration configuration, Environment environment) { final AddressResource resource = new AddressResource(); final AddressHealthCheck addressHealthCheck = new AddressHealthCheck(); environment.healthChecks().register("address", addressHealthCheck); environment.jersey().register(resource); }
  • 21.
    Building: Synchronous PersonAddress • DropWizard • Jetty • Calling Person and Address service, using Jersey. @Override public void run(PersAddrConfiguration configuration, Environment environment) { final Client client = new JerseyClientBuilder(environment).using( configuration.getJerseyClientConfiguration()).build(getName()); final PersonAddressResource resource = new PersonAddressResource(client); …
  • 22.
    Building: Asynchronous PersonPublisher • Spring Boot • Tomcat • Rabbit MQ @Autowired RabbitTemplate rabbitTemplate; … rabbitTemplate.convertAndSend(QUEUE_NAME, repository.getAllPersons()); …
  • 23.
    Building: Asynchronous: PersonPublisher @Bean Queue queue() { return new Queue(QUEUE_NAME, false); } @Bean TopicExchange exchange() { return new TopicExchange(TOPIC_EXCHANGE); } @Bean Binding binding(Queue queue, TopicExchange exchange) { return BindingBuilder.bind(queue).to(exchange).with(QUEUE_NAME); }
  • 24.
    Building: Asynchronous PersonListener • Spring Boot • Tomcat • Rabbit MQ Application: @Bean private MessageListenerAdapter listenerAdapter(PersonListener listener) { return new MessageListenerAdapter(listener, "receiveMessage"); } … PersonListener: public void receiveMessage(Map<Integer, Person> message)
  • 25.
  • 26.
    Deploying Automation •Simple sample application: 5 servlet containers, 1 messaging queue • Configure a deployment pipeline • Use deployment automation from the start • Consider a PaaS – Cloud Foundry, OpenShift, ...
  • 27.
  • 28.
    Efficiently Synchronous vsAsynchronous • Decide early • Rule of thumb – Reading: synchronous – Updating: asynchronous
  • 29.
    Decentralised governance Servicetemplating • Microservices are language agnostic – But don’t change technology because you can. Change because it makes sense. • Start with a common technology stack Modularity • Services can be modules of the system – Own life cycle – Independently deployable – But .. “Options” in regard to re-use
  • 30.
    Deploying DevOps •Own your service – Eat your own dog food • Monitor the monitoring .. – Use the monitoring to make the service self-operational • Log everything
  • 31.
    Efficiently Tracking •Microservices will be using other microservices • Keep track of – a correlation id between services – The ‘age’ of the data / response
  • 32.
    Efficiently Tracking: CorrelationId Publisher: protected Message createMessage(Object object, MessageProperties messageProperties) throws MessageConversionException { messageProperties.setCorrelationId(correlationId.getBytes()); return super.createMessage(object, messageProperties); } Listener: protected Object extractMessage(Message message) throws Exception { byte[] correlationId = message.getMessageProperties().getCorrelationId();
  • 33.
    Efficiently Free Lunch? • Complexity • DRY • Latency and marshalling • Versioning • API Interface • Architect security in from the beginning http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
  • 34.