4 ms·

It's telling that all the hyperscalers keep taking runs at this, driven by the DoD. I'm not sure anyone is making money at it though. Azure tried with Stack Hu

It's telling that all the hyperscalers keep taking runs at this, driven by the DoD. I'm not sure anyone is making money at it though. Azure tried with Stack Hub (private airgapped cloud), Stack Edge (various options, including ruggedized, gpu enabled, battery powered, rackable). The JEDI contract didnt amount to much so I dont know if this range has a future. AWS have tried with outposts and the snow family. Seems to be doing ok in the commercial space. Now google. They all seem to have some weird genesis as data transfer gateways (looks like a local network share, but really sends data back to S3 or some other cloud store), and they all seem to have weird compromises that the disconnected nature forces upon them. For example you need to connect the box to the cloud at least once every 30 days to have it sync to the mother ship, or whatever. I wish them well on this but I doubt it will be much more than a tickbox for government contracts and won't see much live deployment. If google came out with a range of box designs that fit in a backpack or a VPX chassis, could be spared and replaced in the field by any vendor in the defense industrial space, could run disconnected for 120 days or more without degrading, could be operated by an 18 year old under duress in a combat environment (no one is following a manual at that point, it needs to be "turn the key and oress the big red button" simple) and could seamlessly upgrade/clean themselves up when reconnected to the cloud back at base, they'd certainly have my attention. Oh and given the geo situation, maybe made from components that have alternatives not made in Taiwan.

eitally 2y ago
With Google, I have a feeling it largely evolved from two other things [that weren't the DoD]. Google never really tried to sell to Defense until JEDI, and didn't really have a compelling solution at the time to the need for FedRAMP High requirements. However, what Google did have was a business need to offer GCP in mainland China, and a partnership with Tencent to do so. Additionally, after Thomas Kurian joined, Google also had a willingness to partner with KSA as a tangential part of the overall NEOM investment, but with the hyperscaler providing a dedicated region in Saudia Arabia and in exchange potentially getting heavy commercial workloads from Aramco and other KSA entities. Google already had Sovereign Cloud experience, having built out a data center in Germany (that, among other things, SAP uses for internal development), so it wasn't a huge leap to go from the hoops they had to jump through to offer this combo of stuff all in one package: * Interconnect partnerships (Oracle Bare Metal, Tencent) * Integrated management console (Tencent, Anthos) * Sovereign Cloud services (US Gov't, European governments) Beyond all this, Google has been offering CDN appliances for ages, and space in local POPs for 3rd parties (like Netflix) to install their edge appliances, so it's not like there were any skills gaps on the networking side, either. The real question will be whether the hyerscalers will be able to viably sell these sorts of appliances vs their potential customers just running their own data centers and virtual data centers.
- adolph 2y ago
  It’s almost like the classic balance of storage, network, processor has a fourth leg: information encumbrances, or data sovereignty of various sorts.
SloopJon 2y ago
I'm in the funny position of having to test products in the cloud at a company that is really skittish about putting any of its own stuff in the cloud. I looked at AWS Outposts, but determined that it likely wouldn't pass muster with our policies. It was also really expensive, and it was only available for rent, not purchase. I then did an experiment with the Azure Stack Development Kit. It was limited to a weird ghetto of outdated VM images, and had to be rebooted every few weeks. I did not proceed with Stack Hub. If GCP wasn't a distant third place, I might give this thing a try, but it's probably really expensive just for testing. The long term solution is going to be chipping away at our policies, but I was disappointed that I couldn't find a usable on-prem cloud solution.
- arccy 2y ago
  What about oxide's stuff?
  - SloopJon 2y ago
    Testing correctness and compatibility with particular vendors was the priority: block storage, O/S images, APIs, etc. A third-party solution like LocalStack was on my radar, because it aims to be compatible with AWS. My understanding of Oxide is that it's its own thing.
