Todas las entradas hechas por John Dixon

applications, Cloud computing, Featured, IT services, ITIL

5 Ways to Understand Your Applications and IT Services

How do you view your organization’s applications and IT services? At GreenPages, we often suggest that organizations begin to conceptualize IT services as corporate IT evolves from a technology provider to an innovation center. Now, there are ways to establish and maintain a service portfolio through ITBM (IT Business Management or IT Financial Management) systems, but these are often out of reach for customers less than enterprise level. However, you can conceptualize IT services by looking at your applications from five different perspectives. Let’s use Microsoft Exchange as an example.

applications and IT servicesExchange is an enterprise application that provides email and calendaring. If you’re reading this, there is a good chance that you own servers that host the various components that comprise Exchange. One way to think about cloud is to identify the Exchange servers, their operating systems, the application version, performance requirements, etc. and identify a “place in the cloud” where you can procure servers of similar specifications and migrate the instances. I consider this as the infrastructure perspective. When it comes to cloud computing, this is perhaps the least important.

 

To take full advantage of cloud computing, understand your applications and IT services from a few additional perspectives:

  1. Functional
  2. Financial
  3. Operational (including lifecycle)
  4. Organizational
  5. Use-case

 

Hopefully, after looking at these different perspectives, you’ll see Exchange as part of an IT service that fits this description:

“In operation for over 20 years, E-Communications is a business service that allows each of our 1,200 employees to communicate through email, coordinate meetings, find coworkers’ contact information, and organize tasks using their PC, Mac, mobile device, or home computer 24x7x365. The service is supported by Microsoft Exchange and Active Directory, which both run under VMware vSphere. The service requires 1 full-time administrator who added 12 new users and logged 157 support tickets in 2014. In 2014, charges for software maintenance, personnel, infrastructure depreciation, and outside support services totaled $87,456. A software upgrade is planned for 2015. Users do not generally complain about the performance of the service, other than the size of their mailbox quotas (which are limited to 10GB per user). The company as a whole plans to offer telecommuting packages to more than 250 employees in 2015.”

Armed with this understanding of your IT service that includes Exchange, you might take the following action:

  1. Fund an Office365 migration with capital you had allocated for the Exchange upgrade project
  2. Provide copies of Office applications to telecommuters (without additional charge)
  3. Expand the mailbox quota from 10GB to 50GB
  4. Repurpose your Exchange admin to help telecommuters establish their home offices in 2015
  5. Reduce your spend on E-Communications by more than 50% (from $72.88/user to $35.00/user)

 

Of course, not every application is easily identifiable as belonging to an IT service. The functionality or financial aspects of IT services are often difficult to quantify. However, at GreenPages, especially when looking at cloud computing options, we recommend examining all of your applications through these five perspectives. For this reason, GreenPages has embedded this process in a piece of software that can quickly build your services portfolio and recommend optimizations based on current offerings available – such as Microsoft Office 365.

What are your thoughts?

You can hear more from John in his eBook, “The Evolution of Your Corporate IT Department“

By John Dixon, Director of Cloud Services

Cloud computing, Featured, IoT

Cloud Computing in 2020: Looking into that Crystal Ball

Cloud Computing in 2020Recently, @thedodgeretort of Enterprise CIO Forum held a Twitter chat about what cloud computing in 2020 will look like. I decided to write up a quick blog sharing my thoughts on the topic. Looking into the crystal ball, I see a few things happening with cloud by 2020 — call it 5 years out. First, cloud will transform into more of a utility and a grid of computing power. Second, we’ll see a much deeper manifestation of the core characteristics of cloud computing, especially with regard to flexible capacity, consistent access, and high portability. Third, I anticipate a lot of activity in machine-to-machine transactions and communications (call it IoT if you like). Fourth: superesilient applications. Fifth: compute traded as a commodity. And finally, within 5 years, I think IT and the overall business will come together to actually take advantage of these technologies. Read on for more detail.

Cloud Computing in 2020

 

1. A utility and computing grid

In 5 years, large companies will still hang on to their datacenters to run some services. However, with security more robust, I think that corporations will make available their own computing resources as much as they consume cloud resources – just like some households generate their own electricity and sell it back to the grid. I think Cisco’s Intercloud concept has an angle on this.

2. Flexible capacity, consistent access, and high portability

