> However, from a customer point of view any startup or mom-and-pop can leverage these very complex and expensive world-class security developments, whereas in the past this access has been reserved to the very select few that could afford it.
I don't expect startups or mom-and-pop's to build internal clouds. I do expect medium to large companies to do so. The current market turns innovations such as these into competitive advantages of Google, instead of directly exposing the innovation to the market and allowing incorporation of its advantage into anyone's product. It's a less liquid market. Either you buy all of Google's solution as a package, or you buy none. You can't pick, sort and mash a solution of your own from disparate parts.
Note that Google here is just an example. All companies of similar size in IT are doing the same, and strategically it is the correct option (for them). I'm just stating that the overall result is sub-optimal through a collusion of disparate factors.
> I don't know how your Google Voice example (which is an application/service) applies to cloud infrastructure
I tried to explain the concept above, but it's that whether it's an application/service or cloud platform, it's tooling has to be designed for the entire customer base. Often, a far stupider solution can be far more effective, if it only has to be written to apply to one use case.
> such confidence
Don't get me wrong: Nobody's perfect and everyone has security holes. But things like all of the public S3 bucket fiascos should remind you that the cloud is, by default, open to everyone, and people become incredibly overconfident that Amazon or Google or Microsoft will keep them safe.
> If it turns out the equation favors you
It almost always does. When I do something in house, I am paying for hardware, software, and engineers. When I do something on the cloud, I am paying for hardware I don't own, software I don't own, engineers who work for someone else, and a healthy profit margin for one of the five most valuable companies on the planet.
Cloud is a narrowly-effective solution for startups which can't size out their solution themselves fast enough, and short-time peak loads. For everything else, you should probably not cloud.
> I understand for big companies with millions of users they can't operate in that way but for me risk vs reward is too high.
They absolutely can. If anything, big companies have more resources to build their own cloud based on on-prem or rented bare-metal than smaller companies. It's just all cargo-culting.
The "cloud" is not some kind of unobtanium hardware you absolutely can't get anywhere. With rare exceptions, it's standard hardware you can buy directly from any server & network equipment manufacturer.
> Cloud providers aren't very intelligent security layers.
I think I lost track of what you're trying to discuss now. I'm not arguing cloud providers are a security "layer" in any sense, just that they take responsibility for some things you otherwise need to do yourself. If you got that from my post I apologize. Even if I said something like this, I don't know how your Google Voice example (which is an application/service) applies to cloud infrastructure.
> Which is to say, my engineering regiments will always be more capable than my cloud provider's engineering regiments, because mine know my system and my customers and my use cases.
Good for you if true, but I've personally never seen an environment where such confidence on the part of infrastructure engineers has held up. At least not from a security perspective.
> I'm paying engineering regiments either way, so I might as well pay my own.
If it turns out the equation favors you, then great, those companies exist. But I don't think the equation favors many, at least not when including all the items you need to have for self hosting.
> Considering how late Google got into the cloud game, it seems to be doing respectably well, given all of the catch-up it's needed to do first.
Google is still at 3% market share which puts it at the same level as IBM Soft Layer and Rackspace. [0] Given the technologies Google has developed for cloud-native/cloud-scale computing (Kubernetes, MapReduce, TensorFlow, etc.) not to mention outstanding apps like Gmail, this result has to be a disappointment to their investors.
> So far Google has not shown any inclination that they know how to enterprise, and in fact it's fairly counter-cultural for them.
While traditionally true with Google Products, I disagree with Cloud. Did you attend Google Cloud Next? Trust me, they are focusing on enterprises. Their support has improved significantly and they are focusing on business cases (costs, management, audit, security).
I am certain the Google Cloud Next conference in a few years will look just as enterprise as AWS re:Invent.
>Established businesses aren't going to put their data in someone else's datacenter
You are incredibly unbelievably wrong here. I work for a vendor known for incredibly high prices and have knowledge of basically the entire infrastructure of every one of my clients, and nearly all of them have a massive cloud strategy that's in-place right now. I even have clients shipping their security and compliance logs to the cloud, or sending them from cloud to cloud.
Actually the more medium-sized businesses are the ones most hesitant to move to the cloud, because of the lack of cloud expertise on their teams. But even then... it's still a huge strategy. They're all consolidating physical datacenters and using Amazon or Azure or Google.
> and they knew very little about non-proprietary technologies that we used on a day-to-day.
I had an eye opening experience several years ago. My group was partnering with a group at Google. Their developers were sharp, as one would expect. But were very lacking in what would otherwise be considered table stakes, the reason always wound back to they had a proprietary Google equivalent of X, so thus they weren't familiar with X. The one that really hit it home was that we had to teach them how to use Google Cloud, because at least at the time, internally Google folks didn't use GCP but instead used their own internal versions of things.
> Thinking about it, I think this would be a great idea for a startup. Cheap data storage for long term storage, with competitive prices, the ability to per-pay, user-side encryption and a simple UI that grandma can use to drop photos. It should be able to guarantee that the information you desire to will outlive you.
As a consumer, I wouldn't trust a startup for such needs, because there's a likelihood that the startup would either raise prices, pivot to a different service offering, or shut down entirely.
Google Cloud Platform lets you make a manual prepayment [1], so that's an option worth considering. I know Google gets a lot of flak for shutting down consumer services, but I'm inclined to believe that they wouldn't shut down Nearline/Coldline without a significant amount of notice.
> Not to mention the idiotic idea of a single provider solution.
I'm surprised this isn't being discussed more. With a huge $10bil cloud I would think you would want to select a secondary vendor to distribute redundant workloads and data storage. Even if Azure or GCP couldn't meet some requirements today it's a ten-year project and both are expanding quickly. Azure has recently brought online government-specific locations and Google has already has geographically dispersed zones within regions that meet these requirements.
> They seem to have a fundamental misunderstanding in that they (apparently) believe their problem in the market is price when it's actually something much more basic: trust.
Trust is not the issue. Google wants to sell "management" while AWS (et al) are selling raw resources. To use Google Cloud you have to change or build your system for it, using new APIs, configuration systems, other managed services and even programming languages. Todays announcement was: you can have raw VM control with our management too! I don't see it being any easier now (even MORE options!) but I think they're on the right track. They need to make it simpler rather than cheaper.
> If you want to know why Google isn't doing -great- in the cloud, it's because people are afraid they will kill the project.
Spot on, and it is a sentiment I come across more than once every year. The number of startups hosted on AWS is huge, MS Azure is currently runner-up and Google a distant third.
> Of course I also always argue against using the cloud for anything sensitive as “the cloud is really, just someone else’s computers”.
This is too simplistic: employing that argument obligates you to show how you’re mitigating the same threats on your own, especially with regards to ops and security staffing. I have considerably more confidence in any major cloud provider having robust internal monitoring than the typical corporate VMware deployment, and that even extends to bare metal unless you can air-gap it — if you get a bare metal server from AWS, Azure, Google, etc. they’ve still put more work into the firmware, management interfaces, etc. than most IT groups do and those are very juicy attack surfaces.
> unless you’re operating at a huge scale and with Google’s culture.
I'm not sure one has to go to the extreme of huge scale, anywhere near where Google is now, (not that that's what you said), nor all the aspects of their culture, but I agree that key fundamental aspects are often missed.
My favorite example is to point out that Google does not run Hadoop on expensive, virtualized AWS instances (or even brand-name servers with useless-for-purpose features[1] that creep up the cost). Rather, one of their competitive advantages, from the very start, has been to optimize hardware that they purchase, customize, and operate for cost (and performance).
The other is, as you mention, culture, which involves a remarkable amount of specialization, with groups dedicated to hardware, networking, internal tooling (i.e. building and maintaining the Hadoop-euquivalent), and, of course, SRE, who couldn't even begin to do their jobs without all those other groups' support.
Of course, there's an argument to be made that things like k8s and PaaS/IaaS can take the place of all those supporting groups at Google, but my counterargument is that they both fail to impart any benefit of customization (or, conversely cultural benefit of the mindset of doing everything that way across the entire company) and carry a tremendous cost (in money and complexity).
[1] redundant power supplies, high-density chasses, onboard hardware RAID
> One of the scenarios is that the cloud provider has an algorithm they want to keep secret. Clients want to use the algorithm but dont trust cloud provider with their data.
That would indeed go a long way towards resolving the issues caused by the way SaaS is done. It would let us decouple compute provider from the service, in a way in which it would be the end users who are free to chose where the computation happens, and they'd own all the data by default, while the business secrets and IP of the service provider would still be protected.
Shame to see it's so computationally expensive, I was really hoping this kind of computing would take off.
>You should never assume that a cloud provider is better at managing anything better than you could do in house.
This is a piece for a general audience, explaining what a cloud is.
What percentage of its audience do you think could secure things as well as any of the major clouds? 1% 0.1%? 0.00001%?
If you were to take the class of IT professionals, those with jobs working in IT, I would say less than 0.5% would be able to put something in place in their house that even matches what's going on in the large clouds whose design and policies have been vetted by multiple people.
Whatever a person is doing in their own house is going to be quite difficult to match to the same level of security. Not least of which because people's houses are not secure. Breaking in and adding a keylogger or such in order to break disk encryption is much easier there.
> One of the top cloud companies who everybody assumes are supposed to have security and security experts beyond what you can deploy, which is one of the main reasons given for why you should move to cloud deployment,
I’d say your assumptions are wrong there. Security is not one of the main reasons for moving to the cloud. It’s not even _a_ reason to. Delegating responsibility for security might be cited as a reason but that’s not the same as saying the cloud is “more” secure. That’s just saying you are you don’t want to pay for security yourselves. Which is a whole different thing to what you’re claiming.
> Google Cloud continues to have the most resilient and stable cloud infrastructure in the world.
As a company, Google has a lot of work to do about its customer care reputation regardless of what some metrics somewhere say about who's cloud is more reliable or not. I would not trust my business to Google Cloud, I would not trust anything with money to anything with the Google logo. Anyone who's been reading hacker news for a couple of years can remember how many times folks were asking for insider contacts to recover their accounts/data. Extrapolating this to a business would keep me up at night.
> My experience is that Google services are often an order of magnitude harder to use than competitors.
Huh, I think most people feel the exact opposite, especially with the comparison between AWS and GCP. GCP has lots of services that are really easy to get set up and running easily by a small Dev shop (Firebase is pretty fantastic in my opinion), while with AWS unless you have some DevOps/networking experts it's a lot harder to do things correctly and securely.
If anything, I think the biggest issue with GCP is they still don't have the "DNA" to do enterprise support at the level large companies expect, while AWS does.
I don't expect startups or mom-and-pop's to build internal clouds. I do expect medium to large companies to do so. The current market turns innovations such as these into competitive advantages of Google, instead of directly exposing the innovation to the market and allowing incorporation of its advantage into anyone's product. It's a less liquid market. Either you buy all of Google's solution as a package, or you buy none. You can't pick, sort and mash a solution of your own from disparate parts.
Note that Google here is just an example. All companies of similar size in IT are doing the same, and strategically it is the correct option (for them). I'm just stating that the overall result is sub-optimal through a collusion of disparate factors.
reply