Disqus - Latest Comments for natis

Re: Docker, Greed, and Ecosystems

Nati Shalom — Sat, 27 Dec 2014 21:04:04 -0000

Hi Colin

What's your view on Redhat OpenShift/Kubernetes choice?
Do you believe that will be considering Rocket as well?

Re: רברס עם פלטפורמה: 243 Bumpers 18

Nati Shalom — Fri, 26 Dec 2014 03:21:20 -0000

Hi Alissa

I'm not sure what your referring for single container.
You can always use plain Docker (or Rocket) for application that fits into a single container.

Plain Docker/Rocket doesn't provide yet a way to handle composition of containers as you pointed out and since most real life systems are a composition of containers (micro-services are a good example) you'll need an orchestration ontop of Docker as in the case of google Kubernetes or Amazon ..

Re: Open cloud deconstructed. What it means to be native to the OpenStack cloud.

Nati Shalom — Thu, 04 Sep 2014 09:34:01 -0000

Hi Everett
I think that i signed up for that working group but if i recall correctly it is moderated so i'm not sure if i was approved - i'll check this out again.

I also believe that this should be a topic that we should discuss at the summit - i'm not sure though what's needed to set this up - if you have any idea on what should be the best way to do that i'll appreciate it.

Re: OpenStack in Numbers - The Real Stats

Nati Shalom — Thu, 03 Jul 2014 04:08:15 -0000

I agree that % is a better way to quantify the respond as it provide more relative measure to the number of responders. Overall there were 1780 responders but i'm not sure how many of them responded to this specific question - i guess that if you aggregate all of the environments you could get to this number so it should be 175/268 which is 65%

Re: OpenStack in Numbers - The Real Stats

Nati Shalom — Thu, 22 May 2014 04:06:53 -0000

Deployment tools was taken from the original survey - this was done specifically under the application survey. It marks the tools that people use to deploy application on OpenStack.

Re: Why You SHOULD Want to Use OpenStack

Nati Shalom — Mon, 24 Mar 2014 17:11:54 -0000

Thanks for the comment
I i understand you correctly your suggesting that since the infrastructure is going to be abstracted the choice of a particular infrastructure is less important right?

Re: PaaS as Blackbox: PASS or FAIL?

Nati Shalom — Tue, 24 Sep 2013 13:52:04 -0000

Good read - thanks for putting this together

You may find this post about the need for better control relevant as well: http://natishalom.typepad.c...

Interestingly enough this realisation leading to conversion between DevOps Automation frameworks as a foundation to PaaS - in this way you get better tradeoffs between productivity and control as noted here: http://natishalom.typepad.c...

Re: Marginally Interesting: The Real-Time Big Data Landscape

Nati Shalom — Sun, 18 Aug 2013 01:40:42 -0000

Thanks for putting this together
On the technology side i think that you missed Twitter Storm, Apache Kafka,
On the in-memory databases you missed GigaSpaces XAP along side GridGain

Re: OpenStack Needs A Dominant Vendor, Not Interoperability

Nati Shalom — Sat, 27 Jul 2013 23:58:53 -0000

Matt - good read - thanks!

I get your point on leadership and to a degree your right.

Looking at the history of Linux is often a good reference but we need to be careful with the way we draw the facts.
If we look at the role of Redhat in the linux community it is true that without thiere leadership the project wouldn't have probably goten to where it is now. At the same time the fact that Linux became synonymous to Redhat had caused many in the community to stop contributing to the project. That led to years of stagnation as Redhat was primarily focused on monitization.

I think that it is too early (and too risky) for OpenStack community to get a single major leadership and i have real concerns whether redhat would be the right leadership for the project.

I think that it would be healthier if there wouldn't look at the OpenStack project as a single product but rather a group of products/projects that needs to be integrated and have multiple leaders each leading one core project/product for example Compute, Storage, Network and also the layers above.

This process often happens naturally and not through a formal process by the amount of the de-facto contribution to each project.
I hope that the fact that redhat is in the lead of actual contribution would be a wake call for others in the community such Rackspace and IBM.

Re: OpenStack’s Future Depends on Embracing Amazon. Now.

Nati Shalom — Thu, 25 Jul 2013 08:03:05 -0000

Randy to Boris point above if there are missing features in the
current NOVA API wouldn't it be simpler to fill in the gaps under the current (Rackspace driven) implementation and use that as the Native API and add the API gateway ontop of that?

Also in your suggestion do you suggest that the "Native API" would be underlying substrate that support ALL the aggregated features of all the supported API's?

Re: How to pivot away $34m: Israel’s Xeround shuts it doors with a lesson

Nati Shalom — Sun, 12 May 2013 15:27:49 -0000

This is indeed a sad story.

"Bottom line: selecting the technology solution of a young startup can be equated to investing shares in their company. There’s risk involved, but also plenty of benefits if they succeed."

