Serious enterprise, with a need for data durability, consistency, auditing, real IT security, regulatory conformance etc. won't touch that stuff with a 10-feet-pole.
Also, once you choose your provider, you're locked in into this vendor (be it Amazon, GCE or Azure), while you can move your bare metal servers around to whichever colo/DC fulfills your requirements.
I think it is lemming stupidity. Building one's own "cloud" is easy, and can be one in a tiny fraction of the expense any cloud provider charges. The mindless march to the cloud is a huge competitive advantage for anyone "brave" enough to buck the propaganda and run their own hardware.
There is a breed of developer that is doing REST in C++, building services that live in only a few hundred K, and a single physical server can concurrently host thousands of such services for an expense of $75 a month, running 24/7 with 16 cores and 16 GB RAM. The same capacity on a cloud provider is exponentially higher for a single server.
You know that "fake news" idea? I think it has been manipulating developer opinion for a while. The cloud does not make sense, unless you are a cloud provider with a reason to sell that lie.
is, on each step, at least a 2x or 5x increase in cost for the same computational power.
I started out a few years ago with my hobby projects on Heroku, migrated them to Digital Ocean, from there to OVH’ VPS, and now migrated them last year to rented bare metal.
Every migration multiplied my available resources at the same cost, and it’s definitely been worth it.
I did a price comparison of VPS and some bare metal providers over at https://gist.github.com/justjanne/205cc548148829078d4bf2fd39... and the result is pretty much just that. For 16$ a month I can get enough performance to run services handling tenthousands of concurrent users if I go with bare metal, or I can’t even handle a few hundred if I go with the "cloud".
A few years ago, I got a deal on a cabinet at a colo, and then when one of the research labs at USC dumped their servers for the cloud, and they gave me 17 servers. I'd previously custom built a 32 core, 32 gig server just out of hacker interest, and between the USC servers and my previously owned hardware I put together a 196 core cluster with 3 redundant ( dev, staging, live ) environments for my own playground, and similar setups for hosting clients. Adding to and modifying the system for a few years, I had what would have cost $96K a month at AWS, but was only $600 a month to me.
You're basically advocating the model similar to how WhatsApp grew. The truth is that most companies are willing to throw more money for delivering a result faster, and even the fastest C++ programmers cannot pump out a CRUD app and re-iterate as those using some random crap like Node.js and that's a fundamental reality of languages you have to compile and ship versus just modify in-place.
I think it's a great idea for bootstrapped startups to host their own hardware until they've got the capital to try to spend more for results faster. But again, I think the current software market primarily driven by an obsession of faster iterations even at a far greater up-front cost is what de-emphasizes your romanticized notion of development cycles and care for efficiency (which I personally fully support - I started in embedded dev and all this web stuff has been boring to me since the 90s).
The tooling is just arriving to enable as rapid a development cycle in C++ as with managed languages. I was having multiple issues, only optimizing portions of a traditional (W/L)AMP stack or node.js solution with C/C++ components until I found Restbed (https://github.com/Corvusoft/restbed). Now I can create a complete self-contained REST API server in a 100K executable with no (W/L)AMP stack or other infrastructure required. Compiling C++ is fast, and unlike the typical (W/L)AMP, node.js, or other "conventional web stack" one is not compiling and/or executing through gigs of data and executable - the re-compile and execute/debug cycle in C++ for Restbed is instantaneous on modern hardware, and the execution speed runs circles around any managed language.
Such a development solution is faster, consumes exponentially fewer resources, and is a great idea for much more than startups. You just need good C++ developers that also know the web - a bit rare right now, but the savings are too real for the situation to remain that way.
The other part of the equation is that good developers let alone good C++ developers are in very short supply in a market already dying of thirst for merely competent developers. Most large companies that need software simply will never be able to attract them, so you have to throw your net wider and accept the hegemony of Java, Python, Ruby, and Javascript.
I think labor economics fundamentally wins in the current market over any technical factors until we start approaching large scale systems by which time, ironically, the costs of high-overhead, low-LOC software infrastructure are far too great and you're like Facebook drowning in piles and piles of legacy code that people are scared to really tear apart just to save maybe 20% on the number of servers while still making hiring even harder.
Furthermore, a pet dating app founder doesn't really have any benefit picking C/C++ over Python, Node.js, etc. unless they are so under-funded they're trying to save $300 / mo on hosting costs in which case they can't even begin to think about paying someone in the first place. By the time you start hitting $2000 / mo in infrastructure costs where a solid C/C++ core on even AWS you'll likely be bringing in enough users that you could conceivably raise more funding anyway.
I'm totally a fan of writing C/C++ for modern software but if I'm in the driver's seat of a company I really can't expect to be lucky enough to find someone that knows what they're doing with modern C/C++ in that market. Heck, even in the super competitive yet lower-pay games industry most programmers aren't on C++11 or C++14 last I heard, so they'd still have to learn new stuff if I hired them for a random web start-up or big company.
Thanks for the hint - I'll definitely have a look at it. Compile it statically and you can run it on a bare Linux kernel (or on a container) without any dependency... reminds me a bit of Go.
Do you happen to know if there's a benchmark comparison (CPU usage, RAM usage, RPS) against nodejs and php (the code style of the example reminds me of Silex)?
> Building one's own "cloud" is easy, and can be one in a tiny fraction of the expense any cloud provider charges.
Yeah, I've recently run the math - 176 real Xeon cores and 1TB of RAM are around 70k€ (4x 2x22 core Xeon 2699 v4), while the same from Amazon costs a load more.
On the other side, it's the good old capex vs opex debate, plus you're going to need someone to do occasional disk swapping, worry about RAID setup etc. - all this is done by the cloud provider for you.
> The cloud does not make sense, unless you are a cloud provider with a reason to sell that lie.
It certainly makes sense if you have an architecture that allows you to handle the base load with your own bare metal but allows you to quickly (and automatically) add power via cloud instances.
My company is hardly a startup (16 years old), and we are in the process of converting a few of our processes over to Lambda and API Gateway (via luigi), with good success.
I wouldn't agree with the "You're locked in to this vendor" statement. Our Lambda code is just Python Flask apps and our "if Lambda is down" plan is to run the services from our data center via uwsgi serving the Flask apps. GCE also can easily serve Flask apps, but the environment there is weird and I spent tons of time struggling with things that worked in my GCE dev environment to work in the real GCE. I had high hopes for GCE but it was a total pain in the butt.
As far as moving your bare metal servers around to whatever DC... Enterprises don't easily move data centers. Minimum to move our couple of Lambda apps, deployed on uwsgi, is probably a contract for 2 years at a grand a month, and $30K worth of hardware. We wouldn't take down one data center until another is fully up and running and proven.
Yes, but honestly what percentage of businesses need regulatory conformance or anything like signed logs?
My main problem is the lack of transparency, vendor lock-in (so you can't enter non-mainstream markets with some regulatory expectations, such as Vietnam or Russia).
> Yes, but honestly what percentage of businesses need regulatory conformance or anything like signed logs?
Uh, as soon as you're processing PII, be it health information, social security numbers like in payroll, or credit card information, you're required by law (or the CC industry) to have these. And no, cutting corners is not an option, at least if you want to avoid some serious jail time.
Media processing (in the sense of professional movie studios) requires MPAA certification, which in turn requires that all systems handling "customer data/assets" even be airgapped to the Internet (source: MPAA best practices guidelines).
And if you're ever dealing with car manufacturers, goodbye to cloud - they're similarly sensitive when it comes to anything near unreleased products. No Dropbox/Slack/... allowed, and for good reason.
> Uh, as soon as you're processing PII, be it health information, social security numbers like in payroll, or credit card information, you're required by law (or the CC industry) to have these. And no, cutting corners is not an option
True, but you can still organise out less sensitive components to serverless, and there are plenty of payment and payroll gateways to outsource the compliance problems.
> True, but you can still organise out less sensitive components to serverless, and there are plenty of payment and payroll gateways to outsource the compliance problems.
Good luck building all the firewalling and other logic required for a sane system.
And everytime I see "outsource" in reference to the core parts of a company (which payments and payroll definitely are), I cringe. That's a desaster waiting to happen.
And yet fortune 100 and 500 companies are increasingly adopting cloud technology. And there are plenty of solutions already available to distribute your cloud infra to multiple providers at once.
I think the writing's on the wall. Software devs are coding Ops out of a job. Even the network is software now.
Only at Facebook, probably one of the few companies in the world which can afford dedicated engineers for that stuff (and probably needs SDN because a server might shift totally in its roles and thus its networking dozens of times a day).
The rest of the world keeps using Cisco or HP gear, which works fine enough for everything I have seen (from SOHO equipment in small offices over 6-or-so-HE switches in a medium company to rack-sized switches at a municipal government). Also, the amount of HP or Cisco certified network engineers outweighs the amount of SDN by far.
It's definitely more than just Facebook. Every major network equipment vendor already provides SDNs, including Cisco, and HP, who has an entire site and app store dedicated to SDN.
2016: Top 10 SDN market leaders: "market is set to top $12.5 billion by 2020" ... "SDN in the data center and enterprise LAN is going to go mainstream in late 2016, early 2017," ... "We're seeing significant customer deployment. Cisco's got over 1,000 deployed customers for their SDN solution. VMware is around the same number, even though revenue might be higher on the VMware side. NEC has over 250 scaled deployment customers."
Just as an example, Cisco's been running Linux on its new gear for years. They can run multiple OSes in different planes on their custom gear and get crazy fast traffic flows while doing things like deep packet inspection. They wrote custom interfaces to do things like get super-low-latency traffic control.
You can make your own Python apps, and run them when triggered by an event, on the appliance or remotely, with several APIs. You can use Ansible, Puppet and Chef to manage the appliance configuration. You can also configure them with netconf, or XMPP. You can have your switches send you instant messages or post in your ops chatrooms. And you can deploy all your devices from a clean slate using kickstart scripts.
Hm. I see your first point(s), but maybe won't immediately concede that they aren't solvable. But to your second point, lots of really successful enterprise companies get "locked in" to Aws, Gce etc and are running just fine.
AWS is right around ten years old. I have children who could read before it was launched. That's not enough time for a business to stabilize, but it would be a good idea for any business to start planning an escape route.
Serious enterprise, with a need for data durability, consistency, auditing, real IT security, regulatory conformance etc. won't touch that stuff with a 10-feet-pole.
Also, once you choose your provider, you're locked in into this vendor (be it Amazon, GCE or Azure), while you can move your bare metal servers around to whichever colo/DC fulfills your requirements.