Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

JavaOne: Efficiently building and deploying microservices

2,380 views

Published on

Since Martin Fowler’s article on microservices in the beginning of 2014, there has been a lot of controversy about the topic. Although most articles talk about microservices from an architectural perspective, this session intends to go further and also provide examples of and best practices for building and deploying polyglot applications in an enterprise Java environment. In the session, the build process focuses on efficiency and shows that microservices don’t necessarily cause overhead for a project. Microservices don't imply copying and pasting the same boilerplate code over and over. The deployment process in the presentation is, of course, automated but also demonstrates best practices for integration testing between different active services.

Published in: Technology

JavaOne: Efficiently building and deploying microservices

  1. 1. Efficiently building and deploying MICROSERVICES
  2. 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. 3. MICROSERVICES
  4. 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. 5. Small Do 1 thing well • 1 responsibility • About use case / business capability Not about LOC Stateless
  6. 6. Small Decomposition • A monolitic application has disadvantages • Decompose the monolith into microservices
  7. 7. Smart endpoints and dumb pipes Loosely coupled • Make the service smart. Keep the communication dumb. • Favor coarse-grained over fine-grained communication.
  8. 8. Smart endpoints and dumb pipes Synchronous • HTTP request / response
  9. 9. Smart endpoints and dumb pipes Synchronous • HTTP request / response
  10. 10. Smart endpoints and dumb pipes Asynchronous • Lightweight messaging
  11. 11. Smart endpoints and dumb pipes Asynchronous • Event-driven
  12. 12. Decentralized governance API interface • Language agnostic • Multiple versions allowed / encouraged • Publish anything of interest. Don’t wait to be asked. • Evolutionary Disposable
  13. 13. Decentralized data management Polyglot persistence • Each service owns it’s data storage
  14. 14. Decentralized data management Eventual consistency • Transactions impose coupling • Synchronizing databases might be needed Do 1 thing
  15. 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. 16. Automation Infrastructure (deployment) • Large number of services will require automation – Use existing solutions (eg. Jenkins, Bamboo, ..) • Automation as an enabler for microservices
  17. 17. Recap Small Smart endpoints and dumb pipes Decentralised governance Decentralised data management Design for failure Automation
  18. 18. building and deploying
  19. 19. Building: Synchronous Person • Spring Boot • Tomcat @ComponentScan @EnableAutoConfiguration public class PersonApplication { public static void main(String[] args) { SpringApplication.run(PersonApplication.class, args); } }
  20. 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. 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. 22. Building: Asynchronous Person Publisher • Spring Boot • Tomcat • Rabbit MQ @Autowired RabbitTemplate rabbitTemplate; … rabbitTemplate.convertAndSend(QUEUE_NAME, repository.getAllPersons()); …
  23. 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. 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. 25. Building: Sample Address Publisher
  26. 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. 27. Efficiently
  28. 28. Efficiently Synchronous vs Asynchronous • Decide early • Rule of thumb – Reading: synchronous – Updating: asynchronous
  29. 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. 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. 31. Efficiently Tracking • Microservices will be using other microservices • Keep track of – a correlation id between services – The ‘age’ of the data / response
  32. 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. 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. 34. Thank you

×