Feeds

back to article Hands up if you have one good reason to port enterprise apps to ARM

ARM servers look tantalising. Various CPU vendors offer multi-core silicon at a price that makes Intel go weak at the knees. Those CPUs also slurp so little power that by the time a senior manager reads about them in an in-flight magazine you'll be asked why you're not using them yet. Throw in the fact that Dell and AMD have …

COMMENTS

This topic is closed for new posts.

Page:

Why port? Most useful apps already run under ARM. Debian is available on ARM completely. What more do you need?

15
5
Silver badge
FAIL

Re: Martijn Otto

"Why port? Most useful apps already run under ARM....." You mean geek apps, actual business apps that run on ARM are like hens' teeth.

".....Debian is available on ARM completely....." Linux is also available on x64-compatible Atom CPUs, which means if I do have a requirement for low power I can already get it without needing to recompile anything. I may pay a fraction more on power but it will probably be a lot less over the lifetime of the unit than the cost of porting all my apps.

5
11
Bronze badge

Both Debian/Ubuntu and Fedora/EL based distributions now have their fully featured ARM variants, so for a typical Linux shop running a LAMP or similar stack there really is nothing to port - it has all already been done. I have worked with several clients whose LAMP(ish) stack projects migrated without any problems at all on the ARM variant of the same stack.

The biggest obstacle to addoption, IMO, has been the lack of good, standards compliant ARM motherboards - and by this I mainly mean *TX form factor. Random-slab-of-PCB form factor for the vast majority of ARM machines is a huge pain in the backside, as is a frequent lack of SATA ports for any more serious use. AMD's recent noise about the A1100 Opterons is welcome but the announcement was vastly premature - I spoke to them earlier this week and was told that the earliest these might be availble to developers is 2nd half of this year, which is not what you would expect after the announcement fanfare; call me old fashioned but when they talk about something the way they do I expect to be able to get my hands on one within a week or two at most.

Having said all that, there does seem to be one ARM offering that is head and shoulders above the rest in terms of standards compliance (*TX form factor, SATA), specification (4-core Freescale A9, 4GB of RAM) and cost (~£220 for the motherboard which includes the CPU, RAM and PSU, cheaper than comparable x86 Atom based offerings). To put the price into perspective, this is only about 2x the cost of a SheevaPlug, but has about 7x the CPU performance and 8x the RAM, plus the huge added *TX convenience. Best of all - you can buy one _today_. Google cornfed servers and you should be able to find it.

9
0

>, there does seem to be one ARM offering that is head and

> shoulders above the rest in terms of standards compliance

>. Best of all - you can buy one _today_. Google cornfed

> servers and you should be able to find it.

Looks a bit vapourware to me. Have you actually seen one? The website just shows a mini-ITX case and has a "contact us" web form.

FWIW, at this point I think it is probably worth waiting for ARMv8 (64 bit) devices. The future AMD offering may be the best bet.

0
0
Bronze badge

I spoke to them this week and my motherboard is in the post. Definitely not vaporware, unlike the AMD offering. Don't get me wrong - what AMD announced looks _great_. I would love a powerful 8-core ARM (as in, more powerful than Arndale) with 128GB of RAM (mock build everything on tmpfs!) to replace my build farm of Sheev/Guru/Dream Plugs. Unfortunately, I cannot wait for another 6 months for that to become available - I need to get my EL7 ARM build going at a decent pace _now_.

1
1

> my motherboard is in the post.

Well I hope it works out OK. How much did it cost?

If they ask for feedback, tell them that putting actual photos of the board and actual prices on their website would make it look much more believable.

(Not my downvote BTW)

0
0

assurance_not_vapourware

cornfed servers has been shipping our 4 core arm server since dec 2013 and demo'd apps at IT-EXPO in jan. its fully functioning and we have MB and case mounted servers available for developers. If we can help, get in touch at cornfed servers.

