[xoa]

Exactly, in fact there's even more to it then that. Particularly at Apple's scale, maintaining a codebase across multiple architectures internally, even if there is absolutely zero foreseeable intention to use them, offers significant value. Strategically of course it creates some hedge against over dependence on any single supplier, it's not just "the Mac market falling apart" so much as Intel/AMD dropping the ball or becoming unable to go in a direction Apple wanted (as happened with PowerPC). By the same token it helps maintain some level of economic negotiating position, even if Apple faces what is effectively right now a single key supplier situation. The mere fact that they could switch if absolutely forced to is of use.

Non-strategic value though is probably just as important as any of this stuff: as probably most of HN knows well, keeping a codebase portable can be quite helpful in terms of plain and simple quality. Obscure bugs or bad patterns that are hard to find on one architecture can be a lot easier to identify on another. It can help promote discipline and good practices. Portability I think is really a constant process rather then a goal or single thing, it's a lot easier to have worked on it all along for years before you need it then try to "port" something later because without the constant pressure of staying portable it's all too easy to start falling into dependence on features (or worse, quirks) of a single arch and build up more and more technical debt. Then when the "bill" (not necessarily just in terms of money but sheer developer hours) finally comes due it's effectively unpayable.

[Turing_Machine]

"as probably most of HN knows well, keeping a codebase portable can be quite helpful in terms of plain and simple quality. Obscure bugs or bad patterns that are hard to find on one architecture can be a lot easier to identify on another."

Right. Even if they had no intent of making ARM laptops (although I suspect they probably do have that intent), the exercise of keeping the code portable between Intel and ARM would serve them in good stead even if they later went to yet a third CPU architecture.

[pasbesoin]

In addition to the pure R & D value (with all its uncertainty, but with probable considerable upside in the longer term), doing this likely more than pays for itself in terms of the leverage it provides with/against existing vendors/partners.

This is just my speculation. But, 1) You learn things; 2) You lessen lock-in / dependence, in turn reducing the markup you have to pay on existing production inputs.

Apple's benefited very considerably from the increasing customization and optimization of its phone CPU et al. platform. What's the argument against carrying that over to their computer lines, if and when they can make that a relatively smooth transition?

[walterbell]

Should this apply to cloud provider portability?

[derefr]

The problem with portability between "clouds" (IaaS/PaaS providers) is that many of them have features (e.g. object storage; Dynamo-based distributed tables; reliable message-queueing; health checks connected to load-balancing and hypervisor lifecycle control),

• which are "obvious" and perhaps even necessary for productive coding of distributed systems software; and

• which have huge economies of scale (one shared cluster for all customers beats the pants off the performance+availability of your company's puny little three-node private cluster), and yet...

• which other major clouds don't support at all.

Effectively, all the "clouds" currently only offer between 30% and 90% of what you'd want in something that called itself "a cloud." Nobody has a "whole cloud" (AWS is closest, but still not there.)

Designing for portability between these clouds would be like writing assembly intended to be portable between processor architectures, when only one architecture had an ALU, only one had registers, and only one could conditionally branch. It would be madness.

---

Personally, I feel like, to be able to sensibly design for portability between cloud providers, they'd need a lot more features in common than they have now.

Maybe we could invent a minimum common standard to hold the cloud providers' stacks to—maybe a small one at first, with a growing list of expectations over time; or maybe a "core" spec, and then a number of "levels" of support atop it. Then you could say you've targeted "IaaS Level 3", and clouds could claim to support that, and cloud-abstraction libraries like Fog could actually do something useful.

[pm90]

Good question. Ideally it should... operating on Apple's scale, it would be a great idea to have their cloud based solutions running on multiple platforms to reduce dependency/vendor lock-in.

[caycep]

having Marklar around rewarded them substantially in the past