Teknologi Azure untuk proses build

Selesai

Dalam unit ini, Anda mempelajari hubungan antara proses inovasi dan beberapa teknologi dalam industri yang dapat membantu Anda membangun fungsionalitas baru ke dalam aplikasi.

DevOps

Setelah memulai fase pembuatan untuk memvalidasi hipotesis inovasi Anda, siklus pengembangan, integrasi, dan penyebaran yang diperlukan harus dibuat semudah mungkin. Fase ini adalah tempat DevOps masuk. Anda dapat menentukan DevOps sebagai "proses dan alat untuk memberikan fitur perangkat lunak dengan cepat dan andal." Berikut adalah detail tentang definisi ini:

  • Proses dan alat: DevOps, dan proses inovasi sebagai keseluruhan, didasarkan pada pola budaya yang mendorong perubahan. Azure dan GitHub menawarkan perkakas yang baik terkait DevOps, tetapi membeli lisensi tidaklah cukup. Proses dan budaya organisasi Anda perlu berkembang untuk mencakup perubahan dan inovasi.

  • Penyampaian cepat fitur perangkat lunak: Proses dan alat DevOps mencakup konsep gagal secepat mungkin. Membangun MVP atau prototipe untuk memvalidasi dengan cepat apakah fitur tempat Anda bekerja berjalan ke arah yang benar adalah inti dari konsep DevOps.

  • Penyampaian andal fitur perangkat lunak: Organisasi anti perubahan sering kali mengaitkan perubahan cepat dengan gangguan. Namun, Azure DevOps menjanjikan sebaliknya: laju perubahan cepat dan tingkat keandalan yang tinggi. Keandalan ini dimungkinkan dengan mengintegrasikan pengujian pada tahap awal siklus pengembangan, dalam proses yang disebut "geser ke kiri."

    Jika pengembangan fitur di seluruh waktu dilihat sebagai garis dari kiri ke kanan. Kemudian, proses pengembangan warisan akan melakukan validasi pengguna dan kontrol kualitas di akhir siklus pengembangan. Di ujung "kanan" dari baris itu. Namun, Azure DevOps menyarankan Anda untuk menguji dan memvalidasi sedini mungkin, di "kiri" garis waktu tersebut.

DevOps mewujudkan konsep inti budaya inovasi sehat yang sama. Mengadopsi metodologi ini adalah kunci untuk mencapai siklus inovasi yang cepat.

Arsitektur layanan mikro

Modularitas adalah teknik umum untuk mengurangi kompleksitas dalam merancang sistem yang kompleks. Jika sistem adalah interaksi kompleks dari banyak bagian yang tidak dapat dipisahkan (sering disebut "monolit"), interdependensi komponen yang ketat membuat peningkatan sistem menjadi sulit. Setiap perubahan perlu divalidasi dengan sistem lainnya, sehingga memperumit proses pengujian.

Jika sistem modular, Anda dapat memisahkannya menjadi subsistem yang lebih kecil yang berinteraksi satu sama lain melalui antarmuka yang terdefinisi dengan baik. Memperkenalkan perubahan di salah satu subsistem ini lebih mudah, karena selama antarmukanya dengan modul lain tetap konstan, sistem keseluruhan terus berfungsi.

Arsitektur layanan mikro adalah pola aplikasi yang memanfaatkan modularitas. Aplikasi dibagi menjadi komponen kecil yang terpisah yang dapat dikembangkan secara independen satu sama lain, bahkan mungkin menggunakan bahasa pemrogram yang berbeda. Setiap komponen, atau layanan mikro, dapat beroperasi sendiri. Anda dapat menskalakannya sesuai kebutuhan, Anda dapat memecahkan masalahnya sebagai satu unit, Anda dapat memodifikasinya secara independen dari layanan mikro lainnya.

Pertanyaan yang sering ditanyakan organisasi adalah apa yang harus dilakukan jika aplikasi monolitik. Haruskah organisasi mendesain ulang aplikasi menjadi arsitektur layanan mikro sebelum memperkenalkan inovasi, atau dapatkah proses inovasi dan desain ulang berjalan secara paralel? Tidak ada satu jawaban untuk pertanyaan ini. Hal ini bergantung pada kompleksitas dan relevansi bisnis aplikasi yang dipertimbangkan.

Tailwind Traders dihadapkan pada pertanyaan ini saat mencoba memperkenalkan inovasi di platform e-niaga mereka. Keputusan diambil untuk memulai proyek guna mendesain ulang aplikasi e-niaga menjadi arsitektur layanan mikro, karena kekritisan bisnisnya membenarkan upaya ini. Tidak adanya aplikasi modular akan sangat mengganggu kemampuan Tailwind Traders untuk bereaksi terhadap tren yang terus berubah di pasar online.

