Apa itu / definisi dari Virtualisasi dan Cloud Computing?

Walaupun saat ini sudah tahun 2015, dari pengalaman interaksi saya dengan teman-teman lainnya; ternyata masih ada beberapa IT profesional yang menanyakan apa itu “Virtualisasi” dan ujungnya nanti ke pertanyaan apa itu “Cloud Computing”? Dan pertanyaan yang paling mendasar: “Apa untungnya bagi perusahaan untuk mengimplementasikan dua hal tersebut?

Jika kita tanya ke beberapa orang, browsing ke beberapa site, kemungkinan jawaban akan bermacam-macam dengan beberapa definisi yang masing-masing pasti ada benarnya juga. Tapi prinsip jawabannya kemungkinan adalah sama. Menurut saya, definisi virtualisasi dan cloud computing adalah sebagai berikut :

Saya mendefinisikan Virtualisasi sebagai abstraction/pemecahan dari sebuah computing resource dari computing resource lainnya. Yup, se-simple itu (lihat gambar di samping). Contoh: server virtualization maksudnya kita mengabstraksi/memecah operating system dari sebuah server.

Saat ini dengan adanya teknologi virtualisasi, perusahaan dapat menjalankan beberapa operating system dan beberapa aplikasi diatas hardware milik mereka saat ini, dan kebutuhan pembelian hardware baru hanya benar-benar dilakukan jija kapasitasnya memang membutuhkan untuk itu. Sudah tidak jamannya lagi perusahaan membeli server baru jika ada aplikasi baru yang harus di-deploy.

Dengan melakukan penumpukan workloads bersama-sama menggunakan teknologi virtualisasi, maka perusahaan bisa mendapatkan value yang lebih besar dari investasi hardware yang dilakukan oleh mereka. Selain dapat mengurangi biaya pembelian hardware baru (CAPEX/Capital Expenditure). Perusahaan kini juga dapat mengurangi biaya operasional (OPEX/Operational Expenditure) karena jumlah server dan jumlah hardware lainnya (ex: storage, router, etc) yang berkurang secara drastis di datacenter; dan akhirnya juga berefek ke penggunaan listrik, penggunaan pendingin ruangan, atau besarnya datacenter yang dibutuhkan. Pengurangan operational cost akan sangat signifikan. Cara ini yang biasanya disebut sebagai mekanisme “konsolidasi” resources.

Selain manfaat konsolidasi diatas, jika kita menerapkan teknologi virtualisasi, maka perusahaan juga dapat merasakan kenikmatan meningkatnya kualitas “uptime/high-availability” dari layanan anda, mekanisme disaster-recovery yang jauh lebih terencana, mekanisme monitoring asset anda yang lebih terintegrasi, pembuatan beberapa mekanisme otomasi untuk pembuatan server/layanan lain, dan belum lagi peningkatan security yang jauh lebih meningkat. Ujungnya, virtualisasi akan dapat membuat pondasi untuk mencapai konsep “Cloud Computing“.

Cloud Computing sendiri adalah sebuah konsep yang dibangun diatas filosofi dari akses network yang sangat luas, memiliki konsep resource pooling (pengumpulan resouce), memiliki kemampuan untuk memberikan layanan yang langsung bisa diakses oleh penggunanya (bukan administrator) secara langsung, layanan yang bisa diukur kualitasnya (dan bisa juga dikenai biaya berdasarkan itu), dan layanan yang sangat elastis untuk dapat mengikuti kebutuhan pengguna dengan cepat (menambah atau mengurangi resouce dengan cepat).

Implementasi teknologi virtualisasi adalah pondasi yang akan dapat membentuk konsep operasional model baru tersebut (“cloud computing”) dengan jauh lebih efektif dan efisien.


Kind Regards,
Doddi Priyambodo

Review: Puppet vs. Chef vs. Ansible vs. Salt

