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

2. Who Am I? Attila Balogh-Biró Senior developer / Architect
Instructor (Java SE, Java EE, Spring framework)
Skype: attila.balogh86
Mail:

3. Agenda Architectural styles and patterns Layered application
Monolithic design
Microservice style
Spring Boot demo
Conclusion

4. Architectural styles and patterns
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
The comparison between software design and architecture was first drawn in the late 1960s
but the term software architecture became prevalent only in the beginning of the 1990s
Earlier problems of complexity were solved by developers by choosing the right data structures, developing algorithms, and by applying the concept of separation of concerns

5. Architectural styles and patterns
Client-server
Component-based
Layered (or Multilayered architecture)
Monolithic application
Peer-to-peer (P2P)
Service-oriented
Microservices architecture
Shared nothing architecture

6. 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

7. Layered architecture CONT.

8. Benefits Separation of concerns among components
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
Components within
a specific layer deal only with logic that pertains to that layer. For
example, components in the presentation layer deal only with presentation
logic, whereas components residing in the business layer
deal only with business logic. This type of component classification
makes it easy to build effective roles and responsibility models into
your architecture, and also makes it easy to develop, test, govern,
and maintain applications using this architecture pattern due to
well-defined component interfaces and limited component scope.

9. Key concepts - CLOSED LAYERS
Key concepts - CLOSED LAYERS
This is a very important concept in the layered
architecture pattern. A closed layer means that as a request
moves from layer to layer, it must go through the layer right below it
to get to the next layer below that one. For example, a request originating
from the presentation layer must first go through the business
layer and then to the persistence layer before finally hitting the
database layer.
So why not allow the presentation layer direct access to either the
persistence layer or database layer?

10. Key concepts – ISOLATION OF LAYERS
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
- If you allow the presentation layer direct
access to the persistence layer, then changes made to SQL within the
Key Concepts | 3
persistence layer would impact both the business layer and the presentation
layer, thereby producing a very tightly coupled application

11. Pattern Example

12. Considerations Solid general-purpose pattern, good start point
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
sinkhole anti-pattern. This anti-pattern describes the situation where
requests flow through multiple layers of the architecture as simple
pass-through processing with little or no logic performed within
each layer. For example, assume the presentation layer responds to a
request from the user to retrieve customer data. The presentation
layer passes the request to the business layer, which simply passes
the request to the persistence layer, which then makes a simple SQL
call to the database layer to retrieve the customer data. The data is
then passed all the way back up the stack with no additional processing
or logic to aggregate, calculate, or transform the data.

13. Pattern Analysis Overall agility  Low Difficulty of deployment  High
Pattern Analysis
Overall agility  Low
Difficulty of deployment  High
Testability  High
Performance  Low
Scalability  Low
Difficulty of development  Low
- Overall agility is the ability to respond quickly to a
constantly changing environment. While change can be isolated
through the layers of isolation feature of this pattern, it is still
cumbersome and time-consuming to make changes in this
architecture pattern because of the monolithic nature of most
implementations as well as the tight coupling of components
usually found with this pattern
The following table contains a rating and analysis of the common
architecture characteristics for the layered architecture pattern. The
rating for each characteristic is based on the natural tendency
for that characteristic as a capability based on a typical implementation
of the pattern, as well as what the pattern is generally known
for. For a side-by-side comparison of how this pattern relates to
other patterns in this report, please refer to Appendix A at the end
of this report.
Overall agility
Rating: Low
Analysis: Overall agility is the ability to respond quickly to a
usually found with this pattern.
Ease of deployment
Analysis: Depending on how you implement this pattern,
deployment can become an issue, particularly for larger applications.
One small change to a component can require a
redeployment of the entire application (or a large portion of the
application), resulting in deployments that need to be planned,
scheduled, and executed during off-hours or on weekends.
As such, this pattern does not easily lend itself toward a continuous
delivery pipeline, further reducing the overall rating for
deployment.
8 | Chapter 1: Layered Architecture
Testability
Rating: High
Analysis: Because components belong to specific layers in the
architecture, other layers can be mocked or stubbed, making
this pattern is relatively easy to test. A developer can mock a
presentation component or screen to isolate testing within a
business component, as well as mock the business layer to test
certain screen functionality.
Performance
Analysis: While it is true some layered architectures can perform
well, the pattern does not lend itself to high-performance
applications due to the inefficiencies of having to go through
multiple layers of the architecture to fulfill a business request.
Scalability
Analysis: Because of the trend toward tightly coupled and monolithic
implementations of this pattern, applications build using
this architecture pattern are generally difficult to scale. You can
scale a layered architecture by splitting the layers into separate
physical deployments or replicating the entire application into
multiple nodes, but overall the granularity is too broad, making
it expensive to scale.
Ease of development
Analysis: Ease of development gets a relatively high score,
mostly because this pattern is so well known and is not overly
complex to implement. Because most companies develop applications
by separating skill sets by layers (presentation, business,
database), this pattern becomes a natural choice for most
business-application development. The connection between a
company’s communication and organization structure and the
way it develops software is outlined is what is called Conway’s
law. You can Google “Conway’s law" to get more information
about this fascinating correlation.

