Microsoft needs SDN for Azure cloud

Microsoft needs SDN for Azure cloud

Couldn't scale without it, Azure CTO says
The Microsoft cloud, through which the company’s software products are delivered, has 22 hyper-scale regions around the world. Azure storage and compute usage is doubling every six months, and Azure lines up 90,000 new subscribers a month.

Six TED Talks that can change your career
Of the hundreds of TED talks available online, many are geared toward helping people view life in a new

Fifty-seven percent of the Fortune 500 use Azure and the number of hosts quickly grew from 100,000 to millions, said CTO Mark Russinovich during his Open Network Summit keynote address here this week. Azure needs a virtualized, partitioned and scale-out design, delivered through software, in order to keep up with that kind of growth.

“When we started to build these networks and started to see these types of requirements, the scale we were operating at, you can’t have humans provisioning things,” Russinovich said. “You’ve got to have systems that are very flexible and also delivering functionality very quickly. This meant we couldn’t go to the Web and do an Internet search for a scalable cloud controller that supports this kind of functionality. It just didn’t exist.”

Microsoft wrote all of the software code for Azure’s SDN. A description of it can be found here.
Microsoft uses virtual networks (Vnets) built from overlays and Network Functions Virtualization services running as software on commodity servers. Vnets are partitioned through Azure controllers established as a set of interconnected services, and each service is partitioned to scale and run protocols on multiple instances for high availability.

Controllers are established in regions where there could be 100,000 to 500,000 hosts. Within those regions are smaller clustered controllers which act as stateless caches for up to 1,000 hosts.
Related

Why is Microsoft killing off Internet Explorer?
Microsoft builds these controllers using an internally developed Service Fabric for Azure. Service Fabric has what Microsoft calls a microservices-based architecture that allows customers to update individual application components without having to update the entire application.

Microsoft makes the Azure Service Fabric SDK available here.
Much of the programmability of the Azure SDN is performed on the host server with hardware assist. A Virtual Filtering Platform (VFP) in Hyper-V hosts enable Azure’s data plane to act as a Hyper-V virtual network programmable switch for network agents that work on behalf of controllers for Vnet and other functions, like load balancing.

Packet processing is done at the host where a NIC with a Field Programmable Gate Array offloads network processing from the host CPU to scale the Azure data plane from 1Gbps to 40Gbps and beyond. That helps retain host CPU cycles for processing customer VMs, Microsoft says.

Remote Direct Memory Access is employed for the high-performance storage back-end to Azure.
Though SDNs and open source go hand-in-hand, there’s no open source software content in the Azure SDN. That’s because the functionality required for Azure was not offered through open source communities, Russinovich says.

“As these requirements were hitting us, there was no open source out there able to meet them,” he says. “And once you start on a path where you’re starting to build out infrastructure and system, even if there’s something else that comes along and addresses those requirements the switching cost is pretty huge. It’s not an aversion to it; it’s that we haven’t seen open source out there that really meets our needs, and there’s a switching cost that we have to take into account, which will slow us down.”

Microsoft is, however, considering contributing the Azure Service Fabric architecture to the open source community, Russinovich said. But there has to be some symbiosis.

“What’s secret sauce, what’s not; what’s the cost of contributing to open source, what’s the benefit to customers of open source, what’s the benefit to us penetrating markets,” he says. “It’s a constant evaluation.”

Some of the challenges in constructing the Azure SDN were retrofitting existing controllers into the Service Fabric, Russinovich says. That resulted in some scaling issues.
Resources

7 Critical Questions to Demystify DRaaS
“Some of the original controllers were written not using Service Fabric so they were not microservice oriented,” he says. “We immediately started to run into scale challenges with that. Existing ones are being (rewritten) onto Service Fabric.

“Another one is this evolution of the VFP and how it does packet processing. That is not something that we sat down initially and said, ‘it’s connections, not flows.’ We need to make sure that packet processing on every packet after the connection is set up needs to be highly efficient. It’s been the challenge of being able to operate efficiently, scale it up quickly, being able to deliver features into it quickly, and being able to take the load off the server so we can run VMs on it.”

What’s next for the Azure SDN? Preparing for more explosive growth of the Microsoft cloud, Russinovich says.

“It’s a constant evolution in terms of functionality and features,” he says. “You’re going to see us get more richer and powerful abstractions at the network level from a customer API perspective. We’re going to see 10X scale in a few years.”

