Does Cisco do anything innovative any more? Seems like a dinosaur that is trying to survive. Buying a bunch of acquisitions due to not being to innovate internally isn't a positive sign. Seems like they miss many market transitions. Probably explains their large yearly layoffs.
Cisco's networking hardware is still top of the line (albeit expensive). But yes you're right, other than their networking hardware they don't do all that much.
I remember them having some impressive demos of Telepresence and something called Cisco Spark (which probably is an acquesisiton like you said). You join a meeting on your phone, just like Lync(Skype) but if you walk into a meetingroom with video conference equipment it transfers to that.
You're probably right. I was mostly referring to the integration with the Teleprecence technology that you get if you have their super expensive video conference setup.
I don't like the idea that the whole Internet is running on the servers of a single company. Can't we do something to increase the competition in the "cloud" area?
Amazon, Google, Microsoft at the top tier. Three is not too bad.
The business is super capital-intensive: you need a lot of cash to pay the developers, and a lot of cash to build out infrastructure reaching both the economy of scale and geo distribution. Apple could you probably join in, if they put their minds to it.
The internet was designed to be a fault-tolerant network that can automatically cope with outages by rerouting traffic around them. That's all. There's nothing to say who should own or operate the system implied in the design.
It still drives me crazy that ISP's tell you not to run a server - the whole damn point of the internet is that it's two way. Opening port 80 and hosting a website on a raspberry pi that my buddy around the world could see may not be how the next unicorn operates, but it just feels good in principle.
I am from Brazil, here ISPs do that because they aren't Cloudflare.
For example many ISPs explicit write in their contracts that hosting ANY kind of IRC-related content, be it a server itself, or tools, clients, or articles about IRC, will get you banned from the ISP.
I believe ISPs do that because IRC in Brazil is script-kiddie magnet, as soon some new IRC-related stuff is up, thousands (I am not kidding) of lamers will DDoS you, and some will try more serious hacks.
Similarly in Brazil, hosting games is also frowned upon, usually game hosting companies are owned by major ISPs in first place, that rent their servers to people that want to create a game server, yet, hosting games is necessary too, Brazillians are so good at being assholes that they are frequently automatically banned from other countries (example: Combat Arms, irc server AfterNET, and a couple others have Brazil, or most of Brazillian IPs in their ban table.)
Brazil also had the dubious distinction some years ago (I don't know if it still applies) as the leading country in producing "website defacers", so even your port 80 isn't safe.
So at least here, sadly I can't complain of centralization, here it is very possible that if you put a website on your raspberri PI, it will take down the entire city internet down.
The whole internet is not running in the cloud, even if lots of noise is made by cloud/serverless proponents, it's not the only way to host a website, or even the best in many cases.
Many popular sites (like this one) still use their own servers.
It's not. If any of the big three entirely disappeared there wouldn't be a tear shed. It'd be an inconvenience at most and people would suddenly be reminded about portability and lock in.
At a microscopic level it's pretty stupid, dangerous and short sighted building your product to conform to any of these providers' services past the PaaS level. I see people with whole business on AWS who are a billing dispute away from weeks of downtime.
I presume every business who doesn't run all their services on their own servers inside their own building is also just a billing dispute away from downtime. And even then if you don't pay your bandwidth bill you'll still go dark.
Exactly. Also it reduces portability risk. Consider if you implement SQS and SES using their native APIs then Amazon shaft you, where do you go? The answer is rewriting everything as AMQP and basic SMTP services, which until you're done, you're down.
Oh boy. I take it you've never actually moved datacenters before? Last time I did it in 2007 it took weeks of planning, and the time before that in 1999 it was months of planning.
You don't just get up and move. You still have a ton of data to worry about.
> Oh boy. I take it you've never actually moved datacenters before? Last time I did it in 2007 it took weeks of planning, and the time before that in 1999 it was months of planning.
That's nothing compared to a business that chooses to use a specific component that cannot be migrated from one host to another. If your architecture is truly distributed then migration is painless, because your system is designed around it.
Yeah try being distributed with your own D.Cs . Having two asynchronous replicated DR site is not a truly distributed architecture... it's something from 1998
Yeah try being distributed with your own D.Cs . Having two asynchronous replicated DR site is not a truly distributed architecture... it's something from 1998
> If disaster struck, are you saying it would take you weeks to get your site up and running again?
No, because I'm smart enough not to use bare metal. :)
But if I were running a full bare metal datacenter, then yes, it would. Because I would either need to procure a whole bunch more bare metal or I'd have to move what I've got somewhere else.
When was the last time that hte entire data centre went out? One, two servers, maybe a whole rack, but an entire dc out for good, more like a few hours downitme
Read the OP I was responding to. Their initial comment was about having to bail out of your provider, and their claim was that bailing out of your provider is easier when you're on bare metal, so I countered that that isn't true at all.
I take it you've never actually moved datacenters before?
Please don't do this. It may be that their system was simply easier to move. We've moved from DO to a local DC earlier this year and it really wasn't a problem, because (1) we didn't have that much data, and (2) we can take a couple of hours of scheduled downtime.
And frankly, I suspect that our situation is closer to the norm than yours. How many companies outside the Fortune 500 really have humongous quantities of data?
Well, now you've lost me, because according to [1] the data was under 2TB (uncompressed) even as of 2015, so why did it take many days to move? I feel like there's something I'm missing.
You can't just cp live data. You have to migrate it with indexes and rebuild on the fly.
If you're willing to take a downtime, sure you can do it in a few days. But you still need servers to move it to. Where do those new servers come from? Are you going to buy a whole new set of servers? How long does that take?
My point is that moving one datacenter to another isn't easy and there is a lot of things to think about.
My point was that being in the cloud or not is barely relevant.
Also that dataset isn't close to complete. It was a lot more data than that.
Why is it stupid, dangerous and short sighted? People say those things about cloud vendor locking like it's a obvious truth. I really annoyed by this arrogance among my systems minded peer group.
I get where this comes from, but it's too simplistic. Even if your build close around the AWS primitives, why is it harder to migrate away from this when necessary than building the alternative yourself from before you can proof your business or build any MVP.
I'd say use whatever service you helps to get your product out there fast and allows you to iterate quickly. This will also free time to consider your long term options.
The primitives and constraints imposed by a cloud provider often make your life easier even if you migrate to bare metal or another cloud.
I'd even go so far to argue the other way around: You get away with way shittier, less future proof design when running on bare metal and have a ops team taking care of your pets. Not being able to move that to a cloud, private or public, would concern me most.
> Why is it stupid, dangerous and short sighted? People say those things about cloud vendor locking like it's a obvious truth
It depends on the relationship you have with these cloud vendors. If it is a custom contract , with penalties if the host screws up , then by all means, lock yourself in as much as you like. But most clients aren't in any position to negotiate with Amazon. Worse, a well known vendors doesn't hesitate to shut down paid accounts without notice. Imagine your business depends on a specific component of that vendor's stack ... you are screwed.
> The primitives and constraints imposed by a cloud provider often make your life easier even if you migrate to bare metal or another cloud.
Provided you can "migrate" to something else at first place. Look at all these sorry folks building their "serverless architecture" on Amazon. They depend entirely on Amazon services and SDK. There is no migration path to something else.
I've build a couple of startups and sold out, worked for a couple of well known ones as early employees and now reside in an architecture position. This magical free time never appears, particularly when your business is suddenly return focused after your capital comes in. The low capital cost of the services your are integrating typically is used as a justification to utilise them more.
Then a client comes along dangling a few million quid/dollars etc who wants it somewhere else for regulatory compliance or wants to self host it and you have to turn them away.
It's not about making your life easier in the short term, it's about building a solid business foundation and continuation plan and a good DR strategy. A lot of people don't consider this and crash and burn and it's not pretty.
Edit: your approach is known among my circles as the "Ferengi badass" approach.
> This magical free time never appears, particularly when your business is suddenly return focused after your capital comes in. The low capital cost of the services your are integrating typically is used as a justification to utilise them more.
Never talked about magical free time, I'm talking of not having to dedicate an ops team to maintain your bare metal infrastructure.
> Then a client comes along dangling a few million quid/dollars etc who wants it somewhere else for regulatory compliance or wants to self host it and you have to turn them away.
How do you imaging this being easier with a bare metal infrastructure than one on AWS?
It really depends on the specifics: If you're using managed services and the customer wants a on-site solution, you need to find replacement for those. If your customer needs something geographically close, deploying to another region is trivial compared to building our a DC suite.
> It's not about making your life easier in the short term, it's about building a solid business foundation and continuation plan and a good DR strategy. A lot of people don't consider this and crash and burn and it's not pretty.
Indeed, and depending on the specifics it might be much more reasonable to run in the cloud.
>I'm talking of not having to dedicate an ops team to maintain your bare metal infrastructure.
You can still build an architecture that works on any of the large feature rich cloud providers with minimal retooling, and that can be deployed on bare metal if needed (minus automatic scaling, load balancing etc.)
In the end the trick is to build infrastructure agnostic apps that work on AWS as well as on IBMs cloud
Speaking as one of roughly fifty founders thereof, and also the founder of a (now acquired) startup in the space, it really isn't. The point the OP made about needing an Ops team is magnified by the introduction of OpenStack, and the existence of Rackspace as a (not-quite) provider of OpenStack won't help because their public cloud is going away and there isn't really a replacement as the field consolidated and the consolidated players have shed their OpenStack investments (or are laying off and trying to get away from it).
If your goal is to avoid the lock-in to a particular IaaS vendor while avoiding ops overhead, your better bet is to go up-stack and lock yourself into either Cloud Foundry or OpenShift. At least then you'll be able to migrate from IaaS to IaaS semi-transparently, but you are locking into a platform.
> Never talked about magical free time, I'm talking of not having to dedicate an ops team to maintain your bare metal infrastructure.
At the prices AWS charges this was never a requirement even before virtualization became a thing, much less API-driven cloud environments until you reached such a scale it simply didn't matter. I owned a fully managed dedicated server provider in the late 90's/00's where the customers never even logged into their machines - we handled all that for them and provided what essentially were an early primitive form of infrastructure APIs - FTP, HTTP, SMTP, etc. Certainly complexity has increased, but there are many models between consuming MySQL as a vendor lock-in service, vs. running MySQL on bare metal machines you hand built and racked in your own datacenter.
There are far more options than to use the AWS/GCE/etc. "SaaS" offerings that are company specific. I completely agree standing up infrastructure via code is almost a requirement for many businesses these days - I would (and I'm very biased here - I work for a small infrastructure provider) much prefer to see a slightly larger premium being put on solutions that don't promote lock-in. I'm also old and cranky, so seeing things like "resizing jpegs as a service" still makes me think the industry has lost it's collective sanity :)
I think my concern is not that you require a set of functional APIs to stand up basic infrastructure - this is certainly very reasonable. For me it's more the direction of the "outspoken self-described leaders" in the industry seems to be towards consuming more application-specific infrastructure services that come with them huge lock-in costs, as well as long-term opex once you hit any form of scale.
I'm working on a quote now that is taking a $200k/mo AWS bill down to a $18k/mo co-location bill, where we handle absolutely all networking, hardware, or other "bare metal" related issues for them - they just have us stand up a k8 cluster for them, and we handle the underlying things like monitoring for hardware failure. While certainly not perfect nor as seamless or easy as AWS they largely get similar means to consume their infrastructure, and pay a tenth of the cost. All without hiring any ops folks to deal with servers. However they get to spend 6 months unwinding all the amazon-specific code they now currently rely on, so it's not an easy sell as that cost (both in real dollars as well as opportunity cost) is far more than the savings they will see on this deal through it's lifetime.
They are making this move as they see their current lock-in as a long-term strategic risk for the company. Especially as they look at the constant march of increases to opex as AWS bills increase.
Ferengi badass approach is hilarious! (I really enjoyed it)
I also try to urge people when considering a cloud or product vendor that they could expand into your businesses sector and investors or the board could make a decision to avoid that vendor, you will then have to migrate not for technical architecture reasons, but for reasons well out of your control. For example lets say I made a job search application, built on Azure, when Microsoft bought Linkedin the CEO/board of my imaginary company might set out a directive to migrate off of Azure.
There are also legal reasons why someone might have to migrate off of a vendor's product, if the two companies get locked in to a lawsuit.
When designing these systems I think it is important and not always popular to consider different vendors or a self hosted solution with different hardware vendors. Perhaps more important advocate for an Open Source solution in order to help facilitate a potential migrations or other situations.
"Why is it stupid, dangerous and short sighted? People say those things about cloud vendor locking like it's a obvious truth. I really annoyed by this arrogance among my systems minded peer group."
It's not arrogance. It's decades of experience in this industry, and simple business reality. If you let yourself get "locked in the trunk", you've made yourself vulnerable to whoever owns the trunk. If an entire industry gets locked in the same trunk, the only sensible decision for the owner of that trunk is to raise the rent. What are the people in it going to do?
Most recently the industry was here with Microsoft Windows. Our whole industry was so beholden to Microsoft that we basically danced to their tune. Computer manufacturers didn't sell "computers", they sold "Windows machines". Microsoft could move in and take over entire sub-industries with impunity, like the spreadsheet industry and office suites in general, networking software industry, the browser industry, pretty much anything that was software and they decided they wanted.
Yes, there are entities that are too small to be worried about this. If you're a five-person startup, you've got bigger problems than whether or not your cloud vendor is going to become a monopoly in five years and jack the prices through the roof for your services. But larger entities need to be more careful.
There's other cases too; you can end up over-exposed to Oracle databases, for instance. Some small-medium companies end up designing custom hardware for some purpose and end up overexposed to the only people willing to make that hardware at a price you can profit from it. It's not a good idea to be stuck to one entity like that, and even if you judge the benefits to outweigh the costs, that doesn't mean the costs don't exist and you can just forget about them. It's something you need to constantly reevaluate.
I agree that those are all valid problem. My point is more that it's not such hard lock as people assume who never built a "cloud native" infrastructure. I wish we would discuss more specifics.
So what are we talking about? Snapchat running on app engine is probably one of the more extrem examples. Let say they aren't happy with that anymore. So far they deployed easily by using the google apps api and since want to keep a similar workflow. They could setup kubernetes for that. Same for managed data stores. Maybe there is no 1:1 open source equivalent, but most likely there is one similar in design which won't require much change in your code.
Of course all this takes time and live migrating your site isn't trivial.
But so does building on bare metal from the start. Sure, you don't all the fancy self-service features right away, but you want them eventually.
So even if you realize that moving to the cloud, or a specific cloud was a huge mistake, it's not like being locked in a trunk.
I know its cool to blame every Microsoft success on the windows monopoly, but Excel won on its merits. Compare Excel 3 with Lotus 1-2-3 of the same era. One had a GUI the other was stuck in 80x40 character land.
Excel 4 is about when the product really started to resemble its modern form. But even V1 on the Macintosh was a significant improvement over character based spreadsheets.
Simply blaming it on Windows ignores the very real innovations made by early Excel versions. Lotus lost simply because they were late to the GUI, and even then only did it half-heatedly.
OK, but small and medium businesses with server racks in the closet are also one billing dispute with Comcast Business (or power outage lasting longer than their 5 minutes of battery UPS) away from downtime.
Some of them are even swapping tapes daily blissfully unaware that the backup software failed 9 months ago and is just dumping an error in the event log, the UPS batteries are bulging about to burst, a squirrel has been working on nibbling the glass out of their fiber connection between two buildings and there is water dribbling into the main switch rack that caused a fire that is going to engulf the entire building.
I've seen all these and it scares the shit out of me and should do with everyone.
Hence why people must build a DR strategy, run scenarios, regularly test it. We're categorically just talking about one of the risk vectors here which is a pretty soft one but as destructive to a business as a large fire.
To be fair, smaller providers are incredibly numerous in virtually every country. For obvious money reasons, they can't compete on price and available spec against the big three, but support tends to be the money maker for smaller companies, as knowledgable and accessible support technicians is a pretty valuable selling point for these companies. The business I work for provides software/service for thousands of these providers, and I see them all over the place in Europe, Russia, China, and so on. Have not seen it as much in the US, but my support focus is mainly Europe, so it might just be I don't get to see it.
Indeed. In smaller countries there are numerous providers from shared to dedicated hosting and people are using them. The whole Amazon lock in is a thing of Silicon Valley and the largest companies.
Well, there are projects like this - https://sandstorm.io/ - which make it easier to host things on your own hardware (or on cloud providers, but still...)
> Can't we do something to increase the competition in the "cloud" area
Yes, we have to change our mindset back from "Let's put everything (apps and data) into the cloud" to "Let's only use the cloud as _one_ of many ways for data storage and data synching. Everything else is done locally and on private servers".
This whole trend of web-apps is really bad for free software because it creates a dependency on 3rd party servers. Just imagine you could only use Emacs or Vim if you are connected to the internet...
We have to get rid of the idea that the default form of software is supposed to be a webpage. Make software local again and therefore reduce the influence of large cloud providers.
But why? It's convenient for the end user and connectivity is only going to get better. Pining for the days of desktop apps for everything isnt going to get you very far.
A huge part of it is you can hire an HTML 5 developer to give you something with all the eye candy users have come to expect for much cheaper, and much less effort, than the native equivalent. Now we even have Electron so you can package your own version of Chrome and reuse your web devs.
It's practically a self feeding cycle at this point, people aren't going to coding bootcamps for WPF/C#, they're going for HTML/CSS/Js, because people hire for that with much less fanfare.
And people hire for that with less fanfare because HTML/CSS/Js is so ubiquitous.
And with the shift to HTML/Js everywhere "who needs WPF but stuffy business types?"
*Replace WPF and C# with GTK,Qt,C++,C, etc. as needed.
You can certainly deliver local software that uses a browser for display and has all the "eye candy" you want. It doesn't require a network connection at all.
What does that have to do with anything upthread? This non-sequitur is shifting the goal post: your initial challenge sounded like it's something that cannot or should not be done - yet it was.
No, it is a big difference making a prototype to write a paper about it, and making something that is actually viable to be used in production while following industry standards and device integration procedures.
If you tell people about MSHTML they'll be repulsed, but explain how Electron is the same concept and they'll say it's not because Electron is "cross-platform".
I hope one day the industry will accept that cross-platform doesn't have to be a choice between abstracting away the whole platform and abstracting away nothing between platforms.
Native almost always improves UX, I don't get why there was initially such a push to bring the web everywhere in the name of cross-platform, but it seems this time the push has seemingly taken a life of its own
It's too long to really go into, but my personal "old guy" take is that this is yet more of the same cycles computing has always seen.
By cycles I mean the constant cycle between centralizing compute power and decentralizing as the economics and benefits shift between those two paradigms.
What is being done now on the "cloud" (yes, I hate the term) is simply what was being done with mainframe computing systems 35 years ago, only we have better connectivity and graphics to support the consumer version of it.
I expect to see a shift back towards individual "on-prem" devices at some point, but that will probably be another 10-20 years and will take a black swan (or multiple baby black swans) event no one here can predict to happen - just like no one in the mainframe days predicted the consumer Internet.
I absolutely agree giving control of the Internet to perhaps 10 total companies that have 90%+ of the content delivery traffic is a horrible idea with only one assured outcome.
I'd say that pulling out the xkcd when someone's "question" ends in "Pining for the days of desktop apps for everything isnt going to get you very far." is a bit strange.
> We have to get rid of the idea that the default form of software is supposed to be a webpage.
You need to know why that becomes the norm rather than the exception. Ease of management, installation, upgrade, ... is really what drove those changes back to centralised server.
Solve those issues and people will go back to develop local application again. Actually, those issues are solved on mobile and every app store is testament to that.
As a side note, it is interesting to note that Cloud providers could be seen as the ultimate free software end game. Remember the "make your money on support, distribute software for free" ? Well that's what cloud provider are doing: they are just selling you convenience and support in a box on top of what is overwhelmingly free software.
For Amazon, the marginal cost of a server is very small. For some startup, bringing up and maintaining a data center is astronomically expensive. By going with a cloud provider instead of hiring their own staff and buying their own hardware they save lots of money. If you don't need control over the hardware and networking and such then you can save money on the responsibility for it.
Google Cloud and Azure are pretty huge, which many people don't seem to realize. There is no way Amazon can relax, not with the enterprise experience of Microsoft and the tech experience of Google breathing on their necks.
I'd bet AMZN will hit a trillion $ market cap. You could buy it now and make roughly 3 times your investment in 10yrs or less. They (Bezos & team) are so so impressive.
The biggest contender is Kubernetes right now because Google is behind it. Anyone who adopts it is in a better position to move off of Amazon. Google has a better infrastructure and pricing but lags behind in terms of capabilities so that's their strategy.
The worst thing you could do is use Amazon Lambda. Pretty soon the platform will become the application. It ties all the Amazon product in a big ball of vendor lock-in.
I have a few old colleagues that are(were?) working on IaaS powered by OpenStack stuff at Cisco. I can only assume they were working on this. I hope they get to move onto other projects :-(
What's the talent pool like in Germany? I looked at moving to Germany for a while and it seemed pretty strong. I'm in Ireland now but the companies I've worked for have all had German representation in engineering.
how did you know it's lousy exec play that caused the problem?
Amazon is heavy with their advertising and this have a huge mindshare with potential customers and even non-customers alike. No amount of extraordinary exec play would have changed that in favor of Cisco.
Cisco was dedicating $1 Billion to the project, AWS made $2.5 billion in Q1 2016. Think of that for a second
> Amazon is heavy with their advertising and this have a huge mindshare with potential customers and even non-customers alike. No amount of extraordinary exec play would have changed that in favor of Cisco.
Actually - Amazon is now an established brand name even in the corporate/enterprise execs' minds, but Cisco used to be way more famous and trusted than Amazon until recently. They've never been the cheapest or first to market, but their stuff works well enough and their support is good, esp. if you have the patience to first go through the mostly useless level 1 and 2.
There's a famous quote, usually* attributed to Thomas J. Watson: "I think there is a world market for maybe five computers". This is usually trotted out as an example of expert predictions proving spectularly false. But in a roundabout way the consolidation in the cloud sector is proving a truth at the heart of it.
* wikipedia says there's no actual evidence that Watson himself said this.
We started by connecting multiple terminals to one computer.
Then we moved on to the PC where 1 terminal was connected to one computer.
Now we are in the age where 1 terminal is connected to many computers.
saying "amazon claims another victim" is misleading, it's like saying the race leader in a Formula one race is responsible for one of it's rivals not finishing the race.
Cisco were not operating a public cloud, so there is no hardware to get rid of. Intercloud was a way for a network of smaller "Cisco Powered" cloud providers to interoperate and allow workload mobility to/from on-prem Cisco / OpenStack deployments.
How many other folks here had never even heard of Intercloud?
I think that if I had heard of it, I'd have initially placed it as a middle-of-the-road choice. Cisco's no Amazon or Google, but it's also not a Microsoft[1], IBM or HP. It's certainly not an Oracle.
[1] I'd only initially place Azure as bottom-of-the-stack; I've heard enough good things about it that in an actual greenfield cloud project I'd consider it a contender.
There are still investments in the Openstack space and I work on one of them(Managed openstack deployments). Intercloud was previously EOL'd 4 months ago, this is just the formal announcement.
132 comments
[ 3.3 ms ] story [ 38.5 ms ] threadIt's really not though. The majority of their platforms are terribly under powered, and have very high costs per port.
Their only compelling platform at the moment, the NCS, uses a chipset made by a third party.
The ODMs that actually make most of the networking gear are Quanta, Accton, Celstica, Alpha Networks, and Delta Networks.
If you want to buy "white box" switches from those ODMs, you can do so through outfits like Edge-core, QCT, and others.
The business is super capital-intensive: you need a lot of cash to pay the developers, and a lot of cash to build out infrastructure reaching both the economy of scale and geo distribution. Apple could you probably join in, if they put their minds to it.
The internet was ment to be a fully decentralized system. If you think that only three players are not so bad, then I'd ask you to reconsider.
For example many ISPs explicit write in their contracts that hosting ANY kind of IRC-related content, be it a server itself, or tools, clients, or articles about IRC, will get you banned from the ISP.
I believe ISPs do that because IRC in Brazil is script-kiddie magnet, as soon some new IRC-related stuff is up, thousands (I am not kidding) of lamers will DDoS you, and some will try more serious hacks.
Similarly in Brazil, hosting games is also frowned upon, usually game hosting companies are owned by major ISPs in first place, that rent their servers to people that want to create a game server, yet, hosting games is necessary too, Brazillians are so good at being assholes that they are frequently automatically banned from other countries (example: Combat Arms, irc server AfterNET, and a couple others have Brazil, or most of Brazillian IPs in their ban table.)
Brazil also had the dubious distinction some years ago (I don't know if it still applies) as the leading country in producing "website defacers", so even your port 80 isn't safe.
So at least here, sadly I can't complain of centralization, here it is very possible that if you put a website on your raspberri PI, it will take down the entire city internet down.
Many popular sites (like this one) still use their own servers.
At a microscopic level it's pretty stupid, dangerous and short sighted building your product to conform to any of these providers' services past the PaaS level. I see people with whole business on AWS who are a billing dispute away from weeks of downtime.
You don't just get up and move. You still have a ton of data to worry about.
There are some rare stuff where active/active almost come out of the box.
That's nothing compared to a business that chooses to use a specific component that cannot be migrated from one host to another. If your architecture is truly distributed then migration is painless, because your system is designed around it.
If disaster struck, are you saying it would take you weeks to get your site up and running again?
These days we actually can spin the whole lot up in hours if not minutes.
No, because I'm smart enough not to use bare metal. :)
But if I were running a full bare metal datacenter, then yes, it would. Because I would either need to procure a whole bunch more bare metal or I'd have to move what I've got somewhere else.
Please don't do this. It may be that their system was simply easier to move. We've moved from DO to a local DC earlier this year and it really wasn't a problem, because (1) we didn't have that much data, and (2) we can take a couple of hours of scheduled downtime.
And frankly, I suspect that our situation is closer to the norm than yours. How many companies outside the Fortune 500 really have humongous quantities of data?
Well, just doing the reddit data in 2009 took many days to move, and that was with a planned migration.
And that was just text. Nowadays with tons of monitoring and telemetry data and historical data, most companies probably have more than that.
Remember, the premise was that bare metal is better than the cloud because it's easier to move, and my counter was that, no, that's not at all true.
[1] https://www.reddit.com/r/datasets/comments/3bxlg7/i_have_eve...
If you're willing to take a downtime, sure you can do it in a few days. But you still need servers to move it to. Where do those new servers come from? Are you going to buy a whole new set of servers? How long does that take?
My point is that moving one datacenter to another isn't easy and there is a lot of things to think about.
My point was that being in the cloud or not is barely relevant.
Also that dataset isn't close to complete. It was a lot more data than that.
You keep saying this, why does it take a few days to move terabytes?
You're not explaining it at all.
Not only that, with reddit most of that data is historic and unchanging so you can pre-move it.
I get where this comes from, but it's too simplistic. Even if your build close around the AWS primitives, why is it harder to migrate away from this when necessary than building the alternative yourself from before you can proof your business or build any MVP.
I'd say use whatever service you helps to get your product out there fast and allows you to iterate quickly. This will also free time to consider your long term options.
The primitives and constraints imposed by a cloud provider often make your life easier even if you migrate to bare metal or another cloud.
I'd even go so far to argue the other way around: You get away with way shittier, less future proof design when running on bare metal and have a ops team taking care of your pets. Not being able to move that to a cloud, private or public, would concern me most.
It depends on the relationship you have with these cloud vendors. If it is a custom contract , with penalties if the host screws up , then by all means, lock yourself in as much as you like. But most clients aren't in any position to negotiate with Amazon. Worse, a well known vendors doesn't hesitate to shut down paid accounts without notice. Imagine your business depends on a specific component of that vendor's stack ... you are screwed.
> The primitives and constraints imposed by a cloud provider often make your life easier even if you migrate to bare metal or another cloud.
Provided you can "migrate" to something else at first place. Look at all these sorry folks building their "serverless architecture" on Amazon. They depend entirely on Amazon services and SDK. There is no migration path to something else.
Then a client comes along dangling a few million quid/dollars etc who wants it somewhere else for regulatory compliance or wants to self host it and you have to turn them away.
It's not about making your life easier in the short term, it's about building a solid business foundation and continuation plan and a good DR strategy. A lot of people don't consider this and crash and burn and it's not pretty.
Edit: your approach is known among my circles as the "Ferengi badass" approach.
Never talked about magical free time, I'm talking of not having to dedicate an ops team to maintain your bare metal infrastructure.
> Then a client comes along dangling a few million quid/dollars etc who wants it somewhere else for regulatory compliance or wants to self host it and you have to turn them away.
How do you imaging this being easier with a bare metal infrastructure than one on AWS? It really depends on the specifics: If you're using managed services and the customer wants a on-site solution, you need to find replacement for those. If your customer needs something geographically close, deploying to another region is trivial compared to building our a DC suite.
> It's not about making your life easier in the short term, it's about building a solid business foundation and continuation plan and a good DR strategy. A lot of people don't consider this and crash and burn and it's not pretty.
Indeed, and depending on the specifics it might be much more reasonable to run in the cloud.
You can still build an architecture that works on any of the large feature rich cloud providers with minimal retooling, and that can be deployed on bare metal if needed (minus automatic scaling, load balancing etc.)
In the end the trick is to build infrastructure agnostic apps that work on AWS as well as on IBMs cloud
If your goal is to avoid the lock-in to a particular IaaS vendor while avoiding ops overhead, your better bet is to go up-stack and lock yourself into either Cloud Foundry or OpenShift. At least then you'll be able to migrate from IaaS to IaaS semi-transparently, but you are locking into a platform.
At the prices AWS charges this was never a requirement even before virtualization became a thing, much less API-driven cloud environments until you reached such a scale it simply didn't matter. I owned a fully managed dedicated server provider in the late 90's/00's where the customers never even logged into their machines - we handled all that for them and provided what essentially were an early primitive form of infrastructure APIs - FTP, HTTP, SMTP, etc. Certainly complexity has increased, but there are many models between consuming MySQL as a vendor lock-in service, vs. running MySQL on bare metal machines you hand built and racked in your own datacenter.
There are far more options than to use the AWS/GCE/etc. "SaaS" offerings that are company specific. I completely agree standing up infrastructure via code is almost a requirement for many businesses these days - I would (and I'm very biased here - I work for a small infrastructure provider) much prefer to see a slightly larger premium being put on solutions that don't promote lock-in. I'm also old and cranky, so seeing things like "resizing jpegs as a service" still makes me think the industry has lost it's collective sanity :)
I think my concern is not that you require a set of functional APIs to stand up basic infrastructure - this is certainly very reasonable. For me it's more the direction of the "outspoken self-described leaders" in the industry seems to be towards consuming more application-specific infrastructure services that come with them huge lock-in costs, as well as long-term opex once you hit any form of scale.
I'm working on a quote now that is taking a $200k/mo AWS bill down to a $18k/mo co-location bill, where we handle absolutely all networking, hardware, or other "bare metal" related issues for them - they just have us stand up a k8 cluster for them, and we handle the underlying things like monitoring for hardware failure. While certainly not perfect nor as seamless or easy as AWS they largely get similar means to consume their infrastructure, and pay a tenth of the cost. All without hiring any ops folks to deal with servers. However they get to spend 6 months unwinding all the amazon-specific code they now currently rely on, so it's not an easy sell as that cost (both in real dollars as well as opportunity cost) is far more than the savings they will see on this deal through it's lifetime.
They are making this move as they see their current lock-in as a long-term strategic risk for the company. Especially as they look at the constant march of increases to opex as AWS bills increase.
These are of course my own opinions only :)
They should start by cleaning their AWS clusterfuck. $200k is a huge amount of money.
And if they just want a k8s cluster, they should investigate GKE as well.
I also try to urge people when considering a cloud or product vendor that they could expand into your businesses sector and investors or the board could make a decision to avoid that vendor, you will then have to migrate not for technical architecture reasons, but for reasons well out of your control. For example lets say I made a job search application, built on Azure, when Microsoft bought Linkedin the CEO/board of my imaginary company might set out a directive to migrate off of Azure.
There are also legal reasons why someone might have to migrate off of a vendor's product, if the two companies get locked in to a lawsuit.
When designing these systems I think it is important and not always popular to consider different vendors or a self hosted solution with different hardware vendors. Perhaps more important advocate for an Open Source solution in order to help facilitate a potential migrations or other situations.
Care to explain what that is?
Even Google doesn't know.
It's not arrogance. It's decades of experience in this industry, and simple business reality. If you let yourself get "locked in the trunk", you've made yourself vulnerable to whoever owns the trunk. If an entire industry gets locked in the same trunk, the only sensible decision for the owner of that trunk is to raise the rent. What are the people in it going to do?
Most recently the industry was here with Microsoft Windows. Our whole industry was so beholden to Microsoft that we basically danced to their tune. Computer manufacturers didn't sell "computers", they sold "Windows machines". Microsoft could move in and take over entire sub-industries with impunity, like the spreadsheet industry and office suites in general, networking software industry, the browser industry, pretty much anything that was software and they decided they wanted.
Yes, there are entities that are too small to be worried about this. If you're a five-person startup, you've got bigger problems than whether or not your cloud vendor is going to become a monopoly in five years and jack the prices through the roof for your services. But larger entities need to be more careful.
There's other cases too; you can end up over-exposed to Oracle databases, for instance. Some small-medium companies end up designing custom hardware for some purpose and end up overexposed to the only people willing to make that hardware at a price you can profit from it. It's not a good idea to be stuck to one entity like that, and even if you judge the benefits to outweigh the costs, that doesn't mean the costs don't exist and you can just forget about them. It's something you need to constantly reevaluate.
So what are we talking about? Snapchat running on app engine is probably one of the more extrem examples. Let say they aren't happy with that anymore. So far they deployed easily by using the google apps api and since want to keep a similar workflow. They could setup kubernetes for that. Same for managed data stores. Maybe there is no 1:1 open source equivalent, but most likely there is one similar in design which won't require much change in your code.
Of course all this takes time and live migrating your site isn't trivial. But so does building on bare metal from the start. Sure, you don't all the fancy self-service features right away, but you want them eventually.
So even if you realize that moving to the cloud, or a specific cloud was a huge mistake, it's not like being locked in a trunk.
Excel 4 is about when the product really started to resemble its modern form. But even V1 on the Macintosh was a significant improvement over character based spreadsheets.
Simply blaming it on Windows ignores the very real innovations made by early Excel versions. Lotus lost simply because they were late to the GUI, and even then only did it half-heatedly.
Source: I work for a startup who does not pay their bills.
Some of them are even swapping tapes daily blissfully unaware that the backup software failed 9 months ago and is just dumping an error in the event log, the UPS batteries are bulging about to burst, a squirrel has been working on nibbling the glass out of their fiber connection between two buildings and there is water dribbling into the main switch rack that caused a fire that is going to engulf the entire building.
I've seen all these and it scares the shit out of me and should do with everyone.
Hence why people must build a DR strategy, run scenarios, regularly test it. We're categorically just talking about one of the risk vectors here which is a pretty soft one but as destructive to a business as a large fire.
Yes. They're getting silly amounts of finance each year. Plus, the CTO/founder is opposed to Internet surveillance.
Yes, we have to change our mindset back from "Let's put everything (apps and data) into the cloud" to "Let's only use the cloud as _one_ of many ways for data storage and data synching. Everything else is done locally and on private servers".
This whole trend of web-apps is really bad for free software because it creates a dependency on 3rd party servers. Just imagine you could only use Emacs or Vim if you are connected to the internet...
We have to get rid of the idea that the default form of software is supposed to be a webpage. Make software local again and therefore reduce the influence of large cloud providers.
It's practically a self feeding cycle at this point, people aren't going to coding bootcamps for WPF/C#, they're going for HTML/CSS/Js, because people hire for that with much less fanfare.
And people hire for that with less fanfare because HTML/CSS/Js is so ubiquitous.
And with the shift to HTML/Js everywhere "who needs WPF but stuffy business types?"
*Replace WPF and C# with GTK,Qt,C++,C, etc. as needed.
1. https://www.researchgate.net/publication/252958059_Ubiquitou...
What does that have to do with anything upthread? This non-sequitur is shifting the goal post: your initial challenge sounded like it's something that cannot or should not be done - yet it was.
We already had it in the 90's, it was called MSHTML.
There was even the concept of packaged web apps directly supported by Windows.
> *Replace WPF and C# with GTK,Qt,C++,C, etc. as needed.
Yet, I moved from web back into WPF/C#, iOS and Android a few years ago and can't complain about lack of work.
Also gained some sanity in the process.
I hope one day the industry will accept that cross-platform doesn't have to be a choice between abstracting away the whole platform and abstracting away nothing between platforms.
Native almost always improves UX, I don't get why there was initially such a push to bring the web everywhere in the name of cross-platform, but it seems this time the push has seemingly taken a life of its own
Most mobile apps also store their user data in the cloud.
You mind sharing the knowledge that is so "well-known here"? We aren't all part of a hive mind.
By cycles I mean the constant cycle between centralizing compute power and decentralizing as the economics and benefits shift between those two paradigms.
What is being done now on the "cloud" (yes, I hate the term) is simply what was being done with mainframe computing systems 35 years ago, only we have better connectivity and graphics to support the consumer version of it.
I expect to see a shift back towards individual "on-prem" devices at some point, but that will probably be another 10-20 years and will take a black swan (or multiple baby black swans) event no one here can predict to happen - just like no one in the mainframe days predicted the consumer Internet.
I absolutely agree giving control of the Internet to perhaps 10 total companies that have 90%+ of the content delivery traffic is a horrible idea with only one assured outcome.
The usage follow the evolution of technology.
Did mainframe when it was the right tool for the job, will do cloud when it will be the right tool for the job.
If it gets more robust too then sure, but it won't.
You need to know why that becomes the norm rather than the exception. Ease of management, installation, upgrade, ... is really what drove those changes back to centralised server.
Solve those issues and people will go back to develop local application again. Actually, those issues are solved on mobile and every app store is testament to that.
As a side note, it is interesting to note that Cloud providers could be seen as the ultimate free software end game. Remember the "make your money on support, distribute software for free" ? Well that's what cloud provider are doing: they are just selling you convenience and support in a box on top of what is overwhelmingly free software.
For Amazon, the marginal cost of a server is very small. For some startup, bringing up and maintaining a data center is astronomically expensive. By going with a cloud provider instead of hiring their own staff and buying their own hardware they save lots of money. If you don't need control over the hardware and networking and such then you can save money on the responsibility for it.
More than AWS & Google Cloud & Microsoft Azure???
Do you realize there are 3 of the biggest tech companies, investing thousands of people and billions of dollar to fight each other?
Plus the cheaper company Digital Ocean / Linode who are catering to a different market, and are eating the food of GoDaddy/OVH...
The cloud war is actively ongoing. Maybe we should have more articles to show it.
The biggest contender is Kubernetes right now because Google is behind it. Anyone who adopts it is in a better position to move off of Amazon. Google has a better infrastructure and pricing but lags behind in terms of capabilities so that's their strategy.
The worst thing you could do is use Amazon Lambda. Pretty soon the platform will become the application. It ties all the Amazon product in a big ball of vendor lock-in.
(My employer would hire such folks too, but you'd have to be willing to move to Germany).
Amazon is heavy with their advertising and this have a huge mindshare with potential customers and even non-customers alike. No amount of extraordinary exec play would have changed that in favor of Cisco.
Cisco was dedicating $1 Billion to the project, AWS made $2.5 billion in Q1 2016. Think of that for a second
Actually - Amazon is now an established brand name even in the corporate/enterprise execs' minds, but Cisco used to be way more famous and trusted than Amazon until recently. They've never been the cheapest or first to market, but their stuff works well enough and their support is good, esp. if you have the patience to first go through the mostly useless level 1 and 2.
* wikipedia says there's no actual evidence that Watson himself said this.
i wouldn't say amazon claimed another victim but rather cisco failed at advertising its services.
granted it'd been difficult, amazon already has a massive platform to advertise itself.
Note: I am in no way affiliated with them; I just heard they had a cloud a month ago so they are the newest addition to my 'They have a cloud?' list.
I think that if I had heard of it, I'd have initially placed it as a middle-of-the-road choice. Cisco's no Amazon or Google, but it's also not a Microsoft[1], IBM or HP. It's certainly not an Oracle.
[1] I'd only initially place Azure as bottom-of-the-stack; I've heard enough good things about it that in an actual greenfield cloud project I'd consider it a contender.
I think Cisco's and Oracle's cloud are both not heard of before?