Pages Menu
TwitterRssFacebook
Categories Menu

Posted by on Mar 13, 2015 in Automation, Compute, DevOps, Infrastructure, Management, Networking, Security | 0 comments

Version Updates – What’s New?

code release

In a word…Everything!

Big release day for VMware engineering yesterday.  Great work guys!

 

VMware vSphere 6.0n (ESXi, vCenter)

6
12-Mar-15
VMware vRealize Operations for Horizon 6.x
6.1.0
12-Mar-15
VMware vRealize Automation 6.x
6.2.1
12-Mar-15
VMware vRealize Orchestrator 6.x
6.0.1
12-Mar-15
vRealize Business Advanced\Enterprise 8.x
8.2.1
12-Mar-15
vRealize Business Standard 6.x
6.1.0
12-Mar-15
vRealize Business Standard 6.x for vSphere
6.1
12-Mar-15
vRealize Code Stream 1.x
1.1.0
12-Mar-15
vRealize Infrastructure Navigator 5.x
5.8.4
12-Mar-15
vRealize Operations Manager 5.x
5.8.5
12-Mar-15
VMware vCloud Networking and Security
5.5.4
12-Mar-15
VMware vCenter Site Recovery Manager 6.x
6
12-Mar-15
VMware Virtual SAN 6.x
6
12-Mar-15
VMware vSphere Data Protection 6.x
6
12-Mar-15
VMware vSphere Replication 6.x
6
12-Mar-15
VMware Integrated Open Stack
1
12-Mar-15
VMware View 6.x
6.1
12-Mar-15
VMware Horizon Client for Windows 3.x
3.3
12-Mar-15
VMware Workspace Portal 2.x
2.1.1
12-Mar-15
VMware App Volumes 2.x
2.6
12-Mar-15
VMware vSphere PowerCLI 6.x
6
12-Mar-15
vRealize Orchestrator Active Directory plugin
2.0.0
12-Mar-15
vRealize Orchestrator vRealize Automation plugin
6.2.1
12-Mar-15

 

 

Thanks to Amy C for the compiled list!

Disclaimer

Read More

Posted by on Oct 1, 2014 in DevOps | 0 comments

Docker – The Next VMware?

I had a conversation with a customer a couple of months ago around Docker. “Is Docker a threat to VMware”? Was the question posed. “The pants company”? Was my reply. The truth is I had never heard of a Docker container until a few months ago and was completely blindsided by my customer.  So if you’re like me and mainly live on the infrastructure side of the house, hopefully the information I’ve found will be helpful in understanding how Docker and VMware can potentially play together.

First I’ll provide a visual that will hopefully clear things up. Think of a container as you would a shipping container. In the VMware world, that container would contain virtual hardware, a guest OS, applications and all of their dependencies. They would be completely isolated from one another and live in perfect harmony. Docker containers are similar except their containers would hold only an application and its dependencies.

In that context the picture would resemble this one:

OSI-shipping-containers-freight

In the infrastructure world, these would be VMs placed nice and neat stacked up on vSphere riding on a host and would be monitored, managed, secure and highly available.

A Docker world would be similar.  Applications would live side by side, yet be completely isolated and portable.  A Docker user could stuff a container with an application, then a fellow developer could share it and install another component into that container and place it back on the stack.  In Docker terminology, this would be a ‘Docker Hub’.  BUT, keep in mind a Docker container still must run on something.

So to play out the analogy a little further, it would look something like this:

MotorShipZrinWithGoldenGateBr

As you can tell I think in very simple terms. To me the difference is the ship. vSphere is a world class hypervisor. I don’t say that because VMware pays my bills, I see the amount of effort and ingenouity our R&D and QA teams put into our releases time and time again. There are other hypervisors out there, but if your mission critical container is loaded on a brand-x hypervisor, the picture could dramatically change.

personal-container-mngmn4

container spill

You get the idea. Docker containers are cool and there’s value to them, but they still need some level of infrastructure in order to work, so I don’t believe it’s an ‘either-or’ strategy, but an ‘and’.  In the above image there’s a massive disaster about to happen and there’s one person being lowered from a helicopter presumably to save the day.  DON’T BE THAT PERSON!  Be the person that recommends the containers are loaded on the most stable ship on the ocean – vSphere!

Docker was the topic of conversation at a VMworld briefing I attended with one of my customers this year.  They were interested in brokering native Docker containers with Cloud Foundry – all of which is fully supported.  There’s actually quite a few YouTube videos out there.  Search ‘Cloud Foundry Docker’ in YouTube if you’re interested in seeing any.

If you also attended VMworld this year, you may have seen the session with Docker CEO Ben Golub who presented with our own Chris Wolf, Office of the CTO on how Docker is better on VMware.  Check out Chris’s blog post here – http://blogs.vmware.com/cto/vmware-docker-better-together/.