2
0
Bronze badge

I'll let Lew answer the exact cost part (I had no idea he was reading the reg forums :)). I had already mentioned that seeing a product without a price tag was offputting.

Thankfully, for once the lack of a pricetag does not equal to a lack of a product.

0
0
Anonymous Coward

And more importantly so is Windows - Windows Phone and Windows RT already run on ARM.

0
4
Bronze badge

Actually, the lack of a price on the website put me off, but I do have a project in mind for this type of solution, as Lew as taken the time to post here, I will take the time to fill in the enquiry form.

In general however if there is no price on a website I don't bother, too many follow up emails asking how can they help, blah, blah, blah.

4
0
Silver badge

And all of those custom LOB applications? Do you even have all of the source code? Do you have ARM compatible compilers that will take the code?

The OS and some standard packets are all well and good and simple applications, like file, print and web serving can probably be moved across relatively easily. But those bought in LOB solutions? What about the custom written LOB solutions? How much are they going to cost to get somebody in to recompile them and work out any issues and bugs that come along? Are all the third party libraries available in ARM versions?

I'm not saying it isn't possible, or that for standard needs it can't be done relatively easily, but you need to do a lot of investigative work and testing to get custom code transferred. The question is whether it is cost effective to do so? Or maybe wait until the next generation of the LOB tools needs to be written / bought in and go ARM then.

0
0
Silver badge

Is this a shill piece for VMWare and Intel?

Pretty much anything Linux runs fine on ARM. The whole of Ubuntu runs on ARM.

If you need anything else, it is pretty easy to achieve.

I've been writing Linux ARM stuff since about 2000 and being on ARM has never really held anything back. Heck, at one stage I even usesd a complete self-hosted developmnest set up with the compilers, editors etc running on ARM. Normally though cross compiling from a PC is faster and easier.

So tell the boss fine... porting to ARM is not a huge issue in itself.

19
3
Silver badge
Facepalm

Re: Charles Manning Re: Is this a shill piece for VMWare and Intel?

You really need to get that chip on your shoulder looked at.

5
11
Silver badge

I have a couple of little ARM machines handling DNS and DHCP, as a master/slave pair so that there's a bit of resilience. They'll stay up longer than anything else due to the light load on their battery backup, and come up before anything else. They also do local NTP services, polling a different set of servers out on the internet. Far more robust than using a large server, and more configurable than a typical consumer router.

6
0
Silver badge
Facepalm

Re: Number6

"I have a couple of little ARM machines handling DNS and DHCP, as a master/slave pair so that there's a bit of resilience...." TBH, so what? How long did it take you to hand-craft your solution compared to the ease of buying OTS MS components and an x64 serer (or, easier still, buying the processing power in the cloud)? I'm pretty sure it was ten years ago there was a complete website (full LAMPs stack) running on iPaqs that got a lot of geek attention, but it didn't make any business anywhere drop Xeon and MS Windows Server.

If anything is going to break the Wintel server monopoly it is going to be cloud offerings, where you don't give a fudge what is actually running the applications just as long as they do so reliably. And until they build clouds with real business apps on ARM it is still most likely to be an x64 cloud.

2
3
Silver badge

Re: Number6

I see no need to use cloud services for what I do, half the fun is playing with it and learning how the stuff works. I've got another little ARM platformm running a 6to4 tunnel so my home network can do IPv6. I get to pay the electricity bill too, so a couple of little 5W boxes easily beats 100W+ of server ticking over, although I'll admit the room is a lot colder in winter now than it used to be when I had several big x86 machines running. As for handcrafting, that's all part of the learning process, and having done it once, the second one didn't take much time at all.

I would not use the little ARM platforms as-is for serious professional deployment - the lifetime of the SD cards used to boot is not good enough and they suffer bit rot. I've had to rebuild a few times, although once the base image is built, it's easy enough to create a new bootable SD card.

