Minta saran implementasi cloud

[Endy Muhardin]

All,

Saya punya aplikasi web dengan Java.
Aplikasinya standar saja, tipikal aplikasi bisnis,
dideploy di Tomcat, menggunakan database MySQL.

Nah, mohon saran dari rekan2, sebaiknya bagaimana menaruh aplikasi
saya ini di cloud.
Provider mana saja yang bisa dipertimbangkan, berapa cost operasionalnya, dsb.

Thx before

--
Endy Muhardin
http://endy.artivisi.com

[Fajar A. Nugraha]

Artikel IBM taun kemaren:
http://www.ibm.com/developerworks/java/library/j-paasshootout/

--
FAN

2012/5/15 Endy Muhardin <endy.m...@gmail.com>:

[Endy Muhardin]

Thx infonya.
Maksud saya, versi dalam negerinya.
Kalo yang luar negerinya, selain yang di artikel itu, sekarang ada
lagi CloudFoundry-nya VMWare.

--
Endy Muhardin
http://endy.artivisi.com

2012/5/15 Fajar A. Nugraha <li...@fajar.net>:

> --
> The Power of Community
> FB:http://on.fb.me/JKO1hu
> Twitter: https://twitter.com/#!/cloud_indonesia
> Portal: http://cloudindonesia.org/

[Fajar A. Nugraha]

2012/5/15 Endy Muhardin <endy.m...@gmail.com>:

> Thx infonya.
> Maksud saya, versi dalam negerinya.

Emang ngaruh?

> Kalo yang luar negerinya, selain yang di artikel itu, sekarang ada
> lagi CloudFoundry-nya VMWare.

AFAIK kalo dalam negri ya paling sewa vps, configure sendiri. Dan
pengalaman salah satu rekan, walaupun providernya lokal, servernya
akhirnya pilih yang diluar juga karna lebih bagus :P

--
FAN

[Alex Budiyanto]

Nah menarik nih jadi bahan diskusi. Dari cloud provider yang ada di Indonesia, berapa sih yang beneran sudah "cloud". Kita ambil definisi cloud computing dari NIST disini:  http://www.nist.gov/itl/csd/cloud-102511.cfm  

Mungkin dari rekan2 yang sudah pernah pakai, bisa share pengalaman-nya disini.

Terima Kasih

--
Alex Budiyanto
http://alexbudiyanto.web.id/
http://facebook.com/alex.budiyanto
http://twitter.com/abudiyanto

[Endy Muhardin]

2012/5/15 Fajar A. Nugraha <li...@fajar.net>:

> 2012/5/15 Endy Muhardin <endy.m...@gmail.com>:
>> Thx infonya.
>> Maksud saya, versi dalam negerinya.
>
> Emang ngaruh?

Ngaruh di bandwidth.
Biasanya IIX unlimited.
Kalo pelanggan aplikasinya dalam negeri semua kan kenceng.

> AFAIK kalo dalam negri ya paling sewa vps, configure sendiri. Dan
> pengalaman salah satu rekan, walaupun providernya lokal, servernya
> akhirnya pilih yang diluar juga karna lebih bagus :P

Oh, berarti cuma ada sewa VPS aja ya, gak sampe PAAS.

[Agus Kurniawan]

coba hubungi isi? mereka udah implementasi cloudfoundry di local indonesia;)

Saya sih sedang testing mesin mereka pakai nodejs + mongodb;)

mesinnya masih di oprek2x kayaknya;)

ak

2012/5/15 Endy Muhardin <endy.m...@gmail.com>

[Erwin]

Sharing saja....
Saya sudah pakai ISI juga, perush dimana saya bekerja adalah Coal Mining...Alhamdulillah OK, baik system dan juga supportnya cepat/profesional.

Sorry bukan promosi ISI ya....tapi memang so far OK s/d saat ini.

Thanks, Erwin

2012/5/15 Agus Kurniawan <agus...@gmail.com>

[Ibrahim Arief]

Kencang atau tidak menurut saya ngga bisa dipukul rata dengan asumsi semua provider cloud dalam negeri lebih kencang daripada provider luar negeri. Kalau Endy pakai Google Search, mau datacenter terdekat di Singapur, tetap terasa kencang bukan?

Bicara kencang atau tidak, kayanya yang dimaksud latensi antara cloud app dengan user ya? Apakah latensi yang dimiliki cloud provider sekarang sudah cukup cepat atau belum kembali ke kebutuhan sistem kita masing-masing. Latensi 200 ms mungkin masih adequate untuk kebutuhan sebagian besar user web application. Latensi seperti ini tentu ngga acceptable kalau aplikasi yang kita bikin server buat game yang real-time.

