Cisco confirms it’s killing Intercloud public cloud in March 2017
venturebeat.com
venturebeat.com
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.
It'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.
* 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.
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?
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.
(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.