Data Center is our focus

We help to build, access and manage your datacenter and server rooms

Structure Cabling

We help structure your cabling, Fiber Optic, UTP, STP and Electrical.

Get ready to the #Cloud

Start your Hyper Converged Infrastructure.

Monitor your infrastructures

Monitor your hardware, software, network (ITOM), maintain your ITSM service .

Our Great People

Great team to support happy customers.

Tuesday, October 16, 2012

Tentang SLA (Service Level Agreement) & BSM

What are SLAs? 
SLAs are agreements that exist between business units and IT environments where the
level of a service is defined to ensure reliable operations.  They effectively document
business or customer performance and availability expectations of an application or

3 Major Types of SLAs
SLAs mean different things depending on the context.  So let’s define three common types:

  1. Contractual: this kind of agreement is negotiated between two companies, for example between an outsourcer (IBM Global Services, or a smaller managed service provider), an application provider (like or  Amazon’s AWS), or a service (like DropBox, or Evernote).
  2. Service desk based: Mainly for ticket based systems where activities involve people and process and may include complex workflows (like deploying a system, or on-boarding a new employee).
  3. Infrastructure based: Mainly done by IT service management systems where infrastructure is actively monitored and outages of applications are tracked in real-time.

BSM – what is it?
Business Service Management
A business centric view of services provided. It is an overriding theme that sits above ITSM (IT
Service Management).  IT must switch from a technological view to a customer view, and must
understand business workflows and business logic of applications.

What is it we’re actually trying to achieve?
IT and Business need to talk in the same language. For example, from an IT perspective, everything may be operational but are you able to answer: “did the user receive what they paid for, or what they actually requested?”

We need to understand the complex workflows that may not be actively monitored using typical ITSM  tooling.

Is it achievable?
Becoming BSM aware requires a lot of work and transparency on both IT and the business’s side.
Start with a candid dialogue – are we providing adequate service now?  Where should we go?  How
can we improve?  How are you going to help us improve?

TIP: Can you back-test your application availability and performance? Can you go back through
history and see how your business is trending and determine if your SLAs will even meet those

Decomposing an application
You can’t properly monitor an application and understand its key business drivers without first breaking it down.
  1. What does the application do? How do people interact with it?
    1. What are the key business metrics?  Dollars per hour?  Transactions per minute?  Claims per day?
    2. How is the application built?
    3. Are there key dependencies shared across many applications?  Are you depending on third-parties, or cloud based services
    4. Are you using custom, insular components?  They might be hard to monitor or metric.
  2. What infrastructure does the application sit on?
    1. Will one component of your infrastructure affect many applications?  Do you know how to prioritize fixing outages and map them to key applications?
SLA Routines
Try to alter your view from infrastructure-centric to business-centric? Are you delivering the right data in the right amount of time?  What are some routines around SLAs that you can implement?
Building SLAs that work
  1. What are the critical tests for an application?  Can it be actively monitored or is it a complex workflow?
  2. Prioritize your applications: revenue or customer critical should always come first.
  3. How can proactively watching SLAs help?
    1. Catch items before they become too critical! Ensure you able to proactively monitor your environment and  be alerted before an outage or violating an SLA.
    2. Tiger Teams
      • Daily ops review – getting daily reports (are you trending to violate an SLA?).
      • Prioritize what to work on (root cause analysis that impacts key applications).
      • Figure out causal high-priority problems. Determine particular services that impact different applications within your environment, or different components of an application.
      • If something keeps causing outages and headaches – re-architect it!

Respect – how do you start?
  1. Take care of the small stuff first
    1. Trying to monitor business metrics when you keep running out of file system capacity is going to be a lost cause. Make sure your systems are as available as possible.
  2. Don’t aim too high at the beginning
    1. Understand what you’re committing to – see if you can back-test SLAs before you sign up for them.
    2. Make this an iterative approach – aim for incremental improvements and be able to demonstrate them.
  3. Overcome the fear of transparency
    1. Over-communication of outages and how they occur might be cringe-worthy at the beginning, but it ultimately helps your team prioritize and improve.
    2. Yes, it sucks to have outages, but communal betterment is… better!

(Webinar SLA Uptime)

Monday, October 15, 2012

Apa dampak Software Defined Networking utk Network Admin

What is Software-Defined Networking (SDN) and How Will it Impact the Network Administrator?

What is SDN?

Software-Defined Networking has become one of those industry buzzwords that quickly gets so over-used and distorted that it is hard to tell what it really means or if it really matters.  In this blog post I'll try to go back to the basics of what is SDN and how it is likely to impact the network administrator.

