In the world of agile methodologies, Minimal Viable Product (MVP) is a widely accepted concept among application developers. MVP is geared towards developing just enough features to gather validated learning about the product and its continued development. Not only this approach improves time to market, but it is also significantly cheaper from the perspective of both the upfront investment and cost of change to the direction of the product based on feedback. However, that same mentality haven't really crossed into the realm of underlying architecture. As an industry, we're fascinated with solutions that are presented and blogged about by companies working with the bleeding edge technologies. Problem is - most of us don't have the problems those companies are trying to solve. But many don't try to find a solution that matches the problem at hand. That's why reference architectures are treated as tutorials instead of references and technologies are picked based on their rankings on Reddit. In this talk I will discuss some of the anti-patterns for technology selection and architecture design as well as talk about the approach to designing a minimum viable architecture for your use case.

1. 1
building the right
architecture for you
@papa_fire

2. 2
not every problem is
created equal

3. 3
you are not
Netflix

4. 4
you are not
Netflix
you

5. 5
you don’t have
Big Data
your datayour data is tiny
your data

6. 6
define your problem

7. 7
define your problembusiness
need

8. 8
always
consider
cost

9. 9
99.999%

10. 1 0

11. 11
set
realistic
goals

12. 1 2
do you need
99.999%?

13. 1 3
don’t build
build
big
smart

14. 1 4
minimum
viable
architecture

15. 1 5
architecture choices
support business goals

16. 1 6
don’t just scale
scale with business

17. 1 7
don’t envy
thy neighbor

18. 1 8
there is a bash script at the
end of every DevOps road

19. 1 9
build what
you need
not what you
want to need

20. 2 0
thank you
@papa_fire
https://images.nasa.gov