Recently we've spun up a project to explore migrating all our public and private reports to a new SAP BusinessObjects Business Intelligence (BI) 4.x environment. The portal site to deliver the reports will be SharePoint 2010. The reports will be used by the general public and privately by users through a SharePoint-based extranet.
We plan on using the full gamut of BO BI reporting capabilities including WebI, Crystal, Dashboard (Xcelsius), QaaWS, all underpinned by Universes. Our existing Oracle RAC data warehouse will be the source for all reports, with operational databases feeding the data warehouse in near real time using a combination of PL/SQL ETL and SAP BusinessObjects Data Services 4.x ETL.
Over the next few months I hope to blog on some of the benefits and challenges of this project. In particular, gluing these technologies together. If you have a similar project or have some experience using this same technology stack, I would love to hear from you.
Wednesday, December 21, 2011
Wednesday, July 13, 2011
VMware changes its licensing model (and not for the better)
Yesterday VMware announced the release of vSphere 5. Some great new features were announced (Storage DRS for one). But included in the announcement was a change to their licensing model. Under vSphere 5, VMware editions are licensed on a per CPU socket (not core) basis and pooled virtual RAM (vRAM). I applaud any changes that bring licensing models closer to the way public/private cloud chargeback models work. But digging into the licensing model revealed some nasty surprises. At the company I work for, the change effectively increases our VMware licensing costs by 33%.
Here's how it shakes down for us. Our standard VMware ESX is a blade server consisting of 2 CPUs with 6 cores each (12 cores total), and 128GB RAM. Most of our applications, like many other companies, are memory intensive and not CPU intensive. Our standard is to license each blade with VMware vSphere Enterprise Plus edition.
Under the new licensing model, purchasing a 1 socket license of Enterprise Plus entitles to you 48GB of vRAM to allocate to VMs. VMware makes no mention of being able to purchase vRAM entitlements without purchasing the socket license. So in our scenario, we'll have to purchase a 3 socket Enterprise Plus license for our 2 socket blade server in order to use all 128GB of physical RAM.
3 socket license entitles us to 144GB RAM (3 x 48GB)
2 socket license entitles us to 96 GB RAM (2 x 48GB)
Further with the 3 socket license, now we are over entitled on the vRAM, meaning we essentially licensed more vRAM (144GB) than we have physically installed on the blade (128GB). If we had gone with the 2 socket license, we would have under licensed the vRAM (96GB) verses the physical RAM (128GB) and wasted installed RAM.
Now VMware counters that vRAM entitlments are pooled across a cluster (provided all cluster nodes are running the same edition of vSphere e.g. Enterprise Plus). Yes, I like that but it still doesn't solve my problem of this low 48GB vRAM entitlement with Enterprise Plus.
So based on our current blade configuration our licensing costs have increased by 33%. Multiply that across a 36 blade VMware cluster, and the cost increase becomes very serious. Serious enough to have me revisit Gartner's 2011 Virtualization Magic quadrant and re-evaluate VMware as the virtualization platform for the organization. Alternatively, we'll have to reconsider our standard blade server configuration to find a more optimal balance between sockets and installed RAM.
To rub salt in the wound, as of Aug 12, VMware will no longer be selling vSphere 4.1 licenses, only vSphere 5. However, vSphere 5 licenses do come with downgrade rights to vSphere 4.
A quick check on Twitter (#vmwlicensing) shows many VMware users are up in arms over this change. Let's hope by the time VMworld 2011 happens, VMware has reconsidered vRAM entitlement thresholds, or perhaps offers vRAM to be purchased/licensed a la carte.
You can read about the new vSphere 5 licensing model here.
Here's how it shakes down for us. Our standard VMware ESX is a blade server consisting of 2 CPUs with 6 cores each (12 cores total), and 128GB RAM. Most of our applications, like many other companies, are memory intensive and not CPU intensive. Our standard is to license each blade with VMware vSphere Enterprise Plus edition.
Under the new licensing model, purchasing a 1 socket license of Enterprise Plus entitles to you 48GB of vRAM to allocate to VMs. VMware makes no mention of being able to purchase vRAM entitlements without purchasing the socket license. So in our scenario, we'll have to purchase a 3 socket Enterprise Plus license for our 2 socket blade server in order to use all 128GB of physical RAM.
3 socket license entitles us to 144GB RAM (3 x 48GB)
2 socket license entitles us to 96 GB RAM (2 x 48GB)
Further with the 3 socket license, now we are over entitled on the vRAM, meaning we essentially licensed more vRAM (144GB) than we have physically installed on the blade (128GB). If we had gone with the 2 socket license, we would have under licensed the vRAM (96GB) verses the physical RAM (128GB) and wasted installed RAM.
Now VMware counters that vRAM entitlments are pooled across a cluster (provided all cluster nodes are running the same edition of vSphere e.g. Enterprise Plus). Yes, I like that but it still doesn't solve my problem of this low 48GB vRAM entitlement with Enterprise Plus.
So based on our current blade configuration our licensing costs have increased by 33%. Multiply that across a 36 blade VMware cluster, and the cost increase becomes very serious. Serious enough to have me revisit Gartner's 2011 Virtualization Magic quadrant and re-evaluate VMware as the virtualization platform for the organization. Alternatively, we'll have to reconsider our standard blade server configuration to find a more optimal balance between sockets and installed RAM.
To rub salt in the wound, as of Aug 12, VMware will no longer be selling vSphere 4.1 licenses, only vSphere 5. However, vSphere 5 licenses do come with downgrade rights to vSphere 4.
A quick check on Twitter (#vmwlicensing) shows many VMware users are up in arms over this change. Let's hope by the time VMworld 2011 happens, VMware has reconsidered vRAM entitlement thresholds, or perhaps offers vRAM to be purchased/licensed a la carte.
You can read about the new vSphere 5 licensing model here.
Tuesday, May 31, 2011
VMware acquires SocialCast - another steps towards competing with Office365
I mentioned in a previous blog post I believe VMware is building (rather acquiring) an Office365 competitive offering as they move from being an IaaS vendor to a PaaS and SaaS vendor. Today VMware announced their acquisition of SocialCast, an enterprise collaboration tool. SocialCast is offered as on premise, private cloud or SaaS.
I liken SocialCast to Office365's SharePoint offering, but with notable differences such as CRM and ERP integration. So in my mind here's where VMware is at today.
Outlook/Exchange = Zimbra
SharePoint = SocialCast
PowerPoint = SlideRocket
Word = ??? TBD
Excel = ??? TBD
I am over generalizing the comparisions but you get the idea. Any bets on what the future VMware acquisitions will be? Perhaps a Word and Excel equivalent? I would also bet that VMware is looking at porting these applications to CloudFoundry and building a future product/brand offering around them, along with requisite management tools.
I liken SocialCast to Office365's SharePoint offering, but with notable differences such as CRM and ERP integration. So in my mind here's where VMware is at today.
Outlook/Exchange = Zimbra
SharePoint = SocialCast
PowerPoint = SlideRocket
Word = ??? TBD
Excel = ??? TBD
I am over generalizing the comparisions but you get the idea. Any bets on what the future VMware acquisitions will be? Perhaps a Word and Excel equivalent? I would also bet that VMware is looking at porting these applications to CloudFoundry and building a future product/brand offering around them, along with requisite management tools.
New NetApp CommVault OEM Relationship
Today NetApp and CommVault announced an OEM relationship whereby CommVault will integrate with NetApp's snapshot technology. The new NetApp SnapProtect product uses CommVault Simpana to add traditional backup and restore capabilities to NetApp's snapshot technologies (SnapManager, SnapMirror, SnapVault). NetApp SnapProtect provides a single management framework for managing NetApp snapshots, SnapMirror, SnapVault and backup schedules. In the past managing NetApp snapshots and host backup required separate processes and tools. Administrators needed to manually keep track of overlap and scheduling between the tools.
The other benefit is driving the traditional backup to tape process off the host or virtual machine to the storage array level, and utilize snapshots. Using SnapProtect, CommVault can restore of individual files, provide data classification and snapshot management through the SnapProtect framework.
Press release: http://www.netapp.com/us/company/news/news-rel-20110531-291587.html
The other benefit is driving the traditional backup to tape process off the host or virtual machine to the storage array level, and utilize snapshots. Using SnapProtect, CommVault can restore of individual files, provide data classification and snapshot management through the SnapProtect framework.
Press release: http://www.netapp.com/us/company/news/news-rel-20110531-291587.html
Friday, May 13, 2011
VMware Cloud Foundry shakes up the PaaS model
With VMware’s release of Cloud Foundry it seems the momentum continues towards PaaS and SaaS. This is backed by the recent Forrester report "Sizing the Cloud" which shows the future revenue largely in SaaS, followed by PaaS. The following graphic depicts where the major vendors are at with their IaaS, PaaS and SaaS offerings.
What makes VMware’s Cloud Foundry interesting is for those who design and build private clouds. Up to this point anyone building a private internal cloud could only emulate an IaaS offering whereby the applications group could self provision virtual machines equipped with compute resources, an operating system and storage. But this still left the burden of installing and deploying the application layer, and the app itself, on the applications group.
If an organization wanted to offer a PaaS in their private cloud, they were essentially out of luck. In 2010 Microsoft did release an Azure Appliance to allow organizations to build their own internal Azure-based PaaS. However the Azure Appliance is largely targeted at very large service providers.
With the public cloud, picking a PaaS provider meant vendor lock in. Build an app for Azure and forget about moving it to Amazon AWS.
But Cloud Foundry looks to change this. First, companies with private clouds will be able to run the Cloud Foundry PaaS. Theoretically even private clouds build on Hyper-V (rather than VMware vSphere) could run Cloud Foundry. Second, if you build an app and deploy it to Cloud Foundry on the public cloud you aren’t locked in. If you find your vendor isn’t meeting their SLA on a routine basis, simply redeploy the app to Cloud Foundry running in your private cloud or to another public cloud provider running Cloud Foundry.
Looking forward I see a few interesting things happening:
- Most large organizations that are building private clouds and IaaS are not using Hyper–V for server virtualization. They are using VMware vSphere and vCloud (in addition to storage and network virtualization and other components that make up a private cloud). Therefore, my feeling is VMware customers will most likely adopt Cloud Foundry over the Azure Appliance.
- VMware’s decision to open source Cloud Foundry will allow it grow and mature quickly. For example, existing languages such as PHP will be quickly supported. Only Spring for Java applications, Rails and Sinatra for Ruby apps, and Node.js apps are currently supported.
- Cloud Foundry will appeal most to companies not using Microsoft development tools and environments.
While the release of Cloud Foundry may warrant adding it to your organization’s long term enterprise application architecture roadmap few, if any, organizations will entertain bringing it into their private clouds in the near term. The main reason for this is most organizations are still in the process of building out their private clouds and getting a handle on all the orchestration and management tools needed to deliver it and chargeback models needed to economically support it.
Wednesday, April 27, 2011
Is VMware building an Office365 competitor?
Sure seems like it. VMware recently announced the acquisition of SlideRocket. SlideRocket has developed a SaaS application for building, delivering, and sharing presentations online. Sounds similar to Office365 PowerPoint webapp (currently in beta). VMware has also begun encroaching on the PaaS space with the release of Cloud Foundry. Cloud Foundry is VMware's attempt to move into the PaaS space currently occupied by Microsoft Azure and Amazon AWS.
But with the SlideRocket rocket acquisition, this marks VMware move from PaaS (and of course IaaS) to now offering a end user SaaS application. Presumably SlideRocket will eventually be ported to run on Cloud Foundry just like Office365 will eventually run on Azure, if not already.
A recent Forrester report "Sizing the Cloud" seems to confirm this. It shows that global IaaS revenue will peak in 2014. But PaaS, and more so SaaS, is where the future money is, according to Forrester.
It will be interesting to see what other SaaS acquisitions VMware pursues. I wouldn't be the least bit surprised if a SaaS-based word processor and/or spreadsheet acquisition are on the horizon. Or perhaps the SlideRocket acquisition was simply an attempt to excite developers on Cloud Foundry with the hopes of accelerating 3rd party development on it.
But with the SlideRocket rocket acquisition, this marks VMware move from PaaS (and of course IaaS) to now offering a end user SaaS application. Presumably SlideRocket will eventually be ported to run on Cloud Foundry just like Office365 will eventually run on Azure, if not already.
A recent Forrester report "Sizing the Cloud" seems to confirm this. It shows that global IaaS revenue will peak in 2014. But PaaS, and more so SaaS, is where the future money is, according to Forrester.
It will be interesting to see what other SaaS acquisitions VMware pursues. I wouldn't be the least bit surprised if a SaaS-based word processor and/or spreadsheet acquisition are on the horizon. Or perhaps the SlideRocket acquisition was simply an attempt to excite developers on Cloud Foundry with the hopes of accelerating 3rd party development on it.
Sunday, April 10, 2011
Aligning the Zachman EA Framework and the SDLC
Lately I have been looking into the alignment between the Zachman Enterprise Architecture (EA) Framework and the System Development Life Cycle (SDLC).
Zachman is a matrix-based EA framework. The rows are considered stakeholder perspectives or abstractions. Columns represent the different communications questions. At the intersection of these rows and columns are artifacts or tasks, which may produce an artifact in another intersection. Zachman provides a taxonomy for the organization of artifacts. Most organizations will tailor the Zachman framework and the artifacts produced. For example, a combination of intersections at a given perspective (e.g. Planner) may result in one artifact (e.g. Business Case).
On the other hand, the SDLC is a life cycle methodology for the inception, development/implementation, operation and retirement phases of a system.
In general the SDLC consists of the following phases:
In each of the above phases one or more artifacts are produced. For example, in the feasibility or analysis phases a business case along with business requirements may be the resultant artifact. In the Design phase an organization may require UML or Visio diagrams be produced. Like Zachman, most organizations tailor the SDLC in terms of the artifacts produced from the various phases.
So how does the Zachman framework and the SDLC align to each other? Quite nicely in fact. For example, combining the Zachman "Designer" perspective's Logical Data Model (Data/What), System Architecture Model (Function/How), and Distributed Systems Architecture (Network/Where) may result in one SDLC artifact, perhaps called the Solution Design document, that maps to the SDLC Design phase.
Another example may be combining the Zachman's "Builder" perspective's Technology Design Model (Function/How) and Technology Architecture (Network/Where) in a Visio diagram detailing the "as built" implementation. This would correspond with the SDLC Implementation phase.
Organizations looking to implement the Zachman EA framework and align it to their existing SDLC, or vice versa, must spend some time to understand what processes, life cycle phases and resultant artifacts they really require. Once that's complete, aligning the SDLC and Zachman should be a fairly minor exercise.
Zachman is a matrix-based EA framework. The rows are considered stakeholder perspectives or abstractions. Columns represent the different communications questions. At the intersection of these rows and columns are artifacts or tasks, which may produce an artifact in another intersection. Zachman provides a taxonomy for the organization of artifacts. Most organizations will tailor the Zachman framework and the artifacts produced. For example, a combination of intersections at a given perspective (e.g. Planner) may result in one artifact (e.g. Business Case).
On the other hand, the SDLC is a life cycle methodology for the inception, development/implementation, operation and retirement phases of a system.
In general the SDLC consists of the following phases:
- Project planning
- Feasibility
- Analysis
- Requirements
- Design
- Implementation
- Test
- Maintenance
- Retirement
In each of the above phases one or more artifacts are produced. For example, in the feasibility or analysis phases a business case along with business requirements may be the resultant artifact. In the Design phase an organization may require UML or Visio diagrams be produced. Like Zachman, most organizations tailor the SDLC in terms of the artifacts produced from the various phases.
So how does the Zachman framework and the SDLC align to each other? Quite nicely in fact. For example, combining the Zachman "Designer" perspective's Logical Data Model (Data/What), System Architecture Model (Function/How), and Distributed Systems Architecture (Network/Where) may result in one SDLC artifact, perhaps called the Solution Design document, that maps to the SDLC Design phase.
Another example may be combining the Zachman's "Builder" perspective's Technology Design Model (Function/How) and Technology Architecture (Network/Where) in a Visio diagram detailing the "as built" implementation. This would correspond with the SDLC Implementation phase.
Organizations looking to implement the Zachman EA framework and align it to their existing SDLC, or vice versa, must spend some time to understand what processes, life cycle phases and resultant artifacts they really require. Once that's complete, aligning the SDLC and Zachman should be a fairly minor exercise.
Subscribe to:
Posts (Atom)