Baru minggu lalu,
konferensi pengembang Microsoft
Build2019 terbesar
diadakan . Setelah pergi ke sana, saya mengejar 2 gol.
- Tujuan pertama adalah untuk memahami ke mana Microsoft akan pergi dalam hal pengembangan dan apa teknologi dan pendekatan yang dipromosikannya.
- Tujuan kedua adalah untuk memahami keadaan komunitas di sekitar Microsoft. Build - sebuah konferensi publik - memberikan gagasan yang lebih baik tentang ini daripada konferensi internal Microsoft untuk karyawannya. Di acara publik, Anda dapat menarik kesimpulan bahkan pada jumlah orang yang datang ke sesi tersebut.
Bagi saya sendiri, saya telah mengidentifikasi beberapa topik utama yang ingin saya bagikan pemikiran saya:
- .Net Framework Roadmap
- Kubernetes
- Tanpa server
- Komputasi tepi
- Big Data, Pembelajaran Mesin, Kecerdasan Buatan
- Platform Presentasi Windows
.Net Framework Roadmap
Di Build2019, ada laporan oleh
.NET Platform Overview dan Roadmap . Saya sangat merekomendasikan menonton dan membaca
Memperkenalkan. NET 5 ,
C # 8 dan laporan terpisah tentang C # 8 -
Masa Depan C #
- Pengamatan saya sejak pengumuman .net core 3.0 adalah sebagai berikut: pembuatan .net core / .net standar sangat benar, tetapi dalam .net, seperti pada platform lain, banyak kode telah terakumulasi yang tidak dapat diambil dan ditransfer seperti ini. Dan, oleh karena itu, Anda perlu membawa .net inti / roti standar ke proyek lama dengan modifikasi minimal. WinForms / WPF dibawa ke opensource, rilis berikutnya sudah dengan standar .net di bawah tenda, dan Anda bisa melupakan struktur lama file csproj dan mendapatkan lebih banyak bonus. Hal-hal memang benar, tetapi mereka juga disebabkan oleh fakta bahwa warisan juga harus didukung.
- Baik untuk platform seluler, UWP tidak lagi diingat, dan hanya Xamarin untuk pengembang C # yang tersisa.
- Di stand tim .Net Core saya mengajukan pertanyaan: “Dan perubahan besar apa yang Anda rencanakan untuk dibuat di .Net 6-7-8? Dan akankah Anda memiliki alasan untuk meningkatkan versi utama produk setiap tahun? " Kebanyakan saya menyukai bagian dari jawaban yang saya terjemahkan, saya mengerti betapa “ini adalah visi, dan bagaimana nanti, kita akan lihat nanti. „
- Saya memiliki pemikiran yang sama tentang C # 8, serta tentang semua rilis setelah async / tunggu, yang benar-benar mengubah gaya pemrograman di C #. Dan segala sesuatu yang lain, tentu saja, menyenangkan dan menambahkan gula sintaksis, tetapi latar belakang Async / Await tampak agak pudar. Tetapi kode ini menjadi kurang dan kurang seperti klasik C #. Apa yang akan Anda katakan pada kode seperti itu, jadi pada tahun 2012