When it comes to using Windows servers, I'd have to pay for those, with Linux I can just throw together a new system to play with fairly qickly, no licence or activation hassles and no multiple reboots as it's patched from install state to latest release. It was hard at first, but now I'm up the learning curve and it's relatively straightforward. Perhaps if I was paid to do it I'd think differently.

3
0
Bronze badge

Re: Number6

I'd just like to point out there are several ARM boards available with SATA ports, including the recent SheevaPlug, GuruPlug and DreamPlug, TonidoPlug2, CompuLab SBC-A510, Cornfed i.MXQ board, Higher end SolidRun CuBox-is, TrimSlice (note: it's SATA port is actually running via a built in USB->SATA adapter because CompuLab couldn't get PCIe SATA working properly for some reason on Tegra2) just off the top of my head.

On the point of how long it takes - I'm pretty sure it would take me substantially less time to set up a DreamPlug with Linux from scratch to act as a DHCP, DNS and NTP server that it would take to install Windows Server and configure the services on an even remotely similarly specced Atom machine. The process for the DreamPlug would be:

1) Extract rootfs to disk (one-liner)

2) Copy modules/firmware to rootfs and the kernel/initrd to bootfs (2 lines)

3) Configure uboot to tell it where to get the kernel from and tell the kernel where the rootfs is (2 lines)

4) Reboot into new OS

5) yum install dhcpd bind bind-utils ntp ntpdate

6) dhcpd would need 3-4 lines in the config to tell it IP ranges DNS and gateway to serve plus any specifics for more fancy things, e.g. assigning specific IPs to specific MACs. NTP should need no extra configuration, and Bind comes configured by default to act as a caching name server.

All of that would take little more time than it did to type this message.

2
0
Bronze badge

Managed code

Chances are your server code is written in an interpreted language anyway. Java, .NET, PHP, Ruby - as long as there's an engine your apps should just work.

9
0
Silver badge

Hand is up

A decade ago, ARM was big endian, which caused a small hiccup (See man 3 htobe64 for the solution). ARM is big endian now, so the problem has evaporated. There was some hassle when x86 became AMD_64, (see man stdint.h). Sometimes this showed up again when porting AMD_64 back to ARM (See man inttypes.h).

Porting to ARM has been trivial before, and will be even easier for 64-bit ARMs. Been there. Done that. Didn't bother to get a T-shirt.

3
2
FAIL

Re: Hand is up

ARM can do both endians, but it is usually run in little endian mode just like x86.

4
0
Silver badge

Re: Hand is up

If your application only works on machines of a particular endian - it is broken, full stop, no excuses.

It is not hard to make applications work on machines of different: endian or word lengths.

4
2
Silver badge

Re: Hand is up

It depends on how much assembler you are using...

0
0
Silver badge

Re: Hand is up

Early this century, pppd gave me some hassle because back then it had some little endian only code. Endianness shows up whenever multi-byte values go over a network, get stored on disk or are sent to some hardware. As I have been doing embedded systems for decades, I step around the pitfalls without thinking. I heard Microsoft had real problems with endianess because their file formats depended on where the C compiler placed values in a structure. If that is true, it would have hit them again for 64-bit machines, and if they ever meet an 8-bit CPU that does not benefit from padding out to word boundaries it will byte them again.)

(Endian typo - The last few ARMs I met were little endian only. Selectable endianness is fading into history.)

0
0
Silver badge

Windows

For those who mention that Linux already runs on ARM, I suspect VMware really mean "porting Windows apps"

3
0

Re: Windows

Why would anybody bother porting a Windows app to ARM? Is VMWare really that out of touch?

9
1
Silver badge

Re: Windows

Windows? Isn't that a client-side OS?

11
5
Anonymous Coward

Re: Windows

