microservice pitfalls
Post on 12-Jul-2015
1.521 Views
Preview:
TRANSCRIPT
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
top related