More on fabric computing in the cloud

In my last post I covered the concept of fabric computing and why it matters in the world of cloud computing.  With a "fabric" approach towards creating a cloud application, we include the virtual compute, storage and network components inside a fully software-based model of the service. This is distinctly different from a more traditional approach, where the various resources are added and configured one by one.

In response to a comment, I also suggested that this new approach could be compared to a modern espresso machine.  Such a machine delivers a complete service (coffee!) - in an integrated fashion.  No need to worry about the temperature of the water, grinding the beans, any other steps or equipment required to make it happen.

In a cloud computing context, the fabric is integrated "out of the box," like the espresso machine. It doesn't require provisioning, managing, integrating and monitoring lots of VMs and appliances individually. Most cloud solutions approach building a cloud by automating these individual steps - typically through scripting -- but this approach has distinct drawbacks. I included a short demo of the fabric approach below, but to understand these drawbacks we will use another analogy:

The parable of the spreadsheet and the calculator

                                                    

Imagine you are an accountant and you can choose between using a spreadsheet (a fabric) or an automated (scripted) calculator.  Both a calculator and a spreadsheet have similar base functions (add, subtract, multiply, square root). On a calculator, you start with a value and you perform functions against that. If you perform the same functions every month you could put these in a script, so you can play them back automatically next time. You could even edit that script to do it slightly different. This may makes things easier, but it is not a spreadsheet. With a spreadsheet you can have several versions next to each other (you can do a "Save as"), a change in one area immediately updates the other areas (it is integrated, there is no need to rerun a script), you can send a spreadsheet to other users or to your accountant.

Have a look at the demo below to see how that applies also to a fabric cloud application (including "save as", creating multiple versions, send it to someone else to run).  But first ask yourself: when did you last see an accountant with a calculator? In fact automated calculators never really took off. Spreadsheets (fabrics) are simply the better way.

Seeing is believing: the epiphany of a demo
When I personally saw my first demo of this concept in action, it reminded me of two earlier occasions where a demo later reshaped IT as I knew it. The first was after I installed Windows 1.0 (all 12 floppies). Sure back then it was still monochrome, there were no applications and the performance was not great, but it did make me think: "Boy, if they ever get this to work, it will really change how we use desktop computers."

The second "epiphany" was my first experience with X86 virtualization. After having confiscated the biggest machine in the office with the most memory, and after quite some tinkering I saw an actual X86 machine boot inside a window (of course this was not an actual machine - it was a virtual one). After it booted, it could not do much, and running two of them brought the whole machine to a grinding halt. Yet, it did make me think: "Wow, if this ever scales, it can completely change how we handle our machines." And (admittedly somewhat to my surprise), about a decade later around 2009, X86 virtualization did actually start to scale and it developed into the billion dollar industry that is changing the way we manage our servers.

Just like Windows profoundly changed the way we use desktops and virtualization is changing the way we manage servers, this new software-based, virtual fabric approach, in my view will change the way we manage data centers. Now I was certainly not the first person to realize this. Nicholas Carr already acknowledged the power of this approach in his book "The Big Switch." In an interview with eCommerce Times, he subsequently said:

"In 3Tera's AppLogic, you can see the broad potential of virtualization to reshape how corporate IT systems are built and managed..."

How is that so? Well, my marketing colleagues here created quite an entertaining video , but the original - now vintage - 5-minute demo that shows how to define an application as an integrated fabric is also still out there (and shows the potential much better than my above ramblings).
CA 3Tera AppLogic software essentially enables you to do three things: 

1) First, you set it up on commodity x86 servers, creating a single fabric for the storage, network and compute capabilities on those servers.
2) Then, using an integrated modeling tool, you take your application or service - including all its components, such as data, networking, load balancing, security etc.-- and create a 100% software based model (using a Visio-like drawing tool - check out this InformationWeek demo from Cloud Connect to see this in action).
3) Next, you can deploy a model of the fabric, with the software allocating resources based on the model, and providing automated scaling, metering and fail over capabilities.
You can also move the service or application to another data center very simply, even to one in another country or at another provider. Or, you can copy it and provide the same service to another department or customer (nearly instantly).

For a long time, CA 3Tera AppLogic software was kind of an industry insider secret. Several analysts and writers - like Nicholas Carr - were aware of it, discussed it and listed it in their publications. But today there are many case studies and real life success stories of both small and large implementations out there. This may be a good time for you to have a closer look; if only as an interesting implementation of these new fabric computing trends and principles in action.

Is fabric computing the future of cloud?

