Κατανεμημένα συστήματα: Πότε πρέπει να τα δημιουργήσετε και πώς να κάνετε κλίμακα. Ένας οδηγός βήμα προς βήμα.

Μου φαίνεται πάντα πόσους νέους προγραμματιστές πάσχουν από σύνδρομο απατεώνων όταν άρχισαν να δημιουργούν το προϊόν τους.

Κατάλαβα, υπάρχουν πολλά μυαλό-φυσώντας παραδείγματα κορυφαίων εταιρειών με απίστευτα πολύπλοκα κατανεμημένα συστήματα που μπορούν να αντιμετωπίσουν τα δισεκατομμύρια των αιτήσεων , χάρη αναβάθμιση εκατοντάδες εφαρμογές χωρίς downtime, ανάκτηση από καταστροφή σε δευτερόλεπτα, αφήστε κάθε 60 λεπτά, και να έχουν την ταχύτητα του φωτός χρόνοι απόκρισης από οπουδήποτε στον κόσμο.

Αυτές οι προσδοκίες μπορεί να είναι αρκετά συντριπτικές όταν ξεκινάτε το έργο σας. Ωστόσο, όπως ήδη γνωρίζετε πολλοί από εσάς, η πλειοψηφία αυτών των εταιρειών ξεκίνησε με ένα ελάχιστο βιώσιμο σύστημα και μια πολύ κακή τεχνολογία . Υπάρχει ένας απλός λόγος για αυτό: δεν το χρειάζονταν όταν ξεκίνησαν. Το να αφιερώσετε περισσότερο χρόνο στο σχεδιασμό του συστήματός σας αντί της κωδικοποίησης θα μπορούσε στην πραγματικότητα να σας προκαλέσει αποτυχία .

Αυτό το άρθρο είναι ένας βήμα προς βήμα τρόπος καθοδήγησης. Θα σας δείξω πώς, στο Visage, ξεκινήσαμε με το μικρότερο σύστημα ποτέ και δημιουργήσαμε ένα βασικό, κλιμακούμενο κατανεμημένο σύστημα υψηλής διαθεσιμότητας. Πρόκειται για μια πραγματική μελέτη περίπτωσης για την κατάργηση των συμπλεγμάτων σας εάν δεν είχατε ποτέ την ευκαιρία να το κάνετε μόνοι σας.

Όταν έφτασα για πρώτη φορά στο Visage ως CTO, ήμουν ο μόνος μηχανικός. Δεν ήξερα τίποτα για την τεχνολογία stack, αλλά μπήκα γιατί μου άρεσε πολύ η ιδέα του να είναι σε θέση να προσλαμβάνουν χωρίς in-house εργοδότες ή μια υπηρεσία ανθρώπινου δυναμικού. Αυτή ήταν η βασική ιδέα πίσω από το Visage: crowdsourcing που τροφοδοτείται από πολλούς αόρατους recruiters που εργάζονται μαζί για τους ρόλους σας με τη βοήθεια τεχνητής νοημοσύνης που θα αναζητούσε το πιο κατάλληλο ταλέντο για εσάς μέσα σε λίγες μέρες. Τότεασχολείστε άμεσα μαζί τους, όχι μεσαίος.

Το " πλήθος " στο crowdsourcing πυροδότησε αμέσως τον μηχανικό μου εγκέφαλο: υπάρχουν πολλοί άνθρωποι , που εργάζονται ταυτόχρονα , αναμένοντας καλή απόδοση από οπουδήποτε στον κόσμο. Μου άρεσε η πρόκληση.

Αλλά από άποψη συστήματος, τα πράγματα ήταν κακά , πραγματικά κακά . Αυτό βρήκα όταν έφτασα:

  • Μια συμβιβασμένη παρουσία Wordpress που εκτελεί εκατοντάδες ξεπερασμένα ελαττωματικά πρόσθετα, που εκτελούνται σε VM σε κοινόχρηστο διακομιστή
  • Συμβιβασμένα γραμματοκιβώτια
  • Ένας χάλια τόνος των Εγγράφων Google και των υπολογιστικών φύλλων.

Και αυτό είναι απολύτως φυσιολογικό. Και πάλι, δεν υπήρχε τεχνικό μέλος στην ομάδα και περίμενα κάτι τέτοιο. Ακόμα η ομάδα είχε επικεντρωθεί σε μια επιχειρηματική ευκαιρία και έκανε το προϊόν να φαίνεται ότι δούλεψε μαγικά κάνοντας τα πάντα χειροκίνητα! (Ψεύτικο μέχρι να το φτιάξεις). Και αυτό ήταν πραγματικά εκπληκτικό.

