DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Related

  • Microservices vs. Monolith at a Startup: Making the Choice
  • Monolithic First
  • Transitioning from Monolith to Microservices
  • Microservices Governance and API Management

Trending

  • Enhancing Business Decision-Making Through Advanced Data Visualization Techniques
  • Advancing Your Software Engineering Career in 2025
  • How Kubernetes Cluster Sizing Affects Performance and Cost Efficiency in Cloud Deployments
  • Implementing Explainable AI in CRM Using Stream Processing
  1. DZone
  2. Data Engineering
  3. Data
  4. Layered Architecture in Microservices

Layered Architecture in Microservices

This is the first in a series on software architectures, focusing today on layers in microservices and how the architecture is evolving.

By 
Gratus Devanesan user avatar
Gratus Devanesan
·
Jul. 13, 18 · Tutorial
Likes (7)
Comment
Save
Tweet
Share
45.0K Views

Join the DZone community and get the full member experience.

Join For Free

As the name suggests, this architectural style focuses on layering. Layering provides abstraction and separation of concerns. Often different layers run on separate hardware and are individually protected ensuring only a specific neighboring layer has access.

What Is Layering?

Usually, the layering is driven by two factors. Technical and business capabilities and organizational structure - often these can be somewhat intertwined.

The UI Layer, for example, would often be driven by security and usability concerns. On the other hand, the Persistence Layer would be driven by data access, data security, and privacy concerns. By separating these concerns teams can ensure consistency and focus on their specific work. Developers working on the UI Layer don't need to worry about privacy or data security as the Persistence Layer will ensure that data stored is secured, potentially encrypted, and that data access is controlled. Similarly, developers at the Persistence Layer don't need to worry about how data is being displayed, how long text is handled, etc. Teams can become focused and achieve mastery at the layer that they are developing and maintaining.

Additionally, each layer has its own access control. This provides additional safeguards. Only the UI layer would traditionally be exposed to the internet - all underlying layers would be open only to layers above it. This ensures that there is a small attack surface.

Often these layers also match the business functions of teams. A database team might maintain the database layer, ensuring servers are optimized and patched. A digital design team, or even a third party agency, may be maintaining the UI layer.

Advantages

The utopia of Layered Architecture is that one day we can swap out an Oracle DB with SQL Server and we would only need to only modify the Persistence Layer. All other layers will remain as is and will not even have to be tested after the Persistence Layer has been thoroughly vetted.

In reality, nobody is going to swap out a database, primarily because a production database has sensitive information that nobody wants to risk losing during a migration attempt. Validating that the data migration was successful is equally painful and nobody's idea of a desirable project.

It provides some cohesion in terms of team capabilities and clarities in terms of responsibilities. Presentation Layer folks may be highly skilled in Javascript and CSS and live confidently that nobody will ask them to performance tune a SQL query.

Security is heightened by a Layered Architecture. The Persistence Layer would typically be closed to the world and only open to the Business Logic Layer and the database itself. A hacker coming in through the UI Layer would have to hack multiple independent systems to finally penetrate to somewhere worth hacking into. Obviously, this may not always happen as organizations may get sloppy and be weak with the security of inter-layer communication.

Disadvantages

Layered architectures introduce technological independence but inadvertently end up creating logical coupling across distributed environments.

A UI Layer may capture a profile change, e.g. a user updated their home address; this home address needs to travel through several layers, unmodified, to the Persistence Layer to finally be stored in a database. If for some reason, this didn't work, debugging will be challenging as we have to follow the data through several layers. The UI Layer can only talk to the layer directly below it (or in theory the layer directly above it). Any change within any of the intervening layers may have triggered the address to be lost. As a result, layers become strongly coupled in terms of the API they can expose and the modifications they can make to their codebase.

There is an option to open up layers, but as Layered Architectures evolve teams adjust to reduce the need to modify many layers. They think in patterns that allow them to minimize changing more than one layer, essentially pigeonholing the architecture into a single corner. Developers may find that they don't want to edit the UI Layer and the Aggregation Layer as that may require testing and debugging of two layers including the network connection between them. Slowly, Layers become manipulated and drift into all-purpose zones, and may even start resembling the big ball of mud.

Layered architectures can succeed but need strong governance to ensure that feature creep doesn't leave the layers porous.

Microservices and Layered Architectures

When working on a Microservice Architecture, layers may appear in two different ways — one good, one not so good.

1. Release Velocity and Technology

An Engagement Layer may be separate from a Business Capabilities Layer. Architects and developers may be separate from a Business Capabilities Layer. Architects and developers may chose easier to code and faster to modify solutions like NodeJS and MongoDB for engagement focused content that may change frequently and needs to keep up with user demand. On the other hand, core business capabilities will not change overnight and architects may choose more robust enterprise type technology stacks like Oracle and Java. Over time a distinct separation will appear and it would be advisable to introduce a gateway between the two to further ensure independence. This is a good thing and an aspect of evolutionary architecture.

2. Conway's Law

Organizations design systems that reflect the communication structure of the organization. Often large enterprises may have teams with directors and VPs that feel they own a specific business capability. This maybe good - they want to ensure reliability to many clients that rely on their services, or bad - they simply want to push their weight around and stay relevant. Either way, teams will adjust and treat other team's business capabilities as black boxes and build abstractions around them. What emerges is a Layered Architecture of sets of Microservices consisting of specific team's business capabilities.

This hampers innovation as consuming teams are not aware of the actual potential inside another layer. Teams in the same organization end up having to innovate in isolation.

Conclusion

If you are still maintaining a monolith, you may be sitting on an n-tier Layered Architecture. If you are swimming (or drowning) in a microservice ocean you may see layers emerge. Layers can be good if you maintain them properly — they need strong governance.

Architecture microservice teams Data security

Published at DZone with permission of Gratus Devanesan, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Microservices vs. Monolith at a Startup: Making the Choice
  • Monolithic First
  • Transitioning from Monolith to Microservices
  • Microservices Governance and API Management

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!