Download View/Download - CA Technologies

44 | CA TECHNOLOGY EXCHANGE: DISRUPTIVE TECHNOLOGIES
About the author
ca.com
Trend of More Software-Defined “Stuff”
by Rick Langsford, Senior Advisor, Transformation Programs, CA
Technologies
Rick Langsford is a Senior
Advisor with CA Technologies
Transformation Program team.
Rick’s primary focus is
empowering customers with
insights into leveraging these
new approaches to accelerate
application/service delivery.
Prior to CA, Rick was a portfolio
advisor with VMware, working
with VMware customers and
product management to
develop their Cloud and
Virtualization Management
strategy. Before VMware, Rick
was an advisory consultant for
EMC, building joint services and
product solutions for private
cloud operations.
Prior to recent roles at VMware
and EMC, Rick was co-founder
and Vice President at
Pepperweed Consulting, leading
services, sales and R&D. Rick’s
team at Pepperweed launched
several successful consumer
software products and, as
Hewlett Packard Software’s
largest IT management and
automation consulting partner,
Rick’s consulting team delivered
strategy, process and
implementation consulting for
many of HP’s largest and
complex enterprise
engagements.
Rick holds a BS in Computer
Technology from Purdue
University and currently resides
with his family in sunny Tampa,
Florida.
In the last 12-18 months, the term “software-defined” has caught on as a prefix
for number of software manufacturers, desiring to be bellwethers of their
industry. The term is most often used by the vendor to describe an approach to
automation and orchestration and/or virtualization that abstracts infrastructure
to the point that it’s primarily controlled (deployed, used, managed, and disposed
of) through higher level functions and policies. This approach to “shift up” the
app stack by software defining more “stuff” has several distinct advantages. By
negating the bulk of the (often manual) heavy lifting with infrastructure, IT
organizations can shift resources to more innovation-oriented, app-centric
endeavors. Most of these software-defined approaches follow a theme of
standardization and commoditization. Having a similar set of infrastructure
building blocks, that are also inexpensive to acquire and replace, naturally
reduces complexity and cost. However, the most important benefit is often
speed. The ability to immediately and safely reconfigure pieces and parts of
infrastructure on demand dramatically decreases cycle times. This allows
organizations to “go faster” – to get to market quicker, beat competition, draw
new customers, repair broken services, and so on to grow and protect their
business.
So how is software-defined “stuff” manifesting itself today and who are the
players? In this article we explore areas where the industry has taken a software
defined approach to servers, storage, networks and even software defined
software.
Software-Defined Servers
Arguably, software-defined “servers” (using server virtualization technology) over
the last half dozen years have been the genesis of the new software-defined
stuff. The capability of a hypervisor (like VMware, Xen and Hyper-V) to slice
physical servers up into smaller virtual ones is transformative, although much of
the benefit lies in the APIs exposed by those hypervisors to do things
programmatically (either with proprietary or open APIs for internal or 3rd party
consumption).
Part and parcel with the virtualization of servers is the virtualization of storage –
Software Defined Storage (SDS). Although many may correctly point out that both
server and storage virtualization has been around for some time (think VM/CMS,
VSAM from Mainframe environment), only in last decade has it become pervasive
in distributed environments. The technology behind virtual volume management,
virtual SANs, and block storage is not new. What is new is the use case that the
cloud brings. That data can be spread across disparate systems but addressed
and accessed in same manner (using higher level APIs) is what is changing the
game. Platform providers (like Amazon AMS with Simple Storage Service or
Rackspace with OpenStack Block Storage) have these capabilities as part of their
45 | CA TECHNOLOGY EXCHANGE: DISRUPTIVE TECHNOLOGIES
ca.com
core platforms, but cannot always offer the speed, cost effectiveness, security or
on-premise capabilities enterprises are looking for. All the big storage vendors
participate in SDS (EMC, HP/3PAR, and NetApp) but are increasingly disrupted by
focused competitors (like Nexenta and Red Hat Storage Server) to offer some of
the same flexibility but with open hardware platforms. At time of writing, EMC
announced its intent to acquire one of these disruptive vendors, ScaleIO, which
offers an “Elastic Converged Storage” technology that creates and manages a
virtual pool of storage across various hardware platforms (including local server
storage) and abstracts it for common use. This recent acquisition announcement
and other mergers and acquisitions activity in this space is further evidence of a
strong and rapidly changing SDS market.
Software-Defined Networks
So we’ve got software-defined servers and storage, what’s next? The network of
course! Software Defined Networking (SDN) is the area with the most disruption
and buzz lately. This is possibly because the type of abstraction that is inferred
with SDN. Historically, there has been fairly mature technology in the market to
do network device automation and orchestration (like InfoBlox and OpsWare) for
provisioning, configuration, audit and executing policy changes. However this is
automation, not abstraction. At the core of the initial movement in SDN are
several key emerging standards (namely OpenFlow and Open vSwitch) that are at
the heart of newer SDN “Network Operating Systems” (such as Google, Nicera,
Inseime on commercial side or Helios and Maestro in research/academia). These
technologies seek to abstract the controls, features and higher level components
of a network operating system from the specialized network equipment that
moves the packets. In existing virtual datacenters, this allows an application or
infrastructure architect to create an environment (often simply by drawing a
diagram in a UI) of virtual servers with virtual switches, routers and subnets also,
using the underlying physical network as a generic IP backplane. SDN controllers
interact with the physical network by managing routes, policies, rules, tunnels
and VLANs on commodity VM environments that in-turn dynamically control the
lower lever network devices as needed. This is significantly disruptive in at least
three key areas. First, this approach lessens the need for high-end, expensive,
dedicated network hardware that is typically required for core route/switch
infrastructure. Second, an SDN controller abstracts multiple vendors’ gear, with
little to no administrative knowledge of each vendors’ network OS required (e.g.,
IOS for Cisco, Junos for Juniper). Third, applications can directly and dynamically
control network environments as needed (a new level of elasticity to the
network). Nicera’s (acquired by VMware last year) approach is based on Open
vSwitch and takes a multi-layer “virtual switch” approach that leverages many
existing standards for security, QoS, monitoring and control (including
OpenFlow). Inseime (a “spin-in” from Cisco) is also a new player in this emerging
space and is part of Cisco’s ONE (Open Networking Environment) initiative for
SDN. Expectations are for even more players and innovation in SDN.
46 | CA TECHNOLOGY EXCHANGE: DISRUPTIVE TECHNOLOGIES
ca.com
Figure 1. Software-Defined Network Architecture (source: opennetworking.org)
Software-Defined Software
So we have software defined servers, storage and networks, what’s next?
Software-defined software? Yes! From an application-centric perspective none of
this software-defined stuff matters unless you have applications running on it.
Some applications will leverage APIs from these software defined areas directly
(for example a Web app on Amazon EC2 that dynamically makes calls to AWS
EBS, Dynamo DB and ElastiCache services/APIs or a Heroku app that dynamically
instantiates a “dyno” to handle new web services requests). Regardless of how an
app uses (or does not use) these APIs, a fundamental challenge is how to get the
app deployed in the first place. Subsequently the adjacent market of release
automation technologies leverages these various software defined infrastructure
APIs to help encapsulate, manage and automate the application across its
lifecycle. The approach treats an app holistically – the app is certainly the code,
but also the infrastructure, configurations, scripts and other supporting
components that make up the entire (often dependent) app environment. Terms
like “manifests”, “artifacts” and “recipes” are used to describe these tangential
but necessary components of an app from its initial instantiation in development
to the ongoing changes in production. Several of the release and orchestration
technologies have emerged from the Open Source community (like Chef and
Puppet), together with other, often more advanced, commercial versions like CA
Technologies’ Nolio and IBM’s UrbanCode (both recent acquisitions). These truly
leverage software definability to the hilt by allowing software to deliver complete
and very deterministic environments in a completely “zero touch” manner.
47 | CA TECHNOLOGY EXCHANGE: DISRUPTIVE TECHNOLOGIES
ca.com
Figure 2. "Zero Touch" Software Release Architecture (source: CA Technologies)
The Impact of Software-Defined Stuff
So what will be the long term impact to IT organizations? Without question, this
will continue to create pressure to do more with less. As the application and line
of business owners discover these capabilities and trends in the industry they will
turn to IT to deliver comparable options (or broker them through external
providers). SDN in particular may change the long term financial dynamics in
large networks – potentially decreasing the overall spending on gear and support
in large networks. Although major pieces of these software defined technologies
may be leveraged fairly quickly in current environments some may take time as
they can change fundamental architecture or approach (like SDN) and thus, are
likely to be more successful with incremental approaches. There are also distinct
differences in adoption of these technologies by customer segment (Service
Providers, Enterprises, Mid-Market). While Mid-Market may benefit indirectly
from SaaS or Cloud services that may utilize one or many of these technologies in
background (like a CRM app from Salesforce.com or development lab services
from Amazon AWS) it’s the former two segments that will invest the most directly
in these technologies. For many MSPs and Cloud providers, these technologies
are already in place (particularly server, storage virtualization). They often
possess a more normalized datacenter with standard server, storage and network
infrastructure components. Thus SDN, by investment in new vendors (such as
Nicera) or through legacy home-grown systems (such as Google), will allow
providers to deliver even faster and cheaper environments to their customers.
SDN could also open up opportunities for incremental revenue with a capability
to tailor or tune the network dynamically to deliver a higher level QoS to
customers (traffic and bandwidth elasticity). Similarly, Enterprises have large and
expanding virtual server and storage environments. However, it’s likely SDN will
take off primarily in existing “contained” virtual environments where the SDN
controller only minimally controls physical network devices, but provides the
dynamic creation, change, disposal of virtual network assets. Broader SDN
48 | CA TECHNOLOGY EXCHANGE: DISRUPTIVE TECHNOLOGIES
ca.com
SDN investment to control core, distribution and edge gear is likely to come
slowly as part of ongoing network gear tech refresh cycles. Enterprises are likely
to increase investment in software-defined software (software release
automation and orchestration) to gain the speed and consistency they desire and
see in proprietary platforms (like AWS or Heroku). As enterprises seek to similarly
abstract and control dependent infrastructure they will mature to “Environmentas-a-Service” capabilities that allow entire app environments to be delivered on
demand across the SDLC and IT Ops lifecycle. The ability to do this with existing
(often complex and old) application environments but make it seem as easy as
AWS to the requestor is a huge advantage.
As disruptive or cool as some of these new technologies are, implementation of
them will not occur overnight. Certain applications and workloads will not be a fit
for one (or perhaps any) of these, but may be compelling enough and worth the
investment and change for others (especially for new apps or services). Key for
any IT leader is to stay knowledgeable and conversant on this “shift up” approach
and the trend around software defined stuff.
Connect with CA Technologies at ca.com
Agility Made Possible: The CA Technologies Advantage
CA Technologies (NASDAQ: CA) provides IT management solutions that help
customers manage and secure complex IT environments to support agile business
services. Organizations leverage CA Technologies software and SaaS solutions to
accelerate innovation, transform infrastructure and secure data and identities,
from the data center to the cloud. CA Technologies is committed to ensuring our
customers achieve their desired outcomes and expected business value through
the use of our technology. To learn more about our customer success programs,
visit ca.com/customer-success. For more information about CA Technologies go
to ca.com.
Copyright © 2013 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced
herein belong to their respective companies. IT Infrastructure Library is a registered trademark of the Central
Computer and Telecommunications Agency which is now part of the Office of Government Commerce. ITIL is
a registered trademark, and a registered community trademark of the Office of Government Commerce, and
is registered in the U.S. Patent and Trademark Office.
The information in this publication could include typographical errors or technical inaccuracies, and CA, Inc.
(“CA”) and the authors assume no responsibility for its accuracy or completeness. The statements and
opinions expressed in this publication are those of the authors and are not necessarily those of CA.
Certain information in this publication may outline CA’s general product direction. However, CA may make
modifications to any CA product, software program, service, method or procedure described in this
publication at any time without notice, and the development, release and timing of any features or
functionality described in this publication remain at CA’s sole discretion. CA will support only the referenced
products in accordance with (i) the documentation and specifications provided with the referenced product,
and (ii) CA’s then-current maintenance and support policy for the referenced product. Notwithstanding
anything in this publication to the contrary, this publication shall not: (i) constitute product documentation
or specifications under any existing or future written license agreement or services agreement relating to
any CA software product, or be subject to any warranty set forth in any such written agreement; (ii) serve to
affect the rights and/or obligations of CA or its licensees under any existing or future written license
agreement or services agreement relating to any CA software product; or (iii) serve to amend any product
documentation or specifications for any CA software product.
Any reference in this publication to third-party products and websites is provided for convenience only and
shall not serve as the authors’ or CA’s endorsement of such products or websites. Your use of such products,
websites, any information regarding such products or any materials provided with such products or on such
websites shall be at your own risk.
To the extent permitted by applicable law, the content of this publication is provided “AS IS” without
warranty of any kind, including, without limitation, any implied warranties of merchantability, fitness for a
particular purpose, or non-infringement. In no event will the authors or CA be liable for any loss or damage,
direct or indirect, arising from or related to the use of this publication, including, without limitation, lost
profits, lost investment, business interruption, goodwill or lost data, even if expressly advised in advance of
the possibility of such damages. Neither the content of this publication nor any software product or service
referenced herein serves as a substitute for your compliance with any laws (including but not limited to any
act, statute, regulation, rule, directive, standard, policy, administrative order, executive order, and so on
(collectively, “Laws”) referenced herein or otherwise or any contract obligations with any third parties. You
should consult with competent legal counsel regarding any such Laws or contract obligations.