Saya pakai Google App Engine, PaaS dari Google, dan selama ini latensi jaringan yang saya temukan ada di kisaran 200-500 ms round trip. Dan latensi ini tetap konstan meski kita scale up sampai ukuran berapapun, jadi masalah bandwidth udah ngga perlu dikuatirkan.

Jadi kalau bicara soal latensi dan bandwidth, saran saya adalah coba dulu benchmark PaaS yang ada, seberapa latensi yang mereka tawarkan. Kalau cloud providernya di Indonesia tapi infrastruktur mereka lemah juga latensi dan bandwidth yang user rasakan tetap lambat. Jangan terburu-buru mencari provider dalam Indonesia demi asumsi latensi yang mereka sediakan lebih kecil.

Cheers,

Ibam

2012/5/15 Endy Muhardin <endy.m...@gmail.com>

[Golek Upo]

Maaf ikut nimbrung ya. Kalo solusi open source sudah ada pengalaman nggak yg bisa dishare di sini? Apa plus minusnya dibanding yg propertiery?

Thanks & regard.

[Agus Kurniawan]

satu lagi ada yg lupa...

customer/client yg akses sistem dari mana? kalau semua dari indonesia nah itu yg dipikir. Menurutku pasang di indonesia;).

Kalau mix, yg porsi LN akses banyak, yg prefer diLN. Beberapa perusahan di indo ada yg sediakan server di local dan di LN.

Kl Google App, saya belum pernah coba. Yg sy coba windows azure, dimana waktu deploy saya bisa setting app supaya diletakan di asia, us atau eropa semua tergantung customer yg akses sistem. Mungkin bisa di share om ibrahim mengenai google apps nya;)

ngomongin jalur network. sekedar info, jalur network indonesia --> itu menjulur dari jkt- sg-- xxx --> us --> eropa beberapa ada yg bs ke eropa. Jd kl user byk di eropa sebaiknya di host di eropa atau us. Posisi US memang strategi untuk jalur ini. Semua kembali plan & strategi-nya;)

semoga kedepannya gak ada isu beginian, maklum msh ada kesenjangan bandwidth/speed koneksi antar lokasi;)

ak

2012/5/15 Ibrahim Arief <ibam....@gmail.com>

[Ibrahim Arief]

Betul sekali om Agus, mudah-mudahan makin lama kesenjangan bandwidth antar lokasi makin bisa diminimalisir. :)

Semua app di Google App Engine (note: Google App Engine berbeda dengan Google Apps) di-host di datacenter-nya Google, menggunakan infrastruktur dan low-level service yang sama dengan produk-produk Google lainnya. (e.g. Gmail, Google Plus) Kalau dari hasil sharing Google rep waktu beliau presentasi di kantor saya, app yang kita deploy sebenarnya di-replikasi di banyak datacenter Google di seluruh dunia. Jadi theoretically meski saya develop app di Eropa, kalau ada user dari Indonesia yang akses app saya, rekues tersebut diarahkan ke datacenter terdekat (e.g.  Singapura) dan app kita di-warm-up di sana. Hasil akhirnya latensi ke end user bisa seminimal mungkin.

Awalnya saya juga bingung kenapa App Engine ngga ngasih opsi deploy ke lokasi geografis tertentu, tapi ternyata gara2 mereka punya strategi replikasi di atas, lokasi deployment jadi kurang relevan, karena bisa dianggap app kita di-deploy ke seluruh dunia secara sekaligus. :D Selain Azure, Amazon Web Services juga punya opsi buat deploy app kita di lokasi geografis tertentu. Baik Azure maupun AWS bisa kita rekues supaya deploymentnya ke datacenter mereka di  Singapura.

Karena, seperti yang om Agus bilang, lompatan jaringan Indonesia ke Singapura relatif kecil, menurut saya develop cloud app menggunakan tiga PaaS di atas bisa cukup bersaing dengan IaaS dalam negeri. Seberapa bersaing? Kembali ke kebutuhan masing-masing, dan jangan lupa benchmark dulu supaya tahu latensinya sudah memadai atau belum untuk kebutuhannya. :)

Cheers,

Ibam

2012/5/15 Agus Kurniawan <agus...@gmail.com>

[Luki Ishwara]

Mas dhanank perdhana kayaknya bisa share tentang ini  :)

Sent from my Windows Phone

---

From: Golek Upo
Sent: 5/15/2012 5:35 PM
To: cloud-i...@googlegroups.com
Subject: Re: [Cloud-Indonesia] Minta saran implementasi cloud

Maaf ikut nimbrung ya. Kalo solusi open source sudah ada pengalaman nggak yg bisa dishare di sini? Apa plus minusnya dibanding yg propertiery?

Thanks & regard.

On 15 Mei 2012, at 17:27, Ibrahim Arief <ibam....@gmail.com> wrote:

[Endy Muhardin]

2012/5/15 Agus Kurniawan <agus...@gmail.com>:

