microservice pitfalls

From JavaSpaces, JINI and GigaSpaces to SpringBoot, Akka – reactive and

microservice pitfalls

Mite Mitreski

Java2Days 2014

@mitemitreski

What is reactive programming?

Reactive programming is _______

a) Hypeb) Awesomec) Differentd) Just the observer patterne) Microsoft Excelf) Manifestog) All of above

http://www.reactivemanifesto.org/

Responsive

Message Driven

ResilientElastic

Microservices

The monolith Microservices

The monolith

● Componentization is via Services● Often organized around Tech abilities

○ UI Expert teams○ Backend or middleware developers○ DBA’s

● People are bound to step on each other toes

Conway’s law

… organizations which design systems ... are

constrained to produce designs which are copies of

the communication structures of these organizations

The architecture of the system gets cemented in the

forms of the teams that develop it.

—Melvin Conway

The microservices

● Organized around Business Capabilities● Products not Projects

○ development team takes full responsibility for the software in production

○ "you build, you run it" - aka the Amazon way● SOA done right

Decentralized Governance

Java EE

Clojure

Ruby

C# app

Spring based

Spring with tab indentation

Decentralized Governance

Java EE

Clojure

Ruby

NodeJS

Spring based

Spring with tab indentation

V2 replaced C# with NodeJS

Separate pipelines for each app

Java EE

Clojure

Ruby

NodeJS

Spring based

Spring with tab indentation

Other microservice benefits

● Decentralized Data Management● Evolutionary Design

Microservices are the unix way

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

Doug McIlroy, head of the Bell Labs CSRC (Computing Sciences Research Center), and inventor of the Unix pipe

Mike Gancarz: The UNIX Philosophy

1. Small is beautiful.

2. Make each program do one thing well.

3. Build a prototype as soon as possible.

4. Choose portability over efficiency.

5. Store data in flat text files.

6. Use software leverage to your advantage.

7. Use shell scripts to increase leverage and portability.

8. Avoid captive user interfaces.

9. Make every program a filter.

With all the frameworks out there what do I pick?

HOW not to FAIL @ MicroServices

#1 Divide and Conquer

break down complex problems into smaller chunks that can be solved

individually

#2 How big is too big?

● Big enough to fit in your head● Small enough that you team can manage all

the pieces● Each piece should be rewritable ● Lines of code is not an important

measurement @RestControllerclass App { @RequestMapping("/") String home() { "hello" }}

#3 Each service on it’s own repo

● Each service should be on a separate VCS root○ Physical code separation

● Various dependencies temptations not possible

#5 What to standardize

Java EE

Clojure

Ruby

NodeJS

Spring based

Spring with tab indentation

Standardize interface

Free for all

#7 How do test all of this?

NodeJSS2App

S1

NodeJSMockApp

Mock

PRODUCTION

#8 Coupling avoidance

RPC (RMI)Shared serializationSOAPCORBA

Resources (REST)

#9 Avoid distributed transactions

Space B

Space B

JINI/Gigaspaces example

Space A

SOME APP

#9 Monitoring is essential

Java EE

Clojure

Ruby

NodeJS

Spring based

Spring with tab indentation

#9 Monitoring is essential

Spring Boot - Actuator

Plain old JMXCustom HTTP monitoring

Gigaspaces UI and admin API

#10 Use tracking ID

Clojure

Spring App

NodeJS

ID : 223-305

#10 Use tracking ID

Clojure

Spring App

NodeJS

ID : 223-305

ID : 223-305

#10 Use tracking ID

Clojure

Spring App

NodeJS

ID : 223-305

ID : 223-305

ID : 223-305

#11 Have a single way of deployment

Java EE

Clojure

Ruby

NodeJS

Spring based

Spring with tab indentation

Missing the WAR files?

#12 Move to production individually

PROD

S2 1.0.0

S1 1.0.0

App 1.0.0

TEST

S1 1.0.0

App 1.0.0

S2 1.0.0

#12 Move to production individually

PROD

S2 1.0.0

S1 1.0.0

App 1.0.0

TEST

S1 1.0.1

App 1.0.0

S2 1.0.0

#12 Move to production individually

PROD

S2 1.0.0

S1 1.0.1

App 1.0.0

TEST

S1 1.0.1

App 1.0.0

S2 1.0.0

#13 Stability ?

● Timeouts● Circuit breakers● Bulkheads● Handshakes

#14 Make batch calls if possible

ServiceClient

#14 Make batch calls if possible

ServiceClient

Are Microservices the Future?

Who uses microservices ?

Shameless plug

Amazon’s SOA story

1. All teams will henceforth expose their data and functionality through service

interfaces.

2. Teams must communicate with each other through these interfaces.

3. There will be no other form of interprocess communication allowed: no direct

linking, no direct reads of another team’s data store, no shared-memory model,

no back-doors whatsoever. The only communication allowed is via service

interface calls over the network.

4. It doesn’t matter what technology they use. HTTP, Corba, Pub-Sub, custom

protocols — doesn’t matter. Bezos doesn’t care.

5. All service interfaces, without exception, must be designed from the ground up to

be externalizable. That is to say, the team must plan and design to be able to

expose the interface to developers in the outside world. No exceptions.

6. Anyone who doesn’t do this will be fired.

Standing in the shoulders of giants

Microservices resources

● http://martinfowler.com/articles/microservices.html● Microservices not a free Lunch● Adventures in a cloudy future

Summary

Microservices are awesome but be aware of the challenges and make sure you use best practices.

Operation and resilience are the biggest overheads.

Summary

Ensure your team is up to the task.

Ensure you have DevOps experties.

Start small and make adjustments as needed.

Summary

Questions