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.
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
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.
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
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());
…
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
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