There's a risk involved regardless of the company size - see what happened to Sun, Bea, Kodak as an example. Even today the future of other big companies such as Dell doesn't look that bright.
Sometimes big companies are even more exposed as they face hard time to adopt to change even when the writing is on the wall.

My Bottom line is that there's a risk involved in the hi-tech business period.

Re: AWS vs. VMware vs. OpenStack: And The Cloud Winner Is... - by Matt Asay

Nati Shalom — Tue, 16 Apr 2013 03:32:04 -0000

The title led me to believe that the article is going to shade some light on the current direction the cloud market is taking, instead it ended up stating the obvious i.e. "the jury is still out ... " very disappointing!

I'm surprised that still many give VMware so much credit after numerous and continues failures - basically the company failed on executing on almost anything that it did or said it will do in the past few years beyond making its virtualization technology slightly better.

Given that, i see OpenStack becoming a bigger threat to VMware than it is to Amazon. With Intel and PayPal one of the biggest VMWare shops moving larger chunks of their datacenter into OpenStack VMware is quickly loosing ground and its enterprise base isn't such as safe base anymore as the article suggest.

See more details on that regard here:

http://natishalom.typepad.c...

Re: "As The PayPal Vs. VMware Story Turns"

Nati Shalom — Sun, 31 Mar 2013 02:22:30 -0000

Regardless of whether the actual number is 9000 or 80000 i see a major trend which is consistent across various enterprise companies and it is growing fast- Enterprises are questioning the value behind VMWare and are not willing to pay the amount of $$ that they did in the past for that value. OpenStack is currently they're only viable alternative and as OpenStack gets more mature more enterprises will start using it as an alternative. The backing from big companies such as HP, IBM, Redhat that knows the enterprise business helps to speed up that trend.

See my take on this and specifically what i believe OpenStack providers should do in light of this:
http://natishalom.typepad.c...

Re: "10 Tools To Prevent Cloud Vendor Lock-in"

Nati Shalom — Thu, 21 Feb 2013 01:18:35 -0000

I think that Cloud Portability may seem to be a big topic and to most people also means that to get portability we need to compromise on a least common denominator.
The cost of that compromise may often be higher than the cost of "locking".

It is therefore important to note that there are various approaches to avoid locking that doesn't necessarily means that we need to agree on a least common denominator as i pointed out in this post: http://natishalom.typepad.c...

Re: "10 Tools To Prevent Cloud Vendor Lock-in"

Nati Shalom — Wed, 20 Feb 2013 18:18:15 -0000

Good overview: You should also consider cloudifysource.org an opensource framework for managing application across large pool of private and public clouds including Amazon, Rackspace, HPCS, Azure, CloudStack, OpenStack, Eucalyptus. Cloudify also support non virtualised legacy data centres.

Re: The Cloud in HP’s Cloud (Part 2): HP Discover, the Enterprise and AWS Cloud

Nati Shalom — Sun, 20 Jan 2013 17:17:05 -0000

Valid points..
I do believe that openstack is where HP needs to bet its life on.
As you pointed out HP didn't yet took that step and until they do theyle keep confusing everyone, including themselfs.

Re: The next big thing: Cloud-native application services

Nati Shalom — Tue, 04 Dec 2012 01:16:23 -0000

"Cloud-native applications can live in multiple clouds and across multiple providers. Applications built in the cloud are not tied to any single hardware stack."

I agree. Its worth noting that in the past building a cloud native application was extremely complex hence why the only option to simplify things was to outrsource the entire app in the form of SaaS.