> satu lagi ada yg lupa...
> customer/client yg akses sistem dari mana? kalau semua dari indonesia nah
> itu yg dipikir. Menurutku pasang di indonesia;).
> Kalau mix, yg porsi LN akses banyak, yg prefer diLN. Beberapa perusahan di
> indo ada yg sediakan server di local dan di LN.

Nah ini maksud saya mas Ibam.
Pengguna aplikasi saya 100% lokal.
Di banyak penawaran VPS atau colo, biasanya bandwidth IIX unlimited.

Begitu juga halnya di sisi user, pengalaman saya di rumah pakai S****y,
akses mirror Ubuntu lokal jauh lebih cepat daripada mirror internasional.

[Agus Kurniawan]

jelas pak, kalau 100% user local mendingan server local;). Saya testing sejak 2008 hingga sekarang, portal saya pecollege.net untuk host video itu servernya ada di local, erudeye.net ;). Krn user 99% local ya, mending di local hostnya;)

ak

2012/5/16 Endy Muhardin <endy.m...@gmail.com>

[Ronald Widha]

walau geo-affinity yang udah dibahas di atas sangat penting - Windows Azure bahkan punya Traffic manager ( https://www.windowsazure.com/en-us/home/features/virtual-network/) yang essentially bisa geo-load balance traffic; aku mau coba bawa balik diskusinya ke pertanyaan awal ya - gimana naruh aplikasi tersebut di cloud.

saya akan coba bikin bbrp asumsi di sini:

1. alasan mau pindah ke cloud karena tertarik untuk mengurangi komitmen awal (capital expense) dan lebih pilih utility model (pas as you use)
2. ga mau capacity planning buat peak karena traffic-nya seasonal. jadi butuh yang bisa elastis
3. pengen bisa scale out horizontally dengan "mudah"

With the assumptions above kita sudah nge-rule out VPS karena VPS biasanya butuh "reservasi" - misalnya kontrak 1 tahun dsb. Dan untuk nge-provision VPS baru akan butuh interaksi dengan supplier-nya jadi turn around timenya paling engga memakan waktu bbrp jam tidak sekedar menit (configuration changes/API call)

untuk membuat aplikasi kita siap untuk "cloud" (regardless PaaS maupun IaaS dan jg vendor agnostic) ada bbrp hal yang perlu diperhatikan:

1. keep it loosely coupled.
   SOA sangat penting bgt di cloud application. karena tight coupling adalah musuh skalabilitas. Bayangkan kalo kita punya seluruh komponen kita di deploy di sebuah unit komputasi, untuk nge-scale kita bakal nge-scale semuanya padahal mungkin cuma 1 komponen yang menjadi bottle neck. 
   componetize your app and define clear interfaces between them. each component should be able to scale out independently off each other.
   
2. point 1 mengharuskan kita untuk memastikan bahwa setiap komponen ga akan "freak out" kalo ada multiple instances of itself. 
3. point 2 biasanya membuat kita untuk membikin setiap komponen stateless dan asynchronous - biasanya implementasinya membawa kita untuk pake web service contracts & queueing mechanism
4. assume bahwa setiap komponen bisa fail. probabilitas satu komponen rusak akan lebih tinggi di cloud. jadi make sure setiap requestnya durable (ga ilang kalo processing failed) dan idempotent (ga error kalo diproses berkali-kali)
5. karena kita bisa nge-grow ke ratusan, ribuan (bahkan lebih) nodes - sebaiknya kita membuat aplikasi kita dengan fokus kemudahan ops. make the app/deployment etc automatable, repeatable dan monitorable

sumber: 

slide 27-33

http://www.slideshare.net/ronaldwidha/everything-you-want-to-know-about-windows-azure-but-were-afraid-to-ask

2012/5/16 Agus Kurniawan <agus...@gmail.com>

--

Ronald Widha
follow me on http://twitter.com/ronaldwidha
podcast tentang programming dan informatika http://www.temanmacet.com

[Fajar A. Nugraha]

2012/5/16 Ronald Widha <rea...@ronaldwidha.net>:

> With the assumptions above kita sudah nge-rule out VPS karena VPS biasanya
> butuh "reservasi" - misalnya kontrak 1 tahun dsb.

... itu kalo di provider lokal. Di luar mah umumnya nggak, karna kalo
masih gitu gak laku :P

> Dan untuk nge-provision
> VPS baru akan butuh interaksi dengan supplier-nya jadi turn around timenya
> paling engga memakan waktu bbrp jam tidak sekedar menit (configuration
> changes/API call)

s.d.a.

--
FAN

[Ibrahim Arief]

Thank you Ronald udah ngebawa diskusinya "kembali ke jalan yang benar". :) 

