micro services architecture (FrosCon2014)

micro services architecture (FrosCon2014) from smancke

micro services architecture (FrosCon2014)

1. 1. Micro Services Sebastian Mancke Creative Commons BY-SA 3.0
2. 2. 24.08.14 2 Monolythic Software Why are monolythic systems 'evil' ? Because of their dependencies: ● Software is not easy to test ● And hard to refactor ● Effects of changes can not be isolated ● Working with multiple developers/teams is challenging ● No reuse of functionality ● Runtime and deployment dependencies: ● Performance and scaling ● Deployment of features and releases
3. 3. 24.08.14 3 Avoid a Monolyth Monolyths arise from bad design, independent of the technology! ● You can build a monolyth with every software framework. ● Even distributed systems with a lot of services can be monolythic. ● And even software with monolythic builds and deployments may have a good internal structure. So, chosing a popular micro services framework is not enough!
4. 4. 24.08.14 4 Think Vertical! Split the application in functional modules Maximal reduction of dependencies between different functional parts Vertical teams (End-to-End)
5. 5. 24.08.14 5 Classical Approach GUI -Layer Services Database/Persistance
6. 6. 24.08.14 6 SOA Approach GUI -Layer Business Service DB Business Service Business Service Persistence Service DB Persistence Service DB Persistence Service DB Persistence Service DB Persistence Service
7. 7. 24.08.14 7 The Micro Services Way... GUI Service DB GUI Service DB GUI Service DB GUI Service DB
8. 8. 24.08.14 8 Shop Example
9. 9. Micro Services
10. 10. 24.08.14 10 Micro Services Principles 1/2 Small with a single responsibility • Each application only does one thing • Small enough to fit in your head – “If a service is bigger than your head, than it is too big” • Small enough that you can throw them away – Rewrite or Maintain by James Lewis:
11. 11. 24.08.14 11 Micro Services Principles 2/2 by James Lewis: Located in different VCS roots • Each application is completely seperate • Domain Driven Design / Conway’s law – Domains in different bounded contexts shoud be distinct - and it is ok to have duplication – Use physical separation to enforce this • There will be common code, but it should be library and infrastructure code – Treat it as you would any other open source library – Stick it in a nexus repo somewhere and treat it as a binary dependency
12. 12. 24.08.14 12 Implementation No application servers ● Every service runs in it's own process ● Every service brings it's own environment Choose the right stack for the requirements ● 1 monolyth 1 stack, 100 Micro Services flexibility→ → ● Free choice of: OS, language, framework, database, .. ● But: Be careful! New feature, new service? ● At first check, if a feature should build a new functional module ● Only in the second step extend an existing service ● Rule: Merging services is easy, splitting is hard!
13. 13. 24.08.14 13 Java Frameworks ● Spring Boot ● Dropwizard ● Vert.x
14. 14. 24.08.14 14 Database Design goal: Every service should have it's own exclusive database Strategies ● NoSQL / document oriented design ● Treat foreign keys as REST URI references ● When a service needs external data: Call a service ● Don't fear data redundancy ● Replication of data: Pulling feeds with changelogs Tradeoff solutions ● Multiple schemas within the same database ● Read-only views for data of other services ● Use DB features for replication (e.g. database link)
15. 15. 24.08.14 15 UI Design goal: Services should provide their UI themselves Strategies ● Every service serves the full page, including layout and menu bar ● Commitment on one CSS naming schema ● Central asset service (menu, styles, common resources) ● Single page apps only within one service ● GUI composition only on the client (in the browser) ● Use UI fragments / widgets when embedding data of another service
16. 16. 24.08.14 16 Security Problem: The security context is spread over 100 services Solution: Identity Management System ● Identity Management is also a service module (or even multiple) ● Service for management of identities ● Service for login/logout ● Service for self administration ● OAuth2 allows distribution of the login to different services
17. 17. 24.08.14 17 Login implementations Variant a: Shared Cookie ● All services are available under the same domain ● The login service creates a cookie available to all others ● Username, timestamp, rolles/permissions ● Crypted and signed ● All services can verify the cookie by checking the signature Variant b: Independent Applications ● Every service maintains it's own session ● Login is done by OAuth2 ● Double redirect ● Token exchange ● The login service maintains a sessions as well ● Multiple logins are done transparent to the user
18. 18. 24.08.14 18 OSIAM https://github.com/osiam/
19. 19. 24.08.14 19 Communication Everything is allowed But: You should establish one standard for your platform. Principles ● Loose coupling – services should not know about each other ● Smart endpoints, dump pipes ● No intelligence in the communication channel ● No ESB REST is a good choice for many scenarios ● Easy consumable with all languages ● Interfaces are maintainable towards compatibility ● URI references are helpful for navigation to different services and abstraction of the physical location of resources.
20. 20. 24.08.14 20 Communication– further principles Asynchronous Messaging ● Reliable event distribution ● High performance ● Load protection of critical services Resilience ● Tolerance against failures ● Error recovery ● Avoid error cascades API Versioning ● Don't do it for internal APIs!
21. 21. 24.08.14 21 Testing Unit Tests ● Integration tests suffice in many cases because the services are small ● Test the isolated service (Other services should be mocked) Consumer Driven Tests Idea: The integration tests of a service will be defined and implemented by the consumer (not by the service provider). No release before the service passes all consumer's tests ● Test with the real expectations, not with the service specification ● Very smart concept, but hard to maintain ● Has the risk of high test-redundancy for common APIs
22. 22. 24.08.14 22 Deployment Contiuous Delivery ● Create a deployment pipeline ● Need to automate everything One monolyth may be easy to deploy, 100 Micro Services may not! Packaging & Provisioning ● Usage of established standards: DEB, RPM, … ● Robust init scripts ● Configuration management: Puppet, Chef, ...
23. 23. 24.08.14 23 Deployment as platform 1 Micro Service : 1 Linux System Docker ● LXC based virtualisation ● Similar to changeroot (but a lot better!) ● Slim and fast ● Based on git, so changes of the images can be tracked For Hardliners ● Install the Micro Service by shipping and starting the system image ● No packaging ● No init scripts
24. 24. 24.08.14 24 Monitoring Realtime metrics ● Monitor, what currently happens ● Fast reaction to problems ● Do monitoring inside the application, not outside ● Tools: Metrics, Spring Boot Actuator Logging ● Manual search in logs of 100 services is not possible ● Central log aggregation ● Filtering and analyses in realtime ● Tools: Logstash, Graylog2, Kibana, Apache Flume, fluentd
25. 25. 24.08.14 25 Risks Micro Services are a promising paradigm But, you should always be careful with new paradigms! ● Inventarisation of many services ● Challenging for operations ● High network load (if not done right) ● New way of thinking ● The freedom of technology selection may lead to chaos, if it is no governance
26. 26. Thank You!