CIO Point of View = “R E S T”

There are four major C-Level business issues that all CxO level would like to solve.   They are:  R.E.S.T.

R = Revenue
E = Expense
S = Security & Compliance
T – Time to Market

Kind Regards,
Doddi Priyambodo

VMware NSX Use Cases in Real World IT Production

NSX Overview

 


NSX Overview 3


These are some use cases for VMware NSX, detail of each use cases will be explained in another post thread.

Use Case 1 : Network Segmentation
Use Case 2 : Microsegmentation for Securing VDI Infrastructure
Use Case 3 : Intelligent Grouping for Unsupported Operating Systems
Use Case 4 : Automated Security in a Software Defined Data Center (ex: Quarantine zone)
Use Case 5 : Advanced Security (IDS/IPS) Insertion – Example: Palo Alto Networks NGFW
Use Case 6 : ‘Collapsed’ DMZ
Use Case 7 : Integrate Dev, Test and Prod environment into single infrastructure
Use Case 8 : Securing access to and from Jump Box servers
Use Case 9 : Multisite Networking and Security (Cross vCenter)
Use Case 10 : DC Consolidation/Migration – Mergers & Acquisitions
Use Case 11 : Hybrid/Public Clouds Integration
Use Case 12 : Disaster Recovery
Use Case 13 : Self Service IT
Use Case 14 : Fast Application Deployment of template
Use Case 15 : Islands of Unused Compute Capacity
Use Case 16 : Compute Asset Consolidation
Use Case 17 : Reducing capital outlay in expensive HW devices by NSX Edge Services

 

Kind Regards,
Doddi Priyambodo

Pertanyaan Teknis yang diajukan saat vSphere Design during Requirement Analysis

Saya coba merangkum sekilas saja mengenai beberapa pertanyaan teknis dasar yang biasa diajukan saat kita melakukan Requirement Analysis / Design Workshop engagement dengan customer.

Berikut ini adalah beberapa high level questions yang biasa saya ajukan, dan melakukan penggalian lebih dalam berdasarkan pertanyaan tersebut. (Note: ini adalah pertanyaan2 teknis, jadi bukan diajukan ke business person or C level. So, to find the correct audience is important)

  • Compute: To gather information regarding the planned target Compute infrastructure
  • Storage: To understand the current and expected storage landscape
  • vCenter: To describe the state of vCenter to manage the ESXi environment
  • Network: To gather information around current and target network infrastructure
  • Backup & Patching: To understand the current backup and patching methodology.
  • Monitor: To analyze current and expected the Monitoring processes
  • VM Workloads: To analyzie the details of the current physical workloads to be virtualized and consolidated
  • Security: To understand detail the current security practices.
  • Processes & Operations: To understand the current operation procedures and processes
  • Availlaibility & Disaster Recovery: to gather information on Business Continuity Processes

Breakdown lebih detail dari pertanyaan tersebut diatas, bisa saja dilakukan lebih detail, contohnya sebagai berikut:

  • Compute: tipe hardware, network, disk, merk, redundancy, processor, koneksi storage, booting, automation, scalability, dll
  • Storage: SAN/NAS/iSCSI/NFS/VSAN, IOps, Latency, storage technology, cloning/snapshot, replication, dll
  • vCenter: linked mode, appliance, database decision, disk size, cpu memory size, pre-requirements, dll
  • Network: leaf spine, backbone technology, bandwith, VLAN, VXLAN, teaming, VPC, link aggregation, distributed switch, vendors, dll
  • Backup and Patching: storage backup, 3rd party backup, VDP, VADP, Update Manager, dll
  • Monitor: items to monitor, centralized log server, performance, capacity, usage, tresshold, alert, placement, dll
  • VM Workloads: user growth, IOps, Tier1/Tier2/Tier3, mission critical, OS clustering, Java/Oracle/SQL Server/SAP, dll
  • Security: firewall ports, virus protection, distributed firewall, hardening system, lockdown mode, access, dll
  • Processes and Operations: SLA agreements, private/public/hybrid strategy, budget/scope constraint, unique processes, dll
  • Availability & DR: RPO, RTO, VMware HA, Fault Tolerance, Active-Active DC. Bandwith and Hops, priority protected VMs, dll