Best Microsoft MCTS Certification, Microsoft MCITP Training at certkingdom.com

The erosion of IT's middle class

Evolve your career with the changing face of IT, or risk getting left behind

As new technologies continue to emerge in the network, the need for highly skilled IT administration resources will grow just as well.

However, the advent of Software Defined Networking (SDN), cloud systems, and orchestration software means many mundane tasks will become automated. If your day is mainly made up of those mundane tasks, then you should be worried about the future of your career.

In the near future, IT teams will of course need high-level engineers, but there will still be a need for lower-skilled resources. This emerging IT environment, however, threatens those in the middle-tier IT ranks.

Increasing complexity in IT environments
In the recent past, enterprise networks have been fairly simple. A core data center contained the internet connectivity, and that data center contained all the servers running the corporate applications. There was a corporate network and WAN, and the IP routing topology was fairly stable (unless new sites were added or moved).

Now we have server virtualization, more functionality and configurability within the hypervisor (Network Functions Virtualization), and layer-2 data center interconnection protocols tunneling traffic between data centers. Now enterprises have a completely eroded internet perimeter, cloud-based data centers, remote virtual workers, and virtual machines that move from on-premise to cloud-data center.

How this affects the IT super star
This increased complexity requires IT staff to be multi-disciplined in order to be effective at their jobs. No longer can server administrators get away with being be familiar with the operating system alone. They need to have mastered server virtualization, understand how the services operate in a virtualized environment, how applications are secured with firewalls, and how network virtualization connects those applications. Network administrators not only need to know about IP routing protocols and spanning tree, but they must also know about network virtualization (VRFs, VDCs), layer-2 data center interconnect protocols (OTV, TRILL, VXLAN, NVGRE, STT, VPLS), Quality of Service (QoS), how firewalls operate, and how networking functions can now be placed within the hypervisor (VMware NSX, Cisco Nexus 1000V, virtual load balancing, virtual firewalls). While many IT organizations are still heavily siloed into separate teams, troubleshooting events often bring these groups together. Unfortunately, when these groups get together to resolve an issue, the proverbial “finger pointing” starts while everyone digs in to defend their turf. Organizations that are more effective have interdisciplinary groups that cross these boundaries to help break down barriers and foster cooperation. Mature organizations with cross-functional teams and better processes realize increased operational availability, lower downtime, and faster response to business needs.

To get to this level, the IT staff needs to have many years of experience and a desire to learn about a broad range of technologies. IT staff need to be aware of the end-to-end IT environment, follow ITIL practices, able to traverse the full OSI stack, and comfortable dealing with hardware and software. Those with a programming background and an understanding of applications, operating systems, databases and storage systems, as well as networking and security, will have the most job security.

The IT middle class
Many enterprise organizations do not see a need to have these IT super stars, and instead staff their teams with middle-tier administrators. Enterprise organizations have historically needed a middle-tier of skilled resources because these resources fit the continually reduced IT budget. These individuals have been the first line of support and help troubleshoot problems. They were the staff that operated the current infrastructure. They handle the configuration, maintenance, and troubleshooting of the IT infrastructure. This staff handled day-to-day moves/adds/changes.

Now, most IT organizations spend 75% of their time maintaining the IT systems that have been purchased and only 25% of the time working on new projects that help evolve the business. It’s no wonder companies want to divest themselves of the physical IT infrastructure that consumes so much CAPEX and move to cloud-based IT services that use only OPEX money.

Here are just some of the mundane day-to-day tasks that could potentially be automated:
Virtual machine/virtual server maintenance
Patching servers and systems
Firewall rule changes
Simple network changes like configuring Ethernet switch ports
Assigning server connections to specific VLANs
Cutting and pasting configuration commands from a template

Over time, organizations will have fewer reasons to keep middle-tier to mid-level administrators. These mid-tier staff helped maintain the on-premise infrastructure, apply patches, upgrade software, and other operation tasks that need to be completed during a change window. As more of these tasks are automated and outsourced, these staff member’s future is tenuous at best.

The IT lower class
There are also many IT professionals who have not been in the industry very long or are still just learning about how systems work. IT work is pretty good, as far as jobs go. It’s mostly indoor work, not that dirty, doesn’t require heavy lifting, doesn’t require employees to dress particularly fancy, and allows for flexible work hours. Sometimes you have to work weekends, but then there are other days when you can leave work early if things are running smoothly.