14. 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

15. Pattern Analysis Overall agility  Low Difficulty of deployment  High
Testability  High
Performance  Low
Scalability  Low
Difficulty of development  Low

16.
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

17. SERVICE components 2016-05-17 Rather than think about services
within a microservices architecture, it is better to think about
service components, which can vary in granularity from a single
module to a large portion of the application. Service components
contain one or more modules (e.g., Java classes) that represent either 27
a single-purpose function (e.g., providing the weather for a specific
city or town) or an independent portion of a large business application
(e.g., stock trade placement or determining auto-insurance
rates). Designing the right level of service component granularity is
one of the biggest challenges within a microservices architecture.
This challenge is discussed in more detail in the following servicecomponent
orchestration subsection

18. 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

19. 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.”

20.
Conway's Law
When l looking to split a large application into parts, often management focuses on the technology layer, leading to UI teams, server-side logic teams, and database teams. When teams are separated along these lines, even simple changes can lead to a cross-team project taking time and budgetary approval. A smart team will optimise around this and plump for the lesser of two evils - just force the logic into whichever application they have access to. Logic everywhere in other words. This is an example of Conway's Law[5]in action.
The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interfaces structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult. Conway's law was intended as a valid sociological observation, although sometimes it's taken in a humorous context.

21. PATTERN TOPOLOGIES API REST-based topology
Application REST-based topology
Centralized messaging topology

22. API REST-based topology
API REST-based topology
The API REST-based topology is useful for websites that expose
small, self-contained individual services through some sort of
API (application programming interface). This topology, which is
illustrated in Figure 4-2, consists of very fine-grained service components
(hence the name microservices) that contain one or two
modules that perform specific business functions independent from
the rest of the services. In this topology, these fine-grained service
components are typically accessed using a REST-based interface
implemented through a separately deployed web-based API layer

23. Application REST-based topology
Application REST-based topology
The application REST-based topology differs from the API RESTbased
approach in that client requests are received through traditional
web-based or fat-client business application screens rather
than through a simple API layer. As illustrated in Figure 4-3, the
user-interface layer of the application is deployed as a separate web
application that remotely accesses separately deployed service components
(business functionality) through simple REST-based interfaces.
The service components in this topology differ from those in
the API-REST-based topology in that these service components tend
to be larger, more coarse-grained, and represent a small portion of
the overall business application rather than fine-grained, singleaction
services. This topology is common for small to medium-sized
business applications that have a relatively low degree of complexity

24. Centralized messaging topology
Centralized messaging topology
This is similar to the previous application RESTbased
topology except that instead of using REST for remote access,
this topology uses a lightweight centralized message broker (e.g.,
ActiveMQ, HornetQ, etc.). It is vitally important when looking at
this topology not to confuse it with the service-oriented architecture
pattern or consider it “SOA-Lite." The lightweight message broker
found in this topology does not perform any orchestration, transformation,
or complex routing; rather, it is just a lightweight transport
to access remote service components.
The benefits of this topology over the simple
REST-based topology discussed previously are advanced queuing
mechanisms, asynchronous messaging, monitoring, error handling,
and better overall load balancing and scalability. The single point of
failure and architectural bottleneck issues usually associated with a
centralized broker are addressed through broker clustering and
broker federation (splitting a single broker instance into multiple
broker instances to divide the message throughput load based on
functional areas of the system).

25. 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

26. Pattern Analysis Overall agility  High Difficulty of deployment  Low
Pattern Analysis
Overall agility  High
Difficulty of deployment  Low
Testability  High
Performance  Low
Scalability  High
Difficulty of development  Low
Overall agility
Rating: High
Analysis: Overall agility is the ability to respond quickly to a
constantly changing environment. Due to the notion of separately
deployed units, change is generally isolated to individual
service components, which allows for fast and easy deployment.
Also, applications build using this pattern tend to be very
loosely coupled, which also helps facilitate change.
Ease of deployment
Analysis: Overall this pattern is relatively easy to deploy due to
the decoupled nature of the event-processor components. The
broker topology tends to be easier to deploy than the mediator
topology, primarily because the event-mediator component is
somewhat tightly coupled to the event processors: a change in
an event processor component might also require a change in
34 | Chapter 4: Microservices Architecture Pattern
the event mediator, requiring both to be deployed for any
given change.
Testability
Analysis: Due to the separation and isolation of business functionality
into independent applications, testing can be scoped,
allowing for more targeted testing efforts. Regression testing for
a particular service component is much easier and more feasible
than regression testing for an entire monolithic application.
Also, since the service components in this pattern are loosely
coupled, there is much less of a chance from a development perspective
of making a change that breaks another part of the
application, easing the testing burden of having to test the entire
application for one small change.
Performance
Rating: Low
Analysis: While you can create applications implemented from
this pattern that perform very well, overall this pattern does not
naturally lend itself to high-performance applications due to the
distributed nature of the microservices architecture pattern.
Scalability
Analysis: Because the application is split into separately
deployed units, each service component can be individually
scaled, allowing for fine-tuned scaling of the application. For
example, the admin area of a stock-trading application may not
need to scale due to the low user volumes for that functionality,
but the trade-placement service component may need to scale
due to the high throughput needed by most trading applications
for this functionality.
Ease of development
Analysis: Because functionality is isolated into separate and distinct
service components, development becomes easier due to
the smaller and isolated scope. There is much less chance a
developer will make a change in one service component that
would affect other service components, thereby reducing the
coordination needed among developers or development teams.

