Slashdot Mirror
AWS Releases Amazon Linux Container Image For Use in On-Premises Data Centers (venturebeat.com)
Amazon Web Services, a division of Amazon that offers cloud computing and storage services, has released a container image of its Amazon Linux operating system -- which has, until now, only been accessible on AWS virtual machine instances -- that customers can now deploy on their own servers. From a report on VentureBeat: Of course, other Linux distributions are available for use in companies' on-premises data centers -- CentOS, CoreOS, Red Hat Enterprise Linux, Canonical's Ubuntu, and so on. Now companies that are used to Amazon Linux in the cloud can work with it on-premises, too. It's available from AWS' EC2 Container Registry. Amazon Linux is not currently available for instant deployment on other public clouds, whether Oracle's, Google's, Microsoft's, or IBM's. "It is built from the same source code and packages as the AMI and will give you a smooth path to container adoption," AWS chief evangelist Jeff Barr wrote in a blog post. "You can use it as-is or as the basis for your own images."
I heard you like to virtualize your computers, so here's a virtual image to put on your physical hosts, so you can insource while you outsource.
In my limited experience with Amazon Linux on an EC2 VPS at work, it has felt essentially the same as any other RPM distribution. What's the big difference between this and CentOS?
I'm doing lots of work with the other Seattle-based cloud provider's tools, and this seems like it's designed to start the ball rolling on an Azure Stack style deployment model. For those who don't know, Microsoft is going to release an "offline Azure" for on premises use, that uses the same provisioning model, management interface, etc. I think the idea is to at least lock in the companies that don't want to or can't use the public cloud for computing. They're also getting much better at pitching Azure and Azure Stack to "IT Pros" (read: not developers) and writing documentation from their perspective as well. I do think they're going to end up being another IBM just based on the utility computing model they're pushing.
In the AWS case, I'm sure the idea is to get admins and developers used to doing things the AWS way, so that VM images can be moved seamlessly in and out of AWS. With both AWS and Azure, one key to adoption and eventual lock-in is getting the IT side of the house on board. "DevOps Ninjas" working for the latest round of startups may be getting the most press, but traditional IT is slowly coming around this way too, maybe not as freewheeling and crazy as a startup, but certainly interested in the public cloud. Just like when Microsoft, IBM, Sun, etc. spent the resources to make sure a whole fleet of sysadmins were trained on their way of doing things, Amazon and Microsoft are doing the same thing with the cloud.
So this is apparently RPM-based... I assume, then, that we can use yum to keep a VM based on this local image up to date? Does Amazon maintain its own repositories?
#DeleteChrome
I've been using the aws-compat library on Centos for our development systems. It's been ideal and I don't think we'll change. It mimics random I/O problems and occasionally deletes entire servers, just like in AWS. We do a complete run through for every iteration.
That said, in day to day use I do use netstat and ifconfig more often. ip often feels clunky to me, and has imho even worse manpages than ifconfig for out of the norm settings. That said, ip can handle the workload of a number of other tools and probably simplifies the backend work since it can handle lots of protocols in the same place, rather than spreading that work across multiple projects as in the ifconfig/netstat/etc case.
ss I personally haven't had reason to use, although some of its features have sounded useful in the situations that would warrant it.
That said: systemd I haven't found a need for yet, and given the restrictions on kernel versions it operates with, and the fun crashes you can get if your version happens to fail in a cornercase, I would much rather use a 'dumb' init, and a bunch of services, some of which MIGHT fail, so I can get to a console and fix it, rather than use systemd and have it decide to cause a panic, or hang, or demand I use a half baked emergency console that turns out to not have the modules I need to repair my system (yes, that has happened to me on binary distro systems!)
To simplify. AWS Linux try to be an "stable" rpm distro like CentOS 7, with the latest packages, but more closer to a rolling release model, something that Ubuntu discussed years ago and decided not to go. The problem with this work is that is flawed. Many people in AWS, updates ec2 images for their apps, and deploy their images in prod, and work previously in dev/stage/qa before and from this produce this images. And in Databases, AWS gives you more advantages with RDS, SimpleDB and DynamoDB cloud database services instead of you deploy database in ec2. To me is a way to compete against Canonical because inside AWS-EC2 you are going to find more instances deployed with Ubuntu LTS than with Amazon Linux, you can check this here: http://www.zdnet.com/article/u... http://thecloudmarket.com/stat...
"Premise" is an idea; "premises" is a place.