3 ms·
Right now most of my focus is in the financial industry. I would say "in the US" but the truth is that my clients are multi-national behemoths. I'm regularly
by Nrsolis 11y ago
Right now most of my focus is in the financial industry. I would say "in the US" but the truth is that my clients are multi-national behemoths. I'm regularly on plane flights to EMEA and APAC.
Believe me when I tell you that they are still running systems that were around in the 70's. They have a significant investment in code that can only properly run in a mainframe environment and isn't going to get thrown away anytime soon.
This is not to say that they don't have any interest in "cloud" technologies...quite the contrary....they are deploying just about ALL of them: ESX, OpenStack, Cloudstack, etc.
But what often emerges as a barrier to deployment is the operational details: things like upgrades to infrastructure, minimization of downtime, security, and integration with the rest of the network and computing infrastructure.
They don't have the luxury of starting from scratch and they certainly can't just forget about how to make things work with their larger infrastructure. Does OpenStack even have a way to upgrade from Juno to Kilo with ZERO downtime? Questions like that are a huge part of the testing and design that go into their thinking.
These guys spend $1B EVERY YEAR on computing.
And here is ANOTHER barrier: they can't readily do business with startups. It just doesn't work for them. The possibility that a critical part of their infrastructure is dependent on the fortunes of a group of maybe 50 people being successful.
And it's not enough to say "well they have the source code" and can support it themselves. That doesn't work for them when the auditors come out and need to identify WHO is responsible for taking care of support and the lifecycle of the code. They write the code for their applications; you can't expect them to code big parts of their OS too.
SO....please take my comments in the spirit they are intended. You can't be successful unless you are able to sell you solutions to the broader market that includes lots of customers that aren't GOOG or AMZN.
Don't forget staffing either. If your infrastructure requires a CS PhD to support/upgrade, you're going to have a hard time selling it out there. Handling of outages tends to be business-specific so NoOPS style models don't work everywhere. It's fine for FB, but not NYSE.
As for storage, EMC is the standard. Transactional databases are in far more places than you'd expect. If your app has scaling issues with accessing a non-virtualized database or datastore, then that's going to be a problem for you. If your OS can't handle redundant datapaths or confuses the Ops people about which piece of physical hardware is causing the issues you're seeing at the virtual layer, then you're going to have even more problems.
So I'm not drinking the Kool-Aid just yet. I love virtual infrastructure but there are still too many open questions that need answers before it's going to be a complete solution for mission critical stuff.
- parasubvert 11y ago"Right now most of my focus is in the financial industry. I would say "in the US" but the truth is that my clients are multi-national behemoths. I'm regularly on plane flights to EMEA and APAC." I'm in a similar situation, though more North America focused. "Believe me when I tell you that they are still running systems that were around in the 70's. They have a significant investment in code that can only properly run in a mainframe environment and isn't going to get thrown away anytime soon." Yep, I agree. Though I've witnessed at least one that actually ditched the mainframe completely... for SAP core banking. It wasn't pretty. "Does OpenStack even have a way to upgrade from Juno to Kilo with ZERO downtime?" I'm not one to defend OpenStack. :) "And here is ANOTHER barrier: they can't readily do business with startups. It just doesn't work for them. " The brokerages in particular have a long history of working with startups at certainly layers of the stack. Retail banks, I tend to agree with you, but it really depends. Startups of a certain size and maturity (100 people+, a few years old) in many cases tend towards even better support than larger companies because they actually CARE about the outcome, and aren't bogged by the bureaucracy of fighting divisions. (How many times does the pre-sales team have to fly in to fix the screw-ups of the consulting group, or vice versa? etc.) Every stodgy bank on the planet wants to work with Docker (150 employees now btw), for example, once they have a product to sell. "And it's not enough to say "well they have the source code" and can support it themselves. That doesn't work for them when the auditors come out and need to identify WHO is responsible for taking care of support and the lifecycle of the code. They write the code for their applications; you can't expect them to code big parts of their OS too." I'm not sure anyone is realistically expecting that. Pivotal (not exactly a startup at 1500+ employees, but sometimes feels like one) for example supports the OS inside Cloud Foundry for the customer, providing patches, upgrades, minimal downtime rolling updates, etc. It's all open source but has 24x7 enterprise support. "Handling of outages tends to be business-specific so NoOPS style models don't work everywhere. It's fine for FB, but not NYSE." I'm not sure I agree here. Having an operating platform handle self-healing and auto-recovery is sort of standard with VMware DRS/HA (admittedly not everyone runs with it turned on). All these cloud platforms are doing is the similar stuff for load balanced application containers and the VMs they run on. I think this really is marking a major shift away from bespoke CMDB-driven "how do we recover the service? get 20 people on a concall" towards systems that reorganize themselves. Yes, there is a legacy that's not going to get this, and needs its small armies... but we've seen shifts away from that before when Java and .NET hit the market. "Transactional databases are in far more places than you'd expect." I'd expect them to be everywhere and anywhere. "I love virtual infrastructure but there are still too many open questions that need answers before it's going to be a complete solution for mission critical stuff" There's a difference between virtual infra and cloud. Virtual infra already handles mission critical stuff in most of the world. Yes, plenty of bare metal and big iron too, but that's actively shrinking. Cloud runs lots of mission critical stuff too, but not with companies born prior to 1990... though that's changing. I agree there is a risk calculation to be made here, but I don't believe it is going to take more than a few years. We are talking orders of magnitude in economic difference for time/cost in many cases. Speed with safety is addictive. Most believe the speed of cloud - the safety part we're verifying now as an industry, and it's happening everywhere.