27. Monolithic vs microservice

28. Important viewpoints Deployability Performance Availability
Important viewpoints
Deployability
Performance
Availability
Modifiability
Testability
Management
Memory use
Pros:
Deployability: more agility to roll out new versions of a service due to shorter build+test+deploy cycles. Also, flexibility to employ service-specific security, replication, persistence, and monitoring configurations.
Reliability: a microservice fault affects that microservice alone and its consumers, whereas in the monolithic model a service fault may bring down the entire monolith.
Availability: rolling out a new version of a microservice requires little downtime, whereas rolling out a new version of a service in the monolith requires a typically slower restart of the entire monolith.
Scalability: each microservice can be scaled independently using pools, clusters, grids. The deployment characteristics make microservices a great match for the elasticity of the cloud.
Modifiability: more flexibility to use new frameworks, libraries, datasources, and other resources. Also, microservices are loosely-coupled, modular components only accessible via their contracts, and hence less prone to turn into a big ball of mud. Dynamic discovery and binding via a registry (e.g., Apache ZooKeeper, Netflix Eureka) is sometimes used for location transparency.
Management: the application development effort is divided across teams that are smaller and work more independently.
Design autonomy: the team has freedom to employ different technologies, frameworks, and patterns to design and implement each microservice, and can change and redeploy each microservice independently
Cont:
Deployability: deployment becomes more complex with many jobs, scripts, transfer areas, and config files for deployment.
Performance: services more likely need to communicate over the network, whereas services within the monolith may benefit from local calls. Also, if the microservice uses dynamic discovery, the registry lookup is a performance overhead.
Availability: if you use a registry for dynamic discovery, unavailability of the registry may compromise the consumer-service interaction.
Modifiability: changes to the contract are more likely to impact consumers deployed elsewhere, whereas in the monolithic model consumers are more likely to be within the monolith and will be rolled out in lockstep with the service. Also, mechanisms to improve autonomy, such as eventual consistency and asynchronous calls, add complexity to microservices.
Testability: automated tests are harder to setup and run because they may span different microservices on different runtime environments.
Management: the application operation effort increases because there are more runtime components, log files, and point-to-point interactions to oversee.
Memory use: several classes and libraries are often replicated in each microservice bundle and the overall memory footprint increases.
Runtime autonomy: in the monolith the overall business logic is collocated. With microservices the logic is spread across microservices. So, all else being equal, it's more likely that a microservice will interact with other microservices over the network--that interaction decreases autonomy. If the interaction between microservices involves changing data, the need for a transactional boundary further compromises autonomy. The good news is that to avoid runtime autonomy issues, we can employ techniques such as eventual consistency, event-driven architecture, CQRS, cache (data replication), and aligning microservices with DDD bounded contexts. These techniques are not inherent to microservices, but have been suggested by virtually every author I've read.

29. 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

30. 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

31. dependency injection and integrations
DI is the heartbeat of Spring framework
@Component
Easy to integrate third party components

32. Central configuration
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)
See, I told you it was that easy! a Spring Cloud annotation that takes care of everything you need to build a configuration server. The only thing left is to specify the location of where your config is going to be taken from, such as a file or a git repository, or a database. Straight away we have the central most piece of our infrastructure ready. Now other services in the deployment will initialize themselves, come to this Configuration Server and obtain the rest of the configuration. This is essential, as now you’ll be able to configure them by type, scale automatically and so on.

33. Central configuration
The only thing left is to specify the location of where your config is going to be taken from
git
file
database

34. 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

35. Service discovery

36. Spring boot as Microservice platform

37. Conclusion

38.
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
The reason the third tenet may not hold for microservices is that one of the characteristics of microservices is that they are generally exposed over a RESTful API, which, one could argue, does not expose contract and schema at all (over and above the regular http verbage), as we see from Fowler:
a suite of small services, each... communicating with lightweight mechanisms, often an HTTP resource API
Another way in which a microservices style deviates from SOA is with this prescription:
These services are... independently deployable by fully automated deployment machinery
T1 : Services interact by sending messages across boundaries. These boundaries are formal and explicit. No assumptions are made about what is behind boundaries, and this preserves flexibility in how services are implemented and deployed.
T2: Services are not subservient to other code: a service reacts to a message – how that message was created and what will happen to any response the service creates is immaterial to the action that this service will take.
T3: Only messages pass from service to service, code does not. These messages are not random but a sequence of one or more that have been agreed upon.
T4: A service must be able to express in a standard representation of policy what it does and how clients should communicate with it. Services don’t just blindly access each other: they need to determine areas of compatibility and agree on how they will interact. Every service provides a policy – a machine-readable description of its capabilities and requirements.

39.
Microservice VS SOA

40. DEMO