Tapi apa yang saya tidak suka tentang sesi ini adalah upaya gigih untuk sekali lagi menekankan kepada semua pengembang .net / C # kebutuhan untuk mengetahui, memahami dan
menggunakan Machine Learning, Cognitive Services , dll setiap hari.
Tentu saja, pengembang yang cerdas harus memahami hal-hal seperti itu, belajar, dan berlatih, jika memungkinkan. Tetapi, dalam 99% kasus, ini tidak diperlukan dalam proyek, dan penginjilan yang terus-menerus seperti itu, terus terang, mulai mengganggu.
Sejujurnya, saya tidak benar-benar percaya pada masa depan proyek-proyek seperti Spark.Net, yang dibahas dalam sesi ini. Pengalaman mengingatkan kita bahwa upaya serupa untuk menulis Wrappers dalam C # atau sepenuhnya mem-porting proyek data ke C # selama 10 tahun terakhir biasanya berakhir tanpa apa-apa, karena komunitas lebih kecil dan bahasanya tidak begitu sulit untuk diubah.
Setelah Build2019, ada
pengumuman bahwa .Net Framework 4.8 adalah versi utama terbaru dari .Net Framework dan hanya akan ada perubahan kecil. Semua dalam semua, saatnya untuk. Net Core.
Fabric Layanan vs Kubernetes
3 tahun di Microsoft, dan selama hampir setengah tahun di EPAM, saya tidak bisa memberikan penjelasan teknis yang normal tentang mengapa Anda membutuhkan Service Fabric (dan Anda, pada saat yang sama, tidak bekerja di Microsoft), jika ada Kubernetes.
- Untuk waktu yang lama, "penerjemah" mengatakan bahwa ini adalah platform yang sama, tetapi ini tidak demikian (google elementer).
- Kemudian ada pembicaraan bahwa SF lebih matang untuk pengembangan Windows, dan Kubernetes untuk Linux.
- Nah, pada saat yang sama, kata mereka, di SF pengembang Anda akan dapat menggunakan keterampilan mereka di Lingkungan Windows, dan di K8 Anda perlu belajar Linux dan mempelajari kembali. Saya setuju, kode warisan dan kebutuhan untuk mempelajari kembali-mempelajari kembali adalah argumen yang serius, tetapi di sisi lain, SF cukup rumit, dan menurut saya itu tidak lebih mudah daripada K8. Nah, di satu sisi, Linux perlu dipelajari dan diketahui pula. Bahkan ke “ladang angin” yang keras (aku juga). Di sisi lain, abstrak Kubernet cukup banyak dari ini.
Di Build2019, saya mengakhiri untuk SF, karena ada
1 laporan tentang itu
(meskipun judulnya tentang Mission Critical ***) .
Dan menurut potongan Kubernetes 20-30 di semua bagian. Saya hanya akan memberikan bagian yang saya rekomendasikan untuk dilihat dalam proyek saya.
DevopsMenurut pendapat saya, Microsoft menyerah dan menerima kenyataan - komunitas .net, pada kenyataannya, tidak menerima Fabric Layanan.
Tetapi Kubernetes telah menjadi standar bahkan untuk dunia .net, yang dengannya saya mengucapkan selamat kepada Anda dan saya.Kekurangan Server untuk semua orang
Namun, banyak yang dikatakan tentang komputasi ServerLess. Tapi, jika sebelumnya hanya Fungsi Azure dan Aplikasi Logika yang dibungkus dengan saus ini, sekarang bahkan Azure SQL Database ServerLess telah terpancing (ketika saya melihat pengumuman, saya sangat terkejut karena ada sesuatu yang salah, dan ServerLess SQL terdengar menarik).
Di sisi lain, Serverless dapat diluncurkan tidak hanya di Azure, tetapi juga secara lokal di dalam wadah. Dengan demikian, Serverless menjadi lebih dapat dimengerti dan kurang magis (insinyur biasanya tidak suka sihir, karena mereka tidak mengerti cara kerjanya ... dan jika tidak berhasil, maka cara memperbaiki sihir).
Inti dari
SQL Serverless adalah Anda dapat menentukan batas bawah dan atas pada sumber daya yang dikonsumsi dan Anda akan membayar di batas bawah, ditambah apa yang Anda konsumsi antara batas bawah dan atas. Sebuah fitur minor yang dapat Anda jeda SQL (dan tidak membayar sumber daya komputasi) jika database tidak digunakan (Anda dapat menjeda selama 6 jam sekarang), saya tidak akan mempertimbangkannya, karena sehingga tidak akan ada satu permintaan ke database selama beberapa jam sama sekali - ini adalah situasi yang sangat aneh, karena setidaknya ada pemantauan, dan pangkalan akan mulai (seperti yang dijanjikan) dalam 30-60 detik, yang juga penting.

Subscription Edge atau Cloud Computing di lebih dari Microsoft Data Center
- Suatu ketika, pada 2008-2010, Microsoft mengatakan sesuatu seperti ini: "Di sini Anda memiliki Layanan Cloud ajaib kami, tulis ulang aplikasi Anda untuk mereka (Peran Web / Pekerja) dan Anda akan bahagia." Kebahagiaan tidak berhasil, karena Warisan merusak segalanya.
Lalu mesin virtual muncul, tetapi sekarang tidak masalah.- Kemudian, ketika menjadi jelas bahwa bahkan sekarang beberapa orang dapat sepenuhnya pindah ke Cloud, Anda masih perlu membuat solusi Hybrid. Pada awalnya, ini berarti VPN ke Azure. Kemudian datang Azure Stack (kompleks perangkat keras-perangkat lunak yang mirip dengan Azure di API dan dapat menahan beban Produksi di atasnya jika regulator tidak mengizinkan penerbitan di Cloud Publik, dan tetap dev / uji dengan data anonim di Cloud Publik)
- Kemudian semua jenis solusi IoT menjadi modis dan populer (untuk Microsoft dan pemain besar lainnya ... telemetri ditulis untuk waktu yang lama). Pada awalnya, dalam skenario Connected Factory (Factory / assembly line), mereka menyarankan menggunakan solusi dari Azure Cloud, tetapi industri menjelaskan bahwa Latency di antara pabrik mereka bisa jauh lebih tinggi daripada yang diizinkan dan menghentikan jalur perakitan karena Internet "yang berkedip" tidak memungkinkan. keputusan.
- Akibatnya, pertama kali muncul Azure IoT Edge, yang, meskipun diunduh dari Azure, tetapi berfungsi dan memproses data pada perangkat keras Anda (Anda memerlukan host yang kompatibel dengan Docker, yang setidaknya kadang-kadang terhubung ke Internet), tetapi pada awalnya ia memiliki serangkaian fitur yang sangat sederhana. Pembicaraan yang baik tentang topik ini adalah Azure IoT Edge & AI: Mengaktifkan Intelligent Edge
- Kemudian, ketika IoT Edge terbukti bermanfaat (untuk konsumen dan untuk keuangan Microsoft), layanan yang sebelumnya dianggap Cloud Only mulai tampak seperti jamur. Misalnya, Layanan Kognitif datang ke Edge. Kontrol kualitas visual produk pada jalur perakitan atau konveyor jauh lebih mudah dilakukan dari wadah buruh pelabuhan lokal daripada merakit latensi ke Pusat Data Azure.
- Tetapi di Build2019, banyak dari layanan ini yang go public atau muncul sebagai pratinjau (saya suka Layanan Pidato untuk sintesis pidato sebagian besar dari semua pratinjau. Itu sangat kurang pada perangkat tanpa akses internet yang konstan).
- Pada saat yang sama, itu ditunjukkan, diumumkan oleh SQL Server, itu Edge ( Sederhanakan Arsitektur Edge dengan Azure SQL Database Edge ).