You may have missed it, but every company I've worked in uses Exchange, MS Office (which, even with Ribbon, is better than Libreoffice), and a whole host of other pretty platform-specific programs. Can you imagine the reaction if you went to a supplier and demanded they now create a Linux version of a diagnostic program for something they stopped building 10 years ago? They wouldnt do it, nor would you get hold of the source code for it.

Not to mention the obligatory poorly-understood internal systems for managing data that came about when a manager heard people yammering on about Databases and thought they were a good idea. Every business has them, and IT depts really dont do enough to give people the tools and knowlege to do this properly (and under the watchful eye of IT).

The first person to create a Linux-on-ARM compatible drop-in Exchange replacement will become a very rich person indeed. But to the best of my knowledge it hasnt happened yet.

4
15
Anonymous Coward

Re: Windows

"Windows? Isn't that a client-side OS?"

Presumably he meant "Windows Server".

1
0

Re: Windows

"The first person to create a Linux-on-ARM compatible drop-in Exchange replacement will become a very rich person indeed. But to the best of my knowledge it hasnt happened yet."

OpenChange ??

http://packages.debian.org/search?keywords=openchange

I see arm in the available architecture list....

Not, of course, that a few people will become rich on the back of this. But plenty will make a decent living, which is acceptable to me.

1
1
Silver badge

Re: Windows

I've used openxchange a few times over the years, but it is a pain to configure and still needs a lot of work. I haven't tried openchange.

0
0
Silver badge

Re: Windows

You mean porting windows apps that dont use VB.

0
0

Re: Windows

I've used Microsoft Exchange a few times over the years, but it is a pain to configure and still needs a lot of work.

The latest complaint from my users is that as soon as they change a new appointment to "all-day", it automagically changes the status from "busy" to "free". Which leads to appointments being put into peoples' holidays, unless they notice this and change it back again. Needless to say, googling reveals lots of moans about this and the inevitable "fix" that "fixes" an entirely different issue, nevertheless being flagged as the "answer" by some Microsoft forum moderator.

0
0

An ARM world would be nice, but...

Remember that porting on any scale would only happen if there's a strong economic reason to do so. We can have all the debates we like about the difficulty or otherwise of porting, but these days money wins.

Now, demonstrate a toolset that makes it equally easy (as in just a compiler option) to build on ARM as x86 and you might get the software houses on board. Persuade them to make their licensing platform agnostic, and you've got a non-argument for corporates when choosing their hardware. Demonstrate that the cost of acquisition is the same or lower as x86, that's another barrier down. Show that you can knock percentage points off of your operating costs, that's the money men on board.

And of course you'll do all of this on the sort of timescale that prevents Intel finally working out how to make the x86 run at really low power (not sure personally that's possible), thus removing your competitive advantage.

Don't have to like it, but you can't stick your fingers in your ears and go 'la-la-la' either...

4
4
Bronze badge
Happy

Re: An ARM world would be nice, but...

>Now, demonstrate a toolset that makes it equally easy (as in just a compiler option) to build on ARM as x86 and you might get the software houses on board.

Ever heard of cross-compiling ? I compile Windows apps on Linux, man ;-).

The thing that is great for ARM is that you already have a complete ecosystem, complete software stacks, OS' etc available on ARM thanks to the freetards. Linux and BSD's run on ARM, what more do you want ? This means the whole Internet infrastructure can be moved to ARM.

Maybe ARM will mean Windows will die off quicker than expected, Intel saved MS' lunch by increasing performance at regular intervals, but I doubt they will get Windows Server to run on ARM ... even ONE gui-less windows server install takes up 32Gb, I can have 10 Linux/Freebsd servers instead ... I know disk space is cheap, but still 10 times more ... Plus, when I calculate CALS, Server licenses, Exchange/SQL Server/whatever license etc I can even get support for the 10 servers for the same price as the one windows server.

Even Avaya claims Linux has a lower TCO than Windows, they are not exactly Linux-friendly as they do not provide client software for Linux.

9
1

Re: An ARM world would be nice, but...

