Queuing is a critical component of software architecture, and choosing the right system for your cloud-native enterprise application is crucial. In this blog post, we'll compare Amazon Simple Queue Service(SQS), Amazon Simple Notification Service (SNS), and Amazon Kinesis, exploring their strengths and weaknesses to help you determine which queuing system is best suited for your use case.
Tag: software engineering
Stop Shakespearizing
Ultimately, you must know your project, your needs, yourself, your skills, and your team. Only you are responsible for your project. So trust your instincts, fellow architect, and don't Shakespearize 🙂
Why don’t they tell you that in the instructions?
The nature of our jobs as software engineers is such that we must deal with externalities. Hardware will crash. Services will auto-scale up and down. Garbage collection will occur. Humans will make mistakes and use our software in ways we did not anticipate. Someone will write configuration instructions for you on how to setup your dev environment, and they might not apply perfectly to your setup.
Monolithic repository vs a monolith
Monorepo makes sense under some circumstances and makes no sense under others. A set of related features with related code, similar security, performance, and scalability profiles belong in a single deployable service. Services that are functionally related and have a closely aligned release cycle belong to the same monorepo.
Java is no longer relevant
Though Java was my primary way of earning a living from about 1997 to 2015, it has long outlived the problems it solved. Java’s issues are being solved now by modern tools like Docker. Except for a few niche use cases, I no longer use Java for my projects.
There is no such thing as one grand unified full-stack programming language
There is no such thing as one grand unified full-stack programming language or a full-stack developer using a single tool. As a SaaS software architect, I certainly do not see some holy grail from my vantage point. We need to use tools that best meet the needs of the task -- and the needs and the skills of developers who use them.
Most terrifying professional artifact
The only way I could wrap my head around this code was by printing it out, taping printed sheets together, spreading it on the floor, and crawling over it using a highlighter to annotate blocks of code.
Tools of the craft
Developers should feel empowered to configure their environment and development tools to their liking and contribute to the shared team standard. They should know the libraries they picked and why they picked them. They should be able to articulate why they like one programming language over another. As part of their job, each developer should be able to state clearly and in actionable terms how they’d like to work.
Application developers like to think their app is the only one
My pet UX peeves described above all seem to fall under the same category: each app thinks it is the only app running on my phone, and it is the only app I am using. It boils down to the developers’ respect for my time.
A year of COVID taught us all how to work remotely
Telecommuting in and of itself isn't the end — it is the means to a more flexible work arrangement. In a sign of changing attitudes in the enterprise world, Gizmodo is reporting that Salesforce would "allow its employees more freedom in choosing how to structure their work lives going forward."
The Dulin Report 
You must be logged in to post a comment.