Semoga bermanfaat.

Kind Regards,
Doddi Priyambodo

Scrum Day Asia 20121123 – AGILE SOFTWARE DEVELOPMENT LIFE CYCLE USING SCRUM

In this post, I will share one of my presentation slide when implementing agile methodology for software development in one of my previous company.

This full presentation material was conducted at Scrum Day Asia event (Nov 23rd, 2012) in Bandung, Indonesia. Me and other speakers (Joshua Partogi, Salma Desenta, Wirawan Winarto) were hoping to change the nature of SDLC from traditional to agile, and making software developers to be a rockstar team!. Also presented about this topic (with a different slide, but almost the same) in other events such as Project Management Institute event in Microsoft, and IBM Innovation Day event.

I personally love the page number 57 in this slide. In one of our Scrum Retrospective Meeting, one of my team member said (put a post-it in the restrospective wall) : “with scrum, it’s not our fault. not your or my fault. it’s our problem. it’s always ours. not yours or mine”

 

Semoga bermanfaat. Selamat menikmati.

Kind Regards,

Doddi Priyambodo

How to do agile Software Development menggunakan Scrum?

Berikut ini saya lampirkan penjelasan mengenai cara software development dengan mengimplementasikan metode scrum. Dimana scrum ini adalah salah satu metode/practice untuk mengimplementasikan agile software development. Saya membuat slide ini beberapa tahun yang lalu, saya rasa masih sangat relevan untuk dunia saat ini. Bahkan, saya rasa lebih relevan untuk diimplementasikan saat ini daripada dulu!

Pada seri berikutnya, akan saya lampirkan juga tools apa yang saya gunakan waktu mengimplementasikan scrum ini di team saya.

 

Selamat menikmati 🙂

Bagaimana membuat agile Infrastructure untuk mendukung dunia Aplikasi yang agile

Berikut ini adalah beberapa slide presentasi lama yang saya buat (waktu saya masih kerja di IBM Indonesia), saya simpan di Slideshare (saat ini sudah diakusisisi oleh Linkedin sebesar US$119M!)

Materi dari presentasi ini adalah, untuk kebutuhan Software Development. Saat ini mekanisme untuk pembuatan aplikasi sudah menuju ke tahapan “Dev-Ops”, dimana kecepatan untuk melakukan release ke production dari tahapan development sudah sangat cepat. Sehingga dibutuhkan infrastruktur yang juga agile, tidak hanya metodologi development-nya saja yang agile.

Actually ada beberapa slide yang membutuhkan penjelasan via whiteboarding session, mungkin nanti kalau sempat akan saya jelaskan lebih lanjut di blog ini.

 

Selamat menikmati 🙂

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

Business Continuity (BC) vs Disaster Recovery (DR) in VMware Site Recovery Manager (SRM) Design – (RPO, RTO, WRT, MTD)

Business Continuity vs Disaster Recovery

DR : – we hoped it would never happen, but it has…
       – get the business running again ASAP
       – it is a tactical and technical movement
BC : – C level executive
       – who, what, where, and when is needed
       – not simply technical, whole of business need to be considered

RPO, RTO, WRT, MTD (Recovery Point Objective, Recovery  Time Objective, Work Recovery Time, Maximum Tolerable Downtime)

This is a simple explanation about RPO and RTO. Also the explanation about WRT and MTD, because there are few customers understand this terms completely. But, we need to discuss about these criteria during our design of Disaster Recovery. Especially if we want to implement VMware SRM (Site Recovery Manager).

 

Consider the following scenario.

Stage 1: Business as usual

At this stage all systems are running production and working correctly.

Stage 2: Disaster occurs

BCDR-02

On a given point in time, disaster occurs and systems needs to be recovered. At this point theRecovery Point Objective (RPO) determines the maximum acceptable amount of data loss measured in time. For example, the maximum tolerable data loss is 15 minutes.

Stage 3: Recovery

BCDR-03

At this stage the system are recovered and back online but not ready for production yet. The Recovery Time Objective (RTO) determines the maximum tolerable amount of time needed to bring all critical systems back online. This covers, for example, restore data from back-up or fix of a failure. In most cases this part is carried out by system administrator, network administrator, storage administrator etc.

Stage 4: Resume Production

