11 सेकंड के downtime के साथ PostgreSQL database migration पूरा

 (gds.blog.gov.uk)
2 पॉइंट द्वारा GN⁺ 2024-01-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GOV.UK Notify ने PaaS बंद होने के अनुरूप 400GB PostgreSQL 11 database को अपने AWS account के PostgreSQL 15 RDS में migrate किया और downtime को लगभग 11 सेकंड तक सीमित रखा
  • target DB में पहले सिर्फ tables बनाई गईं, फिर DMS full load से data copy किया गया, और बाद में indexes तथा key constraints लागू किए गए ताकि बड़े पैमाने के load का समय घटे
  • source DB में लगभग 1.3 अरब rows, 85 tables, 185 indexes और 120 foreign keys थे, और weekdays में प्रति सेकंड लगभग 1,000 insert/update तथा लगभग उतनी ही reads होती थीं
  • application redeploy में लगभग 5 मिनट लगने की सीमा के कारण, पहले से same credentials और Route53 DNS weighted switch तैयार किया गया ताकि वास्तविक cutover समय कम हो
  • DMS को इसलिए चुना गया क्योंकि PaaS और AWS support पाना आसान था, लेकिन PostgreSQL-to-PostgreSQL migration में pglogical जैसा विकल्प शायद अधिक सरल हो सकता था

PaaS बंद होने के अनुसार Notify database migration

  • GOV.UK Notify को GOV.UK Platform as a Service पर host किया गया था, और PaaS बंद होने के कारण पूरी infrastructure को अपने AWS account में ले जाना पड़ा
  • Notify का database, PaaS AWS account में मौजूद AWS RDS PostgreSQL था, जिसमें notification delivery data से लेकर service teams द्वारा इस्तेमाल किए जाने वाले लाखों templates का content तक stored था
  • migration के दौरान पुराने database को source database और नए database को target database के रूप में अलग किया गया
  • मुख्य चुनौती नया PostgreSQL database बनाना नहीं थी, बल्कि सारा data migrate करते समय और application का connection target बदलते समय downtime को न्यूनतम रखना था

source database का आकार और service constraints

  • source database लगभग 400GB का PostgreSQL 11 था
    • लगभग 1.3 अरब rows
    • 85 tables
    • 185 indexes
    • 120 foreign keys
  • सामान्य weekdays में प्रति सेकंड लगभग 1,000 insert या update होते थे, और लगभग उतनी ही reads भी होती थीं
  • GOV.UK Notify हर दिन flood alerts, passport application status जैसे महत्वपूर्ण और समय-संवेदी notifications की लाखों deliveries करता है
  • क्योंकि हर notification delivery के लिए database access जरूरी था, इसलिए service interruption को बहुत छोटा रखना था

DMS के साथ initial load और continuous replication architecture

  • PaaS team ने AWS Database Migration Service का उपयोग करने वाली database migration पद्धति उपलब्ध कराई
  • DMS source database से target database तक data ले जाने का काम करता है, और इसे source या target AWS account, किसी में भी चलाया जा सकता है
  • DMS task दो चरणों में बँटा था
    • full load: एक निश्चित समय तक मौजूद सारा data table-दर-table copy करता है
    • continuous replication: source database के नए transactions को target database पर replay करके दोनों databases को sync में रखता है
  • application को source database की जगह target database इस्तेमाल करने के लिए switch करना Notify team ने खुद संभाला

target database की तैयारी और full load

  • DMS instance source AWS account में बनाया गया
    • PaaS team ने account के अंदर पहले से DMS instance configure किया हुआ था, इसलिए तैयारी जल्दी हो गई
    • DMS instance को source और target PostgreSQL databases से जुड़ने के credentials चाहिए थे
  • क्योंकि DMS instance और target database अलग-अलग VPC में थे, VPC peering सेट किया गया ताकि PaaS VPC का DMS traffic public internet से गुजरे बिना उनके अपने VPC तक route हो सके
  • target RDS instance उनके अपने AWS account में बनाया गया, और PostgreSQL 11 support end के करीब होने के कारण नया database PostgreSQL 15 पर बनाया गया
  • pg_dump से source database schema dump करके schema recreation SQL file बनाई गई, और शुरुआत में सिर्फ table declarations target database पर लागू की गईं
  • foreign keys को full load के समय लागू नहीं किया गया
    • क्योंकि DMS full load, foreign key constraint order के अनुसार data copy नहीं करता
  • primary keys और indexes भी full load से पहले नहीं बनाए गए
    • क्योंकि हर insert पर index update की जरूरत पड़ती, जिससे अरबों rows load करने का कुल समय बहुत बढ़ सकता था
    • पहले सारा data copy करना और बाद में indexes जोड़ना अधिक तेज़ निकला
  • full load task ने start button दबाए जाने के समय तक मौजूद data को copy किया
    • उसके बाद बने नए data या updates full load में शामिल नहीं हुए
    • full load पूरा होने में लगभग 6 घंटे लगे
  • full load के बाद बाकी schema file लागू करके indexes और key constraints जोड़े गए, और इसमें लगभग 3 घंटे लगे