So to answer my own topic question: “Docker, the next VMware”?  “No”.  This is a story of ‘and‘, not a story of ‘or‘.  Bottom line is Docker is better on VMware.

 

 

Disclaimer

Read More

Posted by on Sep 26, 2013 in DevOps | 0 comments

VMware and Amazon – Different Strokes for Different Folks

4_UCPC

 

When looking back at the technology archives one can find many parallels of what is currently happening in “The Cloud” market to what has happened to market leaders and challengers of the past.  The most recent example that comes to mind is Blackberry vs iPhone.  The Blackberry had some great years of being the ubiquitous standard of the smartphone.  However, Blackberry’s approach to the smartphone was very different than its challenger, Apple.

Blackberry had an extremely loyal base of customers, especially in business and government. Blackberry produced stable hardware and placed the right tools in the administrators’ hands to manage the Blackberry ecosystem.  In addition to the loyal customers, Blackberry had a strong sales channel and was one of the fastest growing companies in the world so what could go wrong?

In 2007, when the first iPhone came to market, one of Apple’s top focuses was the end user experience in the form of apps and higher end hardware.  Meanwhile, the Blackberry lacked a sizable app ecosystem and the hardware was modest. Additionally, Blackberry’s platform was based on cumbersome 1990s Java technology while Apple used a newer and a more powerful framework to develop on.
The development cycle for apps on the iPhone’s iOS was a fraction of the time and coupled with higher end hardware, developers had more extensibility and capabilities than what could be accomplished on the Blackberry.  The market’s expectations of the smartphone shifted; however, Blackberry stayed its course on how they envisioned the smartphone should be and not what the market wanted.

Apple’s approach resonated with developers and catapulted a surge in iPhone apps, which only strengthened consumer demand.  The result of Apple’s approach fueled the mobile revolution by driving rapid mobile app development that resulted in one of the major catalysts responsible for creating the $250 billion dollar mobile market we see today.

With all that said, let’s bring this back to “The Cloud”.  There are no shortages of CIOs who are counting on “The Cloud” to be the vehicle to drive down their IT spending while increasing the agility for their enterprise.  After all, it’s a fair bet as we are on the cusp of one of the largest technology delivery shifts just as witnessed in the mobile revolution.  The lingering question remains, which cloud is the right cloud?

Let’s start by looking at what Gartner sees as the perceived shift in cloud trends by comparing Gartner’s Magic Quadrant for Cloud Infrastructure December 2010 to August 2013.  At first glance one can see in the December 2010 Magic Quadrant that VMware based cloud providers dominated as leaders.  Fast-forward to August 2013 and AWS is being portrayed as the leader, by a long shot.  However, is AWS’ solution to “The Cloud” actually that much ahead of everyone else’s or is it just different?
2
1

To understand the AWS strategy one needs to see what’s in AWS’ recipe.  Fortunately, the AWS recipe is simple; it’s about fitting the application to the infrastructure, not the infrastructure to the application.  AWS’ adopters are looking for development velocity to create cloud aware applications so that the application is providing the resiliency, not the infrastructure.  AWS’ recipe contrasts with how central IT has traditionally viewed the application to infrastructure relationship.  As a result, the typical VMware buyer is different than the AWS buyer.

Since Amazon’s perspective of “The Cloud” is a paradigm shift, it hasn’t been an ideal forklift environment for most enterprise applications that aren’t “cloud aware” or “cloud ready”.  Today, most organizations depend on VMware technologies to provide traditional applications a resilient environment to live in.

Just like Apple resonated with developers in 2007, Amazon is luring in a similar DNA of developers to help drive AWS’ path as a cloud provider.  Let’s face it; developers don’t care about infrastructure they care about applications.  Developers much rather expose their applications to a catalog of tools and services they can leverage for quicker on-demand elasticity compared to having the latest and greatest enterprise infrastructure.

Just like in the example of Blackberry vs iPhone, Amazon has focused on a different buyer than what the market leaders have.  Fortunately when Apple did this, they not only disrupted but eventually annihilated Blackberry’s market share.  Sure, “The Cloud” is a much more complex and intricate concept than a $199 subsidized smartphone but the reality of it is that there isn’t a one-size fit all approach at this juncture in “The Cloud” saga. However, there are important lessons to be learned from the Blackberry failure.  When the market was looking for a change, Blackberry insisted otherwise and kept missing their window of opportunity to adapt to reinvent their strategy.

What does all this mean? Regardless if the customer is looking to bring in the proverbial Blackberry or iPhone into “The Cloud” know that the VMware and Amazon’s recipes can taste completely different depending on the customer’s use case, application maturity, and development cycles. To make a comparative cost benefit of using a VMware solution or AWS, one need to understand that they are different approaches which gives customers an AND not an OR option for “The Cloud”.

Read More