Namun, Tailwind Traders membuat keputusan untuk mengatasi beberapa celah utama di platformnya pada saat yang sama. Menunggu selesainya proyek desain ulang aplikasi berarti kehilangan pangsa pasar signifikan untuk permulaan baru yang saat ini mengganggu pasar e-niaga.

Proyek-proyek tersebut adalah berinteraksi satu sama lain, dipandu oleh nilai bisnis inovasi. Upaya desain ulang adalah berfokus pada area aplikasi yang paling penting, di mana kebutuhan modifikasi untuk meningkatkan pengalaman pelanggan adalah yang tertinggi.

Kontainer

Teknologi kontainerisasi tidak eksklusif untuk arsitektur layanan mikro, tetapi konsepnya bekerja sama. Kontainer adalah cara untuk merangkum kode aplikasi dan dependensinya sehingga dapat disebarkan dengan mudah di platform apa pun.

Penyebaran aplikasi tradisional mengharuskan organisasi menginstal perangkat lunak terlebih dahulu, seperti runtime aplikasi, pustaka pemrograman, atau komponen eksternal. Pendekatan ini sering kali mengakibatkan masalah "berfungsi di mesin saya": lingkungan yang sama sulit direplikasi dalam pengembangan, pengujian, penahapan, dan produksi. Perbedaan kecil dalam cara dependensi aplikasi diinstal dapat menyebabkan aplikasi berfungsi dengan baik saat diuji, tetapi gagal saat disebarkan ke produksi.

Kontainer mengubah aturan permainan. Dependensi aplikasi dikemas bersama dengan kode aplikasi dalam unit penyebaran otonom yang disebut gambar kontainer. Apakah kontainer aplikasi disebarkan pada laptop pengembang atau dalam kluster produksi dengan ratusan simpul, penanganan dependensinya sama. Kontainer bekerja dengan cara yang sama persis, sehingga pengujian aplikasi lebih dapat diandalkan dan dapat dipercaya.

Kontainer telah berkembang pesat sejak Docker merilis kode mereka sebagai sumber terbuka pada tahun 2013. Kontainer sekarang mendukung Linux dan Windows, dan arsitektur CPU yang berbeda. Ada banyak penawaran di Azure yang memungkinkan beban kerja berbasis kontainer berjalan. Di unit ini, Anda belajar tentang beberapa dari mereka.

Kube dan Red Hat OpenShift

Runtime kontainer adalah teknologi yang memulai kontainer di komputer, tetapi memerlukan lebih banyak logika di lingkungan produksi. Siapa menyebarkan lebih banyak kontainer jika diperlukan lebih banyak performa? Siapa menghidupkan ulang kontainer jika mengalami masalah? Jika beberapa komputer tersedia, siapa yang memutuskan kontainer tertentu mana yang harus dimulai? Tugas tersebut dan tugas lainnya adalah tanggung jawab platform orkestrasi kontainer.

Kube versi pertama dirilis pada tahun 2015, dan segera menjadi standar de facto untuk orkestrasi kontainer. Kluster Kube terdiri dari beberapa simpul pekerja. Setiap simpul pekerja memiliki runtime kontainer, sehingga dapat menjalankan kontainer di mana sarana kontrol Kubernetes menjadwalkan penyebaran aplikasi dalam kontainer. Sarana kontrol ini biasanya berjalan dalam satu set simpul inti. Sarana ini bertanggung jawab untuk menjaga aplikasi tetap berjalan dengan benar, meningkatkan atau menurunkan skala aplikasi, dan melakukan pembaruan yang diperlukan.

Salah satu alasan utama popularitas Kubernetes adalah kemandirian perangkat keras yang disediakan kontainer. Karena aplikasi berbasis kontainer dapat disebarkan secara andal ke runtime kontainer, kamu dapat menjalankan Kube di cloud yang menggunakan berbagai hypervisor. Aplikasi yang disebarkan harus berperilaku dengan cara yang sama (dengan asumsi bahwa sumber daya perangkat keras yang mendasarinya juga serupa). Oleh karena itu, banyak organisasi telah mengadopsi Kube sebagai lapisan abstraksi yang memungkinkan proses penyebaran aplikasi yang konsisten baik di lokal maupun di awan publik lain.

Menjalankan Kube di Azure itu mudah. Azure Kubernetes Service mudah disebarkan dan hemat biaya, karena pelanggan hanya dikenakan biaya untuk node pekerja. Microsoft membawa biaya dan pengoperasian sarana kontrol yang berisi komponen inti. Microsoft menambal dan memperbarui sistem operasi simpul pekerja, semakin mengurangi kompleksitas operasional pengelolaan kluster Kubernetes untuk menjalankan kontainer Linux dan Windows.

