Port 25: The Open Source Community at Microsoft : Kishi Malhotra, Networking

Managing Global Infrastructure Services: Kishi interviews Arne Josefsberg

admin — Wed, 30 Aug 2006 18:17:00 GMT

Kishi Interviews Arne Josefsberg General Manager of Infrastructure Services in Windows Live Operations. He is responsible for the strategy, design and operation of the online infrastructure that forms the foundation for Microsoft’s online businesses. His areas of responsibility include: global data centers, networks, hardware and operating systems standards; and foundational shared system level services such as caching, load balancing, DNS, Active Directory, back-up/restore, remote management access, content replication etc.

During Arne’s 20 years with Microsoft, he has held technical leadership roles in a number of areas. His Microsoft career started as a Technical Manager on the team that built the Nordic subsidiary region business. Since then he has held management roles in Product Support Services leading OEM and ISV customer teams and OEM hardware compatibility certification; as well as leadership roles in Information Technology managing customer systems applications and IT infrastructure. As a member of the MSN 1.0 launch team, Arne gained early knowledge of the online services business building the dial-up access network as well as data center operations.

Prior to joining Microsoft, Arne worked in systems engineering at Intel Corporation specializing in CPU, operating system and software consulting for Nordic customers. Arne holds a Masters degree in Physics from the Lund Institute of Technology, Sweden.Outside of work he enjoys spending time with his wife and two children, as well as photography, reading and various forms of exercise including soccer, weight training and cycling. Arne shares some insight into the challenges faced when managing a global infrastructure and provides some tips for success.

Video: Managing Global Infrastructure Services: Kishi interviews Arne Josefsberg

Alternate Video Format
Download MPEG4 Video

Infrastructure Management and Strategic Design: Part 4 – Service Management Frameworks

jcannon — Tue, 01 Aug 2006 16:51:00 GMT

Today, the IT departments offering and managing various IT Services might find themselves in what I would call a “pressure-cooker”. They are faced with a multitude of tasks and added pressure to maintain daily operations while driving efficacy, managing the growing complexity of Service Offerings and most importantly, doing so while keeping pace with the industry best practices. This has been one of the most explosive areas of growth and re-examination for the past few years. Back in my Ops days, I trained under ITIL i.e. IT Infrastructure Library and MOF i.e. Microsoft Operations Fundamentals to get a first hand look at some of the best Service Management practices in the industry. No matter how good I thought our Service Management practices might have been, I could not help but to think in terms of the maturity level of the Services that can be achieved by applying these principles. When you get down to it, you realize that the heart and soul of effective Service Management lies in how mature the offering and support model is. I have learnt a lot from the ITIL Service Management Essentials course, which I attribute to research and practices that have gone into developing these models. I’d like to share w/ you what made sense to me:

Bridge Concept: As described in various ITIL formats, Service Management can be referred to as the “bridge layer” between Business and Technology. It is through the conduit of Service Management that core business needs as well as core technologies find their match with each other. This is attained by aligning the Business Needs and Goals of the organization with the various technologies and IT functions that can map to these overall goals
Think Framework: Once you have scoped out, what may be a void in the service hierarchy of your organization, make a commitment to implementing a Service Management and Delivery framework that is suitable for your org. One size DOES NOT fit all and although I am only talking about ITIL concepts here, there are several methodologies you can explore before making the plunge.
Benefits of implementing a Service Management Framework: In just a few minutes after sitting in the ITIL Essentials Training class I was able to get a very crisp idea of what the benefits of implementing a Service Management Framework are. To name a few –

Raising the bar on Service Delivery Quality
More accurate alignment w/ Business Needs
Enhanced relationship between service provider and consumer
Deeper visibility into service complexity
Driving efficiencies with optimal resource utilization

Goals for implementing a Service Management Framework: if and when you do make the commitment to implementing a Service Management Framework, here’s a quick set of goals you can set when you proceed with the implementation of Service Management:

Put an SLA ( Service Level Agreement) or an SLO (Service Level Objective) around the critical and non-critical services you offer, respectively
Manage and monitor the implementation and practice of these SLA’s and SLO’s
Create and publish a service catalog describing the services offered by your IT department/division
Monetize the service management offerings, even if your customers are internal. This will help quantify the service effectiveness and bring measurability across the board