Δεν αποτελεί έκπληξη το γεγονός ότι η πρώτη μου δουλειά ήταν να επαναδημιουργήσω το VM, να επανεγκαταστήσω μια ενημερωμένη έκδοση του Wordpress, να βεβαιωθώ ότι όλοι αλλάζουν τους κωδικούς πρόσβασης, να θεσπίσουν μια πολιτική κωδικού πρόσβασης και να αφαιρέσουν δεκάδες κακόβουλα προγράμματα στους υπολογιστές της εταιρείας… αλλά ας προχωρήσουμε σε θέματα συστημάτων.

Από το Wordpress σε μια διαδικτυακή εφαρμογή

Η πρώτη σας εστίαση όταν αρχίζετε να δημιουργείτε ένα προϊόν πρέπει να είναι δεδομένα . Τα δεδομένα είναι αυτά που οδηγούν την αξία της εταιρείας σας . Θα είναι αυτό που χρησιμοποιείτε καθημερινά για να λαμβάνετε αποφάσεις και αυτό που δείχνετε στους επενδυτές σας για να δείξετε πρόοδο .

Πρέπει να κατανοήσετε τα δεδομένα σας και η συλλογή των δεδομένων σας από διαφορετικές πηγές με διαφορετικές μορφές θα είναι τεράστιο χάσιμο χρόνου . Το Wordpress μπορεί να είναι μια πολύ καλή επιλογή σε πολλές περιπτώσεις, εξοικονομώντας πολύ χρόνο μηχανικής, αλλά για τις ανάγκες τους, η ομάδα του Visage έπρεπε να εγκαταστήσει φανταχτερά πρόσθετα που δεν συντηρούσαν πλέον. Ως αποτέλεσμα, δεν είχαμε τον έλεγχο του παραγόμενου μοντέλου δεδομένων και δεδομένα που δεν μπορούσαν να χωρέσουν στο μοντέλο ήταν διασκορπισμένα σε δεκάδες έγγραφα και υπολογιστικά φύλλα.

Έτσι, εκτός εάν υπάρχει ένα προϊόν εκεί έξω που να καλύπτει ήδη το 90% των αναγκών σας, σκεφτείτε ένα ιδανικό μοντέλο δεδομένων και σχεδιάστε και εφαρμόστε ένα ελάχιστο βιώσιμο προϊόν (MVP) που θα μπορεί να διατηρήσει όλα τα δεδομένα σας.

Τότε σκεφτείτε το API . Η εφαρμογή σας πρέπει να διαθέτει API, θα είναι κρίσιμο όταν το πουλήσετε τελικά. Μην κλιμακώσετε αμέσως, αλλά κωδικοποιήστε με γνώμονα την επεκτασιμότητα. Κάντε το API σας απάτριδες και όσο το δυνατόν πιο ΕΞΟΠΛΙΣΜΕΝΟ, καθώς όλοι θα περιμένουν να μπορούν να το υποβάλουν ερώτημα χρησιμοποιώντας τυπικές μεθόδους HTTP.

Επιλέξαμε το NodeJS στην περίπτωσή μας, επειδή το μεγαλύτερο μέρος του κώδικα μας θα ήταν απλώς επεξεργασία δεδομένων εισόδου και εξόδου. Το NodeJS δεν αποκλείει και διαθέτει μια βιβλιοθήκη που είναι βολική για το σχεδιασμό API: ExpressJS .

Εάν χρειάζεστε έναν ιστότοπο που απευθύνεται σε πελάτες, έχετε πολλές επιλογές. Πρώτα μπορείτε να δημιουργήσετε ένα επίπεδο στο διακομιστή εφαρμογών που θα δημιουργήσει τις σελίδες σας ή μπορείτε να δημιουργήσετε μια εφαρμογή Javascript μίας σελίδας που θα εξυπηρετείται από έναν στατικό διακομιστή φιλοξενίας ιστοσελίδων.

