Bagaimana saya bisa memastikan konsistensi antara layanan microser baru?


10

Organisasi saya mengalami ledakan layanan mikro. Saat ini kami tidak memiliki cara formal untuk mem-bootstrap proyek baru. Saya menemukan bahwa sebuah tim akan mendatangi saya dengan bug dalam penerapan atau proses pembangunan mereka, dan saya akan menghabiskan waktu hanya untuk menyadari bahwa saya sudah menyelesaikannya di proyek lain. Ada juga banyak ketidakkonsistenan antara proyek yang ingin saya lihat terstandarisasi.

Perubahan sering melibatkan file tunggal (mis. Serverless.yml atau Makefile) sehingga solusi yang melibatkan pustaka bersama misalnya submodules git tampaknya tidak dapat dijalankan. Setiap proyek akan memiliki set konfigurasi sendiri yang perlu dipertahankan, misalnya Dockerfiles atau serverless.yml, sehingga solusi manajemen konfigurasi terpusat untuk VM tidak benar-benar berlaku.

Bagaimana saya bisa memastikan bahwa layanan microsoft baru sesuai dengan standar organisasi dan menyertakan perbaikan bug / fitur dari proyek yang ada dengan cara yang mudah dan intuitif untuk pengembang yang ingin memulai proyek baru? Apa saja praktik terbaik untuk menyelesaikan masalah ini?

Alur kerja kami saat ini adalah meminta orang di sebelah Anda "proyek apa yang harus saya klon untuk digunakan sebagai templat?" dan kemudian hapus semua hal yang tidak perlu untuk proyek itu.

Jawaban:


5

Saya akan menambahkan jawaban tentang apa solusi saya sejauh ini, tetapi saya masih sangat tertarik mendengar bagaimana organisasi lain memecahkan masalah ini dan praktik terbaik yang mereka miliki.

Untuk mengatasi masalah tidak memiliki basis yang konsisten untuk membuat proyek, ide saya adalah membuat repositori (repositori?) Pelat / templat dan menggunakan cookiecutter sebagai alat untuk merancah layanan-layanan mikro baru. Dengan cara ini, setiap proyek dibuat dari basis standar dengan semua pelajaran yang telah kami pelajari sebagai sebuah organisasi yang terintegrasi dengannya. Setiap perubahan yang kami buat dapat diintegrasikan ke hulu ke dalam repositori boilerplate. Saya membayangkan kita akan memiliki template untuk gambar Nodejs Docker, Serverless SPA, Python lambdas, dll.

Untuk mengatasi masalah perubahan yang dibuat pada templat yang disebarkan ke hilir untuk setiap proyek, solusi saya adalah menerapkan proses di mana pemilik layanan microser menyadari perubahan pada templat dan kemudian bertanggung jawab untuk menyebarkan perubahan tersebut ke layanan Microsoft mereka.


Inilah yang kami lakukan, dikombinasikan dengan aplikasi hello world sederhana yang menggambarkan praktik terbaik sebagai contoh nyata.
Boikot SE untuk Monica Cellio

4

Gunakan manajemen konfigurasi / sistem penyebaran otomatis. Inilah yang dirancang untuk ini. Hal-hal seperti Kubernetes, Puppet, Chef, Ansible, dan Salt Stack dirancang untuk tujuan ini dan dapat digunakan dengan templat Golden Master, skrip kickstart, Amazon AMI atau hanya sebuah wadah Docker. Ini memungkinkan Anda untuk menggunakan templat basis default dan kemudian lapisan peran tambahan. Ini akan memastikan bahwa bangunan didokumentasikan secara lengkap (sebagai kode) dan akan cepat dan mudah digunakan untuk produksi, dan akan digunakan tepat secara identik dengan apa yang dirancang atau menggunakan contoh tambahan ketika kebutuhan untuk skalabilitas atau redundansi muncul atau ada sesuatu yang rusak. Perubahan / pembaruan juga dapat diintegrasikan dengan cara ini. Sama seperti Anda merilis pembaruan perangkat lunak, Anda dapat merilis pembaruan untuk konfigurasi Anda dan kode konfigurasi dapat dikelola sama seperti kode perangkat lunak Anda dikelola - dalam repo yang sama dan dengan alur kerja yang sama. Dan ketika waktu pemutakhiran tiba, tidak ada misteri bagaimana hal itu dibangun, lihat saja skripnya.

Salah satu cara sistem manajemen konfigurasi melakukan ini adalah melalui penggunaan templating yang berat untuk file konfigurasi Anda. Misalnya, umumnya ada banyak garis yang akan sama atau serupa di lingkungan Anda. SaltStack menggunakan templat jinja dan boneka menggunakan templat Ruby Tertanam . Menggunakan AWS sebagai contoh, Anda mungkin perlu mengatur, tombol api, peran IAM, wilayah (atau secara acak memilih wilayah dari daftar wilayah), VPC, dll yang semuanya sama di semua contoh. Tetapi kemudian Anda harus memiliki fungsi dan output yang unik. Atau lebih baik lagi Anda dapat menulis modul boneka atau formula garam yang mendefinisikan "kontrak" dan menggunakan kontrak tersebut (definisi api) untuk input dan output yang menyelamatkan Anda dari keharusan mengkonfigurasi layanan microsoft Anda dua atau tiga tempat.

SaltStack misalnya baru-baru ini mengadakan pertemuan untuk membahas skenario khusus ini . Selain itu, SaltStack juga dapat mengelola dan menggunakan wadah buruh pelabuhan secara asli . (Boneka juga memiliki modul untuk Docker ) Demikian juga Ansible memiliki buku pedoman dan dokumen untuk bekerja dengan penyebaran tanpa server dan wadah Docker .