The term fabric computing is gaining rapid popularity, but currently mostly within the hardware community. In fact, according to a recent report, over 50% of attendees at the recent Datacenter Summit had implemented, or are in the process of implementing, fabric computing. Time to take a look at what fabric computing means for software and for (cloud) computing as a whole.

Depending on which dictionary you choose, you can find anywhere between two and seven meanings for "fabric." Etymology-wise, it comes from the French fabrique and the Latin fabricare, and the Dutch Fabriek actually means factory. But in an IT context, fabric has little to do with our often used manufacturing or supply chain analogies; instead it actually relates much closer to fabric in its meaning of cloth, a material produced (fabricated) by weaving fibers.

If we check our handy Wikipedia for fabric computing, we get:

Fabric computing or unified computing involves the creation of a computing fabric consisting of interconnected nodes that look like a 'weave' or a 'fabric' when viewed collectively from a distance.[1]

Usually this refers to a consolidated high-performance computing system consisting of loosely coupled storage, networking and parallel processingfunctions linked by high bandwidth interconnects ...

In the context of data centers it means a move from having distinct boxes for handling storage, network and processing towards a fabric where these functions are much more intertwined or even integrated. Most people started to note the move to fabric or unified computing when Cisco started to include servers inside their switches, which they did partly in response to HP including more and more switches in their server deals. Cisco's UCS (Unified Computing System), and its bigger sibling, VCE, are the first hardware examples of this trend (although inside the box you can still distinguish the original components).

One reason to move to such a fabric design is that by moving data, network and compute closer together (integrating them) you can improve performance. Juniper's recent QFabric architecture announcement is another similar example. But, the idea of closer integration of data, processing, and communication is actually much older. In some respects, we may even conclude IT is coming full circle with this trend.

Let me explain.

Many years ago I spoke to Professor Scheer, founder of IDS Scheer and a pioneer in the field of Business Process Management (BPM). (Disclosure: years later IDS Scheer became part of my former employer: Software AG.) He spoke about how - in the old days of IT - data and logic were seen as one. Literally! If - while walking with your stack of punch cards to the computer room (back then it was a computer the size of a room, not a room with a computer in it) - you dropped your stack of punch cards, both data and logic would be in one pile on the floor. You would spend the rest of your afternoon sorting them again. There was just one stack: first the processing/algorithm logic, and then the data. Scheer's point was that just like we figured out after a while that data did not belong there and we moved it to its own place (typically a relational database), we should now separate the process flow instructions from the algorithms and move these to a workflow process engine (preferably of course his BPM engine). All valid and true - at that time.

But not long after, Object Oriented programming became the norm, and we started to move data back with the logic that understood how to handle that data, and treat them as objects. This of course created a new issue of having these objects perform in an even more remotely acceptable way, as we used relational databases to store or persist the data inside these objects. You could compare this to disassembling your car every night into its original pieces in order to put it in your garage. Over the years the industry figured out how to do this better,in part by creating new databases which design-wise looked remarkably similar to the (hierarchical) databases we used back in the day of punch cards.

And now , under the new shiny name of fabric computing we are moving all these processes back in the same physical box.

But this is not the whole story -- there is another revolution happening. As an industry we are moving from using dedicated hardware for specialized tasks to generic hardware with specialized software instead. For example, you might use a software virtualization layer to simply emulate a certain piece of specific hardware.

Or, look at a firewall: traditionally it was a piece of dedicated hardware built to do one thing (keeping non-allowed traffic out). Today, most firewalls are software-based. We use a generic processor to take care of that task. And we're seeing this trend unfold with more equipment in the data center. Even switches, load balancers and network-attached storage are becoming software-based (virtual appliance seems to be the preferred marketing buzzword for this trend).

Using software is more efficient than having loads of dedicated hardware, and we can't ignore the fact that software, because of its completely different economic and management characteristics, has numerous inherent advantages over hardware. For example, you can copy, change, delete and distribute software, all remotely, without having to leave your seat, and even do automatically. You'd need some pretty advanced robots to do that with hardware (if it could be done today).

So how do these two trends relate to cloud computing?
By combining the idea of moving stuff that needs to work together closer together (the idea of fabric) and the idea of doing that by using software instead of hardware (which gives us the economics and manageability of software) we can create higher performance, lower cost and easier to manage clouds.

Virtualization has been on a similar path. First we virtualized servers, then storage and networking, but all remained in their separate silos. Now we are virtualizing all of it in the same "fabric." This means that managing the entire stack gets simpler, with one tool to define it, make it work and monitor it. And that's something that should make any IT pro smile.

In my next post, I'll share my thoughts on why I think this approach has the power to change IT as we know it, based on some of my own epiphanies.

An IT Supply-Chain model, once more with feeling