10 दिनों तक replication बनाए रखने के बाद traffic switch

  • full load खत्म होने के बाद target database, full load शुरू होने के समय के source data से मेल खाता था, लेकिन उसके बाद source पर inserts, updates और deletes चलते रहे
  • DMS की continuous replication, यानी change data capture task शुरू की गई, जो full load शुरू होने के बाद source database के transaction log transactions को target database तक भेजती थी
  • replication process को catch up करने में कुछ घंटे लगे, और उसके बाद DMS replication lag monitor करके sync status की पुष्टि की गई
  • DMS replication लगभग 10 दिनों तक background में चलती रही और पहले से घोषित traffic migration समय तक दोनों databases को sync में रखा
  • traffic switch procedure पहले से Python script में लिखी गई थी
    • source database की ओर जाने वाला application traffic रोका गया
    • replication पूरी तरह catch up हुई है या नहीं, यह जाँचा गया
    • application को target database से जुड़ने की अनुमति दी गई
  • यह स्थिति टालनी थी कि कुछ applications source DB और बाकी target DB इस्तेमाल करें
    • क्योंकि target DB पर हुए changes source DB में वापस नहीं जाते, और users को inconsistent data दिख सकता था
  • script को manual steps की तुलना में अधिक explicit, repeatable और तेज़ execution के लिए बनाया गया, और pre-test तथा rehearsal में इसका कम से कम 40 बार इस्तेमाल हुआ
  • लक्ष्य downtime 5 मिनट से कम रखना था, और migration का समय आधी रात से बचते हुए अपेक्षाकृत शांत शनिवार शाम रखा गया

11 सेकंड का downtime देने वाला DNS switch

  • source database traffic रोकने के लिए application connections पर pg_terminate_backend call किया गया, और इसमें 1 सेकंड से भी कम समय लगा
  • application source DB से फिर reconnect न कर सके, इसके लिए PostgreSQL user password भी बदल दिया गया ताकि reconnect पर authentication error आए
  • DMS ने target database में replication status table बनाई और हर मिनट उसे update किया, और migration script ने इसी table से source और target के बीच lag की जाँच की
  • एक अतिरिक्त safety measure के रूप में, application द्वारा source DB access बंद करने के बाद script ने source DB में एक single record लिखा और उसके target DB तक पहुँचने का इंतज़ार किया
  • application की database connection info SQLALCHEMY_DATABASE_URI environment variable के जरिए दी जाती थी
    • पुराना format username, password और RDS location सहित postgresql://...@random-identifier.eu-west-1.rds.amazonaws.com:5432 जैसा था
    • database location या credentials बदलने के लिए application redeploy जरूरी था, और redeploy में लगभग 5 मिनट लगते थे
  • redeploy से होने वाले अतिरिक्त downtime से बचने के लिए migration से पहले दो तैयारियाँ की गईं
    • source और target databases में समान username और password वाले users बनाए गए
    • AWS Route53 में database.notifications.service.gov.uk DNS record बनाया गया और TTL को 1 सेकंड पर सेट किया गया
  • DNS record का शुरुआती weight source 100% और target 0% रखा गया
  • application URI को पहले ही common username-password और नए domain name का उपयोग करने के लिए बदल दिया गया
  • वास्तविक switch के समय script ने AWS DNS weight को target 100% पर बदला और TTL 1 सेकंड के expire होने का इंतज़ार किया
  • शनिवार शाम 4 नवंबर 2023 के cutover समय पर target database और source database के बीच lag कुछ सेकंड की थी
  • migration script के execution के परिणामस्वरूप application ने source DB access बंद किया, नए target DB का उपयोग शुरू किया, और downtime लगभग 11 सेकंड रही