A cloud/compute socket just like an electrical socket. Standardized applications and connectors that “plug in” to the grid and are removed just as easily. Virtualization has the first stab at this, encapsulating the OS, data, and applications neatly in a VMX and VMDKs. Containers are the next stab. Redhat has an angle on this with their CloudForms PaaS. Raw compute power becomes more and more of a commodity as portability improves; meaning downward pressure on IaaS prices will remain to some degree (see #4).

3. IoT or machine-to-machine communications/transactions

One machine determines that it needs to acquire more compute power to complete its work. It makes a “deal” to go out and acquire that compute power, uses it, and gives it back to the grid. Or, on the flip side, a machine that knows when it can stand idle and rent its own power. Another angle on this, a virtual machine or application has knowledge of its SLA, and moves to the provider who can deliver on that SLA at the least cost. Love it or hate it, Apple’s Siri has an early angle on this. From what I’ve read about the technology, queries to Siri find their way back to Apple datacenters, not only to obtain answers, but to improve the accuracy of queries for all Siri users.

4. Superesilient applications

As prices for cloud trend downward and portability improves (see #2 and #5), disaster recovery will take a new shape. Instead of running on a 2-site/2-region DR architecture, applications will run on a 5, 10, 20, or 30-site “DR” architecture, with all nodes being active. Does it matter where your application is running at that point? Potentially, it’s running all over the east coast, or all over the country. Some services from AWS already have an angle on this with services that are redundant across regions (a.g., S3, elastic load balancing, etc.), not to mention things like DNS on the Internet. I think it will become cost-effective to do this, in general, within 5 years.

5. Compute traded as a commodity, just like crude oil

This might be a stretch in 5 years, but with the trend of IaaS being more commoditized and portability improving, we’ll see a day when compute power is traded in a commodities market. In the channel, this is already fairly common – IaaS providers are eager to cut favorable deals with resellers who agree to purchase large chunks of infrastructure upfront, only to resell at a later date.

6. IT and the business coming together

DevOps was the first marriage of two groups that had been previously at odds (oftentimes). Within 5 years, I think maturity in IT will improve to the point that they become as focused on the business as any other traditional LOB. IT becomes an Innovation Center — they are focused on the business, and behave proactively. Corporate IT shifts its focus from requirements to possibilities. See my previous posts on the emerging idea of a cloud architect who will be important in this shift.

 

To sum up… we’re just at the beginning of possibilities in cloud computing.

 

To hear more from John, you can download his eBook, “The Evolution of the Corporate IT Department“

Photo credit http://bestpaperz.com/ct/8766019-crystal-ball.html

Cloud computing, Featured

So You Want to Be a Cloud Architect? Part II

cloud architect In Part I of this cloud architect series, we highlighted that business skills are at least as important as technical skills for the cloud architect. Here in Part II, we’ll propose three levels of cloud architect, describe the specific skills needed for each level, and make a suggestion on how to obtain these skills.

 

Levels of the Cloud Architect

At GreenPages, we think of three different levels of cloud architect. Through many client conversations, it has become clear that there are common perspectives on cloud:

  • Moving to cloud or “cloud as a bucket”
  • Cloud as a DevOps enabler, to take advantage of cutting edge development concepts
  • Cloud as a management paradigm, particularly to enable self-service and request management
  • A service rationalization strategy

So, the three levels of the cloud architect include the Integration, Developer, and Principal.

  • The Integration Architect has the ability to capture requirements, develop a bill of materials, and help an organization migrate their services to cloud providers. I’d want an integration Architect on staff to help me with a datacenter consolidation/modernization/rationalization project.
  • The Developer Architect builds on the skills of the Integration Architect and focuses on the ability to transform an organization’s development community to use cloud services efficiently. I’d want a Developer Architect on staff to take on a DevOps transformation project.
  • The Principal Architect builds on the Integration and Developer levels by focusing on improving the business’s ability to compete, through the use of cloud services (IaaS, PaaS, SaaS, XaaS) as well as the capabilities of cloud and DevOps. IT Service Portfolio skills are important here to understand an IT organization and what it does for the business as a consumer. Analysis and measurement of the business’s activities/processes/revenues/expenses is also important in this role. An individual in this role might lead a team of cloud architects to transform or build an entire business – perhaps a business that provides cloud services. Further, the individual in this role focuses on possibilities more than analysis of requirements.

 

{Download John’s eBook “The Evolution of Your Corporate IT Department“}

 

Training and Certification

So, which specific skills or certifications are needed for each level?

cloud architect

In a quick look at Coursera, I came across two courses, offered free of charge, that would be helpful for the cloud architect.

On a sidenote, I think Massive Open Online Courses (MOOCs) are a great thing and a nice use of cloud technology (the “flexible capacity” characteristic). Looking ahead, I expect that one would be able to obtain, from a MOOC, all of the training they need to become a cloud architect (amongst other things).

Available from a MOOC for $0.00

GreenPages certifies these levels of cloud architects by validating past certifications and industry experience. We also provide a training course to bring together the skills from various certifications and make them relevant for the cloud architect. Instead of needing to know the complete details of every aspect of these certifications, I think there are some core concepts that are highly applicable to the work of a cloud architect. Consider ITIL v3 in particular. While it is helpful to know how Incident and Problem Management processes work, the cloud architect absolutely needs to know the details of Service Strategy for one. Why? Not to understand which cloud services are available, but to help their organization develop their portfolio of IT services – some of which may be great candidates to source to a cloud service. On a related note, why are we hammering the idea that a cloud architect needs to have all of this business expertise? Well, once IT is defined in terms of the services it delivers, the cloud architect can then analyze that portfolio to identify which services provide the business with a competitive edge, and which services do not (I like to call the latter “commodity” services). The cloud architect may make sourcing recommendations based on this analysis. The table below lists the concepts from various certifications that are important for the cloud architect.

cloud architect

 

 

 

 

 

 

 

 

 

 

 

 

 

 

In Part III I’ll go into more depth on two things:

  • The training course that we provide to tie all of this together
  • The roles and responsibilities of a cloud architect

I’d love to hear your feedback on the role of the cloud architect, especially anything additional that you think the role needs to have. Leave comments below!

 

 

 

Cloud computing, Featured, Virtualization

So You Want to be a Cloud Architect? Part I

Cloud ArchitectLately, I’ve been taking a look at the role of a cloud architect. What does that role look like? How does one acquire the necessary skills? Where do aspiring cloud architects turn for training? Is it possible to acquire the skills to be an effective cloud architect by taking a course or two? Rick Blaisdell wrote a great blog about a month ago called “Top Cloud Skills Employers are Looking For” that I would highly recommend reading.

Cloud Architect Training, Today

I recently wrote a blog about a Forbes article I read by Jason Bloomberg about the concept of cloudwashing. I think this idea applies very well to the cloud training offerings out there today. If you take a look, many of the cloud training courses that currently exist from established vendors are simply rebranded with “Cloud” as a highlight.

The Valuable Cloud Architect

The cloud architect should possess a healthy combination of the following skills:

  • Technical –especially virtualization with a splash of programming and automation
  • IT operations – in particular the concept of IT services and an IT services portfolio
  • Understanding of your business, its initiatives, its challenges, etc.

Technical Skills of the Cloud Architect

Technically speaking, cloud architects need to bring their past experience to bear, validated by the following certifications:

  • Current VCP
  • ITIL v3 Foundations
  • At least one vendor certification (e.g., AWS Certified Solution Architect)
  • Basic knowledge of programming and automation(2)

Technical competence is more of a pre-requisite for a cloud architect. It should be assumed that a cloud architect has some hands-on experience with these items. As they say, these technical skills are necessary but not sufficient for the complete cloud architect. Having acquired these certifications, an architect would probably be hip to the recent progression of IT that occurred since virtualization became mainstream. If you’ve read this far, you’d probably agree that virtualization alone does not mean cloud computing. However, many of the fundamental characteristics of cloud borrow from virtualization and are practical due to virtualization.

Other Core Skills of the Cloud Architect

Maybe the role of the cloud architect is less technical than we think. Business and market knowledge is absolutely critical for the cloud architect, for several reasons:

  1. Products, features, and prices are changing day to day in the market for cloud services – why is this happening and what will happen tomorrow?
  2. The traditional corporate IT market is, effectively, now a competitor in this market for IT services
  3. Using cloud concepts, new companies are being formed and are growing rapidly – some of these companies may challenge your own business – how can the cloud architect understand them and improve their company’s competitive advantage, recognize partnership opportunities, bring products to market more rapidly using cloud and other emerging technology?

 

The third point is a bit of a departure from what we’ve seen as a cloud architect. This says that a cloud architect should really be a specialist in business issues. More than that, we think that Corporate IT should look to transform to specialize in the business rather than specialize in providing IT services. IT departments should be an Innovation Center for the business. More on that in a future post.

The market for cloud computing is changing every day. Established providers like Amazon Web Services introduce new features and products while also dropping prices. Established companies like Microsoft up their game quickly. New companies form to carve out a niche or challenge an established provider. Barriers to entry are low. Economists call this an active competitive marketplace. What does this mean for consumers? Consumers enjoy significant downward pressure on prices for cloud services (especially for commodity IaaS). This also means many new products from which to choose. For this reason, we think the modern cloud architect also needs to have some knowledge of the following:

  • Consulting Experience (particularly, how to assess an organization)
  • Relationships Between the Customer and Provider(1)
  • Essentials of Behavior in a Competitive Market(1) – specialization, substitutes, complements, network effects

I’ve seen a few posts lately suggesting that individuals in corporate IT need to retool. Here is one of those posts. I definitely agree with the author that IT administrators need to shift focus to services rather than servers. What this post leaves out is a recommendation of which new skills are needed. Which skills or certifications should an IT administrator or architect acquire? How do they get them? Later in this series, I’ll propose a training path for the new role of Cloud Architect, why certain skills are important, and how to acquire them.

For Part II, I’ll propose three different types of cloud architect, outline the responsibilities that individuals in this role might have, and describe a path to obtain the skills needed to deliver in this new role. Leave a comment below with your thoughts & stay tuned for part II.

 

By John Dixon, Consulting Architect

Photo credit = http://www.patheos.com/blogs/deaconsbench/2011/10/what-they-didnt-ask/

Cloud computing, cloudwashing, Featured

Forbes Cloudwashing Article: A Few Key Points

By John Dixon, Consulting Architect

 

I came across an article from a couple of months ago by Jason Bloomberg in Forbes entitled, “Why Implement Cloud When Cloudwashing Will Suffice?” The article briefly describes adoption of cloud computing and the term “cloudwashing” – what vendors and customers are tending to do in order to get started with cloud computing. The article makes a lot of good points. Below, I highlighted a few of the points that stood out the most to me and added in some of my own thoughts.

“Cloudwashing typically refers to vendors’ and service providers’ exaggerated marketing, where they label a product as “Cloud” even when such designation is either completely false or at best, jumping the gun on a future capability … But it’s not just vendors and service providers who Cloudwash – executives often exaggerate the truth as well … some CIOs are only too happy to put OpenStack or CloudFoundry on their Cloud roadmaps, secure in the knowledge that they will now be able to present themselves as forward-looking and Cloud savvy…”

I’ve seen this firsthand in various conversations. And I don’t think it’s malicious or wrong – I think it represents a limited understanding of cloud computing. I like to point back to recent history and the days of datacenter consolidation. The whole thing was pretty straightforward…we installed some software on servers (vSphere, Hyper-V, or similar) and went to work virtualizing servers. From that, I derived benefits that were easy to understand – fewer servers to administer, less power consumed, vastly improved time to provision new servers, etc. We didn’t have to do much measurement of those things either. Who needs measurement when you consolidate, say, at least ten servers onto one. The whole thing was very comfortable. I think “cloudwashing” is a good term, and it feels like an attempt to replay datacenter consolidation in terms of cloud computing. And…It’ll be BETTER! After all, it is cloud, so the benefits must be greater!

Not so fast though. Mr. Bloomberg makes a key point later in the article, and I agree 100%.

“The underlying story [of cloud computing] is one of business transformation. Cloud Computing does not simply represent new ways of procuring IT assets or software. It represents new ways of doing business. Cloud, along with other Digital Transformation trends in IT including the rise of mobile technologies, the Internet of Things, and the Agile Architecture that facilitates the entire mess, are in the process of revolutionizing how businesses – and people – leverage technology. And as with any revolution, the change is both difficult to implement and impossible to understand while it’s happening.”

I think the author is absolutely correct here. Cloud Computing is a new capability for the business. One of the most exciting prospects of the whole cloud computing scene is this: it allows a business to take on more risk, fail fast, learn, and begin again. Call that the Deming Cycle or P-D-C-A, or whatever you like. Cloud computing has made real the fantastic growth of companies like Uber (valuation greater than Hertz and Avis combined) and Airbnb (in 2014, estimated to book more “hotel stays” than Hilton). Two crazy ideas that were no doubt implemented in “the cloud.”

Cloud is difficult to implement – if you think of it like any other technology project. Where do you start? How do you know when you’re done? Maybe it is not an implementation project at all.

“The choices facing today’s executives are far more complex than is it Cloud or isn’t it, or should we do Cloud or not. Instead, the question is how to keep your eye on your business goals as technology change transforms the entire business landscape.”

I couldn’t agree more with this. I think that IT organizations should specialize in its company’s core business, rather than administering systems that do not provide competitive advantages. At GreenPages, we’re currently bringing to market a set of Professional and Cloud services that will help organizations take advantage of cloud computing that I’m pretty excited about. To learn more about the evolution of the corporate IT department and what it means for IT decision makers, check out my ebook.

What do you think of Jason’s take on cloudwashing?

 

 

Cloud computing, Featured, XaaS

X as a Service (XaaS): What the Future of Cloud Computing Will Bring

By John Dixon, Consulting Architect

 

Last week, Chris Ward and I hosted a breakout session at Cloudscape 2014, GreenPages’ annual customer Summit. We spoke about cloud service models today (IaaS, PaaS, and SaaS), as well as tomorrow’s models — loosely defined as XaaS, or Anything-as-a-Service. In this post, I’ll discuss XaaS: what it is and why you might want to consider using it.

First, what is XaaS? Is this just more marketing fluff? Why do we need to define yet another model to fully describe cloud services? I contest that XaaS is a legitimate term, and that it is useful to describe a new type of cloud services — those that make use of IaaS, PaaS, and SaaS all neatly delivered in one package. Such packages are intended to fully displace the delivery of a commodity IT service. My favorite example of XaaS is desktop as a service, or DaaS. In a DaaS product, a service provider might assemble it with the following:

  • Servers to run Virtual Desktop Infrastructure from a provider such as Terremark (IaaS)
  • An office suite such as Microsoft Office365 (SaaS)
  • Patching and maintenance services
  • A physical endpoint such as a Chromebook or thin client device

The organization providing DaaS would design, assemble, and manage the product out of best-of-breed offerings in this case. The customer would pay one fee for the use of the product and have the all-important “one throat to choke” for the delivery of the product. At GreenPages, we see the emergence of XaaS (such as DaaS) as a natural evolution of the market for cloud services. This sort of market behavior is nothing new for other industries in a competitive market. Take a look at the auto industry (another one of my favorite examples). When you purchase a car, you are buying a single product from one manufacturer. That product is assembled from pieces provided by many other companies — from the paint, to the brake system, to the interior, to the tires, to the navigation system, to name a few. GM or Ford, for example, doesn’t manufacture any of those items themselves (they did in days past). They source those parts to specialist providers. The brakes come from Brembo. The interior is provided by Lear Corp. The Tires are from Goodyear. The navigation system is produced by Harman. The auto manufacturer specializes in the design, marketing, assembly, and maintenance of the end product, just as a service provider does in the case of XaaS. When you buy an XaaS product from a provider, you are purchasing a single product, with guaranteed performance, and one price. You have one bill to pay. And you often purchase XaaS on a subscription basis, sometimes with $0 of capital investment.

You can download John’s “The Evolution of Your Corporate IT Department” eBook here

So, secondly, why would you want to use XaaS? Let’s go back to our DaaS example. At GreenPages, we think of XaaS as one of those products that can completely displace a commodity service that is delivered by corporate IT today. What are commodity services? I like to think of them as the set of services that every IT department delivers to its internal customers. In my mind, commodity IT services deliver little or no value to the top line (revenue) or bottom line (profit) of the business. Desktops and email are my favorite commodity services. Increased investment in email or the desktop environment does not translate into increases in top-line revenue or bottom-line profit for the business. Consider that investment includes financial and time investments. So, why have an employee spend time maintaining an email system if it doesn’t provide any value to the business? Two key questions:

  1. Does investment in the service return measurable value to the business?
  2. In the market for cloud services, can your IT department compete with a specialist in delivering the service?

When looking at a particular service, if you answer is “No” to both questions, then you are likely dealing with a commodity service. Email and desktops are two of my favorite examples. Coming back to the original question… you may want to source commodity services to specialist providers in order to increase investment (time and money) on services that do return value to the business.

We’ll expand this discussion into the role of corporate IT in a future post. For now though, what do you think of XaaS? Would you use it to replace one of your commodity services? Maybe you already do. I’m interested to hear from you about which services you have chosen to source to specialist providers.

Cloud computing, Featured, hybrid cloud, Public Cloud, Shadow IT

Have You Met My Friend, Cloud Sprawl?

By John Dixon, Consulting Architect

 

With the acceptance of cloud computing gaining steam, more specific issues related to adoption are emerging. Beyond the big-show topics of self-service, security, and automation, cloud sprawl is one of the specific problems that organizations face when implementing cloud computing. In this post, I’ll take a deep dive into this topic, what it means, how it’s caused, and some options for dealing with it now and in the future.

Cloud Sprawl and VM Sprawl

First, what is cloud sprawl? Simply put, cloud sprawl is the proliferation of IT resources – that provide little or no value – in the cloud. For the purposes of this discussion, we’ll consider cloud to be IaaS, and the resources to be individual server VMs. VM sprawl is a similar concept that happens when a virtual environment goes unchecked. In that case, it was common for an administrator, or someone with access to vCenter, to spin up a VM for testing, perform some test or development activity, and then forget about it. The VM stayed running, consuming resources, until someone or something identified it, determined that it was no longer being used, and shut it down. It was a good thing that most midsize organizations limited vCenter or console access to perhaps 10 individuals.  So, we solved VM sprawl by limiting access to vCenter, and by maybe installing some tools to identify little-used VMs.

So, what are the top causes of cloud sprawl? In IT operations terms, we have the following:

  • Self-service is a central advantage of cloud computing, and essentially cloud means opening up a request system to many users
  • Traditional IT service management (a.k.a. ITIL) is somewhat limited in dealing with cloud, specifically configuration management and change management processes
  • There remains limited visibility into the costs of IT resources, though cloud improves this since resource consumption ends up as a dollar amount on a bill…somewhere

How is Cloud Sprawl Different?

One of the main ideas behind cloud computing – and a differentiator between plain old virtualization and centralization – is the notion of self-service. In the language of VMware, self-service IaaS might be interpreted as handing out vCenter admin access to everyone in the company. Well, in a sense, cloud computing is kind of like that – anyone who wants to provision IaaS can go out to AWS and do just that. What’s more? They can request all sorts of things, aside from individual VMs. Entire platform stacks can be provisioned with a few clicks of the mouse. In short, users can provision a lot more resources, spend a lot more money, and cause a lot of problems in the cloud.

We have seen one of our clients estimate their cloud usage at a certain amount, only to discover that actual usage was over 10 times their original estimate!

In addition, cloud sprawl can go in different directions than plain old VM sprawl. Since there are different cloud providers out there, the proliferation of processes and automation becomes something to watch out for. A process to deal with your internal private cloud may need to be tweaked to deal with AWS. And it may need to be tweaked again to deal with another cloud provider. In the end, you may end up with a different process to deal with each provider (including your own datacenter). That means more processes to audit and bring under compliance. The same goes for tools – tools that were good for your internal private cloud may be completely worthless for AWS. I’ve already seen some of my clients filling their toolboxes with point solutions that are specific to one cloud provider. So, bottom line is that cloud sprawl has the potential to drag on resources in the following ways:

  1. Orphaned VMs – a lot like traditional VM sprawl, resulting in increased spend that is completely avoidable
  2. Proliferation of processes – increased overhead for IT operations to stay compliant with various regulations
  3. Proliferation of tools – financial and maintenance overhead for IT operations

 

Download John’s ebook “The Evolution of Your Corporate IT Department” to learn more

 

How Can You Deal with Cloud Sprawl?

One way to deal with cloud sprawl is to apply the same treatment that worked for VM sprawl: limit access to the console, and install some tools to identify little-used VMs. At GreenPages, we don’t think that’s a very realistic option in this day and age. So, we’ve conceptualized two new approaches:

  1. Adopt request management and funnel all IaaS requests through a central portalThis means using the accepted request-approve-fulfill paradigm that is a familiar concept from IT service management.
  2. Sync and discoverGive users the freedom to obtain resources from the supplier of their choosing, whenever and wherever they want. IT operations then discovers what has been done, and runs their usual governance processes (e.g., chargeback, showback) on the transactions.

Both options have been built in to our Cloud Management and a Service (CMaaS) platform. I see the options less as an “either/or” decision, and more of a progression of maturity within an organization. Begin with Option 2 – Sync and Discover, and move toward Option 1 – Request Management.

As I’ve written before, and I’ll highlight here again, IT service management practices become even more important in cloud. Defining services, using proper configuration management, change management, and financial management is crucial to operating cloud computing in a modern IT environment. The important thing to do now is to automate configuration and change management to prevent impeding the speed and agility that comes with cloud computing. Just how do you automate configuration and change management? I’ll explore that in an upcoming post.

See both options in action in our upcoming webinar on cloud brokerage and governance. Our CTO Chris Ward will cover:

  • Govern cloud without locking it down: see how AWS transactions can be automatically discovered by IT operations
  • Influence user behavior: see how showback reports can influence user behavior and conserve resources, regardless of cloud provider
  • Gain visibility into costs: see how IaaS costs can be estimated before provisioning an entire bill of materials

 

Register for our upcoming webinar being held on May 22nd @ 11:00 am EST. “The Rise of Unauthorized AWS Use. How to Address Risks Created by Shadow IT.

 

 

Cloud computing, cloud service broker, Featured, IaaS, IT Management

Are We All Cloud Service Brokers Now? Part II

By John Dixon, Consulting Architect

In my last post, I discussed Cloud Service Brokers and some of their benefits after reading a couple of articles from Robin Meehan (Article 1 here and Article 2 here). In this post, I will break down some of Robin’s points and explain why I agree or disagree with each.

At the end of last post, I was breaking down cloud arbitrage into three areas (run-time, deployment-time, plan-time). Credit to Robin for run-time and deployment-time arbitrage. I really like those terms, and I think it illuminates the conversation. So, run-time cloud arbitrage is really science fiction right now – this is where the CSB moves running workloads around on the fly to find the best benefit for the customer. I haven’t seen any technology (yet) that does this. However, VMware does deployment-time and run-time arbitrage with VMotion and Distributed Resource Scheduling – albeit, in a single virtual datacenter, with individual VMs, and with a single policy objective to balance a cluster’s load across vSphere nodes. See Duncan Epping’s excellent write up on DRS here. Even 10 years ago, this was not possible. 15 years ago, this was certainly science fiction. Now, it’s pretty common to have DRS enabled for all of your vSphere clusters.

A few of Robin’s points…

Point 1:
“The ability to migrate IT workloads dynamically (i.e. at run-time, not at deployment time) is something I sometimes see as a capability under the ‘cloud broker’ banner, but in my view it really just doesn’t make sense – at least not at the moment.”

I agree. Run-time cloud arbitrage and workload migration ala vMotion is not possible today in cloud. Will it be possible within the next few years? Absolutely. I think it will first manifest itself in a VMware High Availability-like scenario. Again, see Duncan Epping’s fantastic deep-dive into HA. If cloud provider X drops off of the internet suddenly, then restart the resources and application at cloud provider Y (where cloud provider Y might even be your own datacenter). This is sometimes known as DR as a service, or DRaaS. And even now, there are some DRaaS solutions that are coming onto the market.

Point 2:
“The rate of innovation in the IaaS/PaaS/DaaS market is such that most of the other vendors are playing catch-up with AWS, as AWS continue to differentiate themselves from the following pack. This shows no sign of slowing down over the next couple of years – so the only way a migrated workload is going to work across multiple cloud vendors is if it only relies on the lowest common denominator functionality across the vendors, which is typically basic storage, virtualised compute and connectivity.”

Also agree, the rate of innovation in the market for cloud computing is rapid as specialization sets in at an industrial level. This also means that downward price pressures are enormous for vendors in the cloud space, even today as vendors vie for market share. As switching costs decrease (e.g., portability of applications increases), prices for IaaS will decrease even more. Now, wouldn’t you, as a customer, like to take advantage of this market behavior? Take in to consideration that CSBs aggregate providers but they also aggregate customer demand. If you believe this interpretation of the market for IaaS, then you’ll want to position yourself to take advantage of it by planning portability for your applications. A CSB can help you do this.

Point 3:
“The bottom line is that if you are going to architect your applications so they can run on any cloud service provider, then you can’t easily use any of the good bits and hence your value in migrating to a cloud solution is diminished. Not ruined, just reduced.”

Disagree. To take advantage of market behavior, customers should look to avoid using proprietary features of IaaS platforms because they compromise portability. Like we noted earlier, increased portability of applications means more flexibility to take advantage of market behavior that leads to decreasing prices.

This is where perspective on cloud becomes really important. For example, GreenPages has a customer with a great use case for commodity IaaS. They may deploy ~800 machines in a cluster at AWS for only a matter of hours to run a simulation or solve a problem. After the result is read, these machines are completely destroyed—even the data. So, it makes no difference to this customer where they do this work. AWS happens to be the convenient choice right now. Next quarter, it may be Azure, who knows? I’m absolutely certain that this customer sees more benefit in avoiding the use of propriety features (a.k.a., the “good bits” of cloud) in a cloud provider rather than using them.

What is your perspective on cloud?
• A means to improve time to market and agility
• A way to transform capex into opex
• Simply a management paradigm – you can have cloud anywhere, even internally as long as you have self-service and infinite resources
• An enabler for a new methodology like DevOps
• Simply a destination for applications

I think that a good perspective may include all of these things. Leave a comment and let me know your thoughts.

Interested in learning more? Download this free whitepaper ‘Cloud Management, Now!’

Cloud computing, cloud service broker, Featured, Public Cloud

Are We All Cloud Service Brokers Now?

By John Dixon, Consulting Architect

 

Robin Meehan of Smart421 recently wrote a couple of great posts on cloud service brokers (CSBs) and the role that they play for consumers of cloud services. (http://smart421.wordpress.com/2014/02/24/were-mostly-all-cloud-services-brokers-now/ and http://smart421.wordpress.com/2014/02/25/cloud-brokerage-and-dynamic-it-workload-migration/). I’m going to write two blogs about the topic. The first will be a background on my views and interpretations around cloud service brokers. In the second post, I will break down some of Robin’s points and explain why I agree or disagree.

Essentially, a cloud broker offers consumers three key things that a single cloud provider does not (these are from the NIST definition of a Cloud Service Broker):

  • Intermediation
  • Aggregation
  • Arbitrage (run-time, deployment-time, plan-time)

My interpretation of these is as follows. We’ll use Amazon Web Services as the example IaaS cloud provider and GreenPages as the example of the cloud broker:

Intermediation. As a cloud broker, GreenPages, sits between you, the consumer, and AWS. GreenPages and other CSBs do this so they can add value to the core AWS offering. Why? Billing and chargeback is a great example. A bill from AWS includes line item charges for EC2, S3, and whichever other services you used during the past month – so you would be able to see that EC2 charges for January were $12,502.90 in total. GreenPages takes this bill and processes it so that you would be able to get more granular information about your spend in January. We would be able to show you:

  • Spend per application
  • Spend per environment (development, test, production)
  • Spend per tier (web, application, database)
  • Spend per resource (CPU, memory, storage, managed services)
  • Compare January 2014 to December, or even January 2013
  • Estimate the spend for February 2014

So, going directly to AWS, you’d be able to answer a question like, “how much did I spend in total for compute in January?”

And, going through GreenPages as a cloud broker, you’d be able to answer a question like, “how much did the development environment for Application X cost in January, and how does that compare with the spend in December?”

I think you’d agree that it is easier to wrap governance around the spend information from a cloud service broker rather than directly from AWS. This is just one of the advantages of using a CSB in front of a cloud provider – even if you’re like many customers out there and choose to use only one provider.

Aggregation. As a CSB, GreenPages aggregates the offerings from many providers and provides a simple interface to provision resources to any of them. Whether you choose AWS, Terremark, Savvis, or even your internal vSphere environment, you’d use the same procedure to provision resources. On the provider side, CSBs also aggregate demand from consumers and are able to negotiate rates. Why is this important? A CSB can add value in three ways here:

1) By allowing you to compare the offerings of different providers – in terms of pricing, SLA guarantees, service credits, supported configurations, etc.

2) By placing a consistent approval framework in front of requests to any provider.

3) By using aggregated demand to negotiate special pricing and terms with providers – terms that may not be available to an individual consumer of cloud services

