VMworld - from a Religious Jewish Orthodox Perspective

I am sure you have all been reading the numerous amount of posts recapping VMworld and their experiences. My RSS feed has been overflowing and it has taken a while to get through it all. This will not be my only VMworld post, but one with which I would like give you all my personal perspective of how I went through VMworld, but not from a technical perspective, but from a personal one just before we start with VMworld 2014 Europe.


Forgive me if this has nothing to do with technology, virtualization or cloud, but as you are all aware, religion is a substantial part of my life, and as a result this has an effect on practically everything I do, including attending technical conferences.


Shabbat – or as you might know it as the Sabbath. Shabbat is typically from sunset on Friday afternoon until when 3 stars are visible in the night sky on Saturday evening. During that period – for me this is a day of rest. I will not go into every single detail of what the laws are but basically this means:
  • no travelling
    • not by car,
    • not by bicycle
    • no public transport
    • not by boat, plane, train, air balloon or space ship for that matter
There are even certain restrictions on how far you can actually walk on Shabbat.

Because of these restrictions, my travel to and from a remote location has to be either before Shabbat or after Shabbat finishes. In the case of VMworld, my travel to San Francisco could not commence before Saturday night, and therefore I would arrive on Sunday morning.

The same with travel back, if a conference finishes late in the week and if there is any chance of my flight back not arriving back in time for me to get home before Shabbat, then I will delay my flights until the following Sunday.

I do my research and see if there is a Jewish community in the city I am visiting, and if there is a synagogue close to the location I will be staying, if not – I will probably move to another hotel towards the weekend closer to the Jewish community.


Kosher dietary laws are very specific, and again I will not go into the specifics but for me it boils down to the following.

I do not eat food that has not been prepared under local rabbinical supervision – either by a caterer, or restaurant, or by a company that has their food under local rabbinical supervision, or at a home prepared by another orthodox religious family, which I can rely on.

I will not eat at any establishment in the city where I am, usually there are a number of places that do adhere to these laws. I usually do my research before hand and if there are any Kosher restaurants in the vicinity of my destination.

If not, (and this does happen) I will have to will bring food with me from home, living on “rations for my duration” something I have done before, when I visited India a while back.

Drinks are a little bit easier, water is fine everywhere – as long as it does not have additional flavoring. Coke, Sprite, all the big brand names are fine, but alcohol is not (not that I drink anyway) but still only certain alcoholic beverages are allowed, again under rabbinical supervision.

For VMworld, this was pretty easy, there was one Kosher restaurant (yes, only one) in San Francisco where I had dinner every evening, and the VMworld event team organized special Kosher meals for all those who requested this in advance (most big conferences are willing to cater with special Kosher food, if it is available locally. Lucky me).


I try as much as possible, not to be out of Israel for Shabbat, but unfortunately that does not always work. I prefer to be in the vicinity of a local Jewish community, but then again, there is not always a community everywhere in the world (almost everywhere, but not always). The wonderful thing is that people are usually very welcoming and hospitable and are willing to welcome a fellow Jewish traveller – the same as I do at home for those in need of a place for Shabbat. Usually you know someone who knows someone else who will be able to help you out.

In the event of me not being able to be in the vicinity of a Jewish community, I need to stay at a the hotel, which is my last preference, because of all the electronics and technology, starting with electronic keys, light sensors and so forth, this becomes a challenge and sometimes a very hard one. There are workarounds that for some of the problems, for example -  climbing 21 flights of stairs instead of using the elevator is no fun, but doable, but a challenge nonetheless.

I do not do sight seeing, shopping, or anything much else on Shabbat, it is a day of rest, so it is not really a holiday but more of a necessity to be there so I can continue on my journey the on Sunday.

I know there are limitations – some of you might feel that I might be crazy, but I would not live my life any other way. Being a observant religious Jew, has its upsides as well. There are challenges, many of them, which I face every day, but I embrace them with open arms and welcome whatever comes my way.

I hope this post was somewhat informative, provided some insight into my way of life, showed some of the considerations I have to take into account when travelling – and how I deal with them.

If you or any other Kosher, Jewish or religious traveller (or anyone else for that matter) would like some more details about what can be done to make Kosher travel easier, please feel free to reach out to me either through Twitter, or the through the contact form on my blog and I will be happy to help out if I can.

As always if you would like to leave a comment, feedback or have any questions, please feel free to do so below.


AWS Summit Tel Aviv 2014

Last week I attended the AWS Tech Summit in Tel Aviv.


The Conference is growing. 500 attendees 2 years ago, 1000 last year, 1500 attendees this year. There was an impressive Solutions Expo, with a quite a number of companies.

I enjoyed the Keynote given by Dr. Werner Vogels (VP & CTO). He is great and passionate speaker.

There was one thing that I found quite enlightening and one of the key takeaways for me from the conference. During the keynote Avi Kochva the CIO of Bank Hapoalim (one of the 3 major banks in Israel) who got up on stage and described how they are using AWS today.

