Ask HN: Books for Learning Software Architecture
I am a CTO (by virtue of being the founding engineer; straight out of college) at a 5-6 year old startup.
We have bootstrapped our way till here and are now looking for funding.
An investor asked me what our technical architecture was. I began to explain to him with a lot of hand waving. After a while he stopped me and told that there are several kinds of architecture like 2-tier, multi-tier, microservices etc. What kind was ours? I could not give him a satisfactory answer.
I realized that it might be helpful for me to understand these architectures and apply them in our context. Can you please recommend me some good books that might go into details of various kinds of architecture?
13 comments
[ 3.7 ms ] story [ 58.0 ms ] threadI'd highly recommend getting an O'Reilly membership. It gives you access to their entire catalog and you can just search whatever topic you're interested in and they'll let you read books on it.
In terms of free resources, I like [Quastor](http://www.quastor.org/). It's a newsletter that looks at all the big tech engineering blogs (Facebook Engineering, Uber Engineering, Lyft, etc.) and then sends a summary of the interesting ones published.
Access to the entire O'Reilly book library for $25 a month is a good deal.
If you're a bootstrapped unfunded startup most-likely it's built using simple and straight-forward software architecture, so learning advanced patterns will not help before you raised more funds and hired more developers.
Also, it seems that your real problem was passing a technical due diligence with investors, not learning advanced software architecture. I would suggest pairing with a consultant for one or more sessions and create a very short HLD (High-level Design) document describing your current architecture and design.
If you still want to learn SW architecture you can start from Martin Fowler's site:
https://martinfowler.com/architecture/
Quick version: https://en.wikipedia.org/wiki/Big_ball_of_mud
Source: https://en.wikipedia.org/wiki/Big_ball_of_mud
It's probably what your company has.
And would have been an honest answer to the potential investor -- they're not an actual investor until they invest.
Whether or not an honest answer to the potential investor would have been what your employer wanted from you is another matter.
Anyway, Wikipedia is a pretty good starting point for software architecture types.
Good luck.
In my personal application I was still using HTTP for almost everything except communicating with the browser, up until last year. I knew a little (very little) of how network communications work in the lower level from my part time info sec job more than a decade ago, so I had the life experience to know I could go further and do more than the clumsiness of HTTP. I didn't really know much about the internals of how websockets work (or even sockets/streams in general). At that point I was using a popular Node library to do all the socket management.
I made the decision to write my own websocket library to meet the specific needs of my application directly as a Node TLS stream interface. This took me about a month to figure out and I required coaching from somebody that was good with binary. I managed to figure it. Switching from HTTP to a socket based communication architecture and managing all network traffic from a single point in my application reduced my test automation time from about 45 seconds to about 7.5 seconds. In the past month I learned to cycle through my socket message queue using an event oriented approach on message drain as opposed to as fast as possible in the code to further reduce that test automation time down to 6.22 seconds. I knew there was a potential for improved execution performance, but not by that much. The purpose was only to liberate the application from the round trips imposed by HTTP instead of a one-way fire and forget approach.
This required a large investment in time to revision my communications architecture and going through the trials (repeated failures) in running a socket library of my own written from scratch. But now my application manages application layer communications faster than anything I have seen in the corporate world in my nearly 20 years of corporate software experience. I have learned architecture through constant refactoring and attempts to impose simplicity (don't repeat yourself principle).