The approval framework is of course optional – if you wish, you could choose to allow any user to provision infrastructure to any provider. Either way, a CSB can establish a request management framework in front of “the cloud” and can, in turn, provide things like an audit trail of requests and approvals. Perhaps you want to raise an ITIL-style change whenever a cloud request is fulfilled? A CSB can integrate with existing systems like Remedy or ServiceNow for that.

Arbitrage. Robin Meehan has a follow-on post that alludes to cloud arbitrage and workload migration. Cloud arbitrage is somewhat science fiction at this time, but let’s look forward to the not-too-distant future.

First, what is arbitrage and cloud arbitrage? NIST says it is an environment where the flexibility to CSB has the flexibility to choose, on the customer’s behalf, where to best run the customer’s workload. In theory, the CSB would always be on the lookout for a beneficial arrangement, automatically migrate the workload, and likely capture the financial benefit of doing so. This is a little bit like currency arbitrage, where a financial institution is looking for discrepancies in the market for various currencies, and makes various transactions to come up with a beneficial situation. If you’ve ever seen the late-night infomercials for forex.com, don’t believe the easy money hype. You need vast sums of money and perfect market information (e.g., you’re pretty much a bank) to play in that game.

So, cloud arbitrage and “just plain currency arbitrage” are really only similar when it comes to identifying a good idea. This is where we break it down cloud arbitrage into three areas:

  • Run-time arbitrage
  • Deployment-time arbitrage
  • Plan-time arbitrage