He described the 3 points that the bank uses to determine when they can use a public cloud provider:

  1. Using the Cloud has better value, and it provides a better solution than what they are using in house
  2. Using the cloud is a a cheaper solution
  3. Since the CIO is criminally liable if information from the bank is compromised, therefore the security provided for the data in the cloud cannot be less that what they currently have.
He then mentioned publicly that the bank has no core banking data or information in the cloud. Yes they are dabbling in other stuff like providing a site – I assume on AWS – that will allow access to completely anonymized data for developing mobile apps, but I am not sure that much else is there.
This was one of my key takeaways from the conference

Evidently they do not feel that AWS is as secure as their datacenters today. Food for thought.

There a number of sessions on optimizing your workloads in AWS that I attended, and besides the pointers that were given in the sessions I came to the realization that there are so many different features you can use in AWS that it actually can make your head spin. And almost always there is a way to save money – but it not the most trivial solution, and you will not always have the correct person to point in that direction.

A company by the name of Hopon won the startup competition. A nice startup in Israel – that provides a solution for ticketing for public transport.

All in all it was a very interesting day, good always to see the other side of the Cloud, understand where things are currently moving and where other solutions still have to go.

All the slide decks from the summit can be found here.


My Toolbox is Becoming Heavy

I would like to add one or two more points points to my previous post - An Open Letter to the OpenStack Foundation.

  1. I used Ceilometer as an example, and only as an example. I am more than sure that there are perfectly valid reasons to have chosen MongoDB instead of MySQL. I have no doubt. But doing so this still introduces more complexity.
  2. Paul Richards left a comment – and because of his example – I think this just made thoughts even clearer.

    "The point is to use the right tool for the job. Don't use pliers when you need to use a wrench".

    I completely agree with that. I “stole” his example and used it to further emphasize my point.

    Of course every tool has to fit the right job, but to steal your analogy (forgive me), each group thinks that their tool is the right one. And over time - instead of walking around with only a pliers and a wrench you now need a big toolbox with a hammer, a saw, 15 different screwdriver bits, a cutters, duct tape, wire, a wrench, a pliers and so on and so on.

    To continue the analogy - I would have like to see the TC either change the bolt - whether now or in the future - that it will become acceptable for both tasks with one tool. Or alternatively create a tool that can be used both as a wrench and as a pliers.

    That is the job of the TC. But I personally feel that since the work being done on the overall architecture, a holistic OpenStack Product architecture, is lacking - here is where the biggest potential failure could occur.

    I already see it breaking apart - with different HA models, different scaling models for the different components. And it is only going to get worse.

ToolboxMy toolbox becometh heavy.


An Open Letter to the OpenStack Foundation

I have recently started to regularly follow the mailing lists and the conversations are quite interesting.

It is quite evident that that OpenStack is starting to go through growing pains. It was quite evident as well from OpenStack Silicon Valley 2014 that was held yesterday.

OpenStack has grown from a minimal amount – where most of the developers knew each other personally, knew each others phone numbers, a good personal community – the way it should be. But as all good things, like all successful thing, it grows. This is what OpenStack looks like today.

Current OpenStack programs are listed below:

New capabilities under development for Juno and beyond:

These are the core components. I do not think that I am exaggerating if I was to say that there are at least another 30 projects or Github repositories either on the OpenStack repo or the Stackforge repo, and a good portion of them are actively being developed.

Ideally each and every project should be independent from the other. This of course has its upside but also problems as well.

Let’s take an example.

Most of the core components use a central database, typically MySQL. Keystone, Neutron, Glance and so on. You could install a database server for each and every component – but that would probably be major overkill, so usually what will happen is you create different tables on the same database server for each component. This now becomes a shared dependency for all the components now using that Database server. The larger the number of components use it, the more things that need to be considered. It has to be made highly available, the MySQL queries of a single component should not have any major effect on any other component, and so on and so forth.

Dependecy Hell? Spaghetti

So you would think that if most components have decided on using the same database then we should do the same for all of the components? That would be a logical assumption. No need to over complicate things.

Along comes Ceilometer. I will not go into the reasons why, but it uses MongoDB, not MySQL. That just created a complication. I now need to know how to manage another database, back it up, replicate it, and make it highly available. In addition to MySQL.

I have seen this many times, my organization is as guilty as any other for doing things like this. A development group starts working on a product and look for what is the easiest way for them to deliver their solution. Sometimes a solution is chosen because it is a “hot technology” and other times, because the standard “just doesn’t cut it”.

(As a side note – a whole other discussion could be held here, is adhering to standards the right way – even if it is more difficult or takes longer, or get the job done in the best and fastest way possible – ideally it should be a balance of the two – IMHO)

Without clear direction from the product leadership, without a proper standard – things can go wrong very quickly.

That is how I came across a product (with about 30 components) that had 6 different database technologies:

  • Cassandra
  • Oracle
  • CouchDB
  • MySQL
  • MongoDB
  • Derby