Juga, jika Anda ingin melanjutkan tema / paradigma tanpa server Anda, Wayang , Anonim, dan Saltstack semuanya tidak memiliki master atau mendukung mode tanpa master, jika Anda ingin melanjutkan tema ini.


Saya telah menambahkan beberapa contoh dan klarifikasi untuk pertanyaan saya. Manajemen konfigurasi tidak benar-benar membantu karena setiap proyek mandiri dalam konfigurasinya. Tidak ada masalah dengan migrasi ke konfigurasi sebagai kode, ini tentang mempertahankan konfigurasi sebagai kode dan perluasan konfigurasi yang bisa Anda dapatkan jika Anda memiliki 100 layanan mikro masing-masing dengan konfigurasi yang berbeda. Saat ini kami menggunakan CI / CD dengan build yang konsisten sehingga tidak menjadi masalah juga.
user2640621

1
@ user2640621 - pernahkah Anda menggunakan sistem manajemen konfigurasi? Memusatkan "konfigurasi konfigurasi" membantu Anda mengelolanya dengan lebih mudah dan dari satu tempat (bukan 100 tempat yang berbeda). Sementara setiap proyek mungkin mandiri, jelas ada beberapa tumpang tindih saat Anda bertanya tentang penempatan templating. Mungkin patut dicoba pasangan di sanbox untuk merasakan bagaimana mereka bekerja sebelum Anda menghapusnya ... Ini tidak hanya mengotomatiskan pengelolaan file konfigurasi Anda - itu jauh lebih dari itu.
James Shewey

1
Saya telah menggunakan SaltStack, Chef, dan Wayang, tetapi hanya untuk mengelola VM. Terima kasih atas jawaban Anda, saya pasti melihat bagaimana manajemen konfigurasi dapat digunakan di luar mengelola VMs sekarang.
user2640621

2
@ user2640621: Jika semuanya berbeda: "Anda kode, Anda jalankan". Biarkan tim mengelola operasi layanan mereka. Biarkan mereka merasakan sakit Anda.
Pasang kembali Monica - M. Schröder

3

Pertanyaan ini luas sehingga jika jawaban saya sedikit tidak masuk akal jangan ragu untuk menambahkan konteks dan contoh spesifik sehingga saya memiliki pemahaman yang lebih baik.

Menggunakan gambar mesin seperti AMI AWS akan memungkinkan Anda untuk membuat gambar dasar atau emas, yang kemudian dapat Anda pelihara dan distribusikan atau terapkan dalam pengiriman berkelanjutan Anda. Dengan menggunakan arsitektur ini Anda memastikan bahwa setiap microservice dikerahkan pada perangkat keras yang konsisten dengan konfigurasi yang identik sehingga setiap masalah yang Anda hadapi terkait dengan konfigurasi microservice / aplikasi.

Anda dapat melanjutkan ketidakterbatasan ini dengan penambahan alat konfigurasi seperti Ansible dan Packer. Dengan menggunakan manajemen konfigurasi, Anda dapat menyediakan gambar mesin dengan apa pun yang Anda inginkan (termasuk aplikasi). Packer kemudian akan memungkinkan Anda untuk mengambil snapshot dari gambar mesin itu dan setiap penyebaran akan sama.

Dengan menggunakan contoh ini Anda dapat 'memanggang' AMI dasar dengan paket, pembaruan, dan konfigurasi yang benar yang diinstal dengan bantuan Ansible dan Packer. Selain itu, Anda bisa melihat 'Ansible-Pull' untuk menyelesaikan penyebaran dengan menarik kode aplikasi, membuat perubahan apa pun, dan menggunakan layanan Microsoft di atas gambar dasar itu.

Namun saran paling penting yang bisa saya berikan adalah hanya dengan memberikan solusi yang dapat didukung dan dipelihara oleh seluruh organisasi. Layak untuk mencoba membangun SDLC yang memecahkan serangkaian masalah khusus Anda, sesuai dengan budaya dan sikap kepemimpinan, dan merangkul praktik arsitektur modern.

Saya telah bersama tiga organisasi dan kami telah mengambil tiga pendekatan yang sangat berbeda.

Semoga berhasil!


Kami tidak menggunakan solusi berbasis VM (kebanyakan Serverless dan sedikit Docker), tetapi saya akan mencoba menerapkan masalah saya ke contoh Anda. Ketika seseorang ingin membuat gambar pengepak baru, di mana mereka akan mulai? Jika setiap proyek mandiri dan tidak ada repositori pusat untuk konfigurasi pengepak, apa yang mereka gunakan sebagai basis mereka untuk membuat gambar? Mungkin salah satu perbedaannya adalah bahwa proyek yang sedang saya kerjakan mencoba menjadi mandiri mungkin, tanpa ketergantungan pada layanan terpusat seperti Ansible di mana Anda dapat memperbarui konfigurasi Anda untuk semua proyek sekaligus.
user2640621

Dengan arsitektur tanpa server dan berbasis Docker Anda masih dapat menerapkan dasar-dasar ini. Salah satu strategi saya adalah mempertahankan file docker dasar. Anda dapat membangun file buruh pelabuhan berbasis-centOS yang mencakup beberapa konfigurasi yang Anda harapkan pada setiap layanan mikro, kemudian masing-masing tim dapat menarik file buruh pelabuhan itu dan membangun file buruh pelabuhan khusus layanan mikro mereka sendiri di atas itu. Untuk membantu dengan manajemen kontainer dan penyebaran berkelanjutan, Anda dapat menggunakan alat seperti Kubernetes.
Chad
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.