The idea of cloud computing making IT management more similar to supply chain management has been mentioned before; it’s time to take a closer look.


This post originally appeared as at ITSMportal.com

Let’s start by looking at the supply chain in its simplest imaginable form, even simpler than the supply chain at a manufacturing company. Think of a transport company – like a Federal Express, DHL or TNT – that transports packages from location A to location B. There are processes, people and resources needed to get the package from A to B within the supply chain.

The reality today is that many of these distribution companies do not actually come to your door themselves – at least not in every region or town; they use subcontractors and local partners at various points. It would be far too expensive for the delivery firm to have their own trucks and employ their own drivers in every remote country, city and village around the world. (Bear with me, we will get to cloud computing in a minute). This way, they can still offer you end to-end-service and keep you up to day of minute by minute parcel movements around the globe. They provide customers with tracking numbers - or “meta“-information (01001011). They know exactly which trucks are where, and with which packages; as a result they can “outsource” almost every logistical process (the outside arrows in our animated diagram).

figure 1: animated IT supply chain

But IT does not transport packages from A to B (at least I hope that is not what you do all day!). IT meets the demands of the business by providing a steady supply of services. IT does not have trucks or warehouses, but departments such as development, operations and support that work within their supply chain. What an IT supply chain essentially does, is take IT resources - like applications, infrastructure and people - and use these to create and deliver services.

Some IT shops have decided not to react to demand, but to actively help the users - work with the business – figure out what they should want or need (shown by the arrow marked “innovation” in the diagram). A more recent trend is the introduction of DevOps, a way to closely connect and integrate the demand side with the supply side. This is often done in conjunction with the introduction of agile development processes.

Users typically care about speed, cost and reliability, not about whether IT used its own trucks or someone else’s. Speed - like in many supply chains - is one of the main criteria. Responding faster to customer or user demands reduces cycle time and time-to-market and makes organizations more agile and more competitive. The use of cloud computing in all its incarnations, such as Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS), can play an important role in further increasing this speed.

With IaaS, the IT department can significantly speed up the procurement, installation and provisioning of required hardware. Because of its OPEX model, no capital expenditure requests need to be raised, no boxes with hardware need to be unpacked, no servers need to be installed. Just as in the above distribution example, the organization can rapidly respond to heavily fluctuating demand, extreme growth or demand for new services by using external capacity if and when needed.

With SaaS the route from determining demand to getting a service up and running is even shorter, because the whole thing is already a service the minute we start looking at it. There is no buying, installing, or configuring of the software. It all runs already at the provider’s website. If you are implementing a solution for ten thousand users across hundreds of departments, the time you save by not having to install a CD is not that significant. Large SaaS implementations go live much quicker than traditional on premises implementations, in many cases for psychological or even emotional reasons.Once the solution is already running, users are much more willing to start using it on the spot. Many SaaS providers reinforce this further by specifically designing their software to enable simple “quick starts.”

In those cases where there is no readymade solution available, PaaS (Platform as a Service) can deliver significant time savings. As soon as the developer has defined the solution, it can be used in production. The PaaS provider – through its PaaS platform – takes care of all the next steps such as provisioning the servers, loading the databases, granting the users access etc. Comparing PaaS with IaaS, the big difference s that with PaaS, the provider continues to manage the infrastructure, including tuning, scaling, securing, and so forth.IT operations does not have to worry about allocating capacity, about moving it from test to production or about all the other things operations normally takes care off. And because the PaaS provider has already done this many, many times, it can be done immediately and automatically.

Sound too good to be true?
Well,actually it might be, because - although the above can be faster – it also can mean IT loses control and can no longer assure the other two aspects that users care about: reliability and cost. So, how can these concerns be addressed? In the same way as in the distribution example: by making sure that at all times, IT has all the information (010011001) about “where everything is,” or better, “where everything is running.”

This management system –call it a “cloud connected management suite” if you like – needs to not only give insight about where things are running and how well they are running, but also allow you to orchestrate the process, move workloads from one provider to another, and help you decide whether to take SaaS or PaaS applications back in house (or move them to a more trusted provider). Ideally it will allow you to dynamically optimize your environment based on the criteria –such as speed, cost reliability – and constraints – such as compliance, capacity, contracts - that are applicable at that moment in time to your specific business.