That is

  1. 6 different connection strings
  2. 6 different database clients
  3. 6 different backup procedures
  4. 6 different High availability models

And so on and so on…

Is this a bad thing? Depends who you would ask. The people who developed it – they are happy – because they got the job done, product works and they did not create a dependency.

For those who have to deploy, manage, troubleshoot and support this product – THIS IS A NIGHTMARE! for obvious reasons, some of them mentioned above.

I think that the same is happening in OpenStack. The proliferation of projects, the number of developers and just the sheer size of the solution is becoming very hard to manage. Goals of one projects do not necessarily align with that of other projects, and cross project collaboration is not the “best” at the moment between the projects.

Randy Bias said yesterday in his talk at OpenStackSV (not an exact quote):

The problem  is that OpenStack does not currently have a unifying vision or product strategy. With the growth in programs, OpenStack’s more consistent mission starts to be degraded and less meaning around OpenStack occurs.

Each program team tends to have their own view of what OpenStack is. This does not mean there needs to be a dictator in OpenStack, but there does need to be product leadership.

(Source – vElemental)

Adrian Ionel also raised some thought yesterday on the subject.

The general developer does not care about things below or around the application like monitoring software, storage, network, or the hypervisor. They care about API quality and ease of use, feature velocity (not about OpenStack plumbing), and portability (devs want to write things once). Is OpenStack too intrinsic and poorly focused? Are infrastructure vendors moving focus away from critical areas?

In conclusion, he believes that there are some tangible things that can be done.
– Focus on API (awesome, well documented, easy to use, consistent, backwards compatible)
– Invest in ease of use vs flexbile plumbing (could have too many options)
– Don’t move up stack partner instead (LB, DBaaS, etc)
– Reshape upstream engineering to foster open competition inside OpenStack projects (engineering come up with solutions and compete while staying in framework and let market forces choose) vs central planning

(Source – vElemental)

I am not sure I agree with everything that Adrian said, especially not the part about competition. Yes this does produce better products in the end – due to the competition, but it also generates a lot of work (and lines of code) that will probably go down the drain in the end. I do not think that the OpenStack Community is currently in the position to allow themselves that luxury. Code reviews and code fixes are not being completed in the fastest time possible. Added to that extra code in two competing projects for the same purpose will only emphasize this point.

One last thing. The OpenStack WTE (Win the Enterprise) initiative is something that should have been kicked off 2 years ago.

No matter how good the product is – if people cannot use it or it does not provide the functionality that people need, it will not be adopted.

There are things, basic things that the Enterprise needs today, and have been asking for a number of years and can get them today in competing products.

I am not saying that OpenStack has to cater for every single kind of workload, for every application, for every single scenario - not at all. But the vision, the direction has to be there. Lay down the basic foundation of what OpenStack is going after, when you think it will happen, and more importantly what will not be supported or worked on in the upcoming future.

The feeling that I have (and I am not the only one) is that each project is doing what is best for them – and not necessarily what is best for OpenStack.

The Technical Committee’s charter:

The OpenStack Technical Committee provides technical leadership for OpenStack as a whole. Responsibilities include enforcing OpenStack ideals (such as Openness, Transparency, Commonality, Integration and Quality), deciding on issues that impact multiple programs, providing an ultimate appeals board for technical decisions and general oversight. It is a fully-elected Committee that represents the contributors to the project, and more details about membership and programs may be found in its charter.

I think at the upcoming Summit this is going to be a hot discussion topic. The important thing is that it should be an open discussion, and I think taking into consideration not only the development part of the community – but also the User and operators as well.

As always I would be happy to help out in any way I can.


#VMunderground Opening Acts

The event was organized by the VMUnderground crew.

The idea here was to have an activity – community driven – to give people who were interested in something to do on the day before VMworld – Sunday. Yes you could mess around and go sightseeing – all of that is fun – but most of us are techies at heart – and we need our tech fix, so unless you were part of Partner Day or TAM day, there was not much you could do today. So many of you turned up at the City View at Metreon where there were 6 sessions you could choose from, all with panelists.

I volunteered to act as a panelist on the Architecture and Design – the panelists were

So of course there was an incentive for people to come – because they wanted to get in on the best party WUPaaS (Warm Up party as a Service) a tradition over many a VMworld. If you ask anyone they will say that this is most probably one of the best evening events throughout the week, again I think because it is community driven. Yes there are sponsors, quite a number of them actually, but the event is not driven by any single vendor. And of course – it is for the community. Cost is minimal (yes you have to pay to get in) but I personally do not mind spending those $10 to support the wonderful people of our community
(I am thankful that the majority of the costs are covered by the sponsors – so we can continue to enjoy this event)

We were the third and last session on the roster, so I assume that the crowd had warmed up with asking questions and interacting with the previous panels, so they were not shy.

Question were asked, it was a great flowing discussion and as always I learned a lot (and I hope the audience did as well).

Embedded below is the session recording and the full playlist of all the sessions can be found here.

More VMworld posts to follow.