milesward 2y ago
heheh Vic and I did one in a backpack, worked good :)
kjkjadksj 2y ago
I’m over here wondering why we even need wifi in an appliance… my favorite appliances have just a mechanical knob.
donavanm 2y ago
> They all seem to have some weird genesis as data transfer gateways (looks like a local network share, but really sends data back to S3 or some other cloud store), and they all seem to have weird compromises… Yes, but Id say they _should_ be data transfer gateways and instead we ended up with _faux disconnected ec2_ racks. From what Ive seen the bulk of outpost usage is really close to the data gateway; “Im an onprem/hybrid customer, give me an EC2 vpc endpoint in my existing DC so I can move data and run some workloads mixed mode.” But instead outposts morphed in to “How do we fit EC2/EBS/S3/RDS in to an on prem rack that their cloud team can manage with our existing APIs.” Thats very much a different product and (IMO) a harder, bordering on unsolvable, problem. Getting down to many thousands of single RU appliances is only making it more impossible and disconnected from the AWS “mainline” infra. Id be REALLY interested to see a version of the outpost product that was a single 1-2RU whitebox router with a handfull of 100/400 gb ports and APIs to setup the tunneling/encap/VPC connections for each port. Give them local “vpc endpoints” termination and “direct” connectivity in to their VPC resources back in the region. But that looks a lot more like a DX kind of product than outposts, I think

eitally 2y ago

With Google, I have a feeling it largely evolved from two other things [that weren't the DoD]. Google never really tried to sell to Defense until JEDI, and didn't really have a compelling solution at the time to the need for FedRAMP High requirements. However, what Google did have was a business need to offer GCP in mainland China, and a partnership with Tencent to do so. Additionally, after Thomas Kurian joined, Google also had a willingness to partner with KSA as a tangential part of the overall NEOM investment, but with the hyperscaler providing a dedicated region in Saudia Arabia and in exchange potentially getting heavy commercial workloads from Aramco and other KSA entities. Google already had Sovereign Cloud experience, having built out a data center in Germany (that, among other things, SAP uses for internal development), so it wasn't a huge leap to go from the hoops they had to jump through to offer this combo of stuff all in one package: * Interconnect partnerships (Oracle Bare Metal, Tencent) * Integrated management console (Tencent, Anthos) * Sovereign Cloud services (US Gov't, European governments) Beyond all this, Google has been offering CDN appliances for ages, and space in local POPs for 3rd parties (like Netflix) to install their edge appliances, so it's not like there were any skills gaps on the networking side, either. The real question will be whether the hyerscalers will be able to viably sell these sorts of appliances vs their potential customers just running their own data centers and virtual data centers.

adolph 2y ago
It’s almost like the classic balance of storage, network, processor has a fourth leg: information encumbrances, or data sovereignty of various sorts.

SloopJon 2y ago

I'm in the funny position of having to test products in the cloud at a company that is really skittish about putting any of its own stuff in the cloud. I looked at AWS Outposts, but determined that it likely wouldn't pass muster with our policies. It was also really expensive, and it was only available for rent, not purchase. I then did an experiment with the Azure Stack Development Kit. It was limited to a weird ghetto of outdated VM images, and had to be rebooted every few weeks. I did not proceed with Stack Hub. If GCP wasn't a distant third place, I might give this thing a try, but it's probably really expensive just for testing. The long term solution is going to be chipping away at our policies, but I was disappointed that I couldn't find a usable on-prem cloud solution.

arccy 2y ago
What about oxide's stuff?
- SloopJon 2y ago
  Testing correctness and compatibility with particular vendors was the priority: block storage, O/S images, APIs, etc. A third-party solution like LocalStack was on my radar, because it aims to be compatible with AWS. My understanding of Oxide is that it's its own thing.

milesward 2y ago

heheh Vic and I did one in a backpack, worked good :)

kjkjadksj 2y ago

I’m over here wondering why we even need wifi in an appliance… my favorite appliances have just a mechanical knob.

donavanm 2y ago

> They all seem to have some weird genesis as data transfer gateways (looks like a local network share, but really sends data back to S3 or some other cloud store), and they all seem to have weird compromises… Yes, but Id say they _should_ be data transfer gateways and instead we ended up with _faux disconnected ec2_ racks. From what Ive seen the bulk of outpost usage is really close to the data gateway; “Im an onprem/hybrid customer, give me an EC2 vpc endpoint in my existing DC so I can move data and run some workloads mixed mode.” But instead outposts morphed in to “How do we fit EC2/EBS/S3/RDS in to an on prem rack that their cloud team can manage with our existing APIs.” Thats very much a different product and (IMO) a harder, bordering on unsolvable, problem. Getting down to many thousands of single RU appliances is only making it more impossible and disconnected from the AWS “mainline” infra. Id be REALLY interested to see a version of the outpost product that was a single 1-2RU whitebox router with a handfull of 100/400 gb ports and APIs to setup the tunneling/encap/VPC connections for each port. Give them local “vpc endpoints” termination and “direct” connectivity in to their VPC resources back in the region. But that looks a lot more like a DX kind of product than outposts, I think