Clearly this dynamic approach is a long way from the more traditional “If it ain’t broke, don’t change it,” but IT will have to get used to this. Or - even better - embrace this new way of doing things, just like planners at industrial companies did. Today’s global manufacturing would not be as efficient and such a driver for the world’s prosperity if they had not started to optimize their global processes a long time ago.
There are, however, a number of prerequisites to be able to implement such a supply chain approach in IT. First, we need to achieve fluidity or movability of IT. IT needs to be able to take fairly sizable IT chunks and move them somewhere else with relative ease. On the infrastructure side, virtualization is a major enabler of this. Virtualization containerizes and decouples from the underlying hardware, thus acting as a dire needed “lubricant”. But to enable true movability, more is needed.

figure 1: animated IT supply-chain  (repeat)

Many of today’s applications are as intertwined as the proverbial plate of spaghetti. This makes the average datacenter a house of cards, where removing one thing may cause everything else to come crashing down. On the functional side, the use of Service Oriented Architectures can help, but we will also need to apply this thinking on the operational side.A virtual machine model is in many cases too low level for managing the movement of complete services; management needs to take place at a higher level of abstraction, ideally based on a model of the service.
The second hurdle is security. I don’t mean that the security at the external providers may be insufficient for the needs of our organization. In fact, the security measures implemented at external providers are often much more advanced and reliable than those inside most enterprises (fear for lack of security is consistently listed as top concern by organizations before they use cloud computing, but it rapidly moves down the list of concerns once organizations have hands-on experience with cloud computing). The real security inhibitor for the dynamic IT supply chain is that most organizations are not yet able to dynamically grant or block access to a constantly-changing set of users, across a fast moving and changing portfolio of applications running at a varying array of providers. This requires us to rethink how security is approached, where it is seen more as along the lines of “Security as a Service”, an enabler instead of an inhibitor.

The third consideration is that any optimization will have to work across the whole supply chain, meaning across all of the different departments and silos that the average large IT organization consists of. For example, it has to look at the total cost of a service, including running, supporting, fixing, upgrading, assuring, and securing it. Likewise, it also has to optimize the speed and the reliability - or at least give visibility into these - across the whole chain.

To prevent sub-optimization (the arch enemy of real optimization) one needs to understand and connect to many of the existing information and systems in these departments. Systems in diverse areas such as helpdesk, project management, security, performance, costing, demand management, data management, etc. IT supply-chain optimization is in its infancy and many start-ups are gearing up to offer some form of cloud management, but it will be clear that offering optimization requires quite a broad and integrated view of IT.

The end result of adopting a Supply Chain approach is that IT becomes more an orchestrator of a supply chain - a broker of services - than a traditional supplier of services. Demand and Supply are two sides of the same coin which occur (almost recursively) throughout the chain. Once we close the loop, the supply chain becomes a cycle that constantly improves and becomes more efficient and agile in delivering on the promises the organization makes to its customers, just like an industrial supply chain but also very much in the spirit of Deming and the original ideas around Service Management.

Vivek Kundra’s decision framework for cloud migration

A framework applicable beyond government and geographies

The decision framework for cloud migration that US Federal CIO Vivek Kundra recently published as part of his Federal cloud computing strategy, offers advice applicable to all organizations.

In my last blog, a cloud of two speeds, I mentioned Vivek Kundra’s very readable cloud strategy and the industry stimulus effect this approach can have on the emerging cloud industry. By presenting his strategy not simply as a way to cut costs and reduce budgets, but as a way to get more value from existing IT investments, he enlisted IT as an ally to his plans, instead of a potential opponent. Section two of the strategy is a pragmatic 3 step approach and checklist for migrating services to the cloud which can also be valuable for organizations outside the government and outside North America. 

The following is a short summary of this “Decision framework for cloud migration”.

The full Federal cloud computing strategy (43 pages and available for download at www.cio.gov) includes a description of the possible benefits of cloud computing, several cases, metrics and management recommendations. A short review of the document was given by Roger Strukhoff at sys-con

Decision Framework for Cloud Migration

The following presents a strategic perspective for thinking about and planning cloud migration.

Select ·   Identify which IT services to move and when ·   Identify sources of value for cloud migrations: efficiency, agility, innovation ·   Determine cloud readiness: security, market availability, government readiness, and technology lifecycle

Provision ·   Aggregate demand where possible ·   Ensure interoperability and integration with IT portfolio ·   Contract effectively ·   Realize value by repurposing or decommissioning legacy assets

Manage ·   Shift IT mindset from assets to services ·   Build new skill sets as required ·   Actively monitor SLAs to ensure compliance and continuous improvement ·   Re-evaluate vendor and service models periodically to maximize benefits and minimize risks

A set of principles and considerations for each of these three major migration steps is presented below.

1. Selecting services to move to the cloud

Two dimensions can help plan cloud migrations: Value and Readiness.

The Value dimension captures cloud benefits in three areas: efficiency, agility, and innovation.

