On the precipice of another Crusade the software development community remains divided. To have servers or not have servers? This seems to be one of the golden questions of our time.
Yes, I did just make up the word serverfull.
Much like many arguements people are either on one side or the other. People seem to be losing nuance on where there are use cases for serverfull services like EC2 and where serverless services like ECS, EKS, (in fargate mode), or Lambda make a lot of sense.
On the other hand many people seem to be in the Frozen Caveman about using servless. Weather its an unexpected bill or having to piece together some spahgetti serverless architecture. Everyone seems to have an opinion on the matter, and as normies do, they are mostly wrong.
Let’s consider this the 4th installment in the Software Architect’s Toolbox series we have going. Make sure you READ the other posts.
What is Software Architecture?
Generally, as you become more senior in software engineering you begin to write less code and focus more on design, high level implementation, and the technical direction of your org. Generally, this is true. However some people do remain high output coders into their staff career. This can all be very individualized. Most people though tend to focus on the abstract and lucrative field Software Architecture, your’s truly included in the lucrative part.
The Power of Breadth: Why Software Architects Need a Wide-Ranging Technical Knowledge Base
Jack of all trades or master of one. This is the common tradeoff you hear for software engineering. For software architecture the answer leans more towards jack of all trades. This post will be the second in a series about the Software Architect’s toolbox, or how to be a software architect. Being a software architect is different than being a developer on a software engineering team. It requires different thinking and skills to be effective. Although, the skillsets are adjacent, there still different.
Balancing Act: The Crucial Role of Tradeoffs in Software Architecture
Introduction In the world of software architecture, there is no such thing as a 'one-size-fits-all' solution. Every decision, every path chosen, brings with it a set of benefits and costs - tradeoffs. These tradeoffs are the invisible strings that shape the destiny of your software system, influencing its efficiency, scalability, and overall performance. Misunderstanding or overlooking these critical decision points can lead to cost overruns, missed deadlines, and subpar end products.
In today’s paradigm, any software architect worth their salt must be able to determine if they have a use case for serverless services.
Table of Contents
Understanding Serverless Architecture
Understanding Non-Serverless or Serverfull Architecture
Comparing Serverless and Serverfull Architecture
Conclusion
Navigating the Future of Software Architecture: Serverless vs. Non-Serverless
Understanding Serverless Architecture
We have written about serverless in the past, and it is a taboo among many software developers. Basically serverless means the infrastructure is mostly abstracted from the developer. Why do some developers have such vitriol towards serverless? Probably because they don’t see the value of it. Like any technology many people shove the “current thing” down people’s throats.
Keep reading with a 7-day free trial
Subscribe to Software Architecture with BowTiedCelt to keep reading this post and get 7 days of free access to the full post archives.