To your point things have changed. There are lots of open-source frameworks that are available today such as Chef, Puppet that provides an abstraction of the underlying infrastructure, and Cloudify (cloudifysource.org) that provides cross cloud orchestration framework. With that the barrier to build native cloud app is significantly lower as i pointed out in one of my previous posts Mapping the Cloud Stack (http://natishalom.typepad.c...

Re: Moving Enterprise Workloads to the Cloud on a Massive Scale

Nati Shalom — Thu, 08 Nov 2012 03:16:54 -0000

I agree that this is a hard problem to solve.

It sounds like your approach tries to address the difference in behavior between a cloud and enterprise data center environment at the VM layer, similar to CA App Logic - is my understanding is accurate?

I'm not sure if it also aims to address the application automation processes for these examples, imagine the following scenarios:

1. Continuous deployment - the ability to update an existing deployment

2. Automation of fail-over - the ability to detect a failure (assuming that failure is not just a machine failure, it could be other things such as JVM Crashes, lack of memory and GC spikes etc) - This also requires the ability to make sure that the relevant application services would be set to run on different machines or event availability zones.

These are just two examples that shows that application automation is something that assumes intimate knowledge of the application and usually tends to be application specific.

In that context I'm not sure the the two approaches should be considered mutually exclusive.

It may be that having a simpler infrastructure to begin with would make the automation process vastly simpler but I'm not sure that it replaces the need for application automation on top of it.

Anyway I'd be happy to learn more about your solution and see if my understating is accurate.

Re: 6 home truths about rock star developers

Nati Shalom — Sat, 01 Sep 2012 13:01:00 -0000

In my experience "Rock Star" can make wonders on a project. In our specific case large part of our innovation came out of those Rock Stars.
It is also true that Rock Start are not nessaraly driven by the same ambition and goals of the project and when you setup a team you should be ready to deal with that. One way to deal with that is to give them enough space outside of the project to do their one stuff. Quite often i found that even if they focus 50% of their time they deliver more than anyone else. It also happened that the things that they did outside of the project found their way into our product and became another important source for innovation.

Its true though that you can't build a team of Rock Starts - that quickly becomes counter productive.

So the right balance is to have 1 or two Rockstar in a group and team them with other that can complement them.

Bottom line: Working with Rock Starts isn't easy and often requires lots of care, attention and often cost but if done right it pays off .

Re: Unsolicited advice for Marissa Mayer

Nati Shalom — Tue, 24 Jul 2012 12:13:14 -0000

To your 8'th point here is another advice - the elephant in the room:
What should Marissa Mayer do with Yahoo! http://ht.ly/csLYg

Re: Amazon Cloud Outage Lesson: Pilot Error?

Nati Shalom — Fri, 15 Jun 2012 17:45:09 -0000

We need to assume that failure like this are inevitable. Instead we need to design our system to cope with those failure.
To reduce the chance for a failure of a particular cloud provider I would even go as far as setting DR sites on two different cloud providers.

The following post on high scalability.com shows how you could easily migrate workload from Amazon to Rackspace in the event of scaling or failure event. That include both the data and the application workload. The post include a working example on github that shows how this setup work.

See the full detailes here: http://highscalability.com/...

Re: Big data in the cloud

Nati Shalom — Sat, 10 Mar 2012 18:54:26 -0000

Hi Edd

I've been following your coverage on BigData and found them quite insightful - this post is of no exception - thanks for putting all this together!

One of the main challenges that i see with BigData in the cloud is that moving data into the cloud is not that practical both form security and bandwidth perspective so in reality if your data is not already in the cloud the solution that you pointed out wouldn't apply.

For this reason i see other class of solutions for dealign with Big Data in private or hybrid cloud.

The solution relies on automation tools like Chef which provides a good answer but can still be fairly verbose and complex.

Cloudify is a new Open PaaS stack that was designed primarily for managing BigData applications on private cloud. It integrates with automation framework like Chef but comes with a more application platform environment that makes the deployment and management of Big Data applications simpler.

You can find more detailes on that thought on of my recent posts: Big Data Application Platform (http://natishalom.typepad.c...

I haven't seen any reference in your post pointing to Big Data in private/hybrid cloud - i was wondering what's your thoughts on that regard?

Re: Big data in the cloud

Nati Shalom — Sat, 10 Mar 2012 18:54:26 -0000

Hi Edd

I've been following your coverage on BigData and found them quite insightful - this post is of no exception - thanks for putting all this together!

For this reason i see other class of solutions for dealign with Big Data in private or hybrid cloud.

The solution relies on automation tools like Chef which provides a good answer but can still be fairly verbose and complex.

You can find more detailes on that thought on of my recent posts: Big Data Application Platform (http://natishalom.typepad.c...

I haven't seen any reference in your post pointing to Big Data in private/hybrid cloud - i was wondering what's your thoughts on that regard?

Re: The Disintegration of PaaS

Nati Shalom — Fri, 02 Mar 2012 18:15:43 -0000

Sam Excellent writeup..

"I'm referring to the shift away from monolithic, one-size-fits-all PaaS systems towards more open, loosely coupled platforms that makes it easy to consume code and services provided by third parties"
Totally agree.

Currently there are two main approaches to deliver application on the cloud:

1. DevOps - use automation and maintain full control
2. PaaS - abstract the entire infrastructure and force the application into a specific blue print that fits into the cloud world.

My point was that each of the approaches has a limit. DevOps is still fairly complex, PaaS is too limited as you pointed out.

The path to Open PaaS IMO is to combine DevOps and PaaS togather.
I wrote a more detailed post on that subject few weeks ago:

"GigaSpaces Cloudify & Vmware CloudDoundary the new PaaS Jailbreaker" .. http://ht.ly/9qhJq

I'd appreciate your view on that regard.

Re: Analytics for Big Data – Venturing with the Twitter Use Case

Nati Shalom — Fri, 17 Feb 2012 13:58:24 -0000

The videocast is avaliable here:
http://blog.xebia.fr/2012/0...