DMS चुनने का आकलन और आगे का काम

  • DMS को इसलिए चुना गया क्योंकि GOV.UK PaaS पर इसका अच्छा support था और AWS support भी मिल सकता था
  • आगे यदि PostgreSQL-to-PostgreSQL database migration फिर करना पड़े, तो pglogical जैसे वैकल्पिक tools पर अधिक विचार किया जाएगा
  • DMS ने संभवतः दूसरे tools की तुलना में अधिक complexity और कम परिचित replication process जोड़ी
  • database migration के बाद अगला चरण application migration है
  • GOV.UK Notify application को AWS Elastic Container Service पर ले जाया जाएगा, और प्रक्रिया बाद में साझा की जाएगी

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-01-19
Hacker News की राय

  • हमने भी ऐसा ही migration AWS RDS Blue-Green Deployments के साथ किया था, और database थोड़ा बड़ा था, लेकिन downtime करीब 20 सेकंड था और काम भी बहुत कम लगा। हैरानी है कि इस thread में अभी तक इसका ज़िक्र नहीं हुआ
    मूल रूप से, आप अपनी चाही गई changes के साथ नया Blue/Green deployment शुरू करते हैं, और जब मौजूदा blue configuration traffic संभालता रहता है, तब AWS logical replication के जरिए green deployment को sync कर देता है
    green पर जब तक writes नहीं करते, तब तक modifications, testing, load testing भी कर सकते हैं, और writes live blue पर जाती रहती हैं और फिर green में replicate होती हैं
    तैयार होने पर switch command चलाते हैं, और AWS sync verification, writes और connections को रोकना, replication के catch up होने का इंतज़ार, database names बदलना, connections और writes resume करना—ये सब संभालता है
    हमारे हिसाब से downtime 20 सेकंड से कम था, और primary व कई read replicas समेत पूरी configuration बिना समस्या switch हो गई। AWS database URL भी बदल देता है, इसलिए settings बदलने की जरूरत नहीं पड़ी; green blue बन जाता है और पुराना blue old blue बन जाता है, जिसे बाद में delete कर सकते हैं
    जोरदार recommendation, लेकिन limitations हैं—जैसे account-to-account move जैसे मामलों में शायद काम न करे: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-...

    • Blue/Green के लिए +1. हालांकि इस case में लगता है account-to-account move की वजह से इसका इस्तेमाल नहीं कर पाए होंगे। MySQL और Postgres दोनों में इसे इस्तेमाल किया है, और MySQL में queries per second लेख से दो orders of magnitude ज्यादा थीं, फिर भी दोनों smoothly चले
      documentation, खासकर limitations, बार-बार पढ़नी चाहिए। dev environment में load के साथ test run करें, और staging में भी दोबारा करके देखें
      या फिर सीधे production में YOLO कर दें, शायद ठीक ही रहेगा
    • MySQL 5.7 से 8.0 पर major engine version upgrade करते समय RDS Blue/Green deployment इस्तेमाल किया था, और downtime के लिहाज से यह शानदार था। API में देखी गई downtime शायद करीब 13 सेकंड थी
      हालांकि यह बात हमें मुश्किल तरीके से सीखनी पड़ी कि RDS Blue/Green को arbitrary changes के लिए इस्तेमाल नहीं किया जा सकता। हमारे मामले में पता चला कि इसका इस्तेमाल सिर्फ engine version ऊपर ले जाने के लिए हो सकता है, नीचे लाने के लिए नहीं
      MySQL 8.0 में एक stored procedure बहुत कभी-कभार fail हो रहा था, इसलिए हमने 5.7 पर rollback का option देखा, लेकिन वह संभव नहीं था
    • जानना चाहता हूँ कि क्या किसी ने पहले से unencrypted RDS storage को Blue/Green के जरिए encrypt किया है
    • यह जानना चाहता हूँ कि database access करने वाली applications को आपने कैसे stop और restart किया। ECS पर कई tasks चल रहे हैं, और उन्हें down होने में 1 मिनट, फिर वापस up होने में कुछ मिनट लग सकते हैं
    • Route53 Groups और Blue/Green setup के लिए +1. हमने भी PostgreSQL upgrade में कुछ ऐसा ही किया था, और AWS R53 groups व अपने Rails ActiveRecord transaction patch के साथ चल रही queries को retry करके downtime के बिना निपटा लिया
      trade-off यह था कि कुछ seconds के लिए कुछ requests धीमी हो गईं
      DNS Groups और retry का combination इस तरह के काम के लिए काफी उपयोगी mechanism है
      इस्तेमाल किया गया tool: https://github.com/shayonj/pg_easy_replicate

  • incoming Postgres queries को “pause” करने के कई तरीके हैं; उदाहरण के लिए pgbouncer का इस्तेमाल करके उन्हें fail किए बिना तब तक delay किया जा सकता है जब तक replication catch up न कर ले, और फिर new database पर continue कराया जा सकता है
    अगर कुछ गड़बड़ हो जाए और replication catch up न कर पाए, तो pause हटाकर उन queries को पुराने database पर चलने दें
    इससे 11 सेकंड की downtime, page load time में 0–11 सेकंड की अतिरिक्त देरी में बदल जाती है। इससे भी महत्वपूर्ण बात यह है कि database के उन हजारों users में, जिन्होंने अब तक query failures नहीं देखे हैं, अगर कहीं buggy error handling path हो या एक ही failed query से पूरा batch job टूट जाता हो, तो collateral damage काफी कम हो जाता है

    • queries को रोकना संभव हो सकता है, लेकिन सोच रहा हूँ कि क्या पहले से चल रहे transactions को भी रोका जा सकता है। वह कैसे काम करता है?

  • https://knock.app/blog/zero-downtime-postgres-upgrades से तुलना करें तो यह दिलचस्प है। संबंधित चर्चा https://news.ycombinator.com/item?id=38616181 पर हुई थी
    उस समय चर्चा का बड़ा हिस्सा आखिरकार इस बात पर आकर रुका था कि “कुछ मिनट के downtime से बचने के लिए क्या यह बहुत जटिल नहीं है?” यह मामला मानो उसका प्रमाण लगता है, और ऐसा लगता है कि AWS Data Migration Service इस्तेमाल करके, DNS entries बदलकर production पर handover करने के बाद बस 11 सेकंड का downtime स्वीकार करना पड़ता है

    • इसमें “बस” जैसा कुछ नहीं है। मुख्य सीख “सीखी गई बातें” में है

      DMS चुनने की वजह यह थी कि GOV.UK PaaS में इसका अच्छा support था और AWS support भी मिल सकता था। आगे अगर PostgreSQL से PostgreSQL में database migrate करना हुआ, तो हम pglogical जैसे alternative tools की जाँच में ज्यादा समय लगाएंगे। DMS ने शायद दूसरे tools की तुलना में अधिक जटिलता और अपरिचित replication process जोड़ दी। यह PostgreSQL-to-PostgreSQL migration के बारे में AWS खुद जो कहता है, उससे भी मेल खाता है
      यहाँ संदेश “बस DMS इस्तेमाल करो” नहीं है

    • उत्सुकता है कि क्या किसी ने https://cloud.google.com/database-migration/docs/postgres/qu... से ऐसा ही काम किया है। क्या यह AWS DMS जैसा ही काम करता है?
    • DMS अंदरूनी तौर पर pglogical इस्तेमाल करता हुआ लगता है, लेकिन इसमें कई pitfalls हैं। यह hardware-level replication नहीं है, इसलिए बड़े rows, बड़े columns और बड़े tables में समस्याएँ आ सकती हैं, और foreign keys को भी ठीक से handle नहीं करता
      कुछ विशेष data types को शायद बिल्कुल process न कर पाए। migration के बाद sequences भी update करने पड़ते हैं, वरना duplicate primary key errors आ सकते हैं
      अगर उचित primary key नहीं है, तो समस्या हो सकती है क्योंकि यह हमेशा पूरे row को एक बार में copy नहीं करता
      अगर database उसी AWS account के अंदर है और आप 4–5 मिनट का downtime सह सकते हैं, तो global database या snapshots का उपयोग करके hardware-level replication ज्यादा आसान होने की संभावना है

  • हाल ही में अपने self-hosted 3TB PostgreSQL database को 12 से 16 पर migrate किया, और Ubuntu 18 से Ubuntu 22 पर शिफ्ट किया। साथ ही कई extensions भी upgrade करने थे, खासकर Timescale के लिए ऐसा compatible version नहीं था जो सभी combinations को satisfy करे
    हमने read-only replica को upgrade करने के तरीके से काम किया: शुरुआत PG12, Ubuntu 18, TS2.9 से थी, और पहले Ubuntu 22 पर PG12 और TS2.9 बनाए रखते हुए read-only replica बनाया
    इसके बाद maintenance mode में गए, सभी services रोकीं, read-only replica को अलग किया, फिर Ubuntu 22 पर PG12 को PG15 में upgrade किया लेकिन TS2.9 बनाए रखा
    फिर PG15 और TS2.9 से TS2.13 पर upgrade किया, और अंत में Ubuntu 22 पर PG15 को PG16 में upgrade करते हुए TS2.13 बनाए रखा
    आखिर में services को नए database server से फिर से connect किया, सभी services resume कीं और maintenance mode समाप्त किया
    सभी database upgrade steps को Ansible से अच्छी तरह test और automate किया था, लेकिन testing में न दिखी एक समस्या आई, जिससे downtime बढ़कर लगभग 30 मिनट हो गया। हमारे use case के लिए यह पूरी तरह acceptable था
    अगर हमने logical replication इस्तेमाल किया होता, तो अंतिम क्षण की अप्रत्याशित समस्या कम हो सकती थी, और अगले upgrade cycle में हम इस approach पर विचार करेंगे

    • हमने भी हाल ही में लगभग यही upgrade path follow किया। बस उस समय Timescale अभी PG16 support नहीं करता था, इसलिए PG15 + TS 2.12 पर रुक गए
      upgrade downtime घटाने के लिए logical replication पर भी विचार किया, लेकिन database schema और DDL commands replicate नहीं होते, इसलिए Timescale शामिल हो तो यह recommended नहीं लगता था
      Timescale को अंदरूनी तौर पर जो underlying schema changes करने होते हैं, वे ज्यादातर hypertable chunk size और incoming write pattern का function होंगे, इसलिए उन्हें plan या time किया जा सकता होगा, लेकिन हमें लगा कि pg_upgrade पूरा होने तक एक छोटा maintenance window रखने की तुलना में संभावित complexity और risk बहुत ज्यादा है

  • ऐसे low-downtime/zero-downtime migrations के दुश्मन long-running queries हैं
    उदाहरण के लिए, अगर कोई single update query 30 मिनट लेती है, तो आपको उस query को kill करके rollback करना होगा या 30 मिनट की availability loss स्वीकार करनी होगी
    मेरी जानकारी में currently running queries को migrate करने का कोई तरीका नहीं है

    • अगर यह software engineering project है, तो transaction time को इससे काफी कम limit करना बेहतर है। statement_timeout setting आपका दोस्त है
      अगर अत्यधिक लंबी transactions हैं, तो संभव है कि उनके चलने के समय से बचकर cutover किया जा सके। उम्मीद है कि वे random occurrence नहीं, बल्कि scheduled job जैसी किसी चीज़ का result हों
      transaction time limits और failover configuration—जैसे existing primary को fail करना—और pgbouncer जैसी चीज़ों को मिलाकर downtime की जगह slowdown period को काफी precise तरीके से control किया जा सकता है
      सच कहूँ तो मुझे ज्यादा चिंता इस बात की होगी कि पूरा stack और जिन external cache DNS servers पर यह depend करता है, वे DNS TTL को ठीक से respect करते हैं या नहीं
      लेकिन आम तौर पर app में करीब 10 सेकंड downtime से बचना mission-critical नहीं होता, इसलिए अपने लिए जो solution सरल हो उसे चुनना सही है
    • व्यक्तिगत रूप से, मेरे लिए यह कल्पना करना मुश्किल है कि 30 मिनट की update query बेहद inefficiently लिखी न हो, या फिर one-off बड़े data migration का मामला न हो
      बेशक पहला मामला वास्तविकता में बहुत मौजूद है। मिनटों या घंटों वाले jobs को milliseconds में बदलने का मज़ा मैंने काफी बार देखा है
    • कुछ नया सीखा। उत्सुकता है कि 30 मिनट से ज्यादा चलने वाले writes किस तरह के होते हैं
      किस तरह का data और किस तरह के लोग ऐसे database writes संभालते हैं, जिनमें upper layer पर queue से छोटे हिस्सों में बाँटने के बजाय DB engine पर इतने लंबे समय तक काम करने के लिए निर्भर रहना पड़ता है

  • database.notifications.service.gov.uk पर 1 सेकंड TTL वाला AWS Route53 DNS रिकॉर्ड बनाया गया, फिर migration script ने AWS की DNS weight को बदलकर 100% target database location पर भेजने के लिए सेट किया और TTL expire होने तक 1 सेकंड इंतज़ार किया—यह हिस्सा अजीब लगता है।
    उनका कहना था कि इसके बाद जब app अगली बार database को query करने की कोशिश करेगा, तो वह target database को query करेगा। क्या इसका मतलब है कि उनका ORM या Python का default behavior हर query पर DNS lookup करता है और block होता है?
    क्या वह resolved address को कुछ समय के लिए cache भी नहीं करता, और connection pooling या reuse भी नहीं करता?

    • शायद OS का getaddrinfo या gethostname यही behavior दे रहा होगा। Python system-level calls को शायद ही reimplement करता है, इसलिए यह system settings पर निर्भर करता है।
      अगर 1 सेकंड TTL का पालन हुआ, तो यह 1 सेकंड के लिए cache हुआ होगा, लेकिन DNS lookup libraries और खासकर caching DNS servers का TTL को पूरी तरह न मानना भी असामान्य नहीं है। सच कहें तो यह observed downtime के कुछ हिस्से को explain कर सकता है।

  • अच्छा है। हमने अभी RDS पर करीब 2TB data और 8 databases वाले 3 Postgres clusters को Postgres 14 से 16 पर migrate किया। 00:00 से 04:00 तक downtime रहा।
    पहले हमने Cloudflare Workers पर चलने वाली बहुत हल्की alternate site, यानी “maintenance mode”, enable की और Terraform से DB इस्तेमाल करने वाली सभी apps को 0 पर scale down किया।
    AWS web UI में upgrade button दबाकर pg_upgrade से 14→15 किया, उसके complete होने का इंतज़ार किया, फिर दोबारा दबाकर 15→16 किया।
    हमने database के connections accept करना शुरू करने तक इंतज़ार किया; हालांकि ready दिखने से पहले भी वह connections accept करता लग रहा था, और ऐसा लगा कि AWS pg_upgrade के अलावा भी कुछ और कर रहा था।
    इसके बाद VACUUM ANALYZE; REINDEX DATABASE CONCURRENTLY शुरू किया। मकसद versions के बीच performance issues से बचना और नए version की performance improvements का लाभ लेना था।
    हमने apps को फिर से start करना शुरू किया, सभी apps में कुछ containers up होने का इंतज़ार किया, फिर traffic लेना शुरू किया, maintenance site बंद की और सोने चले गए।
    REINDEX CONCURRENTLY सबसे बड़े DB पर 18 घंटे और चला, लेकिन उसने कुछ भी block नहीं किया।
    अगली बार downtime से बचने के लिए AWS Blue/Green deployment इस्तेमाल करने की योजना है। इस बार नहीं कर पाए क्योंकि हम 14.9 पर नहीं थे, जो Blue/Green द्वारा supported 14 की minimum minor version है।
    अगर मैं खुद करूँ, तो AWS cost दिए बिना logical replication और load balancer से Blue/Green खुद configure करूँगा।

    • मैं होता तो in-place upgrade के लिए pg_upgrade --hardlinks इस्तेमाल करता।
      अपने on-premises Postgres instance पर 2TB DB भी 1 मिनट से कम में कर चुका हूँ।

  • GOV.UK Notify, GDS द्वारा UK public institutions को दी जाने वाली services के bundle का हिस्सा है। इसके साथ GOV.UK Pay और GOV.UK PaaS भी हैं, और इसे मूल रूप से Government As A Platform के नाम से जाना जाता था।

  • DMS एक बेहद खराब migration tool है। कई migration issues से लगभग एक महीने तक जूझने के बाद हमने हार मान ली।
    यह text और json types migrate नहीं कर पाया, और AWS support भी कोई समाधान नहीं दे सका।
    हमने शुरुआती testing phase में AWS Blue/Green इस्तेमाल किया, और उसी की वजह से लगभग zero-downtime upgrade हकीकत बन पाया।

    • अगर आपको लगता है कि DMS खराब migration tool है, तो इसे external target पर continuous replication के लिए इस्तेमाल करके देखिए।
      यह पूरी तरह टूटा हुआ है।

  • दिलचस्प है, लेकिन समझ नहीं आता कि सरकार शुरुआत से ही AWS क्यों इस्तेमाल कर रही है। यह कोई ऐसा startup नहीं है जो product-market fit खोजने के लिए hacking कर रहा हो, और न ही यह marketing-driven traffic spike का अनुमान न लगा पाने पर उससे निपटने की स्थिति है
    उन्हें पता है कि ऐसी service लंबी अवधि में चाहिए, और usage patterns का भी काफी अच्छा अनुमान लगाया जा सकता है
    वे public-sector cloud बना सकते हैं या कोई तर्कसंगत on-premises approach अपना सकते हैं। इसके लिए funding, coordination और technical leadership चाहिए, लेकिन लंबे समय में यह taxpayers के लिए भारी लागत बचाएगा
    public-sector IT आम तौर पर गड़बड़ होती है, लेकिन मुझे पता है कि उसके भीतर काम करने वाले अच्छे engineers भी हैं

    • एक startup के तौर पर “cloud”, यानी PaaS, इस्तेमाल करने की वजह traffic spikes संभालना नहीं, बल्कि focus है
      hard disks और drivers, या उनके cloud version—storage और Ansible जैसी चीज़ों—के पीछे भागते हुए बिताया गया 1 घंटा, ग्राहकों को चाहिए चीज़ बनाने में इस्तेमाल नहीं हो पाता
      सरकार के लिए यह अलग क्यों होना चाहिए?
      हम उम्मीद नहीं करते कि सरकार अपनी cars खुद बनाएगी; हम उम्मीद करते हैं कि वह Volkswagen या Renault से खरीदेगी। भले ही सरकार की transport needs साफ़ तौर पर हों। फिर IT infrastructure खुद बनाने पर इतना जोर क्यों है, समझ नहीं आता
    • अगर आपको लगता है कि सरकार की जरूरतें और demand predictable हैं, तो आपने politics, खासकर पिछले 10 साल की UK politics, follow नहीं की है
      और pandemic जैसी चीज़ें भी होती हैं जो बिल्कुल अप्रत्याशित रूप से सामने आ जाती हैं। pandemic के दौरान demand के हिसाब से scale कर पाना इस बात का एक मुख्य demonstration case था कि public sector को commercial public cloud इस्तेमाल करना चाहिए
    • पूरी UK government बड़े public clouds और कुछ on-premises/colocation को साथ में चलाती है
      Gov.UK के कई iterations और clouds के बीच migration पर सितंबर की presentation https://youtube.com/watch?v=mpY1lxkikqM&pp=ygUOUmljaGFyZCB0b... देखने की सलाह दूंगा
      कम से कम UK government में procurement requirements के कारण हर कुछ साल में usage-based quote को फिर से market में रखना पड़ता है
      उदाहरण के लिए, अगर Oracle Cloud की कीमत एक-दसवां हो, तो उसके contract जीतने की संभावना ज्यादा होती है; फिर contract period के दौरान Oracle पर migrate करना होगा, और बाद में कोई और सस्ता cloud आए तो फिर से move करना पड़ सकता है
    • EU के कई देशों ने public cloud बनाए होंगे। Croatia में मैंने इसे खुद अनुभव किया था, और मैं उन developers में से था जिन्हें उस पर deploy करना पड़ा
      यह मेरी जिंदगी में देखी सबसे खराब चीज़ों में से था। मैंने VB.NET, Web Forms, पुराने SharePoint, Basic, यहां तक कि पूरी app के एक विशाल stored procedure के ढेर जैसी legacy चीज़ों के साथ भी काफी काम किया है, फिर भी
      AWS, Azure, Google Cloud कम से कम end user, यानी developer, को ध्यान में रखकर बनाए गए थे। इसके उलट government cloud को ऐसे lowest bidder ने design और build किया था जिसका पहला लक्ष्य हर संभव जगह cost काटना था
    • UK के बारे में नहीं जानता, लेकिन US में AWS काफी समय से GovCloud देता रहा है, और सच कहूं तो मैंने वहां जो बहुत-सा infrastructure देखा है उसकी तुलना में यह लगभग वरदान है
      इसके उलट, मैंने German government healthcare institution के in-house datacenter चलाने वाले वाकई बेहतरीन infrastructure/operations लोगों से भी मुलाकात की है। वहां समस्या technology या लोग नहीं थे, बल्कि management और processes 100% समस्या थे, जो infrastructure team और engineering team के बीच हर interaction में bottleneck बनना चाहते थे