LLVM?

Would be nice if someone implemented a "fat-elf" (dwarf is already taken) shared library/executable format that could store x86, x64, ARM 32 and ARM 64 all in a single file. Would actually be child's play. Then just package an LD which can link fat binaries generated by four cross compilers.

0
0
Bronze badge

Re: LLVM

This was discussed to some extent back when soft-float/hard-float issue on arm was being considered. In the end, the conclusion was that rather than coming up with a dynamic linker bodge that could handle both and rolling fat binaries that contained the payload for both, this taking up double the memory (or requiring awkward strapping that would purge the non-executable payload from memory after mmap()-ing it) it was more sensible to have a clean break. And you know what? This isn't such a big deal because the vast majority of software people run on ARM is FOSS.

The question is really why would you want a single hugely bloated executable that runs on multiple platforms? What problem does it solve that isn't much better solved by just having different binaries? You have to compile it once for each platform before gluing them all together anyway, so what does it actually gain you that shipping 4 different binaries (or a zip file, or shell archive containing all 4) wouldn't do just as well?

1
0

Database file compatibility

Now what would be interesting is a database with two sets of executables, one on ARM the other on x86 but can read the same datafiles.

During the day I might want to shunt my DBs off to a lower power farm running ARM.

So shutdown x86 VMs, start ARM VMs and attached to the same set of datafiles.

I don't believe that is supported by either Oracle or IBM.

In fact the only DB I know of that is certified to run on different CPU architectures using the same datafiles is SQLserver, on x86 or Itainium but who runs windows on Itanium these days?

0
3

Re: Database file compatibility

try MySQL

http://www.clusterdb.com/mysql-cluster/mysql-cluster-running-on-raspberry-pi

"who runs windows on Itanium these days?" Well, certainly no-one who wants to run Windows Server 2012 ;-)

3
0
Bronze badge

Re: Database file compatibility

@Fenton:

You can already do this with both MySQL and PostgreSQL. The on-disk formats and wire protocols are exactly the same, completely compatible, and endiannes independent. I do this sort of thing all the time.

4
0

High performance ARM

Is it not time we had a high performance ARM chip. In my scenario above of migrating from x86 for peak high performance load to off peak low perf requirements, if we had a 2 different ARM architectures, a nice lower power one and a 3.x GHz monster we could use Vmotion to move loads around.

Or just stick to x86 with xeons and Atoms.

Alas my apps only run on DB/oracle/SQLserver/Sybase

0
0
Bronze badge

Re: High performance ARM

@Fenton:

Have you heard of ARM's big.LITTLE achitecture? It gives you 4 Cortex A15 CPU cores and 4 Cortex A7 CPU cores. The A7 cores are a little less powerful, but a LOT less power hungry, so depending on the load the system is on, it will use one or the other set of cores (or all 8 cores on the recent Exynos CPU systems such as the Arndale board). So ARM already provides this kind of functionality on a single slab of silicon.

As for your apps - if they are based on closed, proprietary technologies you are indeed screwed, but that was always going to be the case, starting with the cheque you write to the vendor for the licences every year.

3
1

Re: High performance ARM

@Gordan

The apps arn't the problem, (ok they have not released an arm port yet), as they are OS/DB independent

just we are constrained on the DBs as the Vendor only supports "Enterprise class" DBs.

Oracle is such a pain in that you have to migrate to a new OS, even on the same CPU architecture. I'd rather just replace the exe's and just read the database files.

0
0
Bronze badge

Re: High performance ARM

It's funny you should say that Vendor only supports "enterprise class" DBs, and then you mention Oracle - when Oracle now owns MySQL. Oracle DBs don't even feature in the top 10% of biggest databases by size or throughput I have seen in the field, every one of those has been MySQL. Oracle is down there in the noise with PostgreSQL. I'm not saying that PostgreSQL isn't as good a database - far from it; I'm merely saying it doesn't seem to be as popular.

