2016-10-25

Pre-OpenStack Summit Post

I am on my way to the summit – cutting it fine, as I will only be arriving after the keynotes have started on Day 1. That is part of my life being a religious orthodox Jew.

Just a few hours ago, I finished the festival of Sukkot, a festival where we ‘leave’ our homes for 8 days and move to a temporary house. Well not really leave the house – but we eat all our meals in the Sukkah for the whole festival.

It symbolizes the fact that we have faith in G-d and remember that life is was not so easy and that we left slavery in Egypt many years ago to become a free nation.

Going back to the title of the post.

Barcelona Summit

The main reason I am going to this summit is because I am co-presenting a session on the work
Shamail Tahir and myself have been leading with the Active User Contributor (AUC) working group over the past few months.

If you are interested in more details about the work – I will not rehash the post that has already been published - Recognizing active user contributors to OpenStack.

Please take a minute or three to read it over.

Great!! You are back.

I think that we are at a time where OpenStack is about to change, and for the better. Traditionally Operators and Users have been neglected left out of many of the decisions made in the projects, something which I have vocally opposed many a time (you can find most of my posts here) especially this one - We Are All OpenStack! Are We Really????.

A number of things have happened recently – and will continue to evolve over the next few months – which will enable Users and Operators to actually have a voice (at least that is my true hope and belief).

Proper representation, real recognition, and hopefully some more influence in directions and perhaps also priorities.

If you are going to be at the summit, make sure you join Shamail and myself presenting the work that was done over the past few months.

I hope that one day we will be able to look back on the past and reflect on a time once past, and understand that we are all now one community.

Looking forward to see you there!

2016-10-16

VMware on AWS - My Thoughts

The world shook a few days ago, with the announcement of a partnership between VMware and AWS.

Screenshot at Oct 15 21-46-03

There are a number of posts that have been released, by a number of bloggers and analysts,  about what this actually means but I would like to highlight 3 of them, and also insights from the Joint announcement and my thoughts on the matter as whole.

