What if WS-* had worked out, figuring out CoreOS

Meta-data

Hello again, welcome to #6. It's Friday night, and most of time was spent talking with people, so this will be short. Today we have 20 subscribers, so we're +1. I'd love to hear what you like, dislike, your feedback, etc.: memo@cote.io.

See past newsletters in the archives, and, as always, see things as they come at Cote.io and @cote.

Sponsor

I mentioned a few newsletters back that my work, 451 Research, is having it's big cloud conferences this Fall, Oct. 6th to 8th. I'll have a session or two on developer relations and marketing, and other analysts will be talking about their area. Anyhow, if you're interested, I have a discount code you can use: go to the registration page, and enter the code MC200 to get $200 off the registration price.

Follow-up

I got two pieces of follow-up, which were nice. One was that my marginalia on CA's quarterly call was timely; it also included a nice summary of the key take-aways which were spot on. I'd still like to find a way to better display the CriticMarkup I was doing there so I can start doing this kind of commentary regularly and not have it be a weird HTML file somewhere.

Second, over some beef ribs, I talked with one of you about the rational for doing a newsletter. As ever, the best piece of input was to be briefer, even to pick less things to list, even pick just one. Fair enough, that doesn't seem to bad.

Tech & Work World

Under Development episode #008

Today's episode of the Under Development podcast goes over building teams and microservices. Bill and I talk through some interesting business benefits for microservices. While eating beef ribs today, it also occurred to me that the architectural style may be an enabler for things like internal "cloud brokers." Just imagine if WS-* actually worked and was efficient, and what kind of opportunities that would open up for more coding inside of companies.

CoreOS

I had a briefing with CoreOS awhile back, right before they announced their first round of funding. I've been working on a report write-up and have been spending most of my time trying understand and explain exactly what it does. This interview on the CenturyLink Labs podcast is one of the better overviews. So far, my summary is along the lines of:

CoreOS should be looked at as re-imaging what a Linux distribution is with large service and cloud providers in mind. It is not targeted at desktops, small collections of servers, or embedded devices. Instead, the creators with their background from Rackspace are building an OS that fits the needs for managing cloud-scale clusters of servers. As such, there are many moves taken that seek to remove much of the "infinite reconfigurability" on a server level in favor of the efficiencies of homogeneity providers require at scale. When dealing with 10,000's of thousands of servers, to seek profits through operational efficiency, you're free to pick any color as long its black.

To do that, CoreOS first strips away some extraneous packages (like GUIs), instead focusing on a "minimal install." Next, CoreOS bundles some key components to have a more crowd friendly like way of accessing server configuration: instead of flat files in the /etc directory, you use HTTP-based API calls to /etcd to store and retrieve configuration for your fleets of nodes.

Speaking of fleets, CoreOS also has a component called "fleet" to manage the placement of workloads across CoreOS clusters and otherwise do the job of a "scheduler," like redeploying workloads that have failed.

CoreOS also uses systemd, which while now more widely used (by Ubuntu and Red Hat, for example) is still thought of as a new approach to managing the startup and boot-strapping of Linux OSes. Systemd also gives CoreOS much more control over containerization and resource management.

For containers, CoreOS bundles and uses Docker for container management, again targeting at the efficiency needs of cloud and service providers rather than the "heavy weight" virtualization needs of traditional enterprise Linux users.

With its original focus on easy updates, CoreOS also speeds up the refresh process by maintain a two partitions by node, an active one that's the current running system and a passive partition that's used for updates. The passive partition is updated, and when it's time to update, the active partition is shut down, and the passive is booted up, becoming active. This allows for faster boot-times, but also requires architecting for more stateless systems, much like put forward by the 12 factor architecture patterns for microservices. This fast and easy updating is core to delivering on the early goal of securing Linux.

That's a first pass after sorting through the fog. I haven't gone to verify and fact check all that, so who knows if it's right?

I never really liked Linux stuff, you know, so it's interesting to look at a "re-imagining" of Linux through fresh eyes, the creators of CoreOS. To put it one way, they seem like web-natives who are trying to bring that thinking to Linux. Hence all the fuss between the shell-script init crowd and the API-loving systemd folks...I think.

I'd be curious to see your explanation of CoreOS, dear readers, or know if you've poked around at it, or actually used it.