நான் ஏன் குறியீடு எழுதுவதை நிறுத்திவிட்டு வடிவமைக்கத் தொடங்கினேன்
மென்பொருள் மேம்பாடு (software development) என்பது அம்சங்களை (features) எழுதுவது என்று நான் முன்பு நினைத்தேன். என் வேலை என்டிட்டிகளை (entities) உருவாக்குவது, கன்ட்ரோலர்களை (controllers) கட்டமைப்பது மற்றும் தரவுத்தளங்களை (databases) இணைப்பது என்று நினைத்தேன்.
சமீபத்திய ஒரு திட்டம் எனது பார்வையை மாற்றியது. குறியீடு எழுதுவது (coding) என்பது தீர்வின் ஒரு பகுதி மட்டுமே என்பதை நான் கற்றுக்கொண்டேன். நீங்கள் ஒரு வரியைக் கூட எழுதுவதற்கு முன்பே உண்மையான வேலை தொடங்கிவிடுகிறது.
நீங்கள் கட்டமைப்பு (architecture) குறித்து முடிவெடுக்க வேண்டும். அது ஏன் பொருந்துகிறது, அதன் செலவு என்ன, மற்றும் அது எந்த அபாயங்களைத் தீர்க்கிறது என்பதை நீங்கள் கேட்க வேண்டும்.
இதோ எனது முக்கிய பாடங்கள்:
• கட்டமைப்பு தயாரிப்பின் நிலைக்கு (product stage) ஏற்றதாக இருக்க வேண்டும். உடனடியாக microservices, Kubernetes மற்றும் சிக்கலான event queues ஆகியவற்றைப் பயன்படுத்தத் தோன்றும். எங்கள் திட்டத்திற்காக, நாங்கள் ஒரு ஒற்றை செயல்முறையில் (single process) அடுக்கு கட்டமைப்பை (layered architecture) தேர்ந்தெடுத்தோம். இது ஒரு விநியோகிக்கப்பட்ட அமைப்பின் (distributed system) தலைவலி இல்லாமல் பொறுப்புகளைப் பிரிக்க எங்களுக்கு அனுமதித்தது. நீங்கள் தொடங்கும் போது எளிமையாக இருப்பது பெரும்பாலும் சிறந்தது.
• சில முடிவுகள் இப்போது மலிவானவை, ஆனால் பின்னர் விலை உயர்ந்தவை. முதல் நாளிலிருந்தே எங்கள் தரவு மாதிரியில் (data model) ஒரு TenantId-ஐச் சேர்த்தோம். எங்களுக்கு ஒரு வாடிக்கையாளர் மட்டுமே இருந்தபோதிலும், இது எதிர்காலத்தில் SaaS மாதிரியில் மாறுவதை எளிதாக்கியது. மல்டி-டெனன்சியை (multi-tenancy) சேர்க்க நீங்கள் மிக நீண்ட காலம் காத்திருந்தால், அந்த இடமாற்றம் (migration) ஒரு பயங்கரமான விஷயமாக மாறிவிடும்.
• வடிவமைப்பு எதிர்காலத் தடைகளைத் தடுக்கிறது. புரோகிராமிங் (Programming) ஒரு உடனடிப் பிரச்சனையைத் தீர்க்கிறது. வடிவமைப்பு (Designing) எதிர்காலத்திற்கான கதவுகளை மூடிவிடாமல் ஒரு பிரச்சனையைத் தீர்க்கிறது. வெவ்வேறு உள்கட்டமைப்பிற்கு (infrastructure) மாறுவதை எளிதாக்க நாங்கள் ஆரம்பத்திலேயே கன்டெய்னர்களைப் (containers) பயன்படுத்தினோம். வழங்குநர்களை (providers) எளிதாக மாற்றுவதற்கு நாங்கள் இன்டர்ஃபேஸ்களைப் (interfaces) பயன்படுத்தினோம்.
• வணிக மாற்றங்கள் தொழில்நுட்ப மாற்றங்களை வழிநடத்துகின்றன. வணிகம் வளருவதால் ஒரு அமைப்பு microservices-க்கு மாறுகிறது. ஒரு ஒற்றை கிளினிக் செயலி நூற்றுக்கணக்கான கிளினிக்குகளுக்கான SaaS தளமாக மாறுகிறது. இந்த மாற்றம் நீங்கள் பில்லிங் (billing), சந்தாக்கள் (subscriptions) மற்றும் அளவிடுதல் (scaling) ஆகியவற்றை எவ்வாறு கையாளுகிறீர்கள் என்பதை மாற்றுகிறது.
• நம்பகத்தன்மைக்குச் சிறந்த முறைகள் (patterns) தேவை. நாங்கள் ஒத்திசைவான அழைப்புகளிலிருந்து (synchronous calls) நிகழ்வு சார்ந்த கட்டமைப்பிற்கு (event-driven architecture) மாறினோம். ஒரு மருத்துவ அமைப்பில், மெதுவான அறிவிப்புச் சேவை (notification service) ஒரு அப்பாயிண்ட்மெண்ட் முன்பதிவை முடக்கிவிடக் கூடாது. மெசேஜ் புரோக்கர் (message broker) தோல்வியடைந்தாலும் தரவு பாதுகாப்பாக இருப்பதை உறுதி செய்ய நாங்கள் Outbox pattern-ஐப் பயன்படுத்தினோம்.
• முறைகள் (patterns) அந்தத் துறைக்கு (domain) ஏற்றதாக இருக்க வேண்டும். முறைகளை குருட்டுத்தனமாகப் பயன்படுத்தாதீர்கள். மருத்துவக் கண்டறிதலுக்கு வலுவான நிலைத்தன்மை (strong consistency) தேவை. நோயாளியின் பாதுகாப்பிற்காக நீங்கள் eventual consistency-யை நம்பியிருக்க முடியாது. உங்கள் தணிக்கைப் பாதையை (audit trail) பாதிக்கும் என்றால், உணர்திறன் மிக்க மருத்துவத் தரவுகளுக்கு கேச் (cache) பயன்படுத்தாதீர்கள்.
• DevOps என்பது ஒரு கூடுதல் சிந்தனை அல்ல. வரிசைப்படுத்துதல் (Deployment), ஆரோக்கியச் சோதனைகள் (health checks) மற்றும் குழாய்கள் (pipelines) ஆகியவை ஆரம்ப வடிவமைப்பின் ஒரு பகுதியாகும். நீங்கள் செலவுகளைக் கணக்கிட வேண்டும் மற்றும் உங்கள் தேவைகளைப் உண்மையில் பூர்த்தி செய்யும் கூறுகளைத் தேர்ந்தெடுக்க வேண்டும்.
ஒரு மென்பொருள் உருவாக்குநருக்கும் ஒரு வடிவமைப்பாளருக்கும் இடையிலான வித்தியாசம் அந்த "ஏன்" என்ற கேள்வியில்தான் உள்ளது.
ஒரு மென்பொருள் உருவாக்குநர் கேட்கிறார்: "இதை நான் எப்படிச் செயல்பட வைப்பது?" ஒரு வடிவமைப்பாளர் கேட்கிறார்: "இந்த குறிப்பிட்ட பிரச்சனைக்கு இதுதான் சரியான தீர்வா?"