Slashdot Mirror
Why PayPal Chose OpenStack
AlbanX writes in with this story about Paypal's use of OpenStack. "PayPal's IT team has taken control of its technology release cycle by shifting key components of its IT infrastructure onto OpenStack. For PayPal, the decision to use components of OpenStack was based around speed to market. It allows the payments provider to untether its release cycle from those of vendor partners. 'PayPal has not historically been known for its fast reactions,' PayPal senior engineer Scott Carlson conceded to attendees at the VMworld conference in San Francisco this week. 'It has taken us six to nine months sometimes to react to our competitors.'"
No articles on Credit Suisse's decision not to use OpenStack and their rationale for not doing so? On my own head be it, I suppose....
It's a collection of open source API's for the management and automation of virtual machines at scale. It can be used with a number of hypervisors including VMWare vsphere, Xen, KVM, Hyper-V and a few others.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Both AC's fail to notice the 2nd line explaining Open Stack.
They have a single business, with a relatively constant, yet probably growing number of users. If they need 100 servers today, next year it will be 120. They don't need massive content or application distribution, they don't need to rush new products to market, they don't need all that cloudy stuff. If "OpenStack" just means they virtualized some old iron that's another story, but a far less interesting one.
I want to delete my account but Slashdot doesn't allow it.
Those involved in Virtualisation probably (or should have) known this anyhow.
The Hypervisor war is done. Pretty much everyone (VMware, MS, Citrix) have their new cloud based offerings that are agnostic towards the hypervisor that runs on the tin. If you have played with vClould Automation Center for example, there are multiple options for the hypervisor types including Citrix. The bottom line is there is not much more to add to to hyervisor and there is also less money in the hypervisor. It is an old (mature?) technology.
The new hot button is the tools to manage the infrastructure and that is where the real war is going to be won or lost.
http://www.writeitfor.us - Writing IT for the IT generation.
Anonymous - check
"Shitload" - check
Not afraid of excessive punctuation - check
Congrats, you are my new financial advisor, call me.
In the paypal use case they could use it to take an internal image and burst it quickly into a cloud provider to scale up their capacity as they see demand spiking beyond what their internal resources can accommodate (not saying they are doing this, just that it's a possible application). For a typical enterprise it's useful to allow on demand lab creation for developers, snapshot the current production machines and generate an isolated sandbox that accurately mirrors the production environment. Automated unit testing is another popular use of API driven provisioning. If you can't find a use for automation in your environment it's either too small to qualify (I'm in this boat, we're fairly big at over 300 VM's at our main site but still too small for much automation) or you're not thinking outside your current box.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Not if you want things to scale easily. I think a good example is SOE. They have a bunch of MMOs and years ago they virtualized their servers. Now it's completely irrelevant how many players are playing any particular game they have. If they have even 1 paying customer a limited amount of resources is dedicated to the server side of that players gameplay. If the population suddenly shoots up to 100,000 it just scales up assets dedicated to that game. It's brilliant really and is why SOE has been able to keep decades old games going for so long. None of their hardware is application specific.
In a non-virtualized environment once the player population fell bellow a few thousand it would not longer be profitable for them to keep the game running and they've have to shut it down... and lose all those customers.
Because many companies have many products and development efforts going on at any given time. Because many companies have weeks- or months-long provisioning cycles for new physical servers.
Because as the summary says, having a platform allowing for rapid (consistent) deployment of infrastructure like development, test, and production servers allows companies faster time to market on their major development efforts.
Because as you may have heard, software-defined infrastructure allows you to leverage automation to a much greater extent than with physical servers, allowing you to literally provision 100 identically configured servers in a couple hours for a server farm with just a couple commands.
Because if you can't see the benefit in allowing that, you aren't qualified to express an opinion about the wisdom of the approach.
Why would I be biased about OpenStack? I have no horse in this race. If VMware is "orders of magnitude" cheaper, good for them, go nuts. My point is just that there's a lot of moving parts in these decisions. What is true for one organization is not true for another. And look, those TCO calculations are messy.
Here's a story I like to tell. A friend of mine is head of server architecture at a very large company. They're a huge IBM shop, and they were deciding where to make their primary server investments over the next three years. They can do linux on the mainframe, AIX on P-series, or Linux on X-series. Which one is going to be the cheapest? Best ROI for their workloads? Best TCO over five years? He's got three IBM server reps, one for each platform. He tells each of them that he wants an in-depth TCO study done for their respective platform, based on their current skillsets, investments, technologies in use, etc. They do interviews, asset inventories, it takes a month and a half. At the end, he gets three reports back, one from each sales rep, each conclusively proving that *their* platform would be the cheapest . The numbers worked out, everything was written out clearly, nothing was made up or fudged. It's just that if you make a couple of slightly different assumptions, or weight things differently, you can come up with a totally different result.
Again, that doesn't mean that CS is wrong, it's just a question of where you want to spend your costs, and that TCO means different things to different people.
One thing I will quibble with - $1b is their capex spend annually, that's capital outlays on hardware and software for their entire IT organization. He said they saved orders of magnitude on their people costs to operate. A fraction of a fraction of their capex spend.
me@mzi.to
Not really, there's a world of difference between the two. It's really a case of bringing portability, redundancy and scalability to a whole raft of applications which didn't have it before, and simplifying it dramatically in the process.
I don't think any OS below the million dollar mark has supported moving running processes and environments between actual independent hardware nodes with little or no interruption, and now you can have that with a free OS and a little configuration.
No longer do you have to wait for your vendor to send over a part in order to stop a critical system running in degraded mode - just allocate that VM to a sdifferent node in your cloud cluster, if it wasn't done automatically for you...
Oh...you mean they didn't RTFA?
Here, you lazy bums:
OpenStack is an IT infrastructure framework made up of several components contributed under an open source license by multiple technology providers.
End the FUD
Thanks, Balmer! I'll keep that in mind next time...
bork bork bork!
I agree. When I read about their 15 minute rule I was like: "Well that's nice, but are deployments really where they are losing time in reacting to competitors?"
Having been involved in production deployments for over 15 years now, I can tell you that deployment time is pretty much a non-issue with speed to market. Things like VMs and storage options and all of that make for easier, and less risky deployments, I agree. However, I have never heard of a piece of software that was ready for prod that was waiting for more than a simple scheduled maintenance window in order for it to go out. Maybe some of the more complex deployments might have required a week at most to practice and get the scripts right. That's it.
Compare that to the weeks and months that marketing, product management, development, QA testers are working on features and it is insignificant.
When I do a deployment, I'm perfectly willing to do 8 hours of prep work to make sure that my customers could get 5 minutes less downtime, and preferably no downtime. Rushing things into production from test is like spending your R&D budget on improving fuel efficiency from 50 to 51 MPG while you spend nothing on getting 12 MPG trucks up to a respectable 18 or something. Where is the real time savings?
If this is Paypal's solution by itself, I predict that they will remain behind the curve going forward as well. Maybe they should figure out how to improve their development process?