Hacker News new | past | comments | ask | show | jobs | submit login

The drive here is to reduce dependencies to locations the state itself have jurisdiction over i.e. things that can be controlled.

It's essentially to avoid having the states data taken hostage when the slowly brewing conflict between America's lack of respect for it's foreign partners data protection regulation and the EU's very popular trend towards less and less tolerance for corporate data abuse comes to an head and we see actual blocks being mandated on high-security networks against US data harvesting companies(of which MS is but one).




And how do you do that? You think EU companies will stop buying Office 365 subscriptions to reduce their dependency on the US?

Companies buy Office 365 subscriptions so they can focus on their main business and don't want to think about their office solution and want something that JustWorks which is already compatible with what everyone else uses.

They have a business to run and money to makes, so spending extra time and effort on alternative office solutions with various degrees of compatibility, just to fight a virtual trade war, will slow then down significantly from their main business goal.

Why do you think Google uses SAP instead of rolling out their own solution? You think they don't have the technical know-how, or is it because it's not worth the effort and better use what everyone else is already using and focus your resoruces on what really matters?


If the entities you depends on for funding migrate from Words to LibreOffice, then yes, you will consider moving as well.

The network effect may be mostly considered in regard to social media, but it is just as powerful when it come to tools and file format.

Administrations moving en-mass to open-sourced software would ensure a significant chunk of companies would follow.


This is precisely why Microsoft freaked out when Germany last tried this. It led to them inventing this nebulous "TCO" concept wherein they massively overestimated the costs surrounding moving to FOSS in order to try and convince clueless managerial stakeholders to stick with them.


To be fair in certain cases the cost might be very high and considerably higher than whatever the license/subscription fees paid to MS are. e.g. Libre Office doesn’t really have a drop-in replacement for Excel (for non trivial use cases. To be fair it still might be sufficient for the majority of users, but that would mean that some proportion of your workforce has to stay on Excel/Office which kind of beats the whole purpose).


To be equally fair, in certain cases the non-licensing costs of Microsoft software are higher than the FOSS equivalent.

In fact, I'd argue that in some cases these are higher. A good example of this is that piece of shit that is Microsoft Teams - both the horrid security flaws and the ways it keeps breaking. I've used FOSS equivalents and they have a smaller attack surface and are more reliable.

They also play all sorts of user-hostile tricks that make vendor lock in possible, and this often has an underappreciated impact on delivery.


Vendor lockin is no excuse leaking PI to MS though. You could buy some Office 2003 CD and use Excel locally.


Uh using an out of date and unsupported Excel version is a really bad idea. Lots of security vulnerabilities around VB scripting/macros which gives you the very real risk of being compromised by a malicious spreadsheet.

Better to just switch where you can and invest resources into improving FOSS offerings to handle the use cases it currently can’t.


Executing malicious code on your computer is a problem, ye.

If you want to give the users a nice programming environment you can't also prevent them from doing arbitrary computations.

You can run Excel in a VM if you want.


Medical researchers in many places leak non-anonymized sensitive patient data to MS, even when they know better and that's one of the reasons Office LTSC exists


> Vendor lockin

That, but also lack of feature parity. Unfortunately Libre Office is just not very good


> It led to them inventing this nebulous "TCO" concept

Source? Is that phrase really a Microsoft invention?


You don't need everyone switching over. Let's say that by next year, a total of 10% of orgs in the EU are using LibreOffice, and then Redmond is hit by a comet. It'd be painful for the other 90% to switch but there would be some familiarity with the process, whereas if there's an MS monoculture then it would take a whole lot longer and be a lot messier.


You just do it like USA does: if you want to do business with the public sector, you must not rely on a foreign cloud.


What are the alternatives. Like, really. I get it: Hetzner and OVH exist. But what are the alternatives to AWS, GCP, Azure?


As someone who split his time 50/50 between AWS and vmware based instances, i cant really think of anything we run in AWS that is not eventually supposed to go back on prem when we have stabilized the specification and lifecycle expectations. And who could not have gone in on prem if we had been willing to spend capex upfront(which would likely had led to lower lifecycle costs).

The last time this debate came along ms was able to sweep in with an solution that did not require cloud integration with an price/support package that was by all estimate at bellow cost, and i would be surprised if the state in question have anything in the cloud that MS did not use to offer as on-prem solutions, and im pretty sure the current wintel/mso solution is based around those on-prem implementation of AD and SharePoint that no longer exists and viable alternatives to opensource based document storage repositories.