In my next post, I will break down cloud arbitrage as well as go over some specific points Robin makes in his posts and offer my opinions on them.

 

To learn more about transforming your IT Department to a broker of IT services download this ebook

 

 

Cloud computing, Featured, IaaS, PaaS, Saas

The PaaS Market as We Know it Will Not Die Off

I’ve been hearing a lot about Platform as a Service (PaaS) lately as part of the broader discussion of cloud computing from both customers and in articles across the web. In this post, I’ll describe PaaS, discuss a recent article that came out on the subject, and take a shot at sorting out IaaS, PaaS, and SaaS.

What is PaaS?

First a quick trip down memory lane for me. As an intern in college, one of my tours of duty was through the manufacturing systems department at an automaker. I came to work the first day to find a modest desktop computer loaded with all of the applications I needed to look busy, and a nicely printed sheet with logins to various development systems. My supervisor called the play: “I tell you what I want, you code it up, I’ll take a look at it, and move it to test if it smells ok.” I and ten other ambitious interns were more than happy to spend the summer with what the HR guy called “javaweb.” The next three months went something like this:

Part I: Setup the environment…

  1. SSH to abcweb01dev.company.com, head over to /opt/httpd/conf/httpd.conf, configure AJP to point to the abcapp01 and 02dev.company.com
  2. SSH to abcapp01.dev.company.com, reinstall the Java SDK to the right version, install the proper database JARs, open /opt/tomcat/conf/context.xml with the JDBC connection pool
  3. SSH to abcdb01dev.company.com, create a user and rights for the app server to talk to the web server
  4. Write something simple to test everything out
  5. Debug the environment to make sure everything works