Regarding naruh aplikasi yang sudah didevelop sebelumnya di cloud, kita coba lihat dulu dari segi aplikasi yang mas Endy miliki dan hendak di-cloud-kan:

• Di-develop menggunakan Java.
• Di-deploy di Tomcat.
• Backing database-nya MySQL.

Menurut saya aplikasi seperti di atas cocok untuk di-migrasi-kan ke Google App Engine, dengan catatan cloud providernya tentu di luar Indonesia. Kembali ke mas Endy sendiri apa latensi dan bandwidth yang disediakan Google cukup memadai atau tidak bagi keperluan aplikasinya.

Poin-poin yang harus diperhatikan jika ingin migrasi aplikasi seperti di atas ke Google App Engine:

• Google App Engine support tiga bahasa pemrograman, salah satunya Java, jadi migrasi Java app supaya bisa jalan di App Engine cukup straightforward.
• Google App Engine Java support deployment Java Servlet secara langsung. Google milih Jetty sebagai Java servlet container-nya, jadi app yang di-develop untuk Tomcat bisa dimigrasikan dengan mudah ke GAE/J.
• Google support MySQL database di cloud dalam bentuk Google Cloud SQL. Pricing-nya baru di-publish beberapa hari lalu, bisa dilihat di sini.
• Google Cloud SQL terintegrasi baik dengan Google App Engine Java.

Sekarang, beberapa caveat mengenai Google App Engine Java yang harus diperhatikan agar migrasinya bisa berlangsung mulus:

• Versi JRE yang di-support oleh App Engine masih Java 6, ngga ada rencana buat upgrade support ke Java 7, tapi karena Java 7 ngga ngasih banyak improvement, Java 6 should do fine.
• App yang kita deploy di Google App Engine jalan di sandbox-nya Google. Ada beberapa kelas-kelas Java yang di-restrict oleh Google. Misalnya, buka socket buat komunikasi ngga diperbolehkan. Tujuan Google me-restrict ini sebenarnya bagus, kita jadi dipaksa mendesain app yang scalable dan ringan. Daftar kelas-kelas Java yang diperbolehkan untuk jalan di App Engine bisa dilihat di sini.
• Pengalaman saya, pembatasan kelas-kelas Java seperti di poin atas awalnya bikin frustrasi. Tapi banyak service yang disediakan Google untuk mengganti fungsionalitas kelas yang di-restrict yang pada akhirnya bikin app kita lebih scalable.
• Kalau mau lepas dari MySQL dan coba pake NoSQL datastore-nya Google, harus ada re-desain arsitektur database yang digunakan di app kita. Datastore Google sangat bagus karena bisa infinitely scalable, tapi paradigma key-value datastore sangat berbeda dengan paradigma SQL biasa.

Caveat-caveat lain yang generik, berlaku untuk cloud app manapun, serupa dengan yang Ronald list di atas, terutama poin 1-4. Bikin app kita as stateless as possible, misalnya, bisa jadi bakal makan banyak effort migrasi di awal, tapi pada akhirnya bikin app kita nicely scalable. Poin 5, tentang kemudahan deployment ketika scaling up, kurang relevan dengan App Engine karena deployment-nya sudah diurus otomatis sama underlying platform-nya Google.

In my opinion, web app seperti yang mas Endy deskripsikan di atas, kebanyakan operasinya bakal berkutat ke pemrosesan rekues yang ukuran payload-nya relatif kecil, tapi frekuensinya besar. Dalam hal ini latensi kecil lebih penting dibanding bandwidth besar, dan PaaS luar bisa jadi pertimbangan yang menarik. Kalau misalnya app yang mas Endy miliki banyak menangani I/O data dalam jumlah besar dari user, maka memang lebih cocok di-host di provider lokal. :)

Cheers,

Ibam

2012/5/16 Ronald Widha <rea...@ronaldwidha.net>

[Ronald Widha]

bam..langsung jadi blog tuh ayo copy paste trus publish ke cloudindonesia

2012/5/16 Ibrahim Arief <ibam....@gmail.com>

[Dhanank Perdhana]

Heheheh.. Belum ada yang bisa dishare. Saya baru coba XCP (turunan Citrix XenServer), selain juga CloudStack. Semoga nanti ada yang bisa dishare.

-- 

Salam,

Dhanank Perdhana

2012/5/15 Luki Ishwara <s...@y.fvck.eu>

[Endy Muhardin]

Wih, baru sempat lihat thread lagi, ternyata udah ada rekomendasi2
yang komprehensif.

Thx all atas sharingnya, coba saya akan explore lagi opsi GAE seperti
yang disarankan mas Ibam.
Yang udah kebayang bakalan rearchitecture lumayan signifikan ya
database backendnya kalau pengen pake Google Datastore.

--
Endy Muhardin
http://endy.artivisi.com

2012/5/21 Dhanank Perdhana <dha...@gmail.com>: