Monolithic to Microservices Architecture - STM 6
Download as ODP, PDF2 likes727 views
The document discusses the transition from monolithic to microservices architecture, highlighting the limitations of monolithic systems such as large code bases and difficulty in scaling. It outlines the benefits of microservices, including resilience, ease of deployment, and composability, as well as providing guidance on how to effectively split a monolith into microservices. Additionally, it addresses testing, integration, orchestration, monitoring, and security considerations for microservices development.
Monolithic to Microservices Architecture - STM 6
- 1. Monolithic to Microservices Architecture LAZO APOSTOLOVSKI JAVA DEVELOPER @ TRICODE MACEDONIA
- 2. What is Monolithic Architecture?
- 3. Monolithic Architecture drawbacks? ● Huge code base ● Hard to manage ● Difficult Continuous Integration ● Difficult application Scaling ● And so on...
- 5. What are Microservices? Microservices are small, focused, autonomous services that work together.
- 6. Benefits of Microservices ● Mixed Technology can be used ● That fits needs of that microservice. ● Resilience ● If one node fails, others continue to work and isolate the problem. ● Ease of Deployment ● On code change, only affected part can be redeployed faster. ● Composability ● Microservice can be used for different purposes, and from different applications. ● Replaceable ● Easier to replace, delete or rewrite is much easier on small functionality.
- 7. What Makes a Good Service? 3 things
- 8. What Makes a Good Service? ● Loose Coupling ● Whole point is to make changes to one service and deploy it. ● High Cohesion ● Related behavior is located on one place. ● Shared and hidden models ● Share only minimum information to customer, and hide internal implementation.
- 9. From where to start?
- 10. Always start from Monolith Application and split later.
- 12. Why to split the monolith?
- 13. Why to split the monolith? ● Code base is huge to manage ● Some part will change frequently ● We need to deploy new changes fast ● Some data need additional protection around ● Different technology should be used
- 14. Splitting is complex and will cost you a lot, if you not do it right.
- 15. Where to start? ● From existing monolith ● Detect functionality boundaries ● Separate to modules first ● Extract as stand alone microservices
- 16. That is about code. But what about database?
- 17. Splitting database ● Isolate data in separate tables first ● Break foreign key relations ● If all good move it to another database ● Extract code in microservice ● If fail merge it all back and rethink
- 18. Deal with... ● Static data (enumerations) Copy or put it in configuration ● Shared data (different functionality use same data) Can be separated as different microservice too ● Transactions (no transactions anymore) Different ways to handle this. Try again later or abort everything.
- 19. T E S T I N G Tests are important
- 20. TESTING ● Unit tests Have a lot of them ● Acceptance tests Check if its implemented like it should ● Performance tests How system can handle the load ● Exploration tests Finding the way to break the system
- 21. TESTING ● Service tests Stub and mock external services ● Test service in isolation ● Test without user interface ● End-to-end tests Testing all together ● Slow and tricky to manage ● Its hard to locate the problem
- 22. Developer's team write tests by itself!
- 23. Testing microservice into production. How to do it?
- 24. In production all that go wrong will go wrong. Minimize the impact with 2 basic approaches.
- 25. Minimize the impact Blue / Green deployment.
- 26. Minimize the impact Canary deployment
- 27. Microservices integration Get it wrong, and disaster awaits.
- 29. Integration Avoid braking changes! Consumers should be able to use service until they are ready to switch.
- 30. Versioning ● Microservices are changing constantly ● Internal changes do not affect consumers. ● Changes should not prevent consumers use service. ● Small changes and Breaking changes.
- 31. Dealing with small changes. ● New field is added ● Unused field is removed ● Consumer read only what is needed ● Use flexible technology JSON or XML.
- 32. Dealing with breaking changes ● Need to be avoided ● Support old version for a while – Give consumers time to switch ● Two parallel service instance (easy way) – Balance between them ● Expose both version under same instance – Adding complexity need to be avoided
- 33. Integration Make service simple for Consumers Use common communication protocol. Json for example.
- 34. Integration Hide internal implementation details Consumers should not know what is happening inside microservice.
- 36. Integration Interface the customer instead Consumers should not know what is happening inside microservice.
- 38. Orchestration and Choreography ● For example When some event happen we need to: 1) Send confirmation email 2) Send order from warehouse 3) Update finance department ● This can be done on two ways.
- 39. Orchestration ● Synchronous tasks execution ● One microservice delegate execution ● If “mastermind” service fails, all process stops ● Its slow ● Easier to guarantee consistency
- 40. Choreography ● Asynchronous tasks execution ● Every microservice is responsible for his job ● Its faster because all executions are parallel ● If some microservice fails others will complete ● Additional retry mechanisms
- 41. Microservices monitoring Why we need it?
- 42. Microservices monitoring ● Single service, Single Server Nagios is your friend
- 43. Microservices monitoring ● Single service, Multiple Servers Nagios + Logstash for logs aggregation
- 44. Microservices monitoring ● Multiple services, Multiple Servers Nagios + Logstash + Kibana for visual monitoring
- 45. Metrics can help a lot ● What hardware we need How much resources we need for one service instance to run ● Do we need new host If old one cannot provide us with enough power ● When we need to scale Scale only in peak times ● How much we need to scale Scale just enough to serve clients
- 46. Tools ● Graphite, Kibana, Varnish
- 47. System security
- 49. Service to service Authentication ● Allow everything inside perimeter If attacker penetrate the security, all services are vulnerable ● HTTP(S) basic protocol between services. Communication between services also need to be secured. ● Client certificates Hard to manage, good data encryption ● API Keys Shared public key between ● HMAC Guaranties integrity of request
- 50. Database protection ● Encrypt database data Encrypted data is useless for attacker ● Some database offer integrated encryption Encrypt sensitive data in database ● AES, DSC Good algorithms to use
- 51. Other protection inside perimeter ● Firewall Block suspicious requests ● Intrusion detection Monitor for suspicious activity ● Network segregation Separate sensitive data in separate network ● Operating system Apply security Patch regularly
- 53. This topic is huge, but this is all for now. Any questions?