Tidak, SQL 2017 telah lama berjalan di Linux di Docker, tetapi membutuhkan memori 3,5 GB. Versi ini juga dioptimalkan untuk memori (500MB <dan berjalan pada prosesor ARM), untuk perangkat Edge (biasanya ada sedikit memori pada mereka). Dan pada saat yang sama ada karya Streaming Seri-Waktu dan Analisis Built-In, yang terdengar sangat menarik. - Selain itu, solusi Hardware untuk Secure IoT berbasis Azure Sphere diluncurkan.
- Mereka menunjukkan peralatan komputasi Azure Edge , yang tidak diragukan lagi topiknya dipantau dengan ketat.
True box, saya lebih menyukai migrasi data ke Azure karena Terlihat lebih solid.
Big Data, Pembelajaran Mesin, Kecerdasan Buatan
Di area ini, saya akan menulis dari sudut pandang mantan pengembang (walaupun tidak ada mantan pengembang), dan bukan ahli data.
Sangat sering saya bertemu dengan posisi "menarik" dari beberapa pelanggan bahwa IaaS harus dilakukan di Aws, PaaS di Azure dan Data di GCP. Orang tidak bisa tidak setuju bahwa secara historis masing-masing penyedia mengkhususkan diri dalam sesuatu, tetapi sekarang, jika Anda melihatnya dalam jumlah besar, dalam banyak layanan paritas telah tercapai (perbedaan dalam nuansa, tentu saja, tetap). Integrasi solusi antara berbagai penyedia Cloud tentu saja merupakan pekerjaan yang menarik dan tambang emas, tetapi sebagai aturan, itu sangat tidak efisien bagi pelanggan itu sendiri (Anda selalu harus membayar untuk lalu lintas keluar, tetapi ada juga latensi dan kompleksitas / kompleksitas solusi).
Mungkin arah yang paling menjanjikan untuk Microsoft / Azure dalam waktu dekat dari sudut pandang uang baru adalah bekerja dengan data - "halo" Spark / Hadoop / Kafka, Data danau dan banyak layanan yang lebih menarik, tetapi pada saat yang sama dengan topik hangat (seseorang tidak suka pada hype untuk melakukan penjualan) seperti kecerdasan buatan (Mereka lagi menunjukkan kepada kita Cortana, lagi mereka menunjukkan kepada kita mobil pintar). Jumlah pengumuman, dan yang paling penting kasus (kadang-kadang sintetis, dan kadang-kadang bahkan menunjukkan klien yang bahagia) tentang penggunaan layanan Big Data di Azure di konferensi itu tidak masuk akal. Menurut AI saja, ada 37 sesi (ada 171 di antaranya untuk keseluruhan Build2019, jika kita kurangi laporan koridor 15 menit dan sesi pemrograman untuk siswa.). Bahkan ada laporan DevOps untuk Big Data, platform Windows AI dan AI untuk PowerBI. Sebagian besar teknologi ini bersifat open source, semuanya didorong oleh komunitas dan hadir di ketiga penyedia besar. Beberapa tahun yang lalu, saya akui, saya tidak ingat pendekatan aktif untuk layanan Data.
Salah satu sesi yang ingin saya sebutkan adalah sesi Windows Presentation Platform (WPP). Sejujurnya, saya tidak sengaja berpikir bahwa ini adalah tentang Windows Presentation Foundation (WPF), tetapi saya terkejut bahwa topiknya lebih luas dari yang diharapkan.
Setelah kembali pada tahun 2009, ketika WPF baru saja diluncurkan, topiknya populer: hosting kontrol WinForms di aplikasi WPF, atau sebaliknya - mencoba memasukkan kontrol WPF di WinForms. Itu semua dari apa yang sering tidak mungkin untuk mengambil dan membalikkan potongan-potongan besar aplikasi ke kerangka kerja baru. Dalam rilis pertama, fitur-fitur tersebut tidak diiklankan, tetapi ketika menjadi jelas bahwa kompatibilitas harus ditarik, mereka mulai aktif mempromosikan.
Jadi, pada tahun 2019, kami membahas bagaimana meng-host
kontrol U
WP di WPF (kepulauan XAML) , dan cara
memisahkan komponen UI dan sistem operasi di WinUI 3.0 (mis.
Menyuplai kontrol / kompiler / runtime sebagai paket nuget dan tidak menunggu Pembaruan Windows .)
Idenya bagus, tetapi itu perlu dilakukan di versi pertama UWP, karena saat itu tim Entity Framework telah menghapus EF dari .net Framework beberapa tahun yang lalu untuk berhenti tergantung pada Pembaruan Windows. Dan apa yang menjadi .Net Core adalah dalam pengembangan.
Dan yang paling penting, ini akan tersedia tidak hanya untuk versi terbaru Windows 10, tetapi juga cukup lama, tetapi masih relevan. Sebuah aula besar disediakan untuk sesi ini, tetapi ada cukup ruang kosong di aula (pengembangan untuk Windows telah dikubur selama sekitar 10 tahun), tetapi ini bukan intinya. Ada sangat sedikit anak muda di aula (saya membandingkannya dengan sesi di Asp.Net Core atau, terutama, Machine Learning). Ini hanya pengamatan subjektif saya, saya tidak berurusan dengan pengembangan pemakaman untuk Windows.
Microsoft Ecosystem for Developers
Sebagai seorang insinyur lapangan di Microsoft, saya secara resmi hanya mendukung apa yang dilakukan Microsoft sendiri. Dari pendekatan ini, pengetahuan tentang segala sesuatu berhenti berkembang. Sekarang saya telah meninggalkan Microsoft dan menjadi Solution Architect, sudah sangat penting untuk mengisi celah ini. Dan di Build ada pameran seluruh solusi untuk mitra dan pengembang, di mana Anda bisa pergi ke stan mana pun dan mengajukan pertanyaan, meminta demo. Saya menghemat minggu dengan mengunjungi stan-stan ini.
- Anda masih dapat menggunakan SonarQube untuk mengelola utang teknis (kualitas kode, bukan arsitektur tentunya)
- Ada solusi DevOps khusus pada Kubertenes yang jauh lebih mudah digunakan daripada Azure DevOps
- Ada solusi menarik seperti Aqua (aquasec) / Snyk untuk mengaudit konten gambar buruh pelabuhan dan kontainer yang sudah berjalan.
- Ada solusi menarik untuk memantau dan melacak aplikasi terdistribusi yang memiliki keunggulan dibandingkan ELK dangkal atau Monitor Azure (Wawasan Aplikasi + Analisis Log) seperti Signalfx
- Saya sudah diam tentang R # dan lingkungan pengembangan di .net dari Jetbrains (Saya ingat tentang R # tetapi tidak menggunakannya, karena saya menulis sedikit dan karena itu tidak mendengar banyak tentang lingkungan pengembangan).
- Itu penuh dengan semua jenis solusi berdasarkan AI / ML / Data, dll., Tetapi saya tidak terlalu banyak membahasnya, karena Saya tidak memiliki pengalaman praktis dalam solusi Big Data industri dan saya tidak akan dapat menilai manfaatnya.

Pengumuman
Sejujurnya, secara pribadi pengumuman tahun ini (di
sini dan di
sini ) tidak menyakiti saya, dan saya tidak terlalu mengingatnya. Pada komputer kuantum, bagus untuk melakukan hype, tetapi tidak terlihat bahwa ini adalah teknologi saat ini. Dan tidak ada lagi yang benar-benar diingat.
Kata penutup
Sebenarnya, saya mengharapkan lebih banyak perwakilan dari industri non-industri Microsoft telah lama menyatakan bahwa ia berusaha membantu bisnis dengan proyek, dan bukan itsniknik. Ya, tentu saja, ada laporan dengan
Airbus ,
BMW ... tapi saya berharap lebih.
Office365 bukan topik saya, jadi saya memutuskan untuk tidak mempertimbangkan masalah ini.
Semua hal di atas adalah pendapat pribadi saya, berdasarkan pengamatan dan pengalaman saya sebelumnya. Saya tidak berpura-pura objektif. Anda dapat mendiskusikan tesis apa pun.