> i cant really think of anything we run in AWS that is not eventually supposed to go back on prem

Hod do you handle multi-DC, multi-AZ resilience? What are you using instead of IAM policies that cover every resource?

(Asking unironically, would just like to know. I worked at cloud-centric companies for last 15 years or so.)


I guess the same as people have always done. You have more server rooms on ideally different networks and grids. That can be a rented room/ rack in a bigger DC, your own if you have a big factory with subsidiaries etc.

The IAM etc. will probably done by a combination of technical on organizational measures. You will have certain people doing certain things at least before the solution is ready for IaC. People will create roles, accounts, accesses and such. With networking gear that can be still tricky to implement, with virtualization solutions that is easier today. For databases etc. you can create accounts in them too. Of course, K8s and similar make these things more formalized/ transferable. However there is a lot of stuff before you can deploy that.

People forget however that even if you have hundreds of servers you are tiny compared to the cloud providers. You don't have to have the same breadth and depth of offering. So while you need more baby sitting of hardware, probably will not get nearly as good deals on hardware as the big providers do, you will save their considerable margins. Also, they actually have some of the same expenses too - if a harddrive goes bad they will still swap them basically the same as you do. Big cloud providers will not get substantially different energy pricing than what e.g. a steel foundry would get.

By hosting things on premise or in a nearby datacenter(s) you can shave off a lot of latency too. Some machinery likes to store a lot of data and shaving off latency will decrease your need for thick router buffers because you will not have such a big Bandwidth Delay Product and will achieve the same speeds with much smaller buffers. Building stuff on premise just for you makes some things easier too. Even if you loose some credentials usually you can just hard-reset the equipment as the last resort. There will be no credit card blocking that would affect the operations. If you are less strict with security it will usually matter much less - you are not sharing the hardware with unknown parties and all people that touch it have a contract with the company. So usually everybody want the company to succeed to get the paycheck. You build a deeper know how and can do some optimizations the cloud providers cannot do because you don't have to be general.


Thanks, this makes sense!

I mostly thought about the software infrastructure side. With thousands and even mere hundreds of servers over several locations you already want some uniformity. Would you run k8s? Nomad + Consul? MinIO or Ceph? MySQL + Galera? Would OwnCloud scale to many hundreds of users? How would you unify or integrate access control to all that?

Nothing unsurmountable here, just interesting how it's done in real big on-prem installations.


Well, hundreds or thousands of servers can probably be still managed by Ansible with Fabric, Puppet, Chef etc. I don't think focusing too much on the technologies used is useful when planning the overall approach. Most companies could probably consolidate all the critical hardware to 2-3 racks of equipment if they tried nowadays with HA and everything. Hardware is just really powerful and having less of it makes everything else further up usually simpler.

What I would run depends on the particular customer I would have. I probably wouldn't try to unify or integrate access control much. You are not trying to build another public cloud, you want to develop and deploy applications with reasonable robustness in comparison to the cost and benefit of the solution.

Real on-premise installations usually are a mix of open and proprietary technologies. Many companies probably have a few Windows Server file servers on top of VMware vSAN or some kind of EMC2/ NetApp/ HPE 3PAR or whatever storage with HA capability. There is no S3 compatible storage and all the data is stored on the network drive and referenced in some MSSQL database or stored directly in it. If MSSQL or Oracle is used, they probably run on local storage and have are part of a cluster that are marked such that they are never on the same physical node. You can do similar things with Proxmox, GNU/ Linux and PostgreSQL too with a little more effort. You can run MinIO or Garage for S3 if you want to be cool or buy a supported Ceph installation from e.g. SUSE. Everything will be more rudimentary and half automatic but still a few people will be able to manage that even on a rather large scale without many issues. Of course, if you have bigger needs, there are companies you can by computers from by the rack. Some will offer you a complete cloud management stack with it. It can be Oxide Computers (their own stack), or Cloud&Heat in Germany for instance (that is built on OpenStack). There are so many options.


For AWS we rely almost entirely on backup/restore and database level log shipping on prem this is is in some cases argumented by storage level(netapp and previously hpe 3par) replication but this is going away for cost reasons.

