Steve Singh will become Docker’s new CEO(blog.docker.com)
blog.docker.com
Steve Singh will become Docker’s new CEO
https://blog.docker.com/2017/05/introducing-docker-new-ceo/
128 comments
It's a shame when software companies follow the path of handing over the CEO role to ever less technical people until the CEO barely knows what the company does. I always admire the companies that can avoid that path.
The alternative is to stubbornly hang on to a technical CEO until the CEO barely knows what the company does. I have a hard time admiring CEOs who carry contempt for most of their employees.
The thing about Docker is that the target audience has a technical background. Bob and Joe Accounting has no need for Docker, but Google does, HPC users do, Amazon does, etc. If the CEO doesn't even know how the product works or what it does, that's fine if you're selling iPads to school superintendents, but not so fine if even your customers are likely to know more than you.
Not to insinuate that Singh doesn't understand the product. I'm sure he does, to an appreciable extent. But this isn't just a technical product, it's a technical product that pretty much only other technical people are going to be interested in. You say that holding on to a technical CEO will lead to contempt for the nontechnical employees of the company, I say that even the nontechnical employees of the company (project managers, account execs, salespeople) will need to have technical backgrounds anyway
Not to insinuate that Singh doesn't understand the product. I'm sure he does, to an appreciable extent. But this isn't just a technical product, it's a technical product that pretty much only other technical people are going to be interested in. You say that holding on to a technical CEO will lead to contempt for the nontechnical employees of the company, I say that even the nontechnical employees of the company (project managers, account execs, salespeople) will need to have technical backgrounds anyway
Not that I'm anybody to say so, but I think it's worth posting a friendly reminder that Solomon is a beneficial HN contributor here in good standing (shykes), and will likely read the remarks we post here at some point.
I see some of the posts trending towards vitriolic here, but it's worth remembering that CEO or not, he's one of us, and deserves to be treated as well as any other member of the community.
Personally, I would like to extend my thanks to him for creating dotCloud (which I still miss, and preferred to Heroku for a variety of reasons), extending that into Docker, and for having been a hell of a nice guy all along the way.
I see some of the posts trending towards vitriolic here, but it's worth remembering that CEO or not, he's one of us, and deserves to be treated as well as any other member of the community.
Personally, I would like to extend my thanks to him for creating dotCloud (which I still miss, and preferred to Heroku for a variety of reasons), extending that into Docker, and for having been a hell of a nice guy all along the way.
Thank you Barry, I appreciate this message more than you know.
Steve is an incredible human being, and a founder who took his company from zero to market dominance - Billion+ revenue and still growing fast. He persisted through 20 years of ups and downs to get there, and created a culture where people look out for each other and stay for the long run (average tenure is almost 15 years).
For a founder like me he's the ultimate role model, it's a privilege to be able to work with him and scale Docker together.
Steve is an incredible human being, and a founder who took his company from zero to market dominance - Billion+ revenue and still growing fast. He persisted through 20 years of ups and downs to get there, and created a culture where people look out for each other and stay for the long run (average tenure is almost 15 years).
For a founder like me he's the ultimate role model, it's a privilege to be able to work with him and scale Docker together.
This is a company we're talking about here, not an individual. That is true even if an individual of our group envisioned an important technology. Pulling punches, as it appears that you are asking us to do, is irrational, especially given this latest move is likely to take the company public. I think it's important to note that maybe investments like this in infrastructure are not so great for users or the Internet as a whole, given company's objectives (especially public ones) has always been to dictate how technology makes revenue and how people must conduct themselves when using that technology.
I think it's important we see all sides of it and if Docker happens to be controversial, well, that's their problem to solve, not ours. That's why they get the big bucks and we get to sit here and say what we want about it, at least for the present moment.
I would note that you have just as much right to say what you think here as anyone else, and saying otherwise is "speaking" for us as a group. I appreciate your comment and your presence here in this group.
I think it's important we see all sides of it and if Docker happens to be controversial, well, that's their problem to solve, not ours. That's why they get the big bucks and we get to sit here and say what we want about it, at least for the present moment.
I would note that you have just as much right to say what you think here as anyone else, and saying otherwise is "speaking" for us as a group. I appreciate your comment and your presence here in this group.
> This is a company we're talking about here, not an individual
I'm not saying pull punches, I'm just saying maybe remember that we aren't talking about a faceless politician here, and that to many, Solomon is someone they've interacted with, and likely in a positive way.
Referring to the guidelines, I'm imploring us to "be civil" and "avoid gratuitous negativity".
> I appreciate [etc]
Thanks. :-)
I'm not saying pull punches, I'm just saying maybe remember that we aren't talking about a faceless politician here, and that to many, Solomon is someone they've interacted with, and likely in a positive way.
Referring to the guidelines, I'm imploring us to "be civil" and "avoid gratuitous negativity".
> I appreciate [etc]
Thanks. :-)
> remember that we aren't talking about a faceless politician here
Fair enough. I'd also say remember what Mark Twain said about politicians: “Politicians and diapers must be changed often, and for the same reason.”
Fair enough. I'd also say remember what Mark Twain said about politicians: “Politicians and diapers must be changed often, and for the same reason.”
There's no such thing as a faceless politician, they are human beings too.
I'm legitimately confused - has Solomon ever been CEO of Docker? I don't believe he is now. Why would extra sensitivity around Solomon be needed right now?
Why are you posting this? No one is attacking Solomon.
HN rules dictate one be civil, and if someone isn't being that you can flag their content. This is worse than a "why the downvotes" post, it's "pls be nice guyz i love Docker it great company".
Honestly, I think this is a really strange top post. It feels to me like this is an attempt at manipulating the discourse by providing social proof for Docker and by discrediting the posters that are unhappy about the direction Docker has been heading.
HN rules dictate one be civil, and if someone isn't being that you can flag their content. This is worse than a "why the downvotes" post, it's "pls be nice guyz i love Docker it great company".
Honestly, I think this is a really strange top post. It feels to me like this is an attempt at manipulating the discourse by providing social proof for Docker and by discrediting the posters that are unhappy about the direction Docker has been heading.
Nice. Maybe now they won't copy Apcera so closely.
Surprised there wasn't also the typical "want to spend time with family" part to cover the fact that the CEO was fired and a board seat was his consolation prize.
If you want to raise $180M without a business model to become a fabled unicorn, you had better know what you're doing.
Docker just got a lot less interesting with an ex-Concur exec in charge, but it'll probably exit within 2-3 years and make the investors happy.
If you want to raise $180M without a business model to become a fabled unicorn, you had better know what you're doing.
Docker just got a lot less interesting with an ex-Concur exec in charge, but it'll probably exit within 2-3 years and make the investors happy.
You think that a board seat (the group that the CEO reports to) is a consolation prize? That makes no sense at all.
It makes all the sense in the world when you realize how board's actually work.
Can you expand on that? I'm not familiar enough with how boards operate to understand what you mean.
Founders agree to all sorts of nefarious stuff they think will never be triggered to get to a signed term sheet. Investors will exercise this power when the incentives are misaligned with the founders (aka the company isn't doing well).
You've still not said anything about 'how boards work'.
The kinds of things I'm referring to is almost always around relinquishing power to the investors on the board. Founders end up with very little control even if they have board seats.
Guesses to who would acquire it? My money is on HP or Oracle.
The best for the customers would be to be acquired by Google, AWS or RedHat.
Then they can "replace" the docker name with something that works, earn revenues out of it and benefit from the synergy with their other products.
The issue is, Docker is not worth billions of dollars and these buyers are already en route to kill it with their own replacement.
Then they can "replace" the docker name with something that works, earn revenues out of it and benefit from the synergy with their other products.
The issue is, Docker is not worth billions of dollars and these buyers are already en route to kill it with their own replacement.
Nothing resound 'new' or 'modern' better than the word 'Docker'.
Get a look at https://aws.amazon.com/ecs/ and count how many times the word 'Docker' appears.
If someone buy them will be mostly for the name.
If someone buy them will be mostly for the name.
Would Google or Amazon be actually interested in buying Docker? Like you said, they'd rather make their own product which would happen to support docker features.
Exactly.
Intel
or IBM
RedHat
I highly doubt that given the history between both companies... But would be funny to force a docker dev to merge systemd pr's...
Definitely Red Hat. The relationships run deep and Golub already has a great relationship with Jim Whitehurst.
That maybe be the only reason to keep him on the board there.
That maybe be the only reason to keep him on the board there.
I don't think HP, but Oracle is definitely plausible in my view.
My money would be on SAP. Similar pattern to Nokia.
My kneejerk reaction is that a senior leader from Concur, then SAP, is going to buzzword bingo and "enterprisify" docker into something very different. That's probably not fair though. Concur is a pretty big success story, sold for $8B, and it appears some good decisions drove that.
>"enterprisify" docker into something very different. That's probably not fair though.
But that's actually the industry containers are good for. Enterprise. Predictability trumps costs. The flaws of docker may over time get fixed. It's the small companies and startups that are making a fool of themselves by pretending they extract any kind of value out of docker.
Imagine a large 100+ man software project that spans two years and involves four different organisations collaborating. There are at least 100+ non-technical 'knowledge workers' interacting with this process. The people have the intent of 'not being responsible for anything', but establishing their position/role so their cost/budget is validated. You know, the typical large-scale Oracle/Cap-Gemini/IBM clusterfuck of incompetence.
But that's the secret! They aren't incompetent at all (as organisations). They sell something no-one else sells. They sell predictability.
Because for all what it's worth: they don't make huge architectural fuck ups. They make their deadline. And they are able to deliver something, even with this many stakeholders pissing all over the project from any direction.
For them, docker is brilliant. It standardizes something. It doesn't do it very well, but that doesn't matter. They aren't in a low-margin world. "Docker isn't really secure, you really should run every docker image in a separate VM". Sure. These sort of people are paying 500-1000 per instance anyway. No one cares. Coordinating devops with this many stakeholders, now _thats_ expensive.
The quality of the actual technology (much like on the web itself) is initially irrelevant. The value is in the fact there's a contract. A standard. Docker is a bad implementation of reasonable idea. The question isn't if it's a good technical choice. No, it's not. But it's organisational and economically more compatible with the rest of world.
And you know what? At least those enterprise idiots will run JVM instances on their docker images, so if they need more than three servers it's not because they are incompetent (like every startup wasting their time on cloud orchestration stuff). At least when they pay the price in complexity for building something scalable it's because they actually need something scalable.
But that's actually the industry containers are good for. Enterprise. Predictability trumps costs. The flaws of docker may over time get fixed. It's the small companies and startups that are making a fool of themselves by pretending they extract any kind of value out of docker.
Imagine a large 100+ man software project that spans two years and involves four different organisations collaborating. There are at least 100+ non-technical 'knowledge workers' interacting with this process. The people have the intent of 'not being responsible for anything', but establishing their position/role so their cost/budget is validated. You know, the typical large-scale Oracle/Cap-Gemini/IBM clusterfuck of incompetence.
But that's the secret! They aren't incompetent at all (as organisations). They sell something no-one else sells. They sell predictability.
Because for all what it's worth: they don't make huge architectural fuck ups. They make their deadline. And they are able to deliver something, even with this many stakeholders pissing all over the project from any direction.
For them, docker is brilliant. It standardizes something. It doesn't do it very well, but that doesn't matter. They aren't in a low-margin world. "Docker isn't really secure, you really should run every docker image in a separate VM". Sure. These sort of people are paying 500-1000 per instance anyway. No one cares. Coordinating devops with this many stakeholders, now _thats_ expensive.
The quality of the actual technology (much like on the web itself) is initially irrelevant. The value is in the fact there's a contract. A standard. Docker is a bad implementation of reasonable idea. The question isn't if it's a good technical choice. No, it's not. But it's organisational and economically more compatible with the rest of world.
And you know what? At least those enterprise idiots will run JVM instances on their docker images, so if they need more than three servers it's not because they are incompetent (like every startup wasting their time on cloud orchestration stuff). At least when they pay the price in complexity for building something scalable it's because they actually need something scalable.
This is by far the best post about Docker I've ever seen.
We're a small company and so far we've never found a role for Docker. We just deploy stuff to VMs and bare metal servers with Chef. Docker is occasionally useful for testing and builds but that's about it.
But... the thought of coordinating the way we do things with 100+ developers working under layers of middle management is terrifying. Stuff would be breaking left and right. It would be a disaster.
For that we'd want a true zero-interdependency micro service type way of doing things where everyone's part is a different product and is deployed as a completely separate monolith.
For that Docker with all its warts and inefficiencies is an acceptable, standard solution. As you say it's not ideal or elegant but it works and people know it.
We're a small company and so far we've never found a role for Docker. We just deploy stuff to VMs and bare metal servers with Chef. Docker is occasionally useful for testing and builds but that's about it.
But... the thought of coordinating the way we do things with 100+ developers working under layers of middle management is terrifying. Stuff would be breaking left and right. It would be a disaster.
For that we'd want a true zero-interdependency micro service type way of doing things where everyone's part is a different product and is deployed as a completely separate monolith.
For that Docker with all its warts and inefficiencies is an acceptable, standard solution. As you say it's not ideal or elegant but it works and people know it.
Walking around the exhibit hall at DockerCon, and then trying to pick sessions, I couldn't help but feel that heading a small engineering team I was at the wrong conference.
Same at CloudNativeCon by the way. I went to the technical-sounding talks (as opposed to "success stories"), but most of them were just "observe as I upload a YAML file into Kubernetes and stuff happens".
Meanwhile, the booths were 50% "we can install Kubernetes for you" and 50% "we can do monitoring/logshipping for your Kubernetes", which is interesting given that the Kubernetes guys are working on solving the first issue and Prometheus/Grafana/Fluentd solve the second issue already.
Meanwhile, the booths were 50% "we can install Kubernetes for you" and 50% "we can do monitoring/logshipping for your Kubernetes", which is interesting given that the Kubernetes guys are working on solving the first issue and Prometheus/Grafana/Fluentd solve the second issue already.
2c from my experience.
Fluentd is a terrible log shipper: sub-second timestamping is not yet supported in the stable build, support is patchy in the plugin ecosystem in 0.14. There's also some humdingers buried in the source (Rational numbers for time arithmetic?) Abstractions leak all over the place. The plugin ecosystem is weak and the API shims in the minor version API break are poor and in my experience break semver.
Prometheus has the right idea, but I wouldn't want to be running and scaling my telemetry system if I'd also taken on the burden of running my own container scheduler. Whilst I've no doubt Prometheus can be made to scale, I'd rather somebody else made the federation decisions for me.
Fluentd is a terrible log shipper: sub-second timestamping is not yet supported in the stable build, support is patchy in the plugin ecosystem in 0.14. There's also some humdingers buried in the source (Rational numbers for time arithmetic?) Abstractions leak all over the place. The plugin ecosystem is weak and the API shims in the minor version API break are poor and in my experience break semver.
Prometheus has the right idea, but I wouldn't want to be running and scaling my telemetry system if I'd also taken on the burden of running my own container scheduler. Whilst I've no doubt Prometheus can be made to scale, I'd rather somebody else made the federation decisions for me.
Agreed. There was a remarkable difference between 2017 DockerCon and 2016. I felt right at place in 2016 but 2017... just missed the mark. Felt very much like all the session were geared toward "Introducing Docker" or "How to convince your manager about Docker".
Oh well :\
Oh well :\
Did you try any of the black belt track? It seems like that might have been a good fit for you.
One problem with the Austin convention center is that it's VERY spread out, so it's easy to miss an entire chunk of sessions because they're almost impossibly far if you don't know what you're looking for.
One problem with the Austin convention center is that it's VERY spread out, so it's easy to miss an entire chunk of sessions because they're almost impossibly far if you don't know what you're looking for.
I think the app and sessions guide did a pretty good job of informing about sessions, but I'll second the point about the layout of the Austin convention center. For those not in perfect health (I have a lung condition) it was a bit .. extreme. Probably the longest hikes of any conference I've ever been to.
If only more of us had managers that needed convincing to switch to Docker.
As this thread insinuates, Docker is a VC-driven fad that has been seized upon by posers as the next buzzword to plaster across their resume. I wish more engineering managers were willing to stand up to this nonsense.
As this thread insinuates, Docker is a VC-driven fad that has been seized upon by posers as the next buzzword to plaster across their resume. I wish more engineering managers were willing to stand up to this nonsense.
Docker has been targeting enterprise use cases for a good while now. Frankly, aside from in development, it's not terribly useful until you get to a certain scale which requires a certain development model (complete separation of application and storage, different teams managing different components, etc).
I mean, the whole rebrand is still a bit of a bait-and-switch. It leaves a real bad taste in my mouth and while I may not have been the biggest fan of Docker in the past, but I am certainly going to bias away from them now, rather than simply being indifferent.
Clever, though, to force your predecessor to do that bit of dirty work before you're announced.
That is already happening. They are going for the "build enterprise version then have partners sell it and consultants support it" model as their main revenue funnel. It's the only way that something like this can make money, and given the unbelievable amount of hype for the product right now, it's the smart thing to do IMO
Docker already tried to go the enterprise route but they're getting killed in the market.
The small number of enterprises that are doing containers are going to Kubernetes for technical credibility or Redhat OpenShift for enterprise credibility.
Instead of trying to be a platform company for the enterprise, Docker should have just licensed and supported the Docker engine to the mass market (their one moat) and absolutely cleaned up.
The small number of enterprises that are doing containers are going to Kubernetes for technical credibility or Redhat OpenShift for enterprise credibility.
Instead of trying to be a platform company for the enterprise, Docker should have just licensed and supported the Docker engine to the mass market (their one moat) and absolutely cleaned up.
>Docker should have just licensed and supported the Docker engine to the mass market (their one moat)
I give them a lot of credit for noticing that nobody else was capitalizing on the existing container tech. But it did exist already. They didn't invent something new. They just put a nice cli, daemon, and image repository around it. I think they know the "license the engine" bit is a non-starter, as the higher level container orchestration platforms are already abstracting away from it.[1]
[1]http://blog.kubernetes.io/2016/12/container-runtime-interfac...
I give them a lot of credit for noticing that nobody else was capitalizing on the existing container tech. But it did exist already. They didn't invent something new. They just put a nice cli, daemon, and image repository around it. I think they know the "license the engine" bit is a non-starter, as the higher level container orchestration platforms are already abstracting away from it.[1]
[1]http://blog.kubernetes.io/2016/12/container-runtime-interfac...
Now we finally know the real reason for the rebrand.
Docker is being used to cure diseases, keep planes in the air, to keep soldiers safe from landmines, to power the world’s largest financial networks and institutions
Why do this?
Why do this?
> keep planes in the air
'We really need to land, but the container responsible for landing navigation has crashed and I can't restart it because Docker complains that the endpoint is already registered on the overlay network'
'Just delete /var/lib/docker and re-pull.'
'We really need to land, but the container responsible for landing navigation has crashed and I can't restart it because Docker complains that the endpoint is already registered on the overlay network'
'Just delete /var/lib/docker and re-pull.'
There's that familiar chest pain again.
Rest assured! Docker will never be allowed inside a plane.
All plane software must be certified DO-178. For starters, that means 100% code coverage.
All plane software must be certified DO-178. For starters, that means 100% code coverage.
Jeez, everyone from Linus Torvalds to Intel to the freaking power company could take credit for these things. Maybe tone down the "we're saving the world" rhetoric, Docker?
It makes more sense in the context of the criticism that Docker gets. It's a counter to the inane "Docker isn't stable enough, Docker isn't secure enough, Docker isn't whatever enough to use in production" critique that some obstinate old ops person will throw up because they'd rather keep their job comfortable than try to accommodate a need beyond their own. I don't read it as Docker does all those things so much as Docker is used to do all those things and diseases are getting cured, planes aren't falling from the sky, soldiers aren't getting unnecessarily blown up and financial networks are only crumbling due to their own internal negligence. If it can be used in all those situations, it will probably work for your crappy pool-of-app-servers-on-top-of-a-database webapp.
> obstinate old ops person will throw up because they'd rather keep their job comfortable than try to accommodate a need beyond their own
Oh, come on. This is why I hate Docker. Right here. It's like a heat seeking missile that looks for the friction points between engineering and operations, then explodes in a fireball of "do we really need operations? They're just old and obstinate and in the way of progress," without even really stopping to ask what progress is from the perspective of operations.
Some of us like to think of legitimate technical reasons to push back on Docker in our own circumstances and deployments (some of us even read code to help make that determination), but I suppose your dichotomy would be fun to navigate for everyone involved. I've definitely been in environments where one side characterizes operational pushback as change reticence, which immediately personalizes the discussion. That's a tough environment in which to argue, especially when you're arguing with people who will not be on call for the crap they are trying to deliver to you.
The casual ageism in your comment is, sadly, expected. I'm growing accustomed to HN considering it acceptable to go after "old" and "operations" with equal vigor, which speaks more broadly to worrying trends in our industry. I'm 31 and have devoted my career to operations, and I already have an exit plan. That should say something about the industry, and I think this comment is a fine microcosm of that.
Oh, come on. This is why I hate Docker. Right here. It's like a heat seeking missile that looks for the friction points between engineering and operations, then explodes in a fireball of "do we really need operations? They're just old and obstinate and in the way of progress," without even really stopping to ask what progress is from the perspective of operations.
Some of us like to think of legitimate technical reasons to push back on Docker in our own circumstances and deployments (some of us even read code to help make that determination), but I suppose your dichotomy would be fun to navigate for everyone involved. I've definitely been in environments where one side characterizes operational pushback as change reticence, which immediately personalizes the discussion. That's a tough environment in which to argue, especially when you're arguing with people who will not be on call for the crap they are trying to deliver to you.
The casual ageism in your comment is, sadly, expected. I'm growing accustomed to HN considering it acceptable to go after "old" and "operations" with equal vigor, which speaks more broadly to worrying trends in our industry. I'm 31 and have devoted my career to operations, and I already have an exit plan. That should say something about the industry, and I think this comment is a fine microcosm of that.
For what it's worth, I'm older than you and started in ops. If it helps to put things into context, I spent a ton of 1997 using a chisel to shave a bit off standard RAM to help avoid Sun's near 10x markup. The startup I worked at was provisioning around 20 Sun boxes per week and we had to patch together tools to manage infrastructure of that size before off-the-shelf tooling to do that really existed. I wrote a lot of expect in 97-98.
Where I get frustrated with ops is when they forget that they're in the service business. They're there to serve application developers in the same way that the application developers are there to serve customers. An application developer pushing back at a customer ask with the line, "without really stopping to ask what progress is from the perspective of developers" would be rightly lampooned. And yet somehow there's people that think the ops mindset is reasonable. In my view, "no" is not a valid viewpoint. Application developers are telling you they want the kind of functionality that Docker offers. That makes it your job to figure out how that happens, not if it happens.
Where I get frustrated with ops is when they forget that they're in the service business. They're there to serve application developers in the same way that the application developers are there to serve customers. An application developer pushing back at a customer ask with the line, "without really stopping to ask what progress is from the perspective of developers" would be rightly lampooned. And yet somehow there's people that think the ops mindset is reasonable. In my view, "no" is not a valid viewpoint. Application developers are telling you they want the kind of functionality that Docker offers. That makes it your job to figure out how that happens, not if it happens.
Where I get frustrated with ops is when they forget that they're in the service business. They're there to serve application developers in the same way that the application developers are there to serve customers.
In my view, you've got that completely backwards. Both departments serve customers in a roundabout way. Dev is responsible for turning user stories (generated either by other devs, focus groups, and so forth - which may, but doesn't necessarily involve an actual paying customer) into code, ops is responsible for keeping that code running.
If dev screws up, user gets bugs, or the app goes down. Same for ops - it's just the class of bugs are different.
Application developers are telling you they want the kind of functionality that Docker offers. That makes it your job to figure out how that happens, not if it happens.
As long as me and my ops team are the primary people with skin in the game (read: getting 3AM wakeup calls), me and my team will maintain a say in what tech stack we're responsible for the care and feeding of. The dark days of dev throwing code over the wall to ops is long gone - I am gobsmacked that you'd suggest that this is for some reason improper.
What dev often forgets, and the cause of much strife, is this justification. If you want a team of n people to learn this new thing and its new ways of operating, then you need to do an honest, dispassionate cost/value analysis. And show your work, dammit. When this never happens, it conveys an "Oh great, Dev is on one of their 'Ooh, shiny!' kicks again" mentality to the rest of the team, especially those that aren't politically connected enough in the org to know any different. I know it's because you're busy and have insane deadlines to meet. Meanwhile, the phones ring at 3am, and the message is lost.
The result is a strained and adversarial relationship, often to the customer's detriment.
In my view, you've got that completely backwards. Both departments serve customers in a roundabout way. Dev is responsible for turning user stories (generated either by other devs, focus groups, and so forth - which may, but doesn't necessarily involve an actual paying customer) into code, ops is responsible for keeping that code running.
If dev screws up, user gets bugs, or the app goes down. Same for ops - it's just the class of bugs are different.
Application developers are telling you they want the kind of functionality that Docker offers. That makes it your job to figure out how that happens, not if it happens.
As long as me and my ops team are the primary people with skin in the game (read: getting 3AM wakeup calls), me and my team will maintain a say in what tech stack we're responsible for the care and feeding of. The dark days of dev throwing code over the wall to ops is long gone - I am gobsmacked that you'd suggest that this is for some reason improper.
What dev often forgets, and the cause of much strife, is this justification. If you want a team of n people to learn this new thing and its new ways of operating, then you need to do an honest, dispassionate cost/value analysis. And show your work, dammit. When this never happens, it conveys an "Oh great, Dev is on one of their 'Ooh, shiny!' kicks again" mentality to the rest of the team, especially those that aren't politically connected enough in the org to know any different. I know it's because you're busy and have insane deadlines to meet. Meanwhile, the phones ring at 3am, and the message is lost.
The result is a strained and adversarial relationship, often to the customer's detriment.
I work in IT, so not exactly the same, but I can relate so much to your pain. Teams are constantly bringing in some half-baked app that "Worked in the demo" and give us the registration key and a date to have it running by. Invariably it become the biggest headache for us, because it never works, fails at the worst times, etc. And when it doesn't work, who is the finger pointed at? The person who bought into it wholesale without any testing, or the team who's been working 60+ hours every week trying to string it up with paper clips and rubber bands?
That's exactly the same. Don't sell yourself short. You're doing operations with a different audience, and that type of behavior is just as common in external-facing operations. Hell, it doesn't even have to be an off-the-shelf product; I've been through that song and dance with in-house software.
> As long as me and my ops team are the primary people with skin in the game (read: getting 3AM wakeup calls), me and my team will maintain a say in what tech stack we're responsible for the care and feeding of. The days of dev throwing code over the wall to ops is long gone.
Here's where we're in violent agreement. I believe the best way to ensure that the pager doesn't go off at 2am is to give that duty to developers. Far and away the most likely reason for a production issue is new code that went live. No matter how good communication is within an organization, ops will never have the same context for issues like this that dev will. So dev being the tip of the spear with regard to incident response will result in faster resolution. The job of ops is to be an enabler of this responsibility. They should be building tooling and infrastructure that makes it easy for dev to do the right thing but doesn't force decisions on dev. Ops is an abstraction layer that gives developers higher-level primitives for infrastructure that allows them to solve the customer problems more easily.
But there's no substitute for the dual benefit that you get from a) oh...I wonder if this problem is related to that change I reviewed yesterday and b) hmm...I've got pager duty this weekend, so perhaps I shouldn't just LGTM this PR. And for that reason, developers and developers alone are responsible for a working application. Ops is only there for support.
Here's where we're in violent agreement. I believe the best way to ensure that the pager doesn't go off at 2am is to give that duty to developers. Far and away the most likely reason for a production issue is new code that went live. No matter how good communication is within an organization, ops will never have the same context for issues like this that dev will. So dev being the tip of the spear with regard to incident response will result in faster resolution. The job of ops is to be an enabler of this responsibility. They should be building tooling and infrastructure that makes it easy for dev to do the right thing but doesn't force decisions on dev. Ops is an abstraction layer that gives developers higher-level primitives for infrastructure that allows them to solve the customer problems more easily.
But there's no substitute for the dual benefit that you get from a) oh...I wonder if this problem is related to that change I reviewed yesterday and b) hmm...I've got pager duty this weekend, so perhaps I shouldn't just LGTM this PR. And for that reason, developers and developers alone are responsible for a working application. Ops is only there for support.
> Where I get frustrated with ops is when they forget that they're in the service business. They're there to serve application developers in the same way that the application developers are there to serve customers. An application developer pushing back at a customer ask with the line, "without really stopping to ask what progress is from the perspective of developers" would be rightly lampooned. And yet somehow there's people that think the ops mindset is reasonable. In my view, "no" is not a valid viewpoint. Application developers are telling you they want the kind of functionality that Docker offers. That makes it your job to figure out how that happens, not if it happens.
Nope, nope, nope, nope. I quoted this entire paragraph at length because it's all just completely wrong.
Read Site Reliability Engineering that Google just published for an alternative perspective. SRE at Google is specifically and vocally organized to have authority to push back on engineering. Without exception. "No" is absolutely a valid viewpoint, particularly when you're asking a team to go on call for your code. It's not you sleeping in the guest bedroom and fucking up a marriage, now is it? No, it's us. Let's reframe this: you are responsible for software. I am responsible for production, which happens to run your software along with, likely, a bunch of other things that you don't know about. You said in another comment that operations exists solely to abstract infrastructure for developer consumption, which is such a heavy marginalization of what we do that I'm amazed you even identify yourself as an operator of any kind.
I'm not saying this to be an impediment to you. Both our paychecks flow from the same mission. I just need the authority to push back when your decisions threaten production (especially when you don't understand why). It's contrived, but on one end of the spectrum, if you said let's rewrite the stack in ColdFusion, it's not my job to figure out how to enable you. It's my job to figure out how to keep the lights on, and defending that properly means investing absolutely zero in your ColdFusion rewrite. Escalate to my management if you choose; if it comes down to the ColdFusion rewrite or my continued leadership of operations, I'll go somewhere else. So the more you ask operators to be "yes people" for engineers, the more you end up with operations outsourced to Tata and Infosys -- who will say yes to everything you want. Have fun with that.
Seriously, operations will be the equivalent of COBOL consulting by 2030. Just wait. I'll hit my mid-40s, pull a Mikey Dickerson, and build a consultancy to swoop in and clean up the mess that you're creating by marginalizing operations as strongly as you are and laugh all the way to the bank.
Particularly in SRE, I'm a software engineer who happens to enjoy the plumbing that keeps your code running. I do not exist to serve at the pleasure of application developers, nor do I accept any imagery of my being inferior because I don't spend my days writing red/black trees to shave a few milliseconds off the news feed. I can, and have, do/done SRE without a single application developer customer, and I like to think of SRE as a little bit better than application engineering: you push to a repo and wait. I push Enter and 10,000 things happen instantly. Who's having more fun?
Tossing lame code over the fence is how to sow bad seeds with operations. That you've then had negative experiences with operations, enough to generalize us as a species (are you hitting sysadmins? ops? sysops? devops? hwops? netops? SRE?), is only a reinforcement for that to me. I would say between a combination of educated guessing based on your opinion, prior experience, and a few other inputs that it's pretty likely that your gripes with operations stem from flawed expectations on your part.
Nope, nope, nope, nope. I quoted this entire paragraph at length because it's all just completely wrong.
Read Site Reliability Engineering that Google just published for an alternative perspective. SRE at Google is specifically and vocally organized to have authority to push back on engineering. Without exception. "No" is absolutely a valid viewpoint, particularly when you're asking a team to go on call for your code. It's not you sleeping in the guest bedroom and fucking up a marriage, now is it? No, it's us. Let's reframe this: you are responsible for software. I am responsible for production, which happens to run your software along with, likely, a bunch of other things that you don't know about. You said in another comment that operations exists solely to abstract infrastructure for developer consumption, which is such a heavy marginalization of what we do that I'm amazed you even identify yourself as an operator of any kind.
I'm not saying this to be an impediment to you. Both our paychecks flow from the same mission. I just need the authority to push back when your decisions threaten production (especially when you don't understand why). It's contrived, but on one end of the spectrum, if you said let's rewrite the stack in ColdFusion, it's not my job to figure out how to enable you. It's my job to figure out how to keep the lights on, and defending that properly means investing absolutely zero in your ColdFusion rewrite. Escalate to my management if you choose; if it comes down to the ColdFusion rewrite or my continued leadership of operations, I'll go somewhere else. So the more you ask operators to be "yes people" for engineers, the more you end up with operations outsourced to Tata and Infosys -- who will say yes to everything you want. Have fun with that.
Seriously, operations will be the equivalent of COBOL consulting by 2030. Just wait. I'll hit my mid-40s, pull a Mikey Dickerson, and build a consultancy to swoop in and clean up the mess that you're creating by marginalizing operations as strongly as you are and laugh all the way to the bank.
Particularly in SRE, I'm a software engineer who happens to enjoy the plumbing that keeps your code running. I do not exist to serve at the pleasure of application developers, nor do I accept any imagery of my being inferior because I don't spend my days writing red/black trees to shave a few milliseconds off the news feed. I can, and have, do/done SRE without a single application developer customer, and I like to think of SRE as a little bit better than application engineering: you push to a repo and wait. I push Enter and 10,000 things happen instantly. Who's having more fun?
Tossing lame code over the fence is how to sow bad seeds with operations. That you've then had negative experiences with operations, enough to generalize us as a species (are you hitting sysadmins? ops? sysops? devops? hwops? netops? SRE?), is only a reinforcement for that to me. I would say between a combination of educated guessing based on your opinion, prior experience, and a few other inputs that it's pretty likely that your gripes with operations stem from flawed expectations on your part.
Rules #1 of operations: Don't be on call for other people shit.
You won't survive years in the field if you don't respect the basics.
You won't survive years in the field if you don't respect the basics.
To me, "old" as a prejorative has about as much to do with age as "gay" as a prejorative has to do with homosexuality.
The meaning people use the word to get at is "from another time when problems were solved differently, and staid in their opinions toward new solutions vs. those from the previous era."
I've heard myself called an "old man" online for liking SQL stored procedures. I was 23 at the time. :)
The meaning people use the word to get at is "from another time when problems were solved differently, and staid in their opinions toward new solutions vs. those from the previous era."
I've heard myself called an "old man" online for liking SQL stored procedures. I was 23 at the time. :)
The reality is, as far as I can see, there's just not much benefit in using Docker in a crappy (read: small) pool-of-app-servers-on-top-of-a-database webapp. I've had a lot of newer devs pushing to use Docker. I haven't had these newer devs give a solid reason why relatively low-volume, simple web apps need an additional layer of complexity over an easier-to-manage VM setup with automated provisioning.
[deleted]
The largest financial systems are running on COBOL/mainframes.
Planes are running on embedded microcontrollers still written in C or Ada. (They can't even get the approval to write C++).
Docker is not 1% ready for critical use. The day these things will use Docker, planes will fall and we'll have the next financial crisis.
As someone who worked both in finance and aerospace, handling systems that traded billions of dollars and planes that were carrying hundreds of passengers. This is my testimony on the year we tried to use Docker in production: http://thehftguy.com/2016/11/01/docker-in-production-an-hist...
Planes are running on embedded microcontrollers still written in C or Ada. (They can't even get the approval to write C++).
Docker is not 1% ready for critical use. The day these things will use Docker, planes will fall and we'll have the next financial crisis.
As someone who worked both in finance and aerospace, handling systems that traded billions of dollars and planes that were carrying hundreds of passengers. This is my testimony on the year we tried to use Docker in production: http://thehftguy.com/2016/11/01/docker-in-production-an-hist...
Wow.
But I want to give them a fair opportunity to justify this statement. Can someone give me examples of diseases being cured via docker, or planes being kept in the air (etc)
But I want to give them a fair opportunity to justify this statement. Can someone give me examples of diseases being cured via docker, or planes being kept in the air (etc)
Reproducibility is a big problem in analytic pipelines, specifically genomics. Researchers tend tweak their tools here and there and it has always been quite difficult to "package" a pipeline. Docker makes that much easier. We've seen a huge movement in the containerization of genomics pipelines, the results of which (we hope) help cure serious disease. In my world, we're using Docker every day to try and find cures for pediatric brain cancer. It's obviously not our only tool, but it helps.
Not in genomics but the same in true in spatial pipelines. Trying to get a machine setup with the correct set of libraries and packages across various languages is almost impossible on dev box much less on a prod cluster. Docker makes this easy to do once locally, validate the build and then use the same container to do the production runs.
Neural networks that construct ontologies from gene similarity matrices for discovering cancer pathways are tools that help cure cancer. There are a myriad of technologies supporting these type of applications; Torch, Python, Tensorflow... Docker is a minor detail that has as much to do with curing cancer as JSON or HTTP. When you make a claim like the one Docker is making, you should be a critical piece of the pipeline that actively contributes towards the end goal, not a piece of infrastructure. As a scientist, I find it disgusting that they're using cancer research as their buzz word for stability and importance.
> Reproducibility is a big problem in analytic pipelines, specifically genomics... [Docker solves this problem].
There is a legitimate fundamental issue with reproducing people's setups and Docker solves this. Ergo docker is valuable technology for data science.
Literally typing `docker run...` to reproduce results (vs. VM setup, installation etc.) seems important enough to justify their phrasing.
Fact: there are handfuls of data science startups that essentially rebrand docker and have been funded in the hundreds of millions of dollars specifically to solve this problem.
There is a legitimate fundamental issue with reproducing people's setups and Docker solves this. Ergo docker is valuable technology for data science.
Literally typing `docker run...` to reproduce results (vs. VM setup, installation etc.) seems important enough to justify their phrasing.
Fact: there are handfuls of data science startups that essentially rebrand docker and have been funded in the hundreds of millions of dollars specifically to solve this problem.
"planes being kept in the air"
I assume they mean "minimize time stuck on the tarmac" vs "literally flight critical", but I doubt even that.
The former would imply that something like dispatch functions are in production running on docker. I suppose that's possible, but it's not an area that lends itself to tech that's not very solidly proven for the space.
I assume they mean "minimize time stuck on the tarmac" vs "literally flight critical", but I doubt even that.
The former would imply that something like dispatch functions are in production running on docker. I suppose that's possible, but it's not an area that lends itself to tech that's not very solidly proven for the space.
Marketing Spin! Somewhere there is probably a system that touches some aspect of those things that use Docker.
Our employee bought a plane ticket! Literally keeping airlines in business.
Not sure why you're getting downvoted. Seems you're just doing a little 'reductio ad absurdum'. Sigh ...
Honestly it was a low effort comment that didn't add to the discussion I don't mind. It we pre morning-coffee.
Pre-coffee commenting, the drunk-texting of Hacker News.
What's really funny. I was kind of drunk when I wrote that comment. Re-read it thinking, "that sounds familiar". G'night everyone.
It comes across more like drunk driving to me. Making a mistake, then blaming it on the drink (or lack of coffee here).
Because containers make life every so slightly less terrible? And container orchestration allows for better efficiency of resources?
The following government entities are known to use, or have used (Docker) containers:
* USAF
* US Navy
* CFPB
* CDC
You can look up their RFPs online and see why they want to use containers. IMHO, these are pretty direct ways of keeping soldiers safe, and curing disease.
The following government entities are known to use, or have used (Docker) containers:
* USAF
* US Navy
* CFPB
* CDC
You can look up their RFPs online and see why they want to use containers. IMHO, these are pretty direct ways of keeping soldiers safe, and curing disease.
It probably just means some company that works in pharmaceuticals uses Docker for something, and another company that works in aerospace uses Docker for something, etc.
Somebody should buy a television ad for them: "Feeling tired?
Ask your doctor if Docker is right for you". Include an actor in a lab coat, with a quote from the CEO saying "Docker is being used to cure diseases".
Reminds me of the old Voodoo 3dfx commercial (the "save the planet" part, except serious) https://youtube.com/watch?v=ldiYYJNnQUk
The docker marketing team does seem to be accomplishing their intended purpose, but their preeminence in the company's decision-making does rub the cynical dev crowd the wrong way!
The docker marketing team does seem to be accomplishing their intended purpose, but their preeminence in the company's decision-making does rub the cynical dev crowd the wrong way!
Same thought here. What an arrogant, useless statement.
cure diseases : Nobel prize for Hyperbole right there.
The thing is that all these things can be done w/o docker at all. It may make it simpler (for some definition of "simpler"), but it is not necessary to do any of these things. Now the Linux kernel on which docker is built OTOH is probably not so easy to take away.
Marketing.
The same could be said of almost anything though: "[Linux|Raspberry Pi|Angular|Python] is being used to cure diseases, keep planes in the air, to keep soldiers safe from landmines, to power the world’s largest financial networks and institutions
The same could be said of almost anything though: "[Linux|Raspberry Pi|Angular|Python] is being used to cure diseases, keep planes in the air, to keep soldiers safe from landmines, to power the world’s largest financial networks and institutions
For Linux, the Raspberry Pi and Python it is probably actually true about the first two, not sure about the landmines, Raspberry Pi in finance I doubt but Linux and Python for sure.
Docker was probably a victim of its own success, with so many containers & orchestration systems popping up (CoreOS, Kubernetes, etc.), it became harder for them to capture enterprise market that they had taken for granted. Worse the impression that I got was somehow Docker with its great usability was for amateurs and not for enterprise users (where most of the revenue is expected to come from).
Anyway I think Docker is a great revolutionary product living up to the vision that was initially presented. However it badly needs enterprise adoption to remain viable, all other container systems suck in usability aspects. Hopefully this drives more revenue while keeping the core product still easy to use.
Anyway I think Docker is a great revolutionary product living up to the vision that was initially presented. However it badly needs enterprise adoption to remain viable, all other container systems suck in usability aspects. Hopefully this drives more revenue while keeping the core product still easy to use.
Docker just needed to license and support the engine rather than trying to build a crappy enterprise platform a'la Cloud Foundry.
The Docker engine is the one thing which nobody else can easily replicate.
They would have smashed it in the mass market at something like $100/yr/node.
The Docker engine is the one thing which nobody else can easily replicate.
They would have smashed it in the mass market at something like $100/yr/node.
The Docker engine is the one thing which nobody else can easily replicate.
They can, and have: https://coreos.com/rkt
That's why Docker had to keep expanding.
They can, and have: https://coreos.com/rkt
That's why Docker had to keep expanding.
+ the docker engine is just a polished version of what we had for ages
Not totally accurate.
BSD and solaris have had good containerisation engines for a while.
Linux, not so much.
BSD and solaris have had good containerisation engines for a while.
Linux, not so much.
Ehh... the actual "make a container out of this chunk of the filesystem" bit can be done in a couple hundred lines of Ruby/Python/Perl - Docker is, of course, just telling the kernel to create new uid/filesystem/network/etc namespaces and what to put in them. Most of Docker is the image management system and build tool.
I think the point is that those namespaces are rather recent themselves, whereas e.g. FreeBSD has had jails since 2000.
[deleted]
My company has been a partner of Concur for several years, starting back in 2012 when the original founders (Steve, Raj and Mike) were all still there.
Steve was easily the most-respected leader in the travel industry- even people that disliked Concur admired Steve. He was articulate, created a clear vision for Concur that they maintained even as they grew like wildfire, and he inspired trust and goodwill with Concur partners.
I get the "oh no, SAP executive" instinctual reaction, but Steve is clearly an entrepreneur at heart and considers himself an entrepreneur (it took them 20 years of grinding and ups and downs to build Concur what it is today).
There was also a comment about him leading the company to exit in 2-3 years. I seriously doubt it. Concur's stock symbol is CNQR which isn't a coincidence. They didn't build Concur to sell it, they built it to conquer, which they had basically done when SAP bought them. Plus after 20 years I imagine $8B sounded pretty good, but I don't think their approach was ever to try to "flip" the company and I doubt he would join Docker if that was the intention in any way.
Steve was easily the most-respected leader in the travel industry- even people that disliked Concur admired Steve. He was articulate, created a clear vision for Concur that they maintained even as they grew like wildfire, and he inspired trust and goodwill with Concur partners.
I get the "oh no, SAP executive" instinctual reaction, but Steve is clearly an entrepreneur at heart and considers himself an entrepreneur (it took them 20 years of grinding and ups and downs to build Concur what it is today).
There was also a comment about him leading the company to exit in 2-3 years. I seriously doubt it. Concur's stock symbol is CNQR which isn't a coincidence. They didn't build Concur to sell it, they built it to conquer, which they had basically done when SAP bought them. Plus after 20 years I imagine $8B sounded pretty good, but I don't think their approach was ever to try to "flip" the company and I doubt he would join Docker if that was the intention in any way.
nullnilvoid(3)
I'm sorry to see Solomon go. I think Docker has a challenge on their hands with Kubernetes and that a founder would be the one with the authority to make a drastic change.
It is inspirational to see that nowadays you can build a huge company when you make a product developers want.
It is inspirational to see that nowadays you can build a huge company when you make a product developers want.
Solomon isn't going anywhere :-)
I mean seeing him go as the CEO.
Wonder why there isn't any article about Sudhir Steven Singh in Wikipedia.
https://en.wikipedia.org/wiki/Steve_Singh
https://en.wikipedia.org/wiki/Steve_Singh
I think Docker cannot make money on its own. It's already too late for them to build on the hype as other companies captured the most critical customers / audience.
How can't they? Doesn't Red Hat make a ton of money, despite plenty of other distros capturing market share? :)
1) Red Hat has orchestration, that Docker doesn't have.
2) RedHat is well positioned in the big enterprise market with support/vendor contracts, containerization is just one more lateral offering in the portfolio.
3) RedHat is a well known and trusted brand, Docker is not.
2) RedHat is well positioned in the big enterprise market with support/vendor contracts, containerization is just one more lateral offering in the portfolio.
3) RedHat is a well known and trusted brand, Docker is not.