SDN was defined by the Open Networking Foundation (ONF), a standards group founded in 2011 by Deutsche Telekom, Facebook, Google, Microsoft, Verizon, and Yahoo!, as an architecture that "brings direct software programmability to networks worldwide."  ONF is pushing this goal by defining and driving an OpenFlow interface.  The ONF website describes OpenFlow as follows:

"In a classical router or switch, the fast packet forwarding (data path) and the high level routing decisions (control path) occur on the same device. An OpenFlow Switch separates these two functions. The data path portion still resides on the switch, while high-level routing decisions are moved to a separate controller, typically a standard server. The OpenFlow Switch and Controller communicate via the OpenFlow protocol, which defines messages, such as packet-received, send-packet-out, modify-forwarding-table, and get-stats."

So the basic concept is pretty simple, move the control functions into a software layer that talks to the hardware layer which still moves the data.  The key benefits of this approach, especially if all hardware devices used the same interface protocol, is that it would be much easier to programmatically provision network resources and automate configuration tasks at a common software control layer.

This is largely what happens today in server virtualization.  A software virtualization layer interfaces with the applications and manages the underlying physical compute resources (e.g., CPU, memory, disk, etc.).  This abstraction has enabled a number of key capabilities including rapid provisioning, VM/application mobility, thin provisioning of storage, etc.

Big Vendor Positioning

The idea of abstracting the intelligence from the hardware naturally leads to the conclusion that the network virtualization layer would then be able to run on commodity networking hardware.  This is not a scenario that is likely to be very appealing to Cisco and the other big networking hardware vendors.  Looking at a parallel example in server virtualization, HP, Dell, IBM and others still sell a lot of servers even though VMware provides the most common virtualization layer.  However, it is getting harder and harder to maintain any differentiation at the hardware layer which is driving commoditization and squeezing profit margins – not an appealing vision for Cisco and the other vendors who would be happy with the status quo.  Larry Dignan's article "Cisco makes its software defined network case: Do you buy it?" does a nice job of diving into the Cisco perspective in more depth.

In July 2012 VMware stepped into the picture in a big way with their acquisition of Nicira who has been focused on network virtualization using an SDN approach.  VMware is the dominant player in the server virtualization market so when they acquired Nicira for $1.05B it caught many people's attention.  At VMWorld 2012 in San Francisco this past August, VMware continued to hit the theme of a Software-Defined Data Center that encompasses servers, storage and networking.  The positive side of VMware's interest in SDN is that they have enough market presence already in the virtualization space that the other big players now have to be serious about moving forward with a SDN strategy of their own or risk losing their existing markets to VMware.  On the other side, VMware already has enough market power with their server virtualization capabilities.  It is scary to think about what they could do if they are able to successfully extend that dominance across both storage and networking as well.

So what should we expect from the big vendors like Cisco, VMware and others?  The typical approach for those vendors would be to talk a lot about their SDN strategy, claim open SDN capabilities within their products and pursue activities that have some SDN capabilities while keeping it proprietary to their product line so that they can maintain control of the customer.  With the existing VCE partnership between VMware, Cisco and EMC it will be very interesting to see how this dynamic plays out across network and storage.

How will this Impact the Network Administrator?

If history is any guide, the first challenge the Network Administrator will have to face is wading through the proprietary vendor features or capabilities marketed as SDN.  The admin will need to determine where there is real value, what is designed strictly to lock you in to a vendor, and what is just marketing hype.  In the longer term, SDN has the possibility of being a valuable capability that enables a transition to a more flexible and efficient network similar to what has happened with server virtualization.  With standardized, open SDN capabilities, the network admin would be able to programmatically automate key provisioning, configuration and management tasks.  This would allow more time to focus on business requirements and overall network optimization and less on device-level tasks.   As this transition occurs, probably over the next two to five years, the network admin will want to make sure they are at least keeping up with those changes.  By updating skills they can become the equivalent of the VMware (or Hyper-V, KVM, etc.) admin that can manage the physical server too instead of just being the legacy server admin.

Drawing another parallel, as the network virtualization layer does more, it will be harder to connect what is happening at the application layer down through the virtualization layer to the physical infrastructure.  The network administrator will want to make sure that they can monitor the network and maintain visibility from the application and virtualization layer down into the physical infrastructure.  This visibility enables both system troubleshooting and optimization.   For optimization it ensures that physical capacity aligns with the virtualization demands.   For troubleshooting you can quickly understand where network traffic monitoring or other analysis is needed to identify where the real problems are occurring and what the impacts are.  Keeping that end-to-end mapping capability from the network hardware to the network consumers will ensure that the network admin remains a critical part of the overall data center team.

While this change is likely to happen over years instead of months, it is always good to use change to your advantage as opposed to being caught napping.

By Mike Thompson, SolarWinds Networking Product Marketing Manager; on twitter @michl121
build-access-manage at