So first some history, VMware has always perceived AWS as a competitor. It is no secret that VMware over the years (https://gigaom.com/2013/03/01/vmware-stick-with-us-because-amazon-will-kill-us-all/) have warned their customers about going to AWS. Some of the claims included (but not only):

  • Why this is bad thing.
  • One way ticket – vendor lock-in
  • Enterprise workloads are not suitable
  • The list goes on.

VMware even has (or had) specific playbooks and marketing decks that were used to explain to their customers why vCloud (or vCloud Air) was a much better choice that AWS.

So first facts.

The Announcement

This was the slide that was presented on the live broadcast.

Screenshot at Oct 15 21-48-35

  1. An integrated hybrid cloud service.

    To me that means that I can move my workloads from my on-premises Private Cloud to a Public Cloud Provider – and in this case it would be AWS.

    One thing that should be made clear off the bat.

    The offering that was announced – is not a hybrid solution. What VMware is offering is the option to place your workloads either in your on-premises Private Cloud or in another Private Cloud which is located in a 3rd party Datacenter – in this case – AWS. VMware are trying to position and sell as something that it is not.

    You are not making use AWS as a cloud provider – all you are doing is using them as a 3rd party bare metal provider.
  2. Jointly Architected Solution

    Yes there was some work needed on both sides. But honestly – I think the work was almost completely on the part of VMWare, and hardly any investment on the part of AWS. Let me explain why.

    If you look at what AWS offers today, they are not adding, removing, or changing anything at all in their infrastructure to accommodate this offer. Perhaps they are ensuring that there will be enough capacity to run the solution – but nothing besides that has to change.

    It could be I am wrong – but this is how I would envision how the product would work.

    Once a new Cloud is ordered (see screenshot from Demo below) VMware will go and request the appropriate bare metal hosts from AWS – by invoking an API, install ESXi on the hosts and then provision all the additional building blocks on top of it. I assume that a lot of the work that will bring up this infrastructure will be using the work and the expertise of the people in Project Zombie which already is being used (I hope) for building up vCloud Air.

    Screenshot at Oct 15 21-18-38

    What does AWS have to do allow this solution to work? Nadda, it already exists – anyone can request a bare metal server.

    On second thought, I may be exaggerating – they probably did and will provide an AMI (Amazon Machine Image) with ESXi readily installed – to make things move a bit faster.

    (An interesting tidbit of info that comes out this relationship, that the AWS proprietary hardware – will now be certified to run ESXi)

    So if we look again. What effort was needed on AWS’s part – I assume the AMI image (perhaps some other background stuff – which we do not know about). From the VMware perspective – writing the code to call the correct AWS API’s for the bare metal nodes, the code to provision all the nuts and bolts on the servers and of course let us not forget the required work that went into certifying the proprietary AWS hardware that they use. If you are aware of it – or not, AWS builds their own hardware in direct partnership with hardware manufacturers, they don’t run brand names. At the scale they are functioning – it does not make sense.

    (So just as side bit of information – unless this is a specialized version of ESXi –  it might be – but I assume that the changes will make it into the default code base at some point because maintaining a specific branch, just for AWS does not make sense. In the future you probably will be able to deploy your own bare metal node from AWS and install ESXi on it – all on your own – without the service from VMware. It will not be as polished as the service provided by VMware – but it should be possible. Once they have opened this Pandora’s box – it will be hard to close it)
  3. Primary Public Cloud Solution – delivered, sold and supported by VMware

    So as I said above – this is not really a public cloud solution solution – this is a Private cloud running on a Public Cloud on AWS – who are the suppliers are the bare metal servers. Is this way AWS are no different than any other vendor who provides the same service.

    They are not offering a public cloud solution running on top of AWS. They are not offering the option for you to deploy a Cloud solution that you will be able to sell to your customers. It is a vSphere ,VSAN and NSX environment that you use to your hearts desire. Your applications can use all of AWS’s other services – you cam already do that today – without running VMware on AWS.

    But it is not a Public Cloud.
  4. Run any application across vSphere based Private, Public and Hybrid Clouds 

    Finally something I can agree with!!
  5. AWS will be VMware’s primary Public cloud infrastructure partner, and VMware will be AWS’s primary private cloud partner

    So this one is interesting.

    Firstly, if I was a VMware vCloud partner – I would be very, very worried because there is no-one that can compete with the scale of AWS, and a statement like this one – saying that we have one main partner would put dampers on other partners. For example the partnership announced just over two months ago with IBM (https://www-03.ibm.com/press/us/en/pressrelease/50420.wss).

    The other side of the equation of AWS using VMware as a private cloud partner – is not something that I would take too seriously. AWS has always and still believes that everything should run in the Public cloud.

    What does AWS have to gain from this? Absolutely everything!!!

    VMware are trying to position this offer as a way to start using AWS resources – not with any kind of integration mind you – because from the information currently made available – there is no special integration done with VMware to make use of the AWS resources. Yes the announcement said they will be able to use AWS services – but it also was stated that the benefit here will be the proximity to AWS resources in each location – nothing more. That is a huge plus but then again, this is something that anyone can do today, running from within AWS or running from with their own datacenter. It is just a matter of proximity, not any technological advantage.

    In addition – when VMware users start learning about the plethora of available services that they can use while in AWS  they will see that it might start to make sense to use them natively – without running first on VMware.

    Screenshot at Oct 15 22-13-10

    The above screenshot was from Jeff Barr’s blog post, which I think points towards the future direction and why AWS were ready to accept this with open arms.

    They view the workloads that will run in VMware on AWS as old fashioned, historical applications (and there will always be a need for such applications). And when you the User are ready to grow up and move forward to the future – we are ready to help and will accept you with open arms, you are already half the way there.

    The same as well when you are interested to scale your application – then we have the capacity and the geographical spread to help you out. Just know that running it on VMware might not be your best bet.

    I am sure they are betting on the fact that once they have the workload in an AWS datacenter – the path for migrating off of VMware into AWS native will not be so scary.

Elastic DRS

Screenshot at Oct 15 21-37-23

Technologically speaking this is being made out be a much bigger feature than it really is. For a shop that is heavily into automation – how hard is it to actually scale up your cluster? Honestly – I think the biggest thing would be to order the actual hardware, rack it and stack it. The rest of it really trivial, installing ESXi, Host profiles and adding it to a cluster – is all something that we know how to do, and if we really did some work, automate it up the wazoo.

This is a very simple thing to now to do for VMware in this solution – all they need to do is make an API call to provision a new bare metal server and do all the magic behind. No more rack and stack, no more waiting for hardware to arrive – no more doing things the old way. They have a theoretically infinite supply of hardware to run VMware workloads – so this makes perfect sense. 

The Demo – was just that – a Demo

The demo showed the provisioning of an environment in AWS.

Screenshot at Oct 15 21-28-32

There is no way in hell, ever, that a 4 host cluster with VSAN and NSX, could be provisioned in less than 3 minutes. The installation of all that software – including vCenter  (especially vCenter) is not that fast.

I would suppose that it would take an hour or two to actually provision all the pieces to get it up and running.

Screenshot at Oct 15 21-30-46

(So just for purposes of bike shedding, do you start paying per hour – from the time that you click go – or from the time that the resources are fully available)

Cost

Last but not least – the matter of how much this is going to cost.

There is no denying that this is going to open up a huge amount of options to people who previously were limited in scale because of power, space, hardware limitations, etc.

But this is not going to be cheap. And let us all be honest – the amount of people that are going to use this as on per-hour basis – is going minimal. The majority of customers will use this on a regular basis – trying to maximize the resources they can use for the lowest cost possible.

Doing the math on the amount of CPU and RAM available in the cluster size offered in the demo – it seems that the Dedicated Host type will probably be a an M4.

The monthly cost of an M4 (without even putting any VMware software on it is $1451.90 x 4 servers – means we are looking at ~$6,000 for hardware alone per month.

I assume that VMware are going to want to factor into this the costs of licensing and operations – remember – this is a fully managed service that you are getting (which also brings up a question – how much control do you have over the underlying infrastructure, I assume none).

The current cost for a vCloud host (Dedicated Cloud) is just short of $6,000 per month – without support. I can envision that VMware manage to keep the costs more or less the same as they have up until now – but it will definitely be a good idea to run a proper cost-analysis to see if this is something that will be good for and your organization.

Summary

AWS will be the ones to benefit the most from this in the long run.

VMware are making this out to be a much bigger deal than it actually really is.

As always – please feel free to leave your thoughts and comments below.

2016-10-14

Saying Thank You!

So if I am already on a roll with saying thank you, I wanted to share wiith you all a post I wrote on LinkedIn a month ago (https://www.linkedin.com/pulse/saying-thank-you-maish-saidel-keesing)

Reposting it here in it’s entirety.


Thankyou(Source: http://www.flickr.com/photos/27282406@N03/4134661728/)

Two small words, but they make so much of a difference.

We take things for granted - every single day.

  • Life
  • Breathing
  • Our kids
  • Our family
  • Electricity
  • Email

All of these are things that we interact with every day, and only when they do not work, things go wrong, or are no longer there - do we wonder.

How can this be? Something so basic, so simple - it should be there.

It should work.

But nothing is there forever.

When was the last time you said thank you to your e-mail Admin - for making sure that you can check your email on your phone, at home, when you walk in the door every morning to work, anywhere and everywhere.

Did you say thank you to the utility company that makes sure your gas, water and electricity are working each and every day?

There are so many people that work their ass off to make this happen, come rain or shine, snow, hail or thunderstorm. Every day, every hour of the day.

I would like to share with you a short letter I wrote to a food company that supplies Kosher food, on a flight I was on last week.

Thank You

I received an answer back a week later (and am publishing with their permission)

Thank you

I cannot describe what a great feeling it gave me to receive this answer back.

Say thank you.

Say thank you to the doorman that opens the door for you.

Say thank you to those who clean your office every day.

Say thank you those who serve you a drink in the plane.

Say thank you.

You never know how much those two small words will make a difference - for you and for all those around you.


Have a great weekend everyone!

2016-10-13

A Small Note to Thank two New Sponsors

Writing a blog is mostly fun, but it comes with a cost not only of time and effort but also some cold hard cash (or actually everything is paid today with a credit and it all just numbers on a spreadsheet..) be it for Webhosting, Domain registration – well you all know the drill.

So it is time to thank two new Sponsors of this blog.

solarwinds – who have many products for the IT / Network / DB / VMware Admin and some of them are even free.

The second sponsor that I would like welcome is:

Nakivo – a vendor that have a backup solution for your workloads running in VMware or in AWS.

For any other potential parties who would like sponsor my blog, please feel free to sign up here.

2016-10-09

I Don’t Want to Talk to my Cloud Provider

A short while back I participated in an internal event. A number of priority customers of our internal cloud service were invited for a feedback session, to voice their thoughts, listen to roadmap sessions and just to get to know each other.

There was one comment made there by one of the participants that has been on my mind since then, and it was something along the lines of:

"I have been using AWS longer than I have been using our internal cloud service – that is more than 5 years. Ever since I have started, I have only contacted AWS support once – when I managed to somehow corrupt my two-factor authentication token. I have never received a marketing call, never been invited to such a feedback forum. There has never been a need.

On the other hand, on our internal services, I am flagged as a priority customer, have weekly, bi-monthly, monthly feedback sessions, capacity planning sessions and escalation paths.”

This got me thinking, and I completely agree.

A service where I can say that I use and rely on is something that just plain and simply works.

Let me give you an example. How would you feel if you would have to have a direct line into your electricity company to escalate when your lights did not come on when you flicked the switch, when you had to meet with them to discuss how many appliances you were planning to use this month, if you were planning on baking cakes for a party this week, and therefore you would be needing more electrical resources this month – so the electrical company should be ready for your surge in power consumption. Is that a company that you would say you can trust?

Probably not.

You would like the lights to go on every time you flick the switch, and not have worry about leaving the air conditioner on the whole day because it is really hot that day. All I would need know is that I will pay more that day or month – because I use more of the service your offered.

When we try to build a service – we should be doing it in such a way that it is something that the customer should be able to rely upon, something that we should be able use – without having to have direct lines into the support team to ask questions, because that team has already provided the proper documentation to explain exactly what I need to know – in order to use that service. You have provided additional channels and ways for them to self support themselves. There will always be some who know more, and others that know less. There will even be times where your customers know a lot more and do things with your infrastructure that you would have never dreamed of doing on your own. Let them help others as well.

Provide them with the tools to share their knowledge with others, be it a Wiki that they can update, a chat room where they can also assist other customers. It will benefit your other customers for and will benefit you in the long run, because you will have less load on your support team to answer these questions.

Self service portals for as much as possible – exposing as many of your services as API’s so that your end customers can consume them – without having to ask you to do it for them. All of these and many more, are what makes a successful service, both a public one – and even more so one in-house.

Put in as much automation as possible – because scaling people is so much harder that scaling a process.

Not everything can be infinite – and not everyone can build a service at scale like AWS – but this should be your goal – even if it is not possible at day-1.

I will leave you with the wish that my colleague gave to our internal cloud service team.

"I hope we come to a time where we do not have to contact you – or have frequent meetings to discuss this service. We just consume the service.

When we get to that point – then you know that you are providing service that just plain and simply works, and you have done a really good job."

Some food for thought.

As always, please feel free to leave your thoughts, and comments below.