Our latest data says production use of containers has doubled from 10.2% to 22.5% of orgs between Q1 and Q3 2015. Amazing.
Tweeted by Donnie.
Our latest data says production use of containers has doubled from 10.2% to 22.5% of orgs between Q1 and Q3 2015. Amazing.
Tweeted by Donnie.
I was asked to be on a panel for the first Docker Austin meetup of the year, tonight, Jan 7th at 6pm. Here’s some slides I put together in my capacity as “person who used to put together slides like this and is trying really hard not to do his job pitching Pivotal to avoid being rude” (well, except for a shameless plug or two):
See ya there!
Update: I’d wanted to put a TAM in – the money Docker and containers are going after, this from Gartner:
While matching it to virtualization is a poor match (you’d probably also need some systems management and maybe even appdev numbers in there), I think looking at the current x86 virtualization TAM is as good as you’re going to get with a conservative approach.
My reasoning is that if “the market” is willing to pay this much for virtualization now, that’s the kind of foot-print and allocation we should start looking at for “containers” (over more of a 10 year time span, probably).
For this kind of hand-wavey, way future looking TAM’ing, what’s a plus or minus a billion or so anyhow?
“[I think Docker doesn’t] know where their portfolio ends. ‘Well someday we might want to build a whole exact replica of Cloud Foundry, so let’s just keep our safe distance.'” –James Watters on asking to partner with Docker.
As I mention below, I’ve had more time to write reports recently. I just submitted one titled “Docker: floor-wax or dessert topping? Reflections on DockerCon EU”. It’s one of our “spotlight” pieces, which means it’s an open-ended think-piece rather than a write-up of a briefing.
Here’s some excerpts:
451 Take: The container technology Docker and the ecosystem around it is figuring out its identity while at the same time contending with a sudden rise in popularity. While early attention on Docker paired it up against the likes of VMware at, let’s say, the IaaS level, as we look at it more, Docker looks like more of a PaaS innovator. VMware would certainly like that option, and Docker, Inc. spent much of its recent conference in Amsterdam talking more about Docker-as-PaaS – through the lens of “microservices” – than Docker-as-IaaS. From this vantage point, it looks more and more like dotCloud never really stopped being a PaaS vendor, and instead, with under its new name of Docker is just evolving the nature of PaaS.
The technology promises at least two things: (1.) an alternative way of virtualizing workloads on servers using the underlying containerization technology and (2.) a DevOps friendly way of packaging applications for deployment on cloud and cloud-like infrastructures. Much of the vendor sports watchers fixate onto the first use-case, looking to thrust Docker into a Thunderdome with VMware. However, as both Dockers – the open source project and the startup – have evolved, it’s becoming clear that the second is perhaps the more interesting promise, long-term.
Over the next 12 to 18 months, expect to see much shuffling and toe-stomping on the ecosystem dance floor. Indeed, with so many interests, large and small involved, it wouldn’t be surprising if the landscape changed dramatically over the next year. Early moves like the Rocket container standard effort point towards conflicting (or at least “differing”) interests, and with deep larders and large revenue sources to protect behind many, large Docker ecosystem member’s backs, anything could happen with something as miraculous as a floor wax that also makes butter-scotch pudding taste so terrific.
One of the ongoing theories I hit on in the piece is that (a.) cloud is all about developers, but, (b.) the PaaS market is small compared to others, so, (c.) what up with that? As you can imagine, I posit that the interest in Docker-cum-containers could change the market-dynamics a bit. We’ll see.
I’ll throw a link in here and all the usual places once it gets published, I’m guessing next week. I put in three or four charts too, so look forward to them if you like charts.
(Lucky[?] for you, this is the only place you’ll see the silly dessert topping floor-wax reference as the copy desk asked me to take that out since another analyst used it recently.)
I’ll let you in on a secret: I don’t really pay attention to my main timeline in Twitter. There’s too much crap in there that I’ve ended up following (1,910 account, to be exact) since I started using Twitter in 2006.
Sometime ago, I created a list called “Focus” that I actually follow. It has just 127 accounts in it and it works well. There’s some tricks of how to do this depending on which client you use. I can stand the official Twitter web and iOS (actually, I haven’t looked at it in awhile) apps so I use TweetDeck on my desktop and TweetBot on my phone. In both instances, you can choose to focus on a list.
In TweetDeck, it’s easy: you just move the column over that you want. You’ll notice in the below that my “timeline” is nowhere to be seen:
In TweetBot, it’s a bit more hidden, you have to “long tap” (is that what you call it?) on the title bar until it pops up a list of lists, then select the one you want. You can see what it looks like after I long-tapped on the title bar:
Sometimes I go slightly insane and think there’s not enough from Twitter. Recently, I thought I’d take a look at the timeline and see what was in it, what was going on. It’s a fun walk down memory lane as I discover clusters of accounts I’ve added over the year. I found a bunch from when I thought I didn’t get enough local and “real-world” news so I have/had several Austin accounts and things like Meet the Press. There’s also folks from long ago in there that I vaguely remember. And, going in and out of the analyst world, there’s also a lot of people who are or were clients at RedMonk and 451 Research. Lots of IBM. Lots.
I’ve been pruning that main timeline this week in the hopes of perhaps actually using it. I’m not sure it’s worth it, but it a good distraction-as-entertainment.
Open source foundations, thenewstack.io podcast – last week we talked about the Cloud Foundry Foundation and I ended up comparing them to other OSS foundations. It was fun!
The IBM Design Language, on the Under Development Podcast – also in podcast land, Bill and I discuss IBM’s recent design language guide.
Investment Firm: Amazon Will Spin Off AWS In 2015 – file under crazy. Well, I guess IBM did sell off x86. Hrm.
AOL keyword: Craigslist – over the years all us nerds have observed how Facebook finally cracked getting “normals” to use the web. Sometimes I have to chide my wife to get off her phone and talk to me; this is an odd reversal. Worrying about the “walled garden” that is Facebook is long over, it’s a moot point as that model is accepted. If Facebook gets into the eBay/Craigslist market (which is an excellent idea!), well, that’s a big deal. My wife is also a huge fan of Nextdoor, which would make a logical thing for Facebook to buy if their M&A engine wasn’t robot obsessed. Maybe they’re “leap-frogging” with robots, but, really, I think there’s plenty of work to be done just improving everyday life. They could fix calendars. They could make it easier and securer (and less gross) to sell things to each other (the link here, friend). All sorts of things they could do other than robots. But, hey, what does a meat-sack like me know?
Delicious 7 Layer DIP (DevOps Infrastructure Provisioning) model with graphic! – don’t call it reinventing the wheel, I been here for years. More seriously, I love seeing these analysises (call up Oxford, insert a net word!) of what’s needed for cloud and DevOps-y frameworks. It’s good stuff.
No fun today, just work.
I mentioned the Software Defined Talk recording last week, the episode is up for those who were waiting.
At DockerCon EU – turns out I’ll be at the Amsterdam DocerCon the first week of Dec, just for a day and half, though. If you’re there, it’d be fun to meetup. I’ll have been traveling all of that week, so you can see my brain turned to mush!
Netcraft: DigitalOcean Now Third-Largest Cloud – measurements like these are always weird, but the point is still there: DigitalOcean is on mega-growth, them developers like it.
Apple Pay grabs 50% of McDonald’s tap-to-pay transactions, gives retailers hope for future of mobile payments – I’ve been using Apple Pay when possible. Since you can use it where NFC is accepted, this means it works in taxi cabs, random stores, etc. I tried it at our local mega-grocery chain HEB the other day and it didn’t take. What I find most annoying about the interface is how little feedback there is: I’d like to hold the phone close to the terminal and have it tell me things like “working” or “can’t find it.” I often find myself holding my phone up to a terminal and just sort of waiting for something…or nothing to happen. Yup. First world problems.
The problems with “large, complex projects” in the enterprise – some nice visualizations in this all too brief post.
Why Entrepreneurs Should Be Respected More Than Loved – “leadership” and “management” are exhausting, no matter how many tips and such you get.
EclipseCon 2015 – Register Now – I used to go to EclipseCon a lot when I was RedMonk, it’s always a fun conference, full of coders and lots of Europeans.
Lydia at Gartner: “AWS could be as much as 20% of all VMs, 10%+ of all OS instances, and well over 5x all other cloud IaaS providers put together.”
Podcasts are neither exploding nor dying – they’ve been steadily growing for a decade – file under “don’t call it a come back.” To be fair, awareness and desire are what’s needed. That would lead to good advertising rates in podcasts, injecting more money in there (I’d hope). I’m pretty sure the brand value of Squarespace amongst nerds is purely based on their multi-year podcasting carpet bombing. Igloo too. I’d have never come across those brands as much as I do if it weren’t for podcasts.
Oftentimes, I write a “script” for presentations. I never read it for the presentation (maybe I should!), but it helps me organize my thoughts and presentation. Here’s the one I used for the Docker orchestration webinar I did with CloudSoft last week:
[chart on DevOps delivery pipeline, old dto solutions DevOps pipeline]
I like to reduce things down to brutal simplicity. I have a lot going on in my work and personal life so I have to leave nuance for entertainment. To me, cloud is mostly about supporting custom written software, whether that’s for something like a SaaS (from social to ERP), consumer facing business applications (like online banking), or applications used by companies to help run their business. And what that means is creating a delivery pipeline that encompass all the phases of an applications life and automates each step as much as possible to reduce bottlenecks and increase throughput. You have to look at this pipeline as a mission critical process in your business: from development to production, it’s you’re factory, the thing that helps you make money…not just a cost center. You’re pushing out incrementally improving software that runs your business.
Custom written software is the most valuable work-load for cloud, I’d theorize, where value is rated by how technology can help a company get competitive differentiation.
So, something like Docker is especially interesting because it promises to speed up that pipeline. I don’t think anyone know exactly what it will shape up to be, but it looks like the “private PaaS” answer we’ve all be looking for.
[chart with SaaS, PaaS, ISaaS, IaaS market-sizing – put OpenStack market-sizing in there next to it]
Now, PaaS is an odd category of public cloud. It seems like the perfect realization of the efficiencies of cloud, and yet it keeps limping along as a market as this 451 market-sizing shows.
Much of that revenue comes from Salesforce which has its own Force.com platform (a “PaaS for SaaS” as we call it) and Heroku.
[chart on demand for private cloud]
For some reason, developers and companies have a lust for build your own cloud: they either get their own gear or rent raw IaaS and build up their own stacks to support as automated as a DevOps delivery pipeline as possible. Maybe it’s cost (I haven’t ever heard a developer say public PaaSes like Heroku are cheap), maybe it’s the need to exactly customize functionality, maybe it’s good old paranoia and FUD (which could be justified, who knows).
Whatever the case, people want control over their stacks, and that’s where things get interesting. The more control you have, the more you have to worry about the more hassle there is.
We seem to have a long way to go to replicate the magical, effortless push to deploy demo we remember from early public PaaS days. Much of what’s needed is what’s currently going under the title of “orchestration” which, roughly, means “making sure my complex distributed system is installed and configured properly…and then allowing me to modify its runtime characteristics and upgrade it.” You know, getting the application up and running, tuning its performance ongoing as needed, and upgrading it.
[insert chart showing rise of new automation tools/brands]
This area has long been the domain of custom shell scripts, manual configuration, and, thankfully, in recent years configuration management companies like Chef and Puppet (who are taking over the automation reigns from OpsWare and Bladelogic).
Docker has burst on to the scene of late as an interesting salve for cloud infrastructure woes. To me, it starts with the right goals: make using cloud easier for developers. That may seem subtle, but it’s different than most infrastructure software goals which is make like easier for sysadmins and auditors.
To keep pushing on the dream of being able to build your own PaaS, the ad hoc community around all of this has been obsessing about orchestration of Docker-based clouds, let’s call them, of late. So let’s look at that.
When it comes Docker orchestration, there are almost too many projects to count, and even a few products. I love this mindmap from Krishnan that shows just full this market is – and tedious for analyst to keep up with. This is a good sign, however: there’s so much interest and passion in figuring out Docker and how to orchestrate it that surely, something will work.
When I look across what all of these projects are trying to do – and slap in some old IT Service Management think – I come up a list of requirements for orchestration. Some of them may seem obvious, but it’s always good to be explicit. If you spot ones that are wrong, or missing, you should pass them along and perhaps we can winnow down a list. We don’t need a manifesto or any nonsense like that, but in studying this space, you do find a distinct lack of architectural-level specifications and requirements – which is fine, people are busy coding.
Basic CRUD – creating nodes, updating nodes, restarting them as needed. You want more than just modeling what a node looks like, you want you orchestrator to actually do something.
Separating configuration from basic state – easily modify configuration without having to change too much about each node/image, like changing port numbers easily without rebuilding the entire node
Ensure proper configuration passing across nodes – passing server names and ports to servers, handing out credentials, wiring in service directories, etc.
Asset database to track all your cows – another ITSM trick. this starts getting into “enterprise” needs, but it handy even if aren’t tweedy. You need to know what you have out in the wild and quickly locate it when things go wrong.
Capacity management and adjustment of resources – not only monitoring if you’re over (or under!) capacity, but actually going back to your CRUD operations to make adjustments on your nodes. This is also where keeping configuration separate from node state is handy: you could increase memory, keeping the same configuration, for example, without having to rebuild or swap out nodes.
This last point is key. You need to remember that once you’ve done all the above, that’s when the difficult work begins. You still need to come up with an idea for an actual application and its features that will help your business. You need to stop orchestrating and start coding, not to mention working on the product management that will tell you what to code in the first place. Don’t get all caught up in all this Heathkit stuff: save your cycles for the most valuable thing: ABC.
[Always be coding chart]
And with that, I want to pass it over to CloudSoft to tell you how they’re helping you get closing to coding.
No fun today, just work.