Lower-tier staff needs to perform the following IT tasks:
Racking and stacking of hardware
Helping end-users with desktop or mobile device issues
Installation of cables or wireless access point maintenance
Replacing hard drives in storage arrays
Physical-layer troubleshooting

These may not be the most glamorous tasks, but they are a way to get a foot in the door. I remember when I was young having to gather up all the extra power cords that weren’t being used and put them into boxes. I would crawl around in the ceiling tiles running Twinax cables. I would clean out dot-matrix printers and computer fans with a vacuum. We all have to start somewhere, and this is where many of us began our careers.

Erosion of the IT middle class
The IT industry is transforming. Organizations are looking to move their systems to the cloud and change the physical nature of their compute, storage, and networking resources. Corporations are moving rapidly to virtualize these components and try to speed up the provisioning of new IT systems. The focus is on rapidly deploying or changing the applications, operating systems, servers, storage, and security to make the IT systems more agile and keep up with the rapidly changing business world.

Soon, enterprises will have Software Defined Networking (SDN) systems and other controllers that define policies for how applications will operate. Companies will use software to define the policies with which applications will request resources from the network, and how resources are elastically scaled to meet demand at a moment’s notice.

To be able to deploy these orchestration and automation systems, organizations need top-tier IT resources. IT organizations will need to invest in data center architects and IT practitioners who know how to get the end-to-end network to facilitate the communication between mission-critical applications that may be located in a combination of on-premise and cloud resources. These top-tier resources are going to be the ones setting up these new technologies that others in the company will use to request IT services. These are some of the tasks that these high-end resources will be performing:

Creating the IT self-service provisioning portal
Writing the Cisco UCS Director provisioning workflow scripts
Configuring VMware vCenter Orchestrator or vCenter Operations Management Suite
Configuring the SDN controller (plus some Java or Python coding) for advanced application requirements
Deploying an OpenStack system for automation of public and/or private clouds
Configuring a Cisco ACI Application Policy Infrastructure Controller (APIC) for End-Point Groups (EPGs), Application Network Profiles and Contracts
Configuring the storage replication between on-premise and cloud-based storage systems

If you are a mid-level IT staff member, you will need to improve your skills to move into that top tier and preserve your place in an IT organization. If you fail to make that transition, then you are likely to suffer “brain drain” and you will move into that lower tier.

If you have spent a lot of time in the IT industry and you are just now reaching that middle-tier skill set, your career is at a crossroads. You can choose to stay where you are, but in doing so you risk being made obsolete by a robot or Java/Python script.

If this scares you, then you should invest in your professional development, learn to be cross-functional, and try to learn how to control the software components that will make you more efficient at your job.

---

Best Microsoft MCTS Certification, Microsoft MCITP Training at certkingdom.com

Cisco vs. Juniper: How different are their SDN strategies?

Analysts see more convergence than divergence with recent Cisco, Juniper releases

On the surface, Cisco and Juniper's SDN strategies seem to have sharp contrasts if recent announcements are any indication. For example:
Juniper
Juniper's MX series routers will be among the first of the company's hardware platforms to include new ASICs otimized for SDNs.

• Juniper places much more emphasis on the software angle of SDN, even ushering in a new software licensing business model; Cisco's attempts to make hardware as much, and perhaps even more, relevant than software.

• Cisco is attacking five markets at once -- data center, enterprise, service provider, cloud, academia -- with its strategy, while Juniper is focusing initially on data centers.

• Juniper views SDNs as much more disruptive, potentially allowing it to significantly increase share; Cisco has thus far made no such dramatic market impact statements regarding SDNs.

• As part of its hardware focus on SDN, Cisco is funding a separate spin-in company -- Insieme Networks -- which is believed to be building big programmable switches and controller(s); Juniper has no such hardware investments, but did buy Contrail for $176 million, again emphasizing the software aspect of SDNs.

• Cisco has a timeline of 2013 deliverables; Juniper's timeline pushes a controller and SDN service "chaining" capability out into 2014, and the new software business model into 2015.

Yet analysts say there are really more similarities than differences in both strategies from the fierce rivals.

"I think there are some similarities," says Brad Casemore of IDC. "Both Juniper and Cisco are emphasizing ASICs, and therefore hardware, in their SDN strategies. Both companies also see network and security services -- Layer 4-7 -- as virtualized applications in a programmable network. They each have controllers, but they also will promote hybrid control planes -- decoupled and distributed. Juniper is positioning for a software-licensing business model, true, but it's relatively early along in that process."