The Readiness dimension captures the ability for the IT service to move to the cloud in the near-term. Security, service and market characteristics, organisation readiness, and lifecycle stage are key considerations.

Services with relatively high value and readiness are strong candidates to move to the cloud first.

Identify sources of value

Efficiency: Efficiency gains come in many forms. Services that have relatively high per-user costs, have low utilization rates, are expensive to maintain and upgrade, or are fragmented should receive a higher priority.

Agility: Prioritize existing services with long lead times to upgrade or increase / decrease capacity, and services urgently needing to compress delivery timelines. Deprioritize services that are not sensitive to demand fluctuations, are easy to upgrade or unlikely to need upgrades.

Innovation: Compare your current services to external offerings and review current customer satisfaction scores, usage trends, and functionality to prioritize innovation targets.

Determine cloud readiness

In addition to potential value, decisions need to take into account potential risks by carefully considering the readiness of potential providers against needs such as security requirements, service and marketplace characteristics, application readiness, organisation readiness, and stage in the technology lifecycle.

Both for value and risk, organizations need to weigh these against their individual needs and profiles.

Security Requirements include: regulatory compliance; Data characteristics; Privacy and confidentiality; Data Integrity; Data controls and access policies; Governance to ensure providers are sufficiently transparent, have adequate security and management controls, and provide the information necessary

Service characteristics include interoperability, availability, performance, performance measurement approaches, reliability, scalability, portability, vendor reliability, and architectural compatibility. Storing information in the cloud requires technical mechanism to achieve compliance, has to support relevant safeguards and retrieval functions, also in the context of a provider termination. Continuity of Operations can be a driving requirement.

Market Characteristics: What is the cloud market competitive landscape and maturity, is it not dominated by a small number of players, is there a demonstrated capability to move services from one provider to another and are technical standards - which reduce the risk of vendor lock-in - available.

Network infrastructure, application and data readiness: Can the network infrastructure support the demand for higher bandwidth and is there sufficient redundancy for mission critical applications. Are existing legacy application and data suitable to either migrate (i.e., rehost) or be replaced by a cloud service. Prioritize applications with clearly understood and documented interfaces and business rules over less documented legacy applications with a high risk of “breakage”.

Organisation readiness: is the area targeted to migrate services to the cloud pragmatically ready: are capable and reliable managers with the ability to negotiate appropriate SLAs, relevant technical experience, and supportive change management cultures in place?

Technology lifecycle: where are the technology services (and the underlying computing assets) in their lifecycle. Prioritize services nearing a refresh.

2. Provisioning cloud services effectively

Rethink processes as provisioning services rather than contracting assets. State contracts in terms of quality of service fulfillment not traditional asset measures such as number of servers or network bandwidth. Think through opportunities to :

Aggregate demand: Pool purchasing power by aggregating demand before migrating to the cloud.

Integrate services: Ensure provided IT services are effectively integrated into the wider application portfolio. Evaluate architectural compatibility and maintain interoperable as services evolve within the portfolio. Adjust business processes, such as support procedures, where needed.

Contract effectively: Contract for success by minimizing the risk of vendor lock-in, ensure portability and encourage competition among providers. Include explicit service level agreements (SLAs) with metrics for security (including third party assessments), continuity of operations, and service quality for individual needs.

Realize value: take steps during migration to ensure the expected value. Shut down or repurpose legacy applications, servers and data centers. Retrain and re-deployed staff to higher-value activities.

3. Managing services rather than assets

Shift mindset: re-orient the focus of all parties involved to think of services rather than assets. Move towards output metrics (e.g., SLAs) rather than input metrics (e.g., number of servers).

Actively monitor: actively track SLAs and hold vendors accountable, stay ahead of emerging security threats and incorporate business user feedback into evaluation processes. And track usage rates to ensure charges do not exceed funded amounts  “Instrument” key points on the network to measure performance of cloud service providers so service managers can better judge where performance bottlenecks arise.

Re-evaluate periodically the choice of service and vendor. Ensure portability, hold competitive bids and increase scope as markets mature (e.g., from IaaS to PaaS and SaaS). Maintain awareness of changes in the technology landscape, in particular new cloud technologies, commercial innovation, and new cloud vendors.

The above is a summary of the “Decision framework for cloud migration” section from Vivek Kundra’s Federal Cloud Computing strategy http://www.cio.gov/documents/Federal-Cloud-Computing-Strategy.pdf provided at www.cio.gov.

Disclaimer: This summary uses abridgements and paraphrasing to summarize a larger and more detailed publication. The reader is urged to consult the original before reaching any conclusions or applying any of the recommendations. All rights remain with the original authors.