Devops Italia - Software Architecture from monoliths to microservices

Applying Microservices patterns could be useful even in big companies, with big teams and lots of monoliths. How can we cope with the coexistence of several architectural styles in a big organization? Is it possible to let the monoliths coexist with SOA, microservices and DevOps? In our opinion, yes.

Transcript

1. Software architecture from monoliths to microservices Filippo Bosi Bologna 09-03-2018 @filippobosi fbosi@imolainformatica.it Luca Acquaviva @lacquaviva lacquaviva@imolainformatica.it
2. Unicorns have aggressive approaches to microservices architecture! 2 Real (transactional, financial…) world is different, multiple architectural styles need to coexist without requiring risky “Big Bang” refactorings Frederic J. Brown / AFP / Getty
3. • Software architecture drivers • The evolution of Software Architecture • Software Monolith • Software Monolith issues • Layered System • Layered System issues • Service Oriented Architecture 3 Coexistence of different architectural styles
4. Software architecture drivers 4 Digital transformation in an enterprise requires fast creation of innovative services for the customers and, thus, introduces new requirements Reduced time to market More frequent releases Fast development cycles Continuous Innovation
5. The evolution of software architecture 5 In the last 20 years these requirements drove the evolution of the software architecture from Monolith to Microservices 1990’s 2005 SOA First services are business function exposed as a «web service» ESB as an integration and decoupling layer 2010’s Microservices SOA Specialization, same base concept Monolith Refactoring («vertical slice») New technological and organizational model Software Monolith Vertical silos Client server architecture Point2Point integration (aka spaghetti integration) 2000’s Layered Monolith 3 layer application Layered architecture Point2Point integration
6. Software Monolith Benefits • Simple mental model for developers • One unit of access for coding, building, and deploying • Simple scaling model for operations • Just run multiple copies behind a load balancer 6 One codebase One build and deployment unit One technology stack (Linux, JVM, Tomcat, Libraries)
7. Software Monolith issues • Huge and intimidating codebase for developers • Development tools get overburdened • refactorings take minutes • builds take hours • testing in continuous integration takes days • Scaling is limited • Running a copy of the whole system is resource-intense • It doesn’t scale with the data volume out-of-the-box • Deployment frequency is limited • Re-deploying means halting the whole system • Re-deployments will fail and increase the perceived risk of deployment 7 One codebase One build and deployment unit One technology stack (Linux, JVM, Tomcat, Libraries)
8. Layered System 8 • At most one technology stack per layer • Presentation: Linux, JVM, Tomcat, Libs, EJB/WS client, JavaScript • Logic: Linux, JVM, J2EE container, Java libs • Data Access: Linux, JVM, EJB, JPA, J2EE container, stored procedures Benefits • Simple mental model, simple dependencies • Simple deployment and scaling model A layered system decomposes a monolith into layers Usually: presentation, business logic, data access
9. Layered System Issues 9 • Still huge codebases (one per layer) ...with the same impact on development, building, and deployment • Scaling works better than Monolith, but still limited • Staff growth is limited: roughly speaking, one team per layer works well • Developers become specialists on their layer • Communication between teams is biased by layer experience (or lack thereof) A layered system decomposes a monolith into layers Usually: presentation, business logic, data access
10. Service Oriented Architecture Principles • Standardized Service Contract • Loose Coupling • Service Abstraction • Service Autonomy • Service Reusability Benefits • Enables the horizontal integration across application with heterogeneous software architecture (Monolith, Layered) • Decouples consumer from provider • Service Statelessness • Service Discoverability • Service Composability • Service Interoperability Service Oriented Architecture integrates applications horizontally and in a uniform way 10
11. • Three Aspects of a software architecture • What’s wrong with SOA? • Microservices • SOA and MSA challenges 11 Principles of a good architecture design
12. Three aspects of a Software Architecture There are three basic aspects to be considered during the design of a software architecture 12 Organizational Architectural Technical 12
13. What’s usually wrong with SOA? 13 Often focus is only on the Technical aspects leaving out Most SOA implementations are created starting from a software monolith and a layered application that exposes Web Service If you don’t address all these requirements in implementing SOA service layer, you will end up with the same issues you had with Monolithic architecture Architectural - Loose Coupling - Service Layer is a new required layer that decouples consumers from providers Organisational - Governance - Service lifecycle Management
14. Microservices 14 Loosely coupled Service Oriented Architecture with boundary context • Micro, a microservice must be manageable by a single development team (1/2 pizza team, 5/9 persons) • Functional system decomposition means vertical slicing • Independent deployment no shared state and inter-process communication • Sharing nothing architecture means independent code base On the logical level, microservice architectures are defined by a functional system decomposition into manageable and independently deployable components Microservices Architecture by Source A. Schroeder
15. Microservices trade-off Benefits • Independent deployement • Modularity • Polyglot independent techonology stack 15 Many development teams have found the microservices architectural style to be a superior approach to a monolithic architecture. But other teams have found them to be a productivity-sapping burden. Like any architectural style, microservices bring costs and benefits. Costs • Distribution • Eventual consistency • Increase of complexity M.Fowler MSA isn’t always the best solution To make a sensible choice you have to understand MSAs and apply them when requirements justify the increase of complexity.
16. What will be wrong with microservices in enterprise? A Netflix user won’t care (that much) if he’s forced to restart streaming a chapter of a film twice… On the other hand… An online banking user would care if his money transfer gets executed twice… or… Just imagine your ATM gives you money once but you’re not sure whether your checking account gets charged twice… 16 Most microservices implementations will be created starting from a blind technological point of view, without taking into account the side effects of applying implementation patterns that do not fit completely with the use cases
17. • Testing and monitoring the system ”as a whole” • Data consistency and transactions • Logging and tracing • Service Mesh: life without a centralized ESB 17 Microservices challenges in highly transactional syste
18. Testing and Monitoring the system «as a whole» 18 SERVICE VIRTUALIZATION It is necessary to find a way to "simulate" the external dependencies without having to inject any mock object. TEST AUTOMATION It is necessary to find a way to test in a consistent way an always evolving system APM, Monitoring, Analytics It is necessary to find a way to collect errors, performance problems and find root causes easily in a distributed fashion Challenge #1
19. Data consistency & transactions 19 A B C Monolith Maintaining data consistency is simple and transactional context is well defined SOA and MSA Maintaining strong consistency is extremely difficult for a distributed system, which means everyone has to manage eventual consistency distributed transaction (n.) any situation where a single event results in the mutation of two separate sources of data which cannot be committed atomically Challenge #2
20. Ensure data consistency 20 A B The messaging platform should ensure that the messages sent by the microservices are persisted Then they should be delivered at a later time if the receiver isn’t currently available Create idempotent operations Introduce message-driven approach including compensation Using messaging platform that support persistent queues
21. Logging and Tracing Logging and tracing are already relevant for SOA and become even more challenging in a MSA 21 Challenge #3 Understanding the behavior of an application and troubleshooting problems becomes more complex as application distribution grows exponentially
22. Centralized log management 22 Correlate logs and collect them in a centralized repository (e.g. ELK stack) Correlation ID, is a unique identifier UUID value that is attached to requests and messages and every log that allow reference to a particular transaction or event chain a b c
23. Distribuited Tracing Alternatives • Custom solutions e.g. library • Open Standard e.g. Opentracing • Infrastructural software solution (service mesh) Centralized Tracer • Zipkin • Hawkular • stagemonitor 23 Track information (e.g. start time, end time) about the requests and operations performed when handling requests in a centralized service, and show them as an aggregate on a transaction type basis
24. Dedicated software infrastructure layer for making service-to- service communication safe, fast, and reliable. buoyant.io Service mesh – a distributed friendly alternative to ESB • Service mesh add «infrastructural» behaviour to microservices no code or refactoring is required • Wrap service implementations with lightweight proxies • Utilizes – lightweight proxies deployed side-by-side or together with the services • Ensures – Consistent routing, Security, Resiliency and Monitoring 24 If you’re building a cloud native application, you probably need a service mesh Challenge #4
25. Service mesh technologies 25 Trace and Monitoring service Authorization and Authentication Routing Load balancing Service discovery Circuit breaker istio
26. Patchwork architectural style 26 Single Purpose (Channel) APIs API gateway Special Purpose APIs Presentation APIs Consumer APIs B2B APIs Sync/Async (ESB) Integrations ? A B C Cross cutting concerns Microservices Logging Tracing 26 Other «Legacy» Systems Layered Applications Monoliths Monitoring
27. So what… • You cannot avoid adopting a “patchwork” model • The adoption of an SOA helps. In an enterprise it is crucial to achieve governance and uniformity. • Microservices help balance the slowdown imposed by SOA • You cannot adopt new architectural styles without taking into account the three different aspects of an architecture • Technological • Organizational • Architectural • Microservices in a transactional enterprise should be adopted by respecting additional non-technological requirements 27 27
28. Grazie Questions? 28
29. www.twitter.com/imolinfo www.facebook.com/imolinfo www.linkedin.com/company/imola-informatica Imola Informatica S.P.A.· via Selice 66/a · Imola (BO) www.imolainformatica.it - blog.imolainformatica.it 29
30. Sources and Further Reading • http://martinfowler.com/articles/microservices.html • http://www.infoq.com/articles/microservices-intro • http://brandur.org/microservices • http://davidmorgantini.blogspot.de/2013/08/micro-services-what- are-micro-services.html • http://12factor.net/ • http://microservices.io/ • https://rclayton.silvrback.com/failing-at-microservices • http://www.activestate.com/blog/2014/09/microservices-and-paas- part-iii • http://highscalability.com/blog/2014/7/28/the-great-microservices- vs-monolithic-apps-twitter-melee.html 30