BCDR-04

At this stage all systems are recovered, integrity of the system or data is verified and all critical systems can resume normal operations. The Work Recovery Time (WRT) determines the maximum tolerable amount of time that is needed to verify the system and/or data integrity. This could be, for example, checking the databases and logs, making sure the applications or services are running and are available. In most cases those tasks are performed by application administrator, database administrator etc. When all systems affected by the disaster are verified and/or recovered, the environment is ready to resume the production again.

BCDR-05

The sum of RTO and WRT is defined as the Maximum Tolerable Downtime (MTD) which defines the total amount of time that a business process can be disrupted without causing any unacceptable consequences. This value should be defined by the business management team or someone like CTO, CIO or IT manager.

This is of course a simple example of a Business Continuity/Disaster Recovery plan and should be included in your Business Impact Analysis (BIA).

Referenced from: http://defaultreasoning.com/2013/12/10/rpo-rto-wrt-mtdwth/

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
8.2
VERY GOOD
20% 20% 20% 20% 10% 10%
Enterprise Chef 11.4 9 8 7 9 8 9
8.3
VERY GOOD
20% 20% 20% 20% 10% 10%
Puppet Enterprise 3.0 9 9 9 9 9 9
9.0
EXCELLENT
20% 20% 20% 20% 10% 10%
SaltStack Enterprise 0.17.0 9 8 9 9 9 9
8.8
VERY GOOD

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

VMware TCO / ROI Calculator User’s Guide

You can directly use the Tool in this link = http://http://roitco.vmware.com/

You can read the detail description of TCO in here = http://www.vmware.com/pdf/TCO.pdf

 

This is some simple User Guide on How to use the Tool :

The VMware TCO Calculator was developed jointly by VMware, Inc. and ex-Gartner ROI / TCO experts from Alinean, Inc. to provide a Total Cost of Ownership (TCO) and Return on Investment (ROI) analysis for implementing VMware solutions to virtualize your IT environment including datacenter server infrastructure, testing/development labs and desktops.

You can quickly assess potential cost savings by completing five easy steps:

Step 1: Fill out a Simple Survey Questionnaire

Answer a few questions about your company (such as the type of industry you are in, and location) and which of the VMware solution sets you are most interested in:
1. Data Center Server Consolidation Cost Savings (Using VMware Infrastructure 3)
2. Virtual Lab Automation Benefits (Using VMware Lab Manager)
3. Desktop Control and Manageability Cost Savings (Using VMware Virtual Desktop Infrastructure VDI)

For each selected solution area of interest, you will be asked five to ten additional questions  about your existing assets such as the number of servers or desktops you intend to virtualize,  and about cost reduction opportunities such as current server management, management  activities, storage and other metrics.

Default metrics are provided for all of the questions based on Alinean research regarding your specified industry and location. These defaults can be reviewed and adjusted to best match your own unique metrics. This is the only information that is necessary to get a quick estimate of potential cost savings and return on investment (ROI)!

Step 2: Customize Assumptions

The tool uses over 200 additional metrics to help calculate a credible and achievable costbenefit / ROI analysis. Each of the 200 metrics is set using default assumptions based on the metrics you provided on the questionnaire regarding your industry, location, assets and current cost opportunities, and using industry average and third party research. All of these values are preset using this research, but can be easily reviewed and refined by clicking on the “View/Edit Default Assumptions” link on the bottom right corner of each solution set on the Questionnaire page. You can then review each default assumption and make adjustments to
precisely reflect your current environment and actual costs as needed. For a quick analysis, you can skip this step, revisiting the default assumptions for refinement later.

Step 3: Review Total Cost Savings and Return on Investment (ROI)

Click on the “Next” button to see your customized cost savings, comparing your current (As Is) total cost of ownership (TCO) over the next three years (managing a non-virtualized / business as usual environment), and the cost savings and business benefits estimated for a virtualized VMware environment. Key metric and financial improvements are summarized at the top, while specific details for each solution are provided in the tables, graphs and charts. For each selected VMware solution, you can click on the solution name in the table or the tab to view cost savings / benefit, investment and ROI details for VMware Infrastructure 3, VMware Lab Manager and VDI independently.  Continue reading VMware TCO / ROI Calculator User’s Guide