Additional Resources: the itSMF or IT Service Management Forum (www.itsmf.com ) is an independent, non-profit, user group distributed all across the world that has dedicated itself to exploring and promoting IT Service Management concepts and practices.

I am very eager to hear back from those of you that are an integral part of the Service Management Lifecycle. Please share your experiences, challenges and learning with us.

Kindest Regards and have a great week ahead!

Infrastructure Management and Strategic Design: Part 3

jcannon — Tue, 11 Jul 2006 20:17:00 GMT

Part 3 – Adaptation and simulation of Heterogeneous environments under lab conditions

A simple question that has always perplexed me is how software and hardware OEM’s across the world simulate heterogeneous environments under lab conditions. I have witnessed several different approaches, practices and stages of this adaptation and each one of them is unique and correct in its right and merit. I guess, that leaves the “big” question which remains unanswered i.e., how do you bring a “real-life” scenario and manifest it under lab conditions. This is even more challenging because the average test lab for a medium to large organization is no match to the size and complexity of its elder sibling, the Enterprise Data Center, running its production systems, applications and operations. So why squeeze all that complexity into a smaller scale ? Is there one perfect method?– of course not, depends on what heterogeneity means to you/your business. Let’s look at this and why it’s necessary and also share some techniques that may be helpful.

Start with why it’s necessary to represent if not an equivalent amount of heterogeneity within a lab but a comparable one. Start with simple logic – why do we need a lab in the first place ? In most cases it’s an environment we can turn to and run processes, tests and simulations which we dare not try in a Production Environment. However, the caveat here is that if we do want to test a tool or an app that we’re about to roll into a production environment, our best bet is to test it in the lab with conditions mirroring as closely to the production environment as possible. It’s also a place where we can develop workarounds, fixes, documentation, implementation practices and as much supplementary support mechanism as we’d like before we bite the bullet and push the tool or app into production. The expectation we keep in mind when we do that is that results from the lab and production rollout should bear a resemblance like that of the “Partridge Family” and hopefully not of the “Manson Family”. Okay, bad joke but you get the point.

Now on to “Tips and Tricks” to help with the process of adaptation and simulation of a lab environment that mimics your production one. Here’s what I found useful:

Deployment Methods: Using similar deployments tools, techniques and methods in the lab that are already in use in the production environments makes one aware of “delivery mechanisms” and the path, process the deployment cycle will take when released
Configuration Management: Extreme familiarity and knowledge of the configuration options of not just the delivery mechanism/s but also of the tool/s or app/s is something as valuable as having that Swiss knife in your pocket – you just never know when you’re going to need it
What Business Scale ?: Never hesitate to walk out of the lab and have a conversation with decision makers who chose the tool/app. Find out more about what their expectations out of this application are (by now I know some of you may be cringing in your chairs but I am dead-serious on this one). This is the best way to learn if the application should be tuned towards business scales such as Reliability, TCO, Scalability, Performance, High availability or whatever
Manageability: My personal favorite – always have a lifeboat handy i.e. when the fit hits the shan, will you still be able to recover the system, do a roll-back, connect remotely and most importantly, keep the service/s up and available
Driving Efficiencies: Most IT departments have to squeeze every efficiency they can out of their budgets, and labs are a luxury when they have to deliver results to CTOs. So what’s the best way to accomplish testing, or simulation, on a budget. How does someone with no extra money support such an effort. There’s some creative resource utilization that can be implemented such as:

Rotation of production hardware coming up for decommissioning and reallocating such resources to the lab
Making use of evaluation copies and licensing i.e. since most lab testing scenarios only extend to short periods to drive testing
Using down-time to allocate personnel to testing efforts i.e. if there’s lag time between two projects, using that time and headcount effectively to drive testing