Once again, I am taking this article from another website (http://www.infoworld.com/d/data-center/review-puppet-vs-chef-vs-ansible-vs-salt-231308). It is a very good article that I would like to remember. So, that is the reason why I re-post it again in my blog.

Review: Puppet vs. Chef vs. Ansible vs. Salt

The leading configuration management and orchestration tools take different paths to server automation


The proliferation of virtualization coupled with the increasing power of industry-standard servers and the availability of cloud computing has led to a significant uptick in the number of servers that need to be managed within and without an organization. Where we once made do with racks of physical servers that we could access in the data center down the hall, we now have to manage many more servers that could be spread all over the globe.

This is where data center orchestration and configuration management tools come into play. In many cases, we’re managing groups of identical servers, running identical applications and services. They’re deployed on virtualization frameworks within the organization, or they’re running as cloud or hosted instances in remote data centers. In some cases, we may be talking about large installations that exist only to support very large applications or large installations that support myriad smaller services. In either case, the ability to wave a wand and cause them all to bend to the will of the admin cannot be discounted. It’s the only way to manage these large and growing infrastructures.

[ Read the individual reviews: Puppet • Chef • Ansible • Salt | Puppet or Chef: The configuration management dilemma | Subscribe to InfoWorld’s Data Center newsletter to stay on top of the latest developments. ]

PuppetChefAnsible, and Salt were all built with that very goal in mind: to make it much easier to configure and maintain dozens, hundreds, or even thousands of servers. That’s not to say that smaller shops won’t benefit from these tools, as automation and orchestration generally make life easier in an infrastructure of any size.

I looked at each of these four tools in depth, explored their design and function, and determined that, while some scored higher than others, there’s a place for each to fit in, depending on the goals of the deployment. Here, I summarize my findings.

Puppet Enterprise
Puppet arguably enjoys the biggest mind share of the four. It’s the most complete in terms of available actions, modules, and user interfaces. Puppet represents the whole picture of data center orchestration, encompassing just about every operating system and offering deep tools for the main OSes. Initial setup is relatively simple, requiring the installation of a master server and client agents on each system that is to be managed.

From there, the CLI (command-line interface) is straightforward, allowing module downloads and installation via the puppet command. Then, changes to the configuration files are required to tailor the module for the required task, and the clients that should receive the instructions will do so when they check in with the master or via a push that will trigger the modifications immediately.

There are also modules that can provision and configure cloud server instances and virtual server instances. All modules and configurations are built with a Puppet-specific language based on Ruby, or Ruby itself, and thus will require programmatic expertise in addition to system administration skills.


Test Center Scorecard
20% 20% 20% 20% 10% 10%
AnsibleWorks Ansible 1.3 9 7 8 8 9 9
20% 20% 20% 20% 10% 10%
Enterprise Chef 11.4 9 8 7 9 8 9
20% 20% 20% 20% 10% 10%
Puppet Enterprise 3.0 9 9 9 9 9 9
20% 20% 20% 20% 10% 10%
SaltStack Enterprise 0.17.0 9 8 9 9 9 9

Puppet Enterprise has the most complete Web UI of the bunch, allowing for real-time control of managed nodes using prebuilt modules and cookbooks present on the master servers. The Web UI works well for management, but does not allow for much configuration of modules. The reporting tools are well developed, providing deep details on how agents are behaving and what changes have been made.

Enterprise Chef
Chef is similar to Puppet in terms of overall concept, in that there’s a master server and agents installed on managed nodes, but it differs in actual deployment. In addition to a master server, a Chef installation also requires a workstation to control the master. The agents can be installed from the workstation using the knife tool that uses SSH for deployment, easing the installation burden. Thereafter, managed nodes authenticate with the master through the use of certificates.

Continue reading Review: Puppet vs. Chef vs. Ansible vs. Salt

Fight the FUD – Oracle Licensing and Support on VMware vSphere

In this post I will copy-paste one of the Best reading for Virtualizing Business Critical Applications from Michael Webster’s blog. This can explain that Oracle Database can be virtualized in VMware! Enjoy!

These are the source :






I keep hearing stories from Customers and Prospects where Oracle appears to be trying to deceive them for the purposes of extorting more license money from them than they are legally required to pay. I also keep hearing stories of Oracle telling them they would not be supported if they virtualized their Oracle systems on VMware vSphere. This has gone on now for far too long and it’s time to fight back and stop the FUD (Fear, Uncertainty, Doubt)!

In my opinion the best way for you to prevent this situation for your company is by knowing the right questions to ask, and by knowing what your obligations are. The aim for this article is to give you the tools to pay only what you legally owe, while making the most efficient and economic use of your licenses, and get the world class support that you are used to, even in a virtualized environment on VMware vSphere. All without sacrificing availability or performance.
I’m going to start this article by quoting Dave Welch, CTO, House of Brick – “I believe in paying every penny I owe. However, beyond that, it is my discretion to who or what I donate and in what amount. I have no patience with individuals or entities that premeditate the creation of OLSA compliance issues.  I similarly have no patience with the knowing spreading of FUD by some professionals in what could be construed as extortion of funds beyond customers’ executed contractual obligations. I will continue to vigorously promote and defend the legal rights of both software vendors and their customers even if that means I induce accelerated hair loss through rapid, frequent hat swapping.” Source Jeff Browning‘s EMC Communities article – Comments by Dave Welch of House of Brick on Oracle on VMware Licensing.

I agree with Dave on this. So I am going to show you how you can pay what you owe, while using what you pay for as efficiently and cost effectively as possible, and show you how you can still enjoy the full support you are entitled to. Without the scaremongering that sometimes accompanies discussions with Oracle Sales Reps.

For those that aren’t familiar with the term FUD, it is an acronym which stands for Fear, Uncertainty and Doubt. Something some companies and professionals seem to go to great lengths to create in the minds of customers.

FUD #1 – Oracle Licensing and Soft Partitioning
Oracle’s Server/Hardware Partitioning document outlines the different types of partitioning and how they impact licensing. Oracle may try and tell you that licensing a VMware environment will be more expensive as they don’t consider VMware Hard Partitioning. This is complete rubbish. This assertion is completely irrelevant unless you were only planning on deploying a single small database on a very small subset of a very large server. In this case you probably wouldn’t be using Enterprise Edition and may not be paying per CPU Core (Named User Plus instead). Why would you deploy such a system when you could easily purchase a server that is the right size for the job and licensed appropriately for the job? There is absolutely no requirement to run Oracle Enterprise Edition just because you are virtualizing your databases.

There is absolutely no increase in licensing costs over and above what you would have to pay for the same physical infrastructure to run your Oracle Database if you were running it in the OS without virtualization. You still have to pay what you owe, for what you use. The truth is that your costs could actually be significantly less when virtualizing on VMware vSphere as you can get more productive work done for the same amount of physical hardware, and therefore the license requirements and your costs will be significantly less. This is because you can run multiple Oracle databases on the same server and effectively share the resources, including memory, provided you take care during your design to ensure any undesirable performance impacts are avoided.  Take this image for example showing consolidating two dissimilar workloads on the same hardware (Source: VMware).

Continue reading Fight the FUD – Oracle Licensing and Support on VMware vSphere

VCDX – Supporting Documentation

Berikut ini, saya mengutip resource yang sangat baik dari http://vcdx133.com mengenai persiapan untuk mengambil sertifikasi VCDX. Sertifikasi tertinggi dari VMware Inc.

Once you have finished your design documents, you then have to prepare the supporting documentation.  The length of this task is very often underestimated by aspiring candidates, who either rush the job to make the submission and possibly have their application rejected due to incompleteness or miss their submission date.


List of articles in VCDX series:

  1. VCDX – Recipe for Success
  2. VCDX Study Plan – Networking
  3. VCDX Study Plan – Security
  4. VCDX Study Plan – Storage
  5. VCDX Study Plan – BC/DR
  6. VCDX Study Plan – Compute & vSphere
  7. VCDX – The Submission
  8. VCDX – The Presentation
  9. VCDX – D-Day
  10. VCDX – Think like a Panelist
  11. VCDX – I passed, now what?
  12. VCDX – Design Scenario Strategy
  13. VCDX – Troubleshooting Scenario Strategy
  14. VCDX – Mock Design Scenarios
  15. VCDX – Mock Troubleshooting Scenarios
  16. VCDX – Learn to speak “VCDXese”
  17. VCDX – How do I measure if my Customer Requirements are being met?
  18. VCDX – Logical & Physical Design Blueprints
  19. VCDX – Study Group Etiquette
  20. VCDX – Supporting Documentation

The term “Supporting Documentation” refers to the following documents/sections from the VCDX Blueprint:

  • Implementation Plan
  • Configuration Guide
  • Test Plan
  • Standard Operating Procedures

Assuming you have validated that your design meets your Customer’s Requirements, you now have to ensure that your supporting documentation will allow the design to be implemented, configured, tested and operated successfully.  This is where we separate the men from the boys, so much effort has gone into the design process, you then need to marshal your resources and push through the creation of the supporting documentation.

The strategy is very simple, create a linked list that maps from each physical design decision to the Implementation Plan, Configuration Guide, Test Plan and the SOPs.  This is summarised in the diagram below:


It is very important to maintain a unique numbering system throughout all of your documentation; this will allow you to quickly verify that all components and scenarios are covered and then collate them into a matrix to ensure that nothing is missed.  For example: supporting_documentation_template and supporting_documentation_matrix.


Source: http://vcdx133.com/2014/07/11/vcdx-supporting-documentation/



Berikut ini adalah Summary yang sangat baik untuk mengumpulkan Artikel mengenai Best Practice di VMware vSphere 5.5, saya mengutip dari blog Dan C Barber.







Source: http://www.datacenterdan.com/blog/vsphere-55-best-practices-summary


Agile Infrastructure Design to Support Software Development Life Cycle (SDLC)

Berikut ini adalah salah satu slide yang pernah saya buat sebagai bahan pertimbangan secara sekilas saja mengenai beberapa keuntungan dari Private Cloud yang dikhususkan penggunanya yaitu kepada para pembuat aplikasi (Software Developer).


Single Portal untuk melakukan seluruh kegiatan diatas (Capture, Deploy, Flexible Resource) dengan kemampuan Automation, Orchestration, dan Monitoring serta Chargeback akan sangat memberikan keuntungan yang maksimal bagi para application developer, dan juga infrastructure system administrator tentunya.