Στο Visage, προχωρήσαμε στη δεύτερη επιλογή και αποφασίσαμε να δημιουργήσουμε μία εφαρμογή για χρήστες και μία για διαχειριστές. Αυτό ήταν απλώς και μόνο επειδή θα είχαμε πολύ μεγαλύτερες προσδοκίες για τους χρήστες από ό, τι χρειαζόμασταν με τους διαχειριστές και θέλαμε να διατηρήσουμε και τις δύο βάσεις κώδικα απλές (επίσης, για λόγους CORS αργότερα). Έτσι ήταν το σύστημά μας:

Εκχωρήστε νωρίς την αποθήκευση ευαίσθητων δεδομένων

Εάν δεν είναι κρίσιμο για την επιχείρησή σας, δεν υπάρχει κανένας καλός λόγος για την αποθήκευση ευαίσθητων προσωπικών δεδομένων στα συστήματά σας. Η ασφάλεια είναι ένα περίπλοκο ζήτημα και αν τροποποιείτε τον κωδικό σας καθημερινά έως ότου βρείτε την αγορά των προϊόντων σας κατάλληλη, θα σπάσει. Ας υποθέσουμε ότι οποιοσδήποτε λανθασμένος θα μπορούσε να παραβιάσει την αίτησή σας εάν το ήθελε πραγματικά.

Το κλειδί εδώ είναι να μην κρατάμε δεδομένα που θα ήταν μια γρήγορη νίκη για έναν χάκερ. Κανείς δεν ληστεύει μια τράπεζα που δεν έχει χρήματα . Εάν σχεδιάζετε ένα προϊόν SaaS, ίσως χρειαστείτε έλεγχο ταυτότητας και ηλεκτρονική πληρωμή. Υπάρχουν πολλά τρίτα μέρη με τα οποία μπορείτε να ενσωματώσετε και θα το χειριστείτε με πολύ καλύτερο τρόπο απ 'όσο θα μπορούσατε.

Το Auth0, για παράδειγμα, είναι το πιο γνωστό τρίτο μέρος που χειρίζεται τον έλεγχο ταυτότητας. Το Stripe είναι επίσης μια καλή επιλογή για online πληρωμές. Θα αφιερώσουν όλους τους πόρους τους και τις καλύτερες ομάδες μηχανικής ασφάλειας στον πλανήτη για να διατηρήσουν τα δεδομένα σας ασφαλή - ή δεν έχουν επιχείρηση.

Οι υπηρεσίες Cloud είναι οι καλύτεροι φίλοι σας

Έτσι, σε αυτό το σημείο είχαμε έναν τρόπο να αποθηκεύσουμε όλα τα δεδομένα μας, τον έλεγχο ταυτότητας, την ηλεκτρονική πληρωμή και μια εφαρμογή ιστού που θα μπορούσαν να χρησιμοποιήσουν οι πελάτες μαζί με ένα API που θα μπορούσαμε να πουλήσουμε σε συνεργάτες για διαφορετικές περιπτώσεις χρήσης. Η βάση χρηστών μας αυξανόταν και έγινε προφανές ότι ήθελαν να έχουν πρόσβαση στην εφαρμογή ανά πάσα στιγμή. Έτσι ήρθε η ώρα να σκεφτούμε τη δυνατότητα κλιμάκωσης και τη διαθεσιμότητα .

Βασιζόμασταν σε έναν διακομιστή, αλλά μπορούσε να χειριστεί τόσα πολλά αιτήματα και η αλλαγή διακομιστών ή η κυκλοφορία μιας νέας έκδοσης θα σήμαινε την κατάργηση της εφαρμογής κατά τη διάρκεια της κυκλοφορίας. Οι επόμενες προτεραιότητές μας ήταν: εξισορρόπηση φορτίου , αυτόματη κλιμάκωση , καταγραφή , αναπαραγωγή και αυτοματοποιημένα αντίγραφα ασφαλείας . Φυσικά, εάν είστε ο μόνος μηχανικός της εταιρείας σας, η προσπάθεια να αντιμετωπίσετε όλα αυτά τα θέματα από μόνη σας θα ήταν απόλυτη τρέλα.

Ευτυχώς ζούμε σε μια εποχή που μόνο ένας καλά στρογγυλεμένος μηχανικός μπορεί εύκολα να κατασκευάσει ένα τέτοιο σύστημα μέσα σε λίγες μέρες χρησιμοποιώντας υπηρεσίες Cloud όπως Amazon Web Services , Google Cloud Services ή Azure . Αποφασίσαμε να μεταφέρουμε τα συστήματά μας στο AWS γιατί εκείνη την εποχή ήταν η πιο ολοκληρωμένη λύση και είχαμε 2 χρόνια δωρεάν πιστώσεις.