And finally a small anecdote to help put things in perspective. In my past life, I remember several years ago when I was still on the east coast, I worked on implementing an asset tracking tool for desktops spread through the environment. We tested the tool on individual desktops and did not care about running the entire scenario using network connectivity across the simulation. We were told by the vendor that the tool uses less than 1% of CPU as negligible amount of memory. After random tests, we rolled out the tool and the purpose of the tool was to run a script and send the results back across the network. However, due to ACL’s in place, which we forgot to account for, and lack of validation of packet delivery, the desktops stopped responding. This was an expensive lesson in why we should test the waters to the best possible extent before setting sail.

Just a few thoughts and hope it triggers some more for everyone out there. As always, please do let me know if that has been useful and/or if you have a specific topic in mind you’d like us to write about.

-Kishi

Infrastructure Management and Strategic Design: Part 2 – Driving Network Efficiencies

admin — Fri, 16 Jun 2006 15:21:00 GMT

Infrastructure Management and Strategic Design: Part 2 – Driving Network Efficiencies

Every computing device in existence today lives and breathes on some sort of a Network. Doesn’t matter if your Home PC is connected to a Cable Modem or if you’re office laptop is part of an extended WAN, your device is persistently living and breathing on the Network. From the minute you turn on your device, one of the very first drivers to be loaded are Networking drivers. Everything from DNS, DHCP to the simple sharing of email and office documents depends on the very basic function of the Infrastructure, the Network. So why is it that the same Network which is considered a Category-A asset in an organization is also sometimes at the very root of serious headaches for a Network Administrator. Thoughts about the faith and reliance we put towards Networking Infrastructure is simple staggering. Let’s examine why

If you’re a soccer fan like me, I am sure you have been glued to the World Cup coverage. As I sat with some friends and discussed our loss to the Czech Republic, I realized that in that group, it didn’t matter if you use Firefox or IE to get the game stats, you JUST wanted to know the score. The thought that followed was that maybe “Tools” shouldn’t be as hyped-up as they are sometimes as compared to the stream of “networking” that sustains them. Following that my thoughts turned to the topic of Net Neutrality and how Networks are ideally designed to forward packets regardless of their size, purpose and content. Hmm…this is interesting, I thought. My entire life as an Infrastructure Architect, I tried to come up with creative ways to manage and optimize network / infrastructure performance towards a better outcome for end users.

You see, some of the most perplexing problems for Network Admins is to control and manage “chatty protocols, broadcasts and bandwidth hogs”. How can we do that effectively? Let’s look at this closely: When I read a blog about Web 2.0 or something similar, some of the questions that pop in my head are “Have they considered what effect the implementation would have on their Network Performance” ? How far does the implementation of a new model go towards Application Bandwidth Testing and how inherently and intrinsically dependent we are on Networking.

Networking and the simple availability of bandwidth, wired or wireless, has become as much of an expectation as running water. A few months ago I remember someone saying “Network is like electricity – you don’t call up and thank the power company when you turn on the light, do you, nor do you ask them how much power you can use for your house”. Intriguing thought, nevertheless, for those Layer 2 and 3 warriors, the term “Port Saturation” should definitely ring a bell. Key contributors to reaching port density are instances when there just isn’t any more bandwidth to go around. To avoid choking up the network, I found some of the following tips helpful if you’re managing a small to medium sized network:

Auditing protocols in use: A good place to start overhauling your network can be drawing a good Physical and Logical representation of your company’s network. This will compel you to examine how majority of the devices are connected to each other as well as the medium, physical as well as protocols in place. If you have access to a Sniffer or a Fluke, you might also want to do some packet analysis and see where a majority of the “chatter” is coming from. That in turn will expose what some of the “bandwidth hogs” on your Infrastructure are, be it Application, Devices or Servers
Auditing ACL’s and Policies: If its been a while since you reviewed your network security policies, it may be a good time to do that. The ACL’s you put in place on various switches across your network were driven by the security policies drafted formally. An ACL audit will help provide fresh transparency into the security elements within your network

And the tricky one “finding alternatives to chatter-heavy Tools and Apps”: Once you have identified the bandwidth hogs on your Network, a good bet would be to limit the broadcasts and chatter they generate. Segmentation and or isolation of these tools into separate VLAN’s may be a good starting point. If an application or tool in question is culprit, investigate how many users or mission-critical LOB’s are dependent on it. If the priority is fairly low, it may be time to migrate to something less chatty or simply more efficient