OpenShift adalah platform penyebaran aplikasi berdasarkan Kubernetes, dikembangkan dan didukung oleh Red Hat. Ini menggabungkan banyak fungsionalitas lainnya. Beberapa organisasi yang memilih untuk menjalankan aplikasinya di OpenShift melakukan demikian dikarenakan fitur tambahan tersebut dan dukungan yang diberikan oleh Red Hat. Menjalankan OpenShift di Azure juga mudah. Azure Red Hat OpenShift terdiri dari kluster OpenShift tempat Microsoft mengelola banyak aspeknya, termasuk seluruh siklus hidup kluster.

Azure App Service

Azure App Service adalah platform tempat organisasi dapat menjalankan beban kerja berbasis web mereka tanpa harus mengelola orkestrator atau sistem operasi yang mendasarinya. Satu-satunya persyaratan adalah mengunggah kode aplikasi ke layanan melalui salah satu metode penyebaran yang tersedia. Azure melakukan sisanya: menskalakan aplikasi masuk dan keluar, menambal dan memelihara komputer virtual yang mendasar, dan banyak lagi, tanpa memerlukan kurva pembelajaran Kubernetes.

Azure App Service mendukung beban kerja berbasis kontainer, sehingga Anda dapat mengunggah gambar kontainer, bukan kode aplikasi. Ini juga mendukung beban kerja Linux dan Windows dan banyak runtime aplikasi yang berbeda.

Azure App Service mendukung berbagai model harga, termasuk opsi tanpa server yang disebut Azure Functions. Di Azure Functions, hanya penggunaan aplikasi yang dikenakan biaya. Tidak ada biaya tetap.

Model tanpa server menarik untuk berinovasi, karena memungkinkan Anda menyebarkan layanan mikro baru tanpa menimbulkan tagihan bulanan yang tinggi jika pasar tidak menerimanya. Model ini adalah contoh lain dari strategi fail-fast, di mana inovasi tidak selalu berarti pengeluaran tinggi.

Azure App Service juga menawarkan fitur yang mendukung penyebaran berorientasi DevOps, seperti slot aplikasi web. Slot adalah area pentahapan tempat Anda dapat menyebarkan fitur baru tanpa memengaruhi lingkungan produksi. Slot sangat bagus dari perspektif inovasi, karena Anda dapat mengalihkan pilihan kecil pelanggan Anda ke versi baru aplikasi ini. Kemudian, Anda dapat memvalidasi apakah hipotesis inovasi Anda benar. Akhirnya, jika Anda ingin mempromosikan kode baru ke produksi, Anda dapat "menukar" slot sehingga lingkungan pentahapan menjadi versi produksi.

Ringkasan

Dalam unit ini, Anda telah belajar cara teknologi dapat mendukung inovasi:

  • Proses dan alat DevOps memberi tim pengembangan dan operasi Anda kekuatan super dalam memberikan fitur baru dengan cepat dan andal.
  • Anda dapat menyusun ulang aplikasi menjadi layanan mikro untuk memungkinkan inovasi pada komponennya satu per satu, tanpa memengaruhi sisanya.
  • Kontainer memungkinkan penyebaran aplikasi yang andal di berbagai platform dan lingkungan.
  • Kube adalah platform orkestrasi agnostik cloud untuk menjalankan aplikasi dalam kontainer.
  • Azure App Service dapat menjalankan beban kerja berbasis web dengan kelebihan pengelolaan minimum. Banyak fitur yang ditawarkan, seperti slot aplikasi atau tanpa server, untuk mempercepat siklus inovasi.

Tailwind Traders telah memutuskan untuk memulai desain ulang aplikasi e-niaga menjadi arsitektur layanan mikro. Subsistem aplikasi pertama yang dipisahkan dari "monolit" adalah layanan pembayaran, karena Anda telah mengidentifikasinya sebagai area penting di mana kompetisi menawarkan nilai yang lebih baik kepada pelanggan.

Setelah pembayaran subsistem, lebih banyak komponen aplikasi akan diubah menjadi layanan mikro independen. Layanan mikro dapat berkomunikasi melalui REST API. Kode aplikasi untuk setiap layanan mikro akan dikontainerisasi, dan organisasi pengembangan dan operasi adalah untuk mengadopsi praktik terbaik DevOps.

Karena Tailwind Traders tidak ingin bergantung pada cloud publik tertentu, diputuskan untuk membangun keahlian Kubernetes secara internal dan menyebarkan aplikasi pada kluster Azure Kubernetes Service. Jika layanan mikro baru perlu dikembangkan, perusahaan telah memilih untuk mempertimbangkan Azure Functions sebagai platform untuk penyebaran MVP untuk mengurangi biaya pengembangan.

Di mana berikutnya

Banyak konsep dalam unit ini diartikulasikan lebih lanjut dalam artikel Cloud Adoption Framework Memberdayakan adopsi dengan penemuan digital dan Kube dalam Cloud Adoption Framework.