Γι 'αυτό θα μιλήσω ως επί το πλείστον για λύσεις AWS σε αυτήν την ανάρτηση, αλλά υπάρχουν αντίστοιχες υπηρεσίες σε άλλες πλατφόρμες. Αυτή είναι επίσης η ώρα που επιλέξαμε να ξεκινήσουμε να εκτελούμε τις λειτουργικές μονάδες μας σε κοντέινερ Docker για πολλούς διαφορετικούς άλλους λόγους που δεν θα καλυφθούν σε αυτήν την ανάρτηση (μπορείτε να δείτε αυτό το άρθρο για περισσότερες πληροφορίες: //medium.freecodecamp.org/amazon -fargate-αντίο-υποδομή-3b66c7e3e413).

Το πώς αποφασίζετε να εκτελέσετε τις εφαρμογές σας εξαρτάται πραγματικά από τη θήκη χρήσης σας, όπως η ευελιξία που χρειάζεστε σε σχέση με το χρόνο που μπορείτε να αφιερώσετε στη διαχείριση της υποδομής σας.

Δεν υπάρχει καλή ή κακή απάντηση.

Μπορείτε να επιλέξετε να εμπορευματοποιήσετε όλες τις ενότητες σας και να χρησιμοποιήσετε ένα σύστημα διαχείρισης κοντέινερ , όπως ECS / EKS σε AWS ή κινητήρα Kubernetes στο GCP. Εάν όχι και δεν θέλετε να ασχοληθείτε με πράγματα όπως η αυτόματη κλιμάκωση και η εξισορρόπηση φορτίου, μπορείτε να χρησιμοποιήσετε το Elastic Beanstalk ή το App Engine.

Αν θέλετε να έχετε πλήρη Serverless μπορείτε επίσης να συνδυάσετε τη χρήση των λειτουργιών Lambda και API Gateway. Αποφασίσαμε να πάμε για ECS. Θα αναπτυχθεί 3 περιπτώσεις σε 3 ζώνες διαθεσιμότητα, το φορτίο-εξισορρόπησης , set-up αυτόματη κλιμάκωση ανάλογα με τη χρήση της CPU, ολοκληρωμένη καταγράφει όλα τα δοχεία μας με Cloudwatch και μετρήσεις set-up για να παρακολουθήσουν τα λάθη , τις εξωτερικές κλήσεις και χρόνο απόκρισης API .

Για τη βάση δεδομένων μας, χρησιμοποιήσαμε το MongoDB, επειδή το μοντέλο μας είναι κατάλληλο για μια βάση δεδομένων NoSQL και για την υψηλή του συνέπεια. Αποφασίσαμε να εκμεταλλευτούμε το MongoDB Atlas και αναπτύξαμε 3 αντίγραφα για να επιτρέψουμε υψηλή διαθεσιμότητα. Μεταξύ άλλων υπηρεσιών, η Atlas παρέχει αυτόματη κλιμάκωση , αυτοματοποιημένα αντίγραφα ασφαλείας και σας επιτρέπει να επιστρέφετε στο παρελθόν χωρίς προβλήματα σε περίπτωση καταστροφής.

Αποφασίσαμε επίσης να φιλοξενήσουμε όλα τα στατικά αρχεία ιστού μας στο S3 και χρησιμοποιήσαμε το Cloudfront ως CDN, έτσι ώστε οι εφαρμογές JS να μπορούν να φορτώνονται πολύ γρήγορα οπουδήποτε στον κόσμο και να εξυπηρετούνται όσες φορές ζητηθεί. Το Cloudfare είναι επίσης μια καλή επιλογή και προσφέρει προστασία DDOS από το κουτί.

Για απλότητα, αποφασίσαμε να χρησιμοποιήσουμε τη Διαδρομή 53 ως DNS μας χρησιμοποιώντας τους διακομιστές ονομάτων τους για όλους τους τομείς μας. Αυτή είναι μια από τις αγαπημένες μου υπηρεσίες στο AWS. Κάνει τη ζωή σας πολύ πιο εύκολη. Κάθε φορά που θέλετε να προβάλλετε κάτι μέσω ενός ονόματος domain, είτε πρόκειται για μια παρουσία EC2 , μια ελαστική IP , μια εξισορρόπηση φορτίου , μια διανομή Cloudfront ή οτιδήποτε πραγματικά, ιδιωτικά ή δημόσια, σας παίρνει λεπτά, επειδή είναι τόσο καλά ενσωματωμένο με όλα τα άλλες υπηρεσίες.

