1. Efficiently
building
and deploying
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. MICROSERVICES

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 1 thing 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 and dumb pipes
Loosely coupled
• Make the service smart. Keep the communication dumb.
• Favor coarse-grained over fine-grained communication.

8. Smart endpoints and dumb pipes
Synchronous
• HTTP request / response

9. Smart endpoints and dumb pipes
Synchronous
• HTTP request / response

10. Smart endpoints and dumb pipes
Asynchronous
• Lightweight messaging

11. Smart endpoints and dumb pipes
Asynchronous
• Event-driven

12. Decentralized governance
API interface
• 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
Smart endpoints and dumb pipes
Decentralised governance
Decentralised data management
Design for failure
Automation

18. building
and deploying

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
Person Publisher
• Spring Boot
• Tomcat
• Rabbit MQ
@Autowired
RabbitTemplate rabbitTemplate;
…
rabbitTemplate.convertAndSend(QUEUE_NAME, repository.getAllPersons());
…

23. 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);
}

24. 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)

25. Building: Sample
Address Publisher

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

28. Efficiently
Synchronous vs Asynchronous
• Decide early
• Rule of thumb
– Reading: synchronous
– Updating: asynchronous

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

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. Thank you