Date post: | 27-Jun-2015 |
Category: |
Technology |
Upload: | tweakersnet-developer-summit |
View: | 267 times |
Download: | 3 times |
Imagine this
You are in charge of the architecture
What are the requirements
A website for selling shoes
Site can handle a lot of traffic
Marketing must have good traffic insight
Connected to the backoffice for orders
Good uptime
Vague requirements…….. As always, we developers say
Many difference in definition of architecture
Information architecture
Application architecture
Software architecture
TheoryScalability
Modifiability
Simplicity
Reliability
Performance
Software Architecture in Practice by Len Bass, Paul Clements, Rick Kazman, Ken Bass.
Practice. Make our technology stack
Should do the job…
Conclusion so far..Theory is to vague to make a good selection in components
Just pick some hot stuff doesn’t feel good
Will I be really ready
for the future?
Still got some questions..
Who is going to maintain the components?
Do I really need so much functionality
What is the time schedule for this to implement?
How do I get everything under control?
Problems that you just don’t want to have
Let’s keep close to the facts
Development team
Sysadmin
Organization
Important criteriaMeet concrete requirements (if they are there)
Stable and in Repository
Knowledge available (documentation, best practises, internal/external development)
Learning curve for a component
Is the technology proven for my goal
How much do I use of the component functionality
The component selection
Meet recuiremtns
Stable version
Repository
Documentation
Accepted by developers
Internal indept knowledge
Sysadmin can maintain
External developers available
Proven technology
Hadoop, Hive -/+ - + - - - +/- - -Filelogging -/+ + + + + + ✔
VNU Media issues with Hadoop
No failover for Hadoop’s namenode
From PHP hard to append to Hadoop filesystem
Architecture for the near future
Things to keep in mind
There can be requirements that needs “state of art” components or even unstable, but be very very careful.
Focus on abstraction in code, so you can change
Keep track of updates of your components during development
Don’t let business requirements instantly change your mind about a component
Never stop experimenting with new tools and components, maybe it can make your architecture better in the future.
It’s better to create an architecture that lasts
for one year, than trying to create an
architecture that lasts for ten years.
Stefan Priebsch