Comparison of different architecture styles Attila BaloghBir 2016

Comparison of different architecture styles Attila Balogh-Biró 2016 Monolithic, Layered, Microservice style

Who Am I? › Attila Balogh-Biró › Senior developer / Architect › Instructor (Java SE, Java EE, Spring framework) › Skype: attila. balogh 86 › Mail: abaloghbiro@protonmail. com Ericsson Internal | 2016 -05 -17 | Page 2

Agenda › Architectural styles and patterns › Layered application › Monolithic design › Microservice style › Spring Boot demo › Conclusion Ericsson Internal | 2016 -05 -17 | Page 3

Architectural styles and patterns › An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context › Architectural patterns are similar to software design patterns but have a broader scope – computer hardware performance limitations – high availability – minimization of a business risk Ericsson Internal | 2016 -05 -17 | Page 4

Architectural styles and patterns › Client-server › Component-based › Layered (or Multilayered architecture) › Monolithic application › Peer-to-peer (P 2 P) › Service-oriented › Microservices architecture › Shared nothing architecture Ericsson Internal | 2016 -05 -17 | Page 5

Layered architecture › The most common architecture pattern is the layered architecture pattern › Components within the layered architecture pattern are organized into horizontal layers › Each layer performing a specific role within the application › Each layer in the architecture forms an abstraction › Usually will be created the following layers – Presentation – Business – Persistence – Database Ericsson Internal | 2016 -05 -17 | Page 6

Layered architecture CONT. Ericsson Internal | 2016 -05 -17 | Page 7

Benefits › Separation of concerns among components – Components within a specific layer deal only with logic that pertains to that layer › Well-defined component interfaces and limited component scopes › Makes it easy to develop, test, govern, and maintain applications Ericsson Internal | 2016 -05 -17 | Page 8

Key concepts - CLOSED LAYERS Ericsson Internal | 2016 -05 -17 | Page 9

Key concepts – ISOLATION OF LAYERS › Each layer is independent of the other layers › Changes made in one layer of the architecture generally don’t impact or affect components in other layers › A layer having little or no knowledge of the inner workings of other layers in the architecture Ericsson Internal | 2016 -05 -17 | Page 10

Pattern Example Ericsson Internal | 2016 -05 -17 | Page 11

Considerations › Solid general-purpose pattern, good start point › Sinkhole anti-pattern – analyze the percentage of requests that fall into this category – 80 -20 rule is usually a good practice to follow to determine whether or not you are experiencing the architecture sinkhole anti-pattern › The tend to lend itself toward monolithic applications Ericsson Internal | 2016 -05 -17 | Page 12

Pattern Analysis › Overall agility Low › Difficulty of deployment High › Testability High › Performance Low › Scalability Low › Difficulty of development Low Ericsson Internal | 2016 -05 -17 | Page 13

Monolithic style › The term monolith has been in use by the Unix community for some time. It appears in The Art of Unix Programming › Monolithic application built as a single unit › Monolithic server is a natural way to approach building such a system › A monolithic application is self-contained, and independent from other computing applications › All your logic for handling a request runs in a single process Ericsson Internal | 2016 -05 -17 | Page 14

Pattern Analysis › Overall agility Low › Difficulty of deployment High › Testability High › Performance Low › Scalability Low › Difficulty of development Low Ericsson Internal | 2016 -05 -17 | Page 15

Microservice style › The term "microservice" was discussed at a workshop of software architects near Venice in May, 2011 › Is an approach to developing a single application as a suite of small service components (not services) › This components are separately deployable units › Each running in its own process › Communicating with lightweight mechanisms, often an HTTP resource API Ericsson Internal | 2016 -05 -17 | Page 16

SERVICE components Ericsson Internal | 2016 -05 -17 | Page 17

common characteristics › 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 Ericsson Internal | 2016 -05 -17 | Page 18

Conway's Law “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. ” Ericsson Internal | 2016 -05 -17 | Page 19

Conway's Law Ericsson Internal | 2016 -05 -17 | Page 20

PATTERN TOPOLOGIES › API REST-based topology › Application REST-based topology › Centralized messaging topology Ericsson Internal | 2016 -05 -17 | Page 21

API REST-based topology Ericsson Internal | 2016 -05 -17 | Page 22

Application RESTbased topology Ericsson Internal | 2016 -05 -17 | Page 23

Centralized messaging topology Ericsson Internal | 2016 -05 -17 | Page 24

Considerations › This pattern solves many of the common issues found in both monolithic applications as well as service oriented architectures › It is an important advantage that provides the capability to do real-time production deployments › The microservices architecture pattern is a distributed architecture Ericsson Internal | 2016 -05 -17 | Page 25

Pattern Analysis › Overall agility High › Difficulty of deployment Low › Testability High › Performance Low › Scalability High › Difficulty of development Low Ericsson Internal | 2016 -05 -17 | Page 26

Monolithic vs microservice Ericsson Internal | 2016 -05 -17 | Page 27

Important viewpoints › Deployability › Performance › Availability › Modifiability › Testability › Management › Memory use Ericsson Internal | 2016 -05 -17 | Page 28

Spring boot as Microservice platform › Spring framework was the de-facto framework choice for web applications › Spring has established its own ecosystem › Spring not just a framework, the focal point is the integration › Simple of application development – specify the correct dependency – initialize a Spring component – autowire library beans Ericsson Internal | 2016 -05 -17 | Page 29

Spring boot as Microservice platform › Important built in services for microservice development – dependency injection and integrations – easy central configuration service creation – straightforward service discovery registry › Spring Cloud addresses boilerplate patterns for distributed computing in the Spring programming model – Environment Provisioning – On-Demand Scaling – Failover/Resilience – Routing/Load Balancing Ericsson Internal | 2016 -05 -17 | Page 30

dependency injection and integrations › DI is the heartbeat of Spring framework – @Component › Easy to integrate third party components Ericsson Internal | 2016 -05 -17 | Page 31

Central configuration › We have to ensure that all the microservices get configured properly › This means that they should ideally grab their configuration from another web-service (central configuration hub) Ericsson Internal | 2016 -05 -17 | Page 32

Central configuration › The only thing left is to specify the location of where your config is going to be taken from – git – file – database Ericsson Internal | 2016 -05 -17 | Page 33

Service discovery › How know about each other our services? › The solution is a service registry › As the registry is a microservice itself, it allows other services to register themselves as a service of a particular type › The client service can then query the URLs for all the dependencies it needs and interact with them Ericsson Internal | 2016 -05 -17 | Page 34

Service discovery Ericsson Internal | 2016 -05 -17 | Page 35

Spring boot as Microservice platform Ericsson Internal | 2016 -05 -17 | Page 36

Conclusion Ericsson Internal | 2016 -05 -17 | Page 37

Microservice VS SOA › Microservices architectural style as a specialization of SOA › SOA tenets: – Boundaries are explicit – Services are autonomous – Services share schema and contract, not class – Service compatibility is based on policy Ericsson Internal | 2016 -05 -17 | Page 38

Microservice VS SOA Ericsson Internal | 2016 -05 -17 | Page 39

DEMO Ericsson Internal | 2016 -05 -17 | Page 40

abaloghbiro@protonmail. com