Given that my experience with AWS is to use the same application level cross region resilience techniques im used to on prem(i have worked with high end unix boxen most of my carear) im genuinely baffled when people start talking about cloud resilience as something magical, and nearly all our traffic happens inside of an private network(MPLS/VPN) that stretches across the different sites.

I really haven't seen any magic multi-az resiliiance in aws that dont have an onprem counter part.

None of this is in house whitebox hardware but relatively standard solutions from established vendors(VMware recently started abusing their near monopoly so everyone is looking for/at alternatives like proxmox, xen and nutanix but arent ready to move just yet).


Thanks! Certainly multi-AZ setups are not magical. I just wanted to know how it's now done on-prem, what are the tools, solutions, approaches. Doing this in a cost-effective way for 1000 servers likely takes different tools than doing this at a major cloud provider scale.

One thing that's more "magical" in AWS is S3. Their architecture is impressive, see e.g. https://www.allthingsdistributed.com/2021/04/s3-strong-consi...


Many users don't need multi-DC, multi-AZ resilience. Having a good (and tested) DR plan might be enough.


This is correct. The original comment was about having basically anything AWS has to offer run on-prem, assuming that these things are actually needed.


Scaleway is a great alternative to AWS. A lot cheaper too! And API compatible.


Thanks, looks interesting.


I guess MS could just find a way to guarantee that any data is only stored in data centers in Europe. It shouldn’t be too complicated and I don’t see how could they be considered to be a foreign cloud then.


Can the US government still force them to violate that guarantee? If yes, then they're a foreign cloud.


But then that would apply to every company that has datacenters and provides services both in US and Europe?


I don't think so. The US government could kill Microsoft; no European government could. The EU / some European government could kill a European company; the US couldn't.


openstack


No. OpenStack sucks to deploy and maintain with the result being an inferior cloud with a lack in services.


The goal is not "superior", the goal is "USA can't kill our infrastructure pressing one button"


The goal is also to have a usable cloud on which you can efficiently develop software.

Otherwise we can simply go back to paper.


The initial premise is wrong for a start.

You don't need a cloud to efficiently develop software. I've worked in companies that were running kubernetes on prem. It was a PITA for kubernetes ops but from a developer perspective it wasn't much different than using the cloud in a large company.

Cloud is very flexible for very small orgs that have little processes but once you get into a certain size with lots of processes, privileges separations and nomenclatures, it becomes so bureaucratic all flexibility of a cloud mostly disappear.


> You don't need a cloud to efficiently develop software. I've worked in companies that were running kubernetes on prem. It was a PITA for kubernetes ops but from a developer perspective it wasn't much different than using the cloud in a large company.

EC2 servers and Kubernetes are a very small part of what is necessary to run complex applications.

> Cloud is very flexible for very small orgs that have little processes but once you get into a certain size with lots of processes, privileges separations and nomenclatures, it becomes so bureaucratic all flexibility of a cloud mostly disappear.

That will be the same in any large company.

Friends working at banks have to make formal requests for new versions of Python that months to be accepted.

If anything, clouds can be much more flexible thanks to tools like CDK which bare-metal or OpenStack don't offer.


>Friends working at banks have to make formal requests for new versions of Python that months to be accepted.

And I have been asked by my manager to help a different team and I am still waiting 10 days later to get access to the necessary AWS account.

These kinds of problems are organizational, not technical. Thinking cloud solutions solve organizational issues magically is naive and delusional.


> These kinds of problems are organizational, not technical. Thinking cloud solutions solve organizational issues magically is naive and delusional.

We actually agree on this point.

Using OpenStack is actually not a silver bullet and won't solve this problem. This is an organisational problem.

So my point still stands that OpenStack is lacking in services and is not fit for complex applications if you do not want to reinvent the wheel every day.


okay


> You think EU companies will stop buying Office 365 subscriptions to reduce their dependency on the US?

I don't think they will stop, but they will become much more hesitant.

Concerning your other points: it is of similar economic importance for the company to invest in precautions to prevent that you are taken hostage of, in this case by Microsoft. Thus such measures are actually often in the company's self-interest in opposite to fighting a virtual trade war for someone else.


> And how do you do that? You think EU companies will stop buying Office 365 subscriptions to reduce their dependency on the US?

Well... yes, I think that's exactly the argument being made here. Reliance on foreign cloud infrastructure is a liability, and the US does not hold any of its companies accountable for blatantly unethical and reckless data practices.

