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? [Software Architecture Patterns](https://learning.oreilly.com/library/view/software-architect...) by Mark Richards answers your exact questions - goes into multi-tier, microservices, event-driven, etc. I'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. O'Reilly is expensive Definitely worth it. If you google around you'll find a coupon code for 50% off. Access to the entire O'Reilly book library for $25 a month is a good deal. Access is included with a $100/year ACM membership (excludes a few non-book items). Alternatively, each year they've had a black friday/cyber monday deal for $200/year. They discontinued the ACM deal unfortunately Software Architecture is an interesting rabbit hole that can easily eat many years of your life, but I think you're asking the wrong questions. 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: Not MF please….he doesn’t code anymore To me, the Big Ball of Mud might be the most useful architecture to understand, because that is the architecture that usually gets built. Either sooner or later. 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. A previous thread: https://news.ycombinator.com/item?id=22202769 To improve performance of live updates I refactored my application around streams on persistent sockets. It allows for bidirectional communication of micro services from single points of management within the application in a non blocking way. It’s faster than having to deal with protobuf (gRPC) and still allows communication to the browser or other applications. How did you know those things were “a thing” in the first place to refactor towards that? I started playing with websockets for the first time more than 5 years ago. I knew of them for a long time but never played with them. Websockets are the only bidirectional communications channel supported by the browser. Websockets proved amazing for live updates to a browser app, because otherwise you have to poll the server with repeated HTTP requests. So, I knew of websockets already in a very limited sense. 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). Thanks for this post, my imposter syndrome has been getting to me lately, with my own lack of knowing things are there to be used. So that your journey is years in the making gives me some comfort that my own searching in the dark for hours or days is not that big of a deal.