Συνδυάστε το με το Certificate Manager που σας επιτρέπει να λάβετε δωρεάν πιστοποιητικά SSL (συμπεριλαμβάνονται μπαλαντέρ) σε λίγα λεπτά και να τα αναπτύξετε σε όλους τους διακομιστές σας, σημειώνοντας ένα πλαίσιο και έχετε τον πιο γρήγορο πιο αξιόπιστο τρόπο για να ενεργοποιήσετε το HTTPS σε όλες τις ενότητες σας. Αντίο πιστοποιητικά SSL "Let's Encrypt" που έπρεπε να ανανεώσω και να εγκαταστήσω στους διακομιστές μου κάθε 3 μήνες περίπου;

Αποφασίστε για μια στρατηγική προσωρινής αποθήκευσης

Όλοι μισούν τη διαχείριση της προσωρινής μνήμης, η προσωρινή αποθήκευση μπορεί να συμβεί σε πολλά διαφορετικά επίπεδα και τα ζητήματα που σχετίζονται με την προσωρινή μνήμη είναι δύσκολο να αναπαραχθούν και ένας εφιάλτης για εντοπισμό σφαλμάτων.

Δυστυχώς, η απόδοση των κατανεμημένων συστημάτων βασίζεται σε μεγάλο βαθμό σε μια καλή στρατηγική προσωρινής αποθήκευσης . Υπάρχουν πολλά καλά άρθρα σχετικά με τις καλές στρατηγικές προσωρινής αποθήκευσης, οπότε δεν θα αναφερθώ σε πολλές λεπτομέρειες. Απλώς ξέρετε ότι εάν οι πόροι του Στατικού Ιστού σας είναι μεγάλοι, πιθανότατα θα θελήσετε να εκμεταλλευτείτε την προσωρινή μνήμη του προγράμματος περιήγησης του χρήστη σας χρησιμοποιώντας έξυπνα την κεφαλίδα ελέγχου προσωρινής μνήμης.

Εάν οι σελίδες του χρήστη σας δημιουργούνται ξανά στους διακομιστές εφαρμογών, χρησιμοποιήστε έναν διακομιστή μεσολάβησης προσωρινής αποθήκευσης όπως το Squid . Αλλά το πιο σημαντικό, υπάρχει μεγάλη πιθανότητα να κάνετε τα ίδια αιτήματα στη βάση δεδομένων σας ξανά και ξανά. Για να μειώσετε τη φόρτωση της βάσης δεδομένων σας και να εξοικονομήσετε χρόνο μεταφοράς δεδομένων, χρησιμοποιήστε ένα σύστημα προσωρινής αποθήκευσης αντικειμένων μνήμης, όπως το memcached για αντικείμενα που χρησιμοποιούνται συχνά και σπάνια ενημερώνονται .

Αρχίσαμε να εξετάζουμε τη χρήση memcached επειδή συχνά ζητούσαμε τα ίδια προφίλ υποψηφίων και προσφορές εργασίας ξανά και ξανά. Η εφαρμογή του σε μια μηχανή βελτιστοποιημένη για τη μνήμη αύξησε την απόδοση του API κατά περισσότερο από 30% όταν υπολογίζουμε κατά μέσο όρο όλους τους χρόνους απόκρισης των αιτημάτων σε μια μέρα. Το Memcached διανέμεται επίσης, έτσι ώστε να μπορεί να εκτελείται σε διαφορετικούς διακομιστές, αλλά εξακολουθεί να λειτουργεί σαν να είναι μόνο ένας μεγάλος χώρος μνήμης για την αποθήκευση των αντικειμένων σας.

Τοποθεσία, τοποθεσία, τοποθεσία

Τώρα έχουμε ένα κατανεμημένο σύστημα που δεν έχει ούτε ένα σημείο αποτυχίας (εάν θεωρείτε AWS ELBs και ένα κατανεμημένο memcached) και μπορεί να κλιμακωθεί αυτόματα πάνω και κάτω. Χρησιμοποιούμε επίσης την προσωρινή αποθήκευση για ελαχιστοποίηση των μεταφορών δεδομένων δικτύου. Φαίνεται αρκετά καλό. Σε αυτό το σημείο πιθανότατα θέλετε να ελέγξετε τα τρίτα μέρη σας για να δείτε εάν θα απορροφήσουν το φορτίο όπως και εσείς.