Part II: THEN start coding…

  1. SSH to abcweb01dev.company.com, head over to /var/www/html and work on my HTML login page for starters, other things down the road
  2. SSH to devapp01dev.company.com, head over to /opt/tomcat/webapps/jpdwebapp/servlet, and code up my Java servlet to process my logins
  3. Open another window, login to abcweb01dev and tail –f /var/www/access_log to see new connections being made to the web server
  4. Open another window, login to abcapp01dev and tail –f /opt/tomcat/logs/catalina.out to see debug output from my servlet
  5. Open another window, login to abcdevapp01 and just keep /opt/tomcat/conf/context.xml open
  6. Open another window, login to abcdevapp01 and /opt/tomcat/bin/shutdown.sh; sleep 5; /opt/tomcat/bin/startup.sh (every time I make a change to the servlet)

(Host names and directory names have been changed to protect the innocent)

Setting up the environment was a little frustrating. And I knew that there was more to the story; some basic work, call it Part 0, to get some equipment in the datacenter, the OS installed, and IP addresses assigned. Part I, setting up the environment, is the work you would do to setup a PaaS platform. As a developer, the work in Part I was to enable me and my department to do the job in Part II – and we had a job to do – to get information to the guys in the plants who were actually manufacturing product!

 

So, here’s a rundown:

Part 0: servers, operating systems, patches, IPs… IaaS

Part I: middleware, configuration, basic testing… PaaS

Part II: application development

So, to me, PaaS is all about using the bits and pieces provided by IaaS, configuring them in a usable platform, delivering that platform to a developer so that they can deliver software to the business. And, hopefully the business is better off because of our software. In this case, our software helped the assembly plant identify and reduce “in-system damage” to vehicles – damage to vehicles that happens as a result of the manufacturing process.

Is the PaaS market as we know it dead?

I’ve read articles predicting the demise of PaaS altogether and others just asking the question about its future. There was a recent Networkworld article entitled “Is the PaaS market as we know it dying?” that discussed the subject. The article makes three main points, referring to 451 Research, Gartner, and other sources.

  1. PaaS features are being swallowed up by IaaS providers
  2. The PaaS market has settled down while the IaaS and SaaS markets have exploded
  3. Pure-play PaaS providers may be squeezed from the market by IaaS and SaaS

 

I agree with point #1. The evidence is in Amazon Web Services features like autoscaling, RDS, SQS, etc. These are fantastic features but interfacing to them locks developers in to using AWS as their single IaaS provider. The IaaS market is still very active, and I think there is a lot to come even though AWS is ahead of other providers at this point. IaaS is commodity, and embedding specialized (read: PaaS) features in an otherwise IaaS system is a tool to get customers to stick around.