0
0
Anonymous Coward

Re: High performance ARM

"biggest databases by size or throughput I have seen in the field, every one of those has been MySQL."

Probably because they couldn't afford the licensing fees for the real thing. Big databases usually run on Oracle (top by revenue) or SQL Server (Top by volume) these days. MySQL is mostly a cheap toy for running web sites. Sure it has some niche uses, but nothing even remotely approaching Oracle and Microsoft SQL.

3
1
Bronze badge

Re: High performance ARM

@AC

How are you meaningfully comparing revenue in a meaningful way between Oracle and a FOSS package?

Also how are you comparing the "volume" between MS SQL and a freely downloadable FOSS database? If we are comparing the number of downloads of MySQL (and don't forget to include the distro ISOs rather than just the deb/rpm/tgz as well as summing the totals for MySQL, Percona and MariaDB) with the number of copies of MS SQL shipped/downloaded from MS I suspect that the "volume" of MySQL deployments is some orders of magnitude bigger than MS SQL.

If you are going to compare statistics then make sure those statistics are meaningful in the context of all the items in the comparison.

0
1

We ported from whatever-it-was-hp-had-in-the-micro-xe to Risc and then to x86, why not to ARM?

With VMWares arguments we'd still be running that old HP-3000!

3
0
Silver badge
Boffin

Re: Volker Hett

"We ported from whatever-it-was-hp-had-in-the-micro-xe to Risc and then to x86, why not to ARM?....." In each of the migration cases you mention there was a compelling business case for moving which is, as yet, missing from ARM. Simply saying it uses less power is not going to sway a lot of developers to stump up the costs of porting their products off a platform (x86) that is still selling more than well enough (more than half of ALL the servers in the World in use in business are Wintel), and without the applicatiosn there will be no companies willing to bet on replacing x86 servers with ARM ones. Laugh all you like, but Balmer was very right when he said "developers, developer, developers", and for years MS and Intel have been making it very easy and profitable for application vendors to run their code on x86. Whilst the anti-MS fanbois will shriek and grind their teeth in denial, the fact is Linux has been available on x86 for donkey's years and has hardly made a dent in MS's share of the server market, so expecting it to magically usurp the Wintel beast with ARM is just being tragically naive and wishful.

What ARM really needs is a whole bunch of mainstream COTS applications to be announced as available on ARM-based servers. Until that happens it will remain in the webserving/VDI/HDI niche.

1
2
Anonymous Coward

Re: Volker Hett

"What ARM really needs is a whole bunch of mainstream COTS applications to be announced as available on ARM-based servers. "

Bearing in mind that 75% of servers run Windows Server, and that Microsoft already ported the current Windows Kernel and OS to ARM, yes the apps and an ARM server flavour edition of Windows are all that is needed to drive adoption. No one in enterprise cares about all these weird and wonderful Linux flavours that no one uses It needs to run Windows to be mass market. (Or SUSE / Redhat for Linux stuff)

2
3
Anonymous Coward

Re: "SUSE / Redhat for Linux stuff"

Fedora and OpenSUSE have both had ARM capability for select ARM64 hardware since late last year, and informal ARM capability for much longer than that, so you may not have to wait too long.

e.g. http://www.theregister.co.uk/2013/11/27/review_opensuse_13_1/

1
0
Bronze badge

Re: "SUSE / Redhat for Linux stuff"

Aarch64 has not been in any official Fedora build thus far. Last time I checked there were only preview developer builds because there were still a few important packages that were broken on aarch64 due to package and toolchain bugs.

GCC took quite a while (a year or two) after ARMv7 hardware was easily available before the hard-float support was working sufficiently well to be suitable for full distro building. It would not be surprised if ARMv8 support at toolchain level takes a similar length of time to become sufficiently stable after the easy general availability of hardware..

0
0

Page:

This topic is closed for new posts.