Efficiently
building
and deployingMICROSERVICES
Bart Blommaerts
Me• [email protected]• @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
SmallSmart endpoints and dumb
pipesDecentralised governance
Decentralised data management
Design for failureAutomation
building
and deploying
Building: Synchronous
Person• Spring Boot• Tomcat
@ComponentScan@EnableAutoConfigurationpublic class PersonApplication {
public static void main(String[] args) {SpringApplication.run(PersonApplication.class,
args);}
}
Building: Synchronous
Address• DropWizard• Jetty
@Overridepublic 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.
@Overridepublic 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
@AutowiredRabbitTemplate rabbitTemplate;
…
rabbitTemplate.convertAndSend(QUEUE_NAME, repository.getAllPersons());
…
Building: Asynchronous: Person Publisher@BeanQueue queue() {
return new Queue(QUEUE_NAME, false);}
@BeanTopicExchange exchange() {
return new TopicExchange(TOPIC_EXCHANGE);}
@BeanBinding binding(Queue queue, TopicExchange exchange) {
return BindingBuilder.bind(queue).to(exchange).with(QUEUE_NAME);}
Building: Asynchronous
Person Listener• Spring Boot• Tomcat• Rabbit MQ
Application:@Beanprivate 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
Recommended