"It's a different packaging strategy but both seem equally focused on the value of software in SDN," says Mike Fratto of Current Analysis. "Key points being modular, flexible, and exposing APIs for integration."

Juniper recently divulged its SDN strategy after months of silence - seven months after Cisco announced its Cisco ONE plan. Salient points of Juniper's plan include separating networking software into four planes -- Management, Services, Control and Forwarding -- to optimize each plane within the network; creating network and security service virtual machines by extracting service software from hardware and housing it on x86 servers; using a centralized controller that enables service chaining in software, or the ability to connect services across devices according to business need; and the new software-based licensing model, which allows the transfer of software licenses between Juniper devices and industry-standard x86 servers, and is designed to allow customers to scale purchases based on actual usage.

Cisco's ONE, or Open Networking Environment strategy, includes an API platform to instill programmability into its three core operating systems: IOS, IOS XR and NX-OS. It's focused on five key markets and also includes new programmable ASICs, like the UADP chip unveiled with the new Catalyst 3850 enterprise switch; and a software-based controller for data centers that runs on x86 servers. New ASICs are also expected to be front-and-center when the Cisco-funded Insieme Networks start-up unveils what's expected to be a high-performance programmable switch and controller line.

Juniper's strategy initially targets data centers, and its new software licensing model is based on enterprise practices. The company will expand its traditional carrier and service provider customers from there.

Among the first markets addressed in Cisco's ONE strategy are enterprise customers, data centers and cloud providers.

"Juniper ultimately sees SDN at all layers of the network, spanning not only the data center -- edge/access and core --, but also the WAN, campus and branch," says IDC's Casemore. "Juniper's SDN road map initially targets the SP edge and data center, but it does plan to follow SDN into other areas.

"Cisco sees data center and cloud as near-term markets, and its positioning to play across the board as SDN -- and its outcomes, network virtualization and network programmability -- extends its reach," Casemore says. "Again, there are many similarities."

In terms of market disruption, Fratto says both companies see SDN as perhaps equally disruptive even though one has been much more vocal about that impact than the other.

"I think the two companies view SDN as disruptive but they are approaching it very differently," he says. "Juniper tends to be more conservative in bringing new products to market, particularly with Junos. They have a quarterly software update cycle and they march to that drum. I think they have a strong preference for stability in the platform and based on their consistent messaging on that topic.

"I think for Cisco, the disruption is there but the recent announcements tell a lot about its direction going forward," Fratto continues. "I think it signals ... wanting to be vendor and protocol agnostic vs. promoting their own technology over others. The ONE controller, for example, is modular and will support OnePK and Openflow out of the gate, but there is no reason other than development that it can't support other protocols."

Casemore sees both companies reacting to SDN developments, rather than driving them.

"Neither has led the charge toward SDN. Both are measuring their responses, trying to find a balance between supporting their customers today while preparing for potentially disruptive shifts."

And Casemore sees both equally emphasizing hardware, despite Juniper's software-intensive strategy.

"Juniper has a lot of existing hardware, and hardware customers, that it will attempt to fold into its SDN strategy," he says. "We will see hardware and software from both Cisco and Juniper, as their common ASIC strategies suggest."

And even though the timelines for deliverables differ, they are in keeping with each company's traditions.

"That's Juniper's way, right?" Fratto says. "Produce a road map and then deliver over a longer timeline like 12 to 24 months."

Where the strategies diverge will be in partner ecosystems for SDN-enabled services, he says.

"In both cases, they will need to attract partners into their respective ecosystems. The market for services has a ton of players -- think (application delivery controllers), firewalls, WAN optimization. For those services to be chained, they have to be integrated with Juniper's stuff. Same for Cisco. That's going to be the attractor."

Casemore sees differences in initial target markets too.

"I look at Juniper's strategy as being more attuned to the SP/carrier community than the enterprise -- their service chaining concept is very close to network functions virtualization -- whereas the strategy and technologies Cisco has rolled out thus far are more enterprise oriented," he says. "That's not to say that Juniper won't develop more of an enterprise orientation or that Cisco won't push its SDN strategy into carriers -- both will happen. But that's how I see them now at this particular snapshot in time."

---

Best CCNA Training and CCNA Certification and more Cisco exams log in to examkingdom.com