Ωστόσο, ορισμένοι από τους χρήστες μας διαμαρτύρονταν ότι η εφαρμογή τους ήταν λίγο πιο αργή , ειδικά όταν ανέβαζαν αρχεία. Πράγματι, ακόμη και αν τα στατικά αρχεία ιστού αποθηκεύτηκαν σε κρυφή μνήμη σε όλο τον κόσμο (ευγενική προσφορά του CDN), όλοι οι διακομιστές εφαρμογών μας αναπτύχθηκαν μόνο στα δυτικά των ΗΠΑ. Οι χρήστες από την Ανατολική Ασία αντιμετώπισαν πολύ περισσότερη καθυστέρηση, ειδικά για μεγάλες μεταφορές δεδομένων.

Η λύση ήταν εύκολη: αναπτύξτε το ίδιο ακριβώς σύμπλεγμα ECS σε μια νέα περιοχή στην Ασία μαζί με ένα νέο εξισορροπητή φορτίου και βασιστείτε στη διαδρομή 53 Geoproximity Routing για να δρομολογήσετε τους χρήστες στον «πλησιέστερο» εξισορροπητή φορτίου. Το MongoDB Atlas σάς επιτρέπει επίσης να αναπτύξετε αντίγραφα σε διάφορες περιοχές, ώστε να μην απαιτείται επιπλέον εργασία.

συμπέρασμα

Ενώ το κατανεμημένο σύστημα που βλέπετε εδώ έχει απλοποιηθεί για αυτήν την ανάρτηση, εξετάσαμε τα μέρη που είναι πιο πιθανό να δείτε σε πολλές σύγχρονες εφαρμογές ιστού. Άλλα θέματα που σχετίζονται με αλλά δεν καλύπτονται είναι η αρχιτεκτονική των μικροϋπηρεσιών, η αποθήκευση αρχείων και η κρυπτογράφηση, η αποθήκευση βάσεων δεδομένων, οι προγραμματισμένες εργασίες, ο ασύγχρονος παράλληλος υπολογιστής… ίσως στην επόμενη ανάρτηση!

Το κύριο σημείο μου είναι: μην προσπαθήσετε να δημιουργήσετε το τέλειο σύστημα όταν ξεκινάτε το προϊόν σας. Οι περισσότερες από τις επιλογές σχεδιασμού σας θα εξαρτώνται από το τι κάνει το προϊόν σας και ποιος το χρησιμοποιεί. Θα γνωρίζετε μόνο ότι όταν φτάσετε στην αγορά προϊόντων κατάλληλα και αρχίσετε να έχετε μια καλή επισκόπηση της βάσης χρηστών σας και αυτό μπορεί να διαρκέσει μήνες, ακόμη και χρόνια.

Εστιάστε στο να καταλάβετε τι χρειάζονται οι άνθρωποι και προσπαθήστε να βρείτε μια λύση στο πρόβλημά τους, ακόμα κι αν έχει πολλά χειροκίνητα βήματα . Στη συνέχεια, σκεφτείτε τρόπους αυτοματοποίησης , αφιερώστε το χρόνο σας κωδικοποίηση και καταστροφή και χρησιμοποιήστε τρίτα μέρη όπου έχει νόημα.

Μην κάνετε κλίμακα, αλλά πάντα σκεφτείτε, κωδικοποιήστε και σχεδιάστε για κλιμάκωση. Κατασκευάστε το σύστημά σας βήμα προς βήμα , μην αντιμετωπίσετε ζητήματα σχεδιασμού συστήματος βάσει λειτουργιών που δεν είναι ακόμη ώριμες και, τέλος, προσπαθήστε πάντα να βρείτε την καλύτερη αντιστάθμιση μεταξύ του χρόνου που θα ξοδέψετε και του κέρδους στην απόδοση, τα χρήματα και τη μείωση κίνδυνος.

Αν σας άρεσε αυτό το άρθρο και βρήκατε κάποιο από αυτά χρήσιμο, πατήστε αυτό το χειροκρότημα και ακολουθήστε με για περισσότερα άρθρα αρχιτεκτονικής και ανάπτυξης! ;