I disagree with point #2. The PaaS market has not settled down – it hasn’t even started yet! The spotlight has been on IaaS and SaaS because these things are relatively simple to understand, considering the recent boom in server virtualization. SaaS also used to be known as something that was provided by ASPs (Application Service Providers), so many people are already familiar with this. I think PaaS and the concepts are still finding their place.

Also disagree with point #3, the time and opportunity for pure-play PaaS providers is now. IaaS is becoming sorted out, and it is clearly a commodity item. As we highlighted earlier, solutions from PaaS providers can ride on top of IaaS. I think that PaaS will be the key to application portability amongst different IaaS providers – kind of like Java: write once, run on any JVM (kind of). As you might know, portability is one of NIST’s key characteristics of cloud computing.

Portability is key. I think PaaS will remain its own concept apart from IaaS and SaaS and that we’ll see some emergence of PaaS in 2014. Why? PaaS is the key to portable applications — once written to a PaaS platform, it can be deployed on different IaaS platforms. It’s also important to note that AWS is almost always associated with IaaS, but they have started to look a lot like a PaaS provider (I touched on this in a blog earlier this month). An application written to use AWS features like AutoScaling is great, but not very portable. Lastly, the PaaS market is ripe for innovation. Barriers to entry are low as is required startup capital (there is no need to build a datacenter to build a useful PaaS platform).

This is just my opinion on PaaS — I think the next few years will see a growing interest in PaaS, possibly even over IaaS. I’m interested in hearing what you think about PaaS, feel free to leave me a comment here, find me on twitter at @dixonjp90, or reach out to us at socialmedia@greenpages.com

To hear more from John, download his whitepaper on hybrid cloud computing or his ebook on the evolution of the corporate IT department!