I'll admit LibreOffice is relatively underpowered and unintuitive, but I've been using it for years and I find the compatibility issues to be overblown. I'd hazard a bet that most employees of companies using MS Office could make the switch and be used to it within a couple weeks. Certainly a much, MUCH easier transition than one between ERPs, for example.

> Why do you think Google uses SAP instead of rolling out their own solution?

SAP can be hosted entirely onsite, and at Google's scale that's almost certainly what they're doing. The problem is the infrastructure, not the origin of the software itself. Note how the EU never had anything against MS Exchange Servers.


Of course. Same thing will all those environmental laws shenanigans.

Companies are better off investing in short-term gains and leave the governments taking care of the environment and digital accountability of its citizens.


If the alternative is not getting the security certifications required to operate legally in the sectors they depend on for revenue what alternative does an organization really have to seeking/implementation solutions in sync with the mandated regulations.

And this is not an private company whose demise is insignificant to the society at large(as all companies must be in an functional capitalist economy) but the government itself instituting policies to protect itself from dependence on a single foreign company.

And being told by an court to get off the o365 cloud is not an theoretical prospect for an European governmental organization as the EU commission found out about a month ago(https://www.edps.europa.eu/press-publications/press-news/pre...).



Governments can take a longer and more strategic outlook than private enterprises. It's not even primarily about nationalistic trade wars: I want my tax euros to fund as little closed-source software as possible. It's crazy how much money even just our schools spend for software that can't be freely redistributed or modified. That said, I'm not holding my breath regarding the success of this most recent move.


I mean, even aside that? If you spend the money on European developers instead, that's jobs and tax dollars here.


> And how do you do that? You think EU companies will stop buying Office 365 subscriptions to reduce their dependency on the US?

Most workers in most companies probably don't really need an entire Office suite. It is just they use Outlook and from time to time open a Word document that could've been a PDF or HTML form if they had better processes. For the same reason, most people don't really need to use Windows. However people use Windows, because a lot of "professional" software only ships for it and nobody is going to rewrite an app that the enterprise uses for the last 20 years to prevent the use of Windows or some of its particular version. If it was that easy, why would Windows XP or Windows 7 be still so wide-spread?

> Companies buy Office 365 subscriptions so they can focus on their main business and don't want to think about their office solution and want something that JustWorks which is already compatible with what everyone else uses.

The problem is, many programs in the Office suite don't just work. Being an admin in a larger organization you will face a broken .pst file basically every week. 10+ GB of emails seems to be a problem also considering the search speed etc. The level of engineering incompetence behind Outlook is high. It even has special conditional HTML just so Outlook renders some things correctly, because Microsoft is long term incapable of implementing a web engine to a degree that they had to adopt and adapt a competitors product (Chromium). Similarly for Excel. Most things that are in Excel shouldn't be and instead should be a table + some app in a database or a form + database backend. We have seen that during COVID-19, when essential health data was messed up because of wrong use of Excel but also because Excel just wasn't the right tool for the job frankly. We have been renaming genes or whatever, because Excel has insufficient auto-formatting algorithms and people have to learn how to prevent this - which is proof it doesn't "Just Work" for people.

> They have a business to run and money to makes, so spending extra time and effort on alternative office solutions with various degrees of compatibility, just to fight a virtual trade war, will slow then down significantly from their main business goal.

Most things in most companies should be formalized in digital forms backed by some processing backend. Most companies just are not very good at management therefore they fill these gaps by using more flexible tools where everybody can unfold their creativity generally making a mess making any kind of formalization much harder later on.

No question there are also jobs where you need that flexibility, e.g. where you get data from people precisely in these formats and are expected to produce output in these formats for them too. Because people are generally opposed to change and don't want to learn, if they can avoid it. Much better tools are available for so many activities yet people usually opt for a product out of the Office suite.

> Why do you think Google uses SAP instead of rolling out their own solution? You think they don't have the technical know-how, or is it because it's not worth the effort and better use what everyone else is already using and focus your resoruces on what really matters?

Because promotions are easier to get if you work on a product that makes money for the company (such as search + ads) or is a big cost center and a needed pre-condition for the business (such as the cloud infrastructure) and you can implement changes that safe the company a lot of money. However, don't underestimate how much SAP was customized for Google. It could be that SAP is just the core of a much bigger system.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: