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
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
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
Partner Zones AWS Cloud
by AWS Developer Relations
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
Partner Zones
AWS Cloud
by AWS Developer Relations

Trending

  • Cypress Tutorial: A Comprehensive Guide With Examples and Best Practices
  • Testing Applications With JPA Buddy and Testcontainers
  • Fun Is the Glue That Makes Everything Stick, Also the OCP
  • Measuring Service Performance: The Whys and Hows
  1. DZone
  2. Software Design and Architecture
  3. Microservices
  4. The Cost of Bad Software Architecture

The Cost of Bad Software Architecture

Is your architecture and infrastructure costing you money? Let's look at a quick example.

David Karapetyan user avatar by
David Karapetyan
·
Dec. 18, 18 · Opinion
Like (2)
Save
Tweet
Share
7.01K Views

Join the DZone community and get the full member experience.

Join For Free

Let me know if this sounds familiar. You work at a software company that uses a 3/3.5 tier architecture. There are frontend servers, backend servers, some batch work servers, and a database or two. If it doesn't sound familiar then maybe you have never worked with web application but that's the predominant architecture at most web shops. In fact, even with all the microservice/DevOps/container/serverless hype, no one has managed to change that 3/3.5 tier architecture. There is always a frontend, there is always a backend, there is always a database. The only differences are in the domain logic and implementation details like which language is used for the backend components and which database is used to hold the data. Let's now get into some more concrete but still abstract details because I promise there is a point at the end of this.

Let's say you have 10 frontend servers and 10 backend servers (we'll ignore the database and any other details for the time being). Let's also suppose that like every other place the traffic patterns are periodic so that those 20 servers are for handling peak load instead of average load. The average load across the servers is 50% (even this is a stretch and the real number is probably close to 20% because that's the average I've seen at most places). This means every other server is essentially idling so the average number of servers is actually 5 for the frontend and 5 for the backend. In this imaginary but really non-imaginary configuration, we are paying for 10 extra servers 24 hours a day 7 days a week. That's a concrete number that any CTO and engineer should be able to understand. That's literally real money being wasted every day because for whatever reason the architecture precludes automatically scaling things up and down.

The sensible engineering solution in the above scenario is to figure out the blockers for reducing the server count and work on removing those obstructions but the reality is that most engineering organizations will not bother with changing the status quo. They won't bother with fixing the architecture because changing the status quo is painful. It isn't painful in terms of engineering hours. It is painful in terms of retooling and rethinking required to reimagine the architecture so most engineering organizations will just continuously eat the cost of those 10 extra servers.

My perspective is not unique but there doesn't seem to be much critical analysis on this issue. The only thing I could find was " Why bad software architecture is easy to monetize" that uses housing as an analogy and outlines why there is inherent interest from one side of the market to make bad software and why the other side keeps falling for the trick.

Software architecture

Published at DZone with permission of David Karapetyan, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Cypress Tutorial: A Comprehensive Guide With Examples and Best Practices
  • Testing Applications With JPA Buddy and Testcontainers
  • Fun Is the Glue That Makes Everything Stick, Also the OCP
  • Measuring Service Performance: The Whys and Hows

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

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

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: