Deciding on an architecture has to be a very big deal. Two, three or more layers? What database to use: SQL, NoSQL or NewSQL? You want some messaging with that setup? In many companies there are entire departments dedicated to deciding on an architecture and then refining it until it's "perfect". But the fact remains that there is not a perfect architecture for all situations, and probably not even for a particular situation. The modern stack has very stringent requirements of functionality, scalability, and cost, which keep changing all the time. So why do we expect a rigid architecture to thrive in such a changing environment?
At my current compnay we have to answer many thousands requests per second under very stringent conditions, plus add new functionality all the time to remain ahead of the competition. We might expect our architecture to support anything we throw at it, and we would probably be disappointed all the time; instead we allow it to reflect the changing conditions and evolve as needed. Nothing is sacred: from databases (where we have performed several large-scale migrations in two years) to configuration or even hosting company, we are open to any changes that might increase our scalability and/or lower our costs. The key is to keep our architecture fluid, instead of committing to past decisions.
We will illustrate the principles of the fluid architecture with real-life examples using Node.js.
Speaker Bio
I'm a Spanish software engineer with 15+ years of experience. Currently working as a senior developer at MediaSmart, and sometimes as a freelance scalability consultant to avoid getting rusty on the edges.
Shameless tinkerer since forever, I was seduced by node.js a couple of years ago, and now eat thousands of requests per second for breakfast.
The Fluid Architecture
The story you'd like to tell
Deciding on an architecture has to be a very big deal. Two, three or more layers? What database to use: SQL, NoSQL or NewSQL? You want some messaging with that setup? In many companies there are entire departments dedicated to deciding on an architecture and then refining it until it's "perfect". But the fact remains that there is not a perfect architecture for all situations, and probably not even for a particular situation. The modern stack has very stringent requirements of functionality, scalability, and cost, which keep changing all the time. So why do we expect a rigid architecture to thrive in such a changing environment?
At my current compnay we have to answer many thousands requests per second under very stringent conditions, plus add new functionality all the time to remain ahead of the competition. We might expect our architecture to support anything we throw at it, and we would probably be disappointed all the time; instead we allow it to reflect the changing conditions and evolve as needed. Nothing is sacred: from databases (where we have performed several large-scale migrations in two years) to configuration or even hosting company, we are open to any changes that might increase our scalability and/or lower our costs. The key is to keep our architecture fluid, instead of committing to past decisions.
We will illustrate the principles of the fluid architecture with real-life examples using Node.js.
Speaker Bio
I'm a Spanish software engineer with 15+ years of experience. Currently working as a senior developer at MediaSmart, and sometimes as a freelance scalability consultant to avoid getting rusty on the edges.
Shameless tinkerer since forever, I was seduced by node.js a couple of years ago, and now eat thousands of requests per second for breakfast.