4Developers 2015: Microservices and Modularity or the difference between treatment and cure! - Milen Dyankov
•
0 gefällt mir•167 views
Speaker: Milen Dyankov Language: English Everyone is talking (and some are even implementing) microservices these days! So the question is should you also jump on that bandwagon and why those somewhat older colleagues of yours (yep, those that still remember the EJB 2 revolution) are not that enthusiastic? To help you make the right decisions, this talk will focus on the problem microservices claim to solve - modularity! What are the costs and limitations of what most people think microservices are? Are there other ways to modularize your application? Should you wait for Jigsaw (hopefully in Java 9) or start right away with OSGi? What learning curve to expect? It will also show some modularity success stories and best practices from large enterprise products. 4Developers: http://4developers.org.pl/pl/
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (15)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
4Developers 2015: Microservices and Modularity or the difference between treatment and cure! - Milen Dyankov
- 1. APRIL 20, 2015 Microservices and Modularity or the difference between treatment and cure Milen Dyankov @milendyankov
- 3. ~$ pidof java 9927 2151 ~$
- 4. ~$ pidof java 9927 2151 ~$ ps aux | grep java | grep -v grep | awk '{print $2}'
- 5. ~$ pidof java 9927 2151 ~$ ps aux | grep java | grep -v grep | awk '{print $2}' 2151 9927 ~$
- 6. ~$ pidof java 9927 2151 ~$ ps aux | grep java | grep -v grep | awk '{print $2}' 2151 9927 ~$ Monolith Microservices
- 8. Componentization via Services Organized around Business Capabilities Products not Projects Smart endpoints and dumb pipes Decentralized Governance Decentralized Data Management Infrastructure Automation Design for failure Evolutionary Design Microservices characteristics!
- 9. Componentization via Services Organized around Business Capabilities Products not Projects Smart endpoints and dumb pipes Decentralized Governance Decentralized Data Management Infrastructure Automation Design for failure Evolutionary Design 50% not strictly software but rather operations related!
- 11. wrong but common answer Reducing the complexity of Monoliths
- 13. ...
- 14. ...
- 15. ...
- 16. ... or
- 17. ... or ...∞
- 18. ... or ...∞ ...
- 20. . . . then all you are doing is shifting complexity from inside a component to the connections between components. . . . it moves it to a place that's less explicit and harder to control.
- 22. “The real power ... is the ability for a developer to develop a single entity and then deploy that component multiple times” “Highly Scalable, Robust, Architecture” “In very straightforward terms ... is a component model for building portable, reusable and scalable business components ... for distributed environment.”
- 23. “The real power ... is the ability for a developer to develop a single entity and then deploy that component multiple times” www.onjava.com/pub/a/onjava/2001/12/19/eejbs.html “Highly Scalable, Robust, Architecture” www.dhlee.info/computing/ejb/reference/seybold_ejb.pdf “In very straightforward terms ... is a component model for building portable, reusable and scalable business components ... for distributed environment.” www.idt.mdh.se/kurser/ct3340/archives/ht08/papersRM08/37.pdf Quotes from articles about EJB ( 1999 – 2002 )
- 24. . . . Companies worldwide have overspent about $1 billion . . . vendors are encouraging customer to buy high-end technology that they don't need.
- 26. microservices
- 27. microservices What do they have in common ?
- 28. microservices They build microservices for their own needs!
- 29. microservices They build microservices for their own needs! This makes it easer for them to grow the DevOps culture hire the right people accept “Decentralized” approach automate infrastructure
- 30. . . . a technique that is more effective for a more skillful team isn't necessarily going to work for less skillful teams . . . A poor team will always create a poor system . . .
- 32. microservices Does your organization fit into that space?
- 33. . . . you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem. . . .
- 34. Microservices What else, if not
- 35. Microservices do not cure complexity! Actually nothing does !
- 36. The term "cure" means that, after medical treatment, the patient no longer has that particular condition anymore. Some diseases have no cure. The patient will always have the condition, but treatment can help to manage it.
- 37. Good treatment for complexity is enforcing clean modular architecture
- 38. . . . The Deployment Model is a Detail. . . . there is no such thing as a micro-service architecture. Micro-services are a deployment option . . .
- 39. Interesting !?! But in my project it's not possible because of . . . Really ?!? Modularizing “Duke's forest” JEE tutorial demo! https://github.com/azzazzel/modular-dukes-forest
- 47. Microservices Modularity Is a important software architecture concept! One can design modular application without
- 48. The OSGi specification describes a modular system and a service platform for the Java programming language Confluence Eclipse Fuse ESB Glassfish Jboss JIRA JonAS Service Mix Weblogic Websphere . . . The architecture of choice for and
- 49. Componentization via Services Organized around Business Capabilities Products not Projects Smart endpoints and dumb pipes Decentralized Governance Decentralized Data Management Infrastructure Automation Design for failure Evolutionary Design Same characteristics but more flexible !
- 50. We are transforming a huge code base into small simple core and OSGi (micro)services! We have so far extracted over 80 apps and we are not done yet! This is not theory! We do this at