Alright, that’s it. I am logging off and heading to the movies to watch the Da Vinci Code. Will be back here next week and Thank You for tuning into Port25.

Infrastructure Management and Strategic Design: Part 1

admin — Mon, 05 Jun 2006 17:51:00 GMT

Infrastructure Management and Strategic Design
Part 1: Domains Portfolio Management

Thank you all and especially everyone who has been giving us very productive feedback on what you'd be interested in seeing us write about. Your input helps us tune our content to what’s important to YOU, our viewers. On that note I am kicking off a series of blogs towards Infrastructure Management encompassing suggestions, situations and pointers towards managing and maintaining a large-scale heterogeneous infrastructure. I’d like to start today’s blog on an “unsung” hero of the Infrastructure Service but yet one of the most important– Domains Portfolio Management.

Why is this important: Well, think about this for a minute - EVERYTIME someone types a url in their browser, it translates to someone having secured that url at some point and working with a registrar to purchase and lock it. I can literally write a book on how painful it has been for so many companies to sometimes purchase, acquire or secure something as small as a url and YET, the entire web presence of a company depends on registration of a simple url, a central place which everyone goes to.

Domains Portfolio Management as I understand it, encompasses managing all gTLD’s (Global top level domains such as .com, .net etc) and ccTLD’s (Country Code Top Level Domains such as .au, .in etc.) across the board. This involves managing, securing and expanding your Domain Portfolio credentials to give us a business advantage and to understand and leverage this often overlooked strategy. Let’s say you’re working for an organization that is geographically dispersed in major regions around the world. If you want to maintain, develop and build a strong Internet Presence portfolio, the dynamics of that space are changing very rapidly with the introduction of several new top level domains e.g. .mobi etc. I have spent a significant amount of time in my past life overseeing the several aspects of Domain Management and here’s the top three suggestions I would like to share with you:

1. Manage your Domain Portfolio: If you have more than 100 domains in your Domains Portfolio, it is worth every penny to build a database around these domains and enter essential information like expiration date, registrar details etc in it. This in itself will add years to your life as a Domain Portfolio Administrator. Other helpful suggestions are choosing more than one registrar for your portfolio. The phrase “don’t put all your eggs in one basket” has never been more relevant than at this point. Why you ask, well, think in terms of ‘TDRP – or Technical Disaster Recovery Planning”. You want to put measures in place such that you always have a backup Registrar/Registry that you have been working with and knows your portfolio intimately
2. Secure your Domain Portfolio: Sometimes, we “over-prepare” and I have seen Domain Portfolio Managers registering every single url in every single country in the world, even if they’re not known and/or are not selling a product or service in that region. So what does a good Domain Strategy look like. Well, start by maximizing your gTLD assets, make sure you have fully locked and secured your Domain Assets. Work w/ your Registrar and have them do a comprehensive Domain Audit and review for you. You are more than likely to get a visualization of where most of your Domain investment lies. Sit down w/ your Business and Marketing Team after that to review the findings and align your Domain presence with your core business goals. e.g. if your org is heavily centric in a specific continent or country, make sure your domain assets are maximized for that region.
3. Build a strategy around your portfolio: Once you have a solid strategy around what areas, regions and assets you need to invest in, you are more than likely to get your share of squatters (those who buy popular domain names and then sell them to the highest bidder), type-squatters (those who make their money by buying domains resembling popular / heavy-hitter names ) and some clear violations of your company trademark name. While you’re combing through these issues, “PICK YOUR BATTLES”. If a specific ccTLD is not that important to your company’s business expansion plans, just let it go. But make sure you invest heavily in keeping and securing the Domain Assets that your business model takes for granted.

In conclusion, I would like to say that there’s much more riding on your domain portfolio than most would ever imagine. Building an asset database, building a close professional relationship with your Registrar and always staying on top of the Domains namespace are hard suggestions I would like to make after having lived through managing this service. Have a great week ahead and THANK YOU for tuning in!!