12 ms·

Deis to Join Microsoft

464 points by gabrtv 10y ago

luhn 10y ago
Deis has changed a lot since I last looked at them. They've dropped their original PaaS and developed an ecosystem on top of Kubernetes. Microsoft has been showing a lot of interest in Docker, so can see why this acquisition would make sense for them.
- bacongobbler 10y ago
  > They've dropped their original PaaS Just to clarify, we never dropped the original PaaS. Deis (now named Workflow) is still in active development, uses Kubernetes as the underlying scheduler and has monthly releases. We actually just released v2.13.0 5 days ago. :) https://github.com/deis/workflow https://github.com/deis/workflow
  - yebyen 10y ago
    In a sense it is the same product (for the users, Deis Workflow / Deis v2 is basically a drop-in replacement for Deis v1, and API Clients such as Deis Dash http://deisdash.com/ http://deisdash.com/ can work with both). But in a very real sense also, the old product was End-of-Lifed and Workflow is a completely separate and different product. There is no direct upgrade path from v1 to v2, the branding was changed (new product name entirely) to coincide with the release of v2, and the v1 LTS branch is no longer receiving updates, support, or new builds when issues are identified. It's kind of like the axe that is passed down from generation to generation for 150 years. Can't really call it the same axe anymore when you've replaced the blade and the handle several times over. (This coming from a happy Deis user that still has living installations of both v1 and Workflow.) Congratulations on the acquisition!
    - bacongobbler 10y ago
      > the old product was End-of-Lifed To be fair, we did continue to support Deis v1 for 3 whole years(!), which is very long considering we're just a small startup. Being woken at 3AM from yet another obscure etcd/fleet server failure really sucked, and systemd never truly got along well with Docker making for some fun interactions with Fleet. Overall (speaking personally as an engineer and support engineer), we are very happy we made the decision to switch to Kubernetes. Mind you, we were as early adopter as you could get with Fleet and etcd at the time, and etcd in particular has been significantly better for us in terms of stability/error reporting. > There is no direct upgrade path from v1 to v2 I agree that it sucks there was no upgrade path from v1 to v2, but we felt it was necessary to make breaking changes to move forward from Fleet into the world of Kubernetes. That doesn't change the fact that we never dropped the PaaS product as a whole, though. > the branding was changed (new product name entirely) to coincide with the release of v2 This was actually more to do with us becoming "Deis the company" more-so than the v2 release. Lots of users were getting confused with "Deis the company" and "Deis the github project", so we decided to rename it Workflow to help make it more clear in conversation. > and Workflow is a completely separate and different product. Curious to understand how you feel like v2 is a completely different product. From a user's standpoint the product offering never changed. The API, CLI and `git push` workflows were all still present in v2 and were drop-in replacements, save for backwards-incompatible database migrations (hence v2.0.0). It was just the administration's point of view that changed (Fleet -> Kubernetes, deisctl -> helm). To me it still feels like the same product, but I'm curious to hear from you why you feel differently. :)
      - robszumski 10y ago
        A huge kudos for keeping up your legacy support for 3 years! Making needed but intrusive architectural changes is hard for any open source project, and gets harder when you have paying customers. You typically never get praise for doing the right thing...thank you.
      - yebyen 10y ago
        Please do not take anything I said as an attempt to throw shade or being critical of your team! As a non-paying customer, I have to say I'm extremely happy with the support you've delivered (and consistently.) I wish I could have got my company to throw money at you, but it did not work out. The kind of support I got from Deis the company is really without comparison when it comes to Open Source projects anywhere else. The fact that v2 is a drop-in replacement for v1 really eases the sting of the fact that there is no direct upgrade path. I still have an old Deis v1 kicking around because I left the company, transitioned to hourly, and made an agreement to draw down my hours at this company, where we are in reality hardly using Deis at all. But in the small capacity we are using it, there is what I'd call "VMware Levels of Reliability" and so it successfully became a piece of the infrastructure there. So it is disingenuous for me to say that I was not able to upgrade my v1 installation. The reason I was not able to upgrade is because there was not strong interest in upgrading. The unsupported product is as good as our (also unsupported! but luckily not End-of-Life) VSphere and VSan environment. It is a different product to me, in short because I am the one administering it. It runs on a different platform altogether, it has no distributed filesystem component where the old version did, and it has not really harmed me in any way that there is no upgrade path. It is just a couple of facts that led me to the conclusion that they are in fact distinct and other products that are not directly related to each other, except that they could easily pass for one another if you asked a user. I am really happy for you guys, Microsoft is a real big name compared to EngineYard, and while I could get behind EY+Deis, it's a hard sell for the Design Review Board. But I can tell them "look, Microsoft is doing this now" and they will know what that means instantly. Big guns. No joke software. This is how I've actually felt about Deis from the beginning, but now it's going to be a much easier sell to get Big Wigs to sign off on. Nobody ever got fired for buying Microsoft!
  - eudoxus 10y ago
    I think he is just referring to your Deis v1 PaaS before you started on Workflow and k8.
    - bacongobbler 10y ago
      That is true; though technically the Deis v1 PaaS still lives on as Workflow. Internally the v1 PaaS bits are all there in Workflow, just switching out Fleet for Kubernetes. It was just renamed when we became "Deis the company" rather than "Deis the project". I just wanted to clarify that we never "dropped" doing the PaaS thing.
pvsnp 10y ago
I'm somewhat surprised. Why would Microsoft put weight into Deis vs use something like Kubernetes or Mesos? I haven't kept up with Deis's growth and I'm obviously very happy for them, but I'm curious what the gain is. Based on HN posts and other devops forums, Kubernetes eeems to have gained a lot of momentum recently.
- Alir3z4 10y ago
  https://deis.com/workflow/ https://deis.com/workflow/ & https://helm.sh/ https://helm.sh/ & https://github.com/deis/steward https://github.com/deis/steward All for Kubernetes. edit: links fix
  - strictnein 10y ago
    Both of these links are the same?
    - koolba 10y ago
      Though that doesn't make the statement less true.
    - Alir3z4 10y ago
      Fixed the links ;)
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- gabrtv 10y ago
  Best to think of Deis as a Kubernetes company. We are much more than the PaaS solution many folks know us for.
  - Artemis2 10y ago
edude03 10y ago
Wait what? Didn't the Deis team just join EngineYard last year? Furthermore, why would Microsoft want Deis? They haven't really shown an interest in Kubernetes thus far.
- UK-AL 10y ago
  Well they've gotten kubernetes running on azure.
  - HorizonXP 10y ago
    Yes you can run Azure Container Service using Kubernetes. When we migrated to Azure, we went with this and it worked reasonably well. However, they're using Ubuntu as their base OS, which we weren't the biggest fans of. Instead, we switched to running normal VMs using CoreOS and running Kubernetes on top of that. Same features and stability, but with the auto-update benefits of CoreOS.
    - rattray 10y ago
      Out of curiosity, why'd you choose Azure over GKE?
      - HorizonXP 10y ago
        Cold hard cash. Our Azure credits have a longer expiry date.
        rattray 10y ago
        Makes sense. Any regrets?
        luka-birsa 10y ago
        Basing on my experience there will be a migration to GCE when credits run out and you total the difference in costs. Azure is fine, but can't compete on price. (We migrated from AZ to GCE & K8S)
Sevrene 10y ago
What!? I never would have expected this, quite a surprise. I hope it works out for them.
devy 10y ago
Does this mean a commitment of Microsoft on k8s ecosystems or simply a talent acquisition or both?
- patrickaljord 10y ago
  They've just hired one the founder of Kubernetes so my guess would be yes https://www.onmsft.com/news/google-engineer-kubernetes-founder-brendan-burns-joining-microsoft-azure https://www.onmsft.com/news/google-engineer-kubernetes-found...
alpb 10y ago
Congratulations Gabriel! Having worked on containers space in Microsoft Azure before, my opinion is that this is a great move by Microsoft. In the past years, I've seen the company struggle in finding great talent in OSS/Linux stack. Simply, there are a lot of areas Microsoft could expand, but there is not enough talent. Deis will definitely take a ton of expertise in open source software and community to Microsoft. Now that Kubernetes is a big part of Azure’s container service, Deis brings a lot of fresh blood to Microsoft. I hope it works out great for both companies (and the open source Kubernetes community).
ksikka 10y ago
The Deis team was extremely helpful over IRC when I was building on top of their PaaS. Great team and culture, Microsoft is lucky to have them.
- deleted 10y ago
  [deleted]
WrtCdEvrydy 10y ago
Next week, Flynn to Join Apple. Let the PaaS arms race begin.
dankohn1 10y ago
Congrats to Gabe and the whole Deis team on the acquisition. For folks not familiar with Helm, it's basically apt-get for Kubernetes, but with the ability to deploy complex multi-tier systems. It has now graduated out of the Kubernetes incubator. And their Workflow product (also open source), is basically the smallest piece of software that lets you run Heroku buildpacks on top of Kubernetes. So, you can get a 12-factor PaaS workflow, and still have the full Kubernetes API underneath if and when you need it. Update: And I left out my all-time favorite piece of marketing collateral, their Children's Illustrated Guide to Kubernetes (available both as children's book and video): https://deis.com/blog/2016/kubernetes-illustrated-guide/ https://deis.com/blog/2016/kubernetes-illustrated-guide/ (Disclosure: I'm the executive director of CNCF and Gabe has been a super valuable member.)
- mej10 10y ago
  How does it compare to DC/OS on Mesos? Interested in hearing from people experienced in both.
- andrewstuart2 10y ago
  I think Helm is sold short when it's described as apt-get for kubernetes. I think it's probably substantially closer to chef/salt/puppet for k8s, with a little bit of apt-get in the form of service dependency management. Pulling down the binaries is all handled by docker, but reusing and retooling config files is where Helm's real strength is, IMO. I use Helm on a couple different projects as an integral part of CI/CD for templating config files and Ingress resources. Coupled with a good CI/CD system (I'm using GitLab), Helm templating is pretty critical in my workflow for creating demo applications (one per PR) at some specific endpoint/dns but then after integration, moving the updated code out to multiple DNS endpoints, etc. Congrats to the team, and I look forward to seeing where Helm can go from here!
  - fredsir 10y ago
    Have you written about your setup anywhere? I'm right now working on porting my manifests + kubectl manual k8s workflow to helm+gitlab-ci(to automatically build and push imagines and then deploy to cluster), but I'm only just at the stage of creating the helm charts, so any literature about how to set up a ci to build the Docker images, push them, bump the chart version, deploy to staging environment for every PR and so on is something I'm very interested in.
ridruejo 10y ago
The industry is consolidating around the Kubernetes ecosystem. This acquisition is an example of many others that will follow as the major players want to build up their offerings and expertise.
xena 10y ago
Congrats on the acquisition, I'm just sad I can't be there to congratulate you.
AlexB138 10y ago
Well, that's definitely a way to buy yourself into the Kubernetes ecosystems. Congratulations to the Deis team!
deleted 10y ago
[deleted]
kayoone 10y ago
Love Deis, we have used V1 and V2 (with kubernetes) at my current job with success, but also had weird stability and reliability issues from time to time.
briandear 10y ago
I really hope Microsoft doesn't hurt this. For example, there are great docs for AWS and Google, but given the way they've ruined Skype, I really hope they don't turn this into some kind of Azure-focused system while dropping support for AWS, etc. Congrats to the awesome Deis team -- let's just hope that Microsoft doesn't just run it into the ground when it comes to non-Azure platforms.
briandear 10y ago
"Microsoft has a storied history of building tools and technologies that work for developers." I'm not sure how I feel about that statement.
RRRA 10y ago
I'm really curious how people administer their K8S clusters for installation, upgrades, etc. I'm very familiar with docker, which we've been using for over 2 years. But now, we're trying to get k8s running, with either kargo, kubeadm, deb packages, etc.: They all failed with different bugs on different set of clouds / settings. (Trying to stick to running it on Ubuntu xenial). Not sure if it's because 1.6.* just came out of the oven when I started...? Thanks to Minikube, I understand how powerful k8s can be, and actually find kubectl quite simple to use, but I'm confused by how fragile and complex installation and setup seems to be. I'm unsure how someone is supposed to maintain this system considering how (overly?) modular it is and the bugs I've encountered. Knowing that docker has a LOT of bugs, and k8s builds on top of it, I'm a bit scared. And there is no clean documentation on how to install it, with sections for all your choices, in a generic/agnostic way (deb+rpm distros, cloud integration or simple abstract VMs, ...) What is you workflow? :)
- ben_jones 10y ago
  I agree with k8s not being environment agnostic. It's most of the way there but your decision to run on GCP, AWS, or some other platform, can play a large role in decision making and k8s adoption. I feel like right now in particular development is weighting to make k8s more friendly on GCP probably because the GCP team is working really hard and they're using that momentum (and a lot of open source / conference presence) to keep that advantage going forward. I think minikube is a crucial early step in allowing at least agnostic development where a "professional" can then ease it into a cloud provider by turning knobs here and there. It'll probably stay that way for awhile but we'll see.
- MattRogish 10y ago
  We (ReactiveOps.com) use kops: https://github.com/kubernetes/kops https://github.com/kubernetes/kops It works well with Ubuntu and we are working on CoreOS (although no promises it gets merged back into core). Kops can do upgrades although historically it was safer/easier to stand up another cluster alongside and migrate. Happy to help if you have any questions - Matt [at] reactiveops.com.
- pat2man 10y ago
  We are using https://github.com/openshift/openshift-ansible https://github.com/openshift/openshift-ansible which gets you a k8s cluster + user management and a great web interface. I actually learned a lot about cluster management from that repo since it goes through all the standard best practices.
rbanffy 10y ago
Every time someone is acquired by Microsoft I can't avoid feeling sad for them. It's true they'll get a decent amount of money, that, from now on, they have infinitely deep pockets, that they'll have some of the best keyboards and mice, but it's also true their wiki will end up in Sharepoint and their e-mails in Exchange.
- CydeWeys 10y ago
  And what's the fate of their source control system?
  - steve-howard 10y ago
    TFS+git would be my guess.
  - cronin101 10y ago
    Microsoft is aligning on Git, so it's unlikely that anything will change (and the horror stories of the past are no-longer applicable for new aqui-hires.)
    - CydeWeys 10y ago
      Vanilla git can't handle a repo the size of Microsoft's combined codebase though; surely there must be some additional secret sauce involved?
      - yebyen 10y ago
        Well I'd suggest "repo" -- the tool that goes with Gerrit, and collects many git repos into reviewable release units with a manifest. That's what Android does. (But I'd guess that's probably enough to shoot it down as a tool for Microsoft to ever use, right there. Not rightfully, but likely in fact... maybe that's the old Microsoft though.)
      - jmspring 10y ago
        A lot of development around Azure tools is done in the open under various "groups" -- MicrosoftDx, Azure, etc -- there is no one "source repo" for all products. Even when I was at Skype, the repo for that was separate from that for S4B, etc -- I'm sure this has changed in the last few years. But, there isn't a monolithic repo. Something like Office or Windows, well, that's outside my wheel house of knowledge.
jasonmccay 10y ago
If Deis was that valuable, one could assume that EY agreed to this arrangement because they are low on cash and needed the money. How often is a company, in effect, acquired twice?
sameersbn 10y ago
Congratulations to the Deis Team. It's been a pleasure working with them on the Helm project.
olalonde 10y ago
Congrats to the Deis team! I was an early adopter and the team was just fantastic at answering questions, implementing feature requests and resolving issues on GitHub. PS: I'll take this opportunity to shamelessly promote my web based Deis UI: http://github.com/olalonde/deisdash http://github.com/olalonde/deisdash

464 points by gabrtv 10y ago

luhn 10y ago

Deis has changed a lot since I last looked at them. They've dropped their original PaaS and developed an ecosystem on top of Kubernetes. Microsoft has been showing a lot of interest in Docker, so can see why this acquisition would make sense for them.

bacongobbler 10y ago
> They've dropped their original PaaS Just to clarify, we never dropped the original PaaS. Deis (now named Workflow) is still in active development, uses Kubernetes as the underlying scheduler and has monthly releases. We actually just released v2.13.0 5 days ago. :) https://github.com/deis/workflow https://github.com/deis/workflow
- yebyen 10y ago
  In a sense it is the same product (for the users, Deis Workflow / Deis v2 is basically a drop-in replacement for Deis v1, and API Clients such as Deis Dash http://deisdash.com/ http://deisdash.com/ can work with both). But in a very real sense also, the old product was End-of-Lifed and Workflow is a completely separate and different product. There is no direct upgrade path from v1 to v2, the branding was changed (new product name entirely) to coincide with the release of v2, and the v1 LTS branch is no longer receiving updates, support, or new builds when issues are identified. It's kind of like the axe that is passed down from generation to generation for 150 years. Can't really call it the same axe anymore when you've replaced the blade and the handle several times over. (This coming from a happy Deis user that still has living installations of both v1 and Workflow.) Congratulations on the acquisition!
  - bacongobbler 10y ago
    > the old product was End-of-Lifed To be fair, we did continue to support Deis v1 for 3 whole years(!), which is very long considering we're just a small startup. Being woken at 3AM from yet another obscure etcd/fleet server failure really sucked, and systemd never truly got along well with Docker making for some fun interactions with Fleet. Overall (speaking personally as an engineer and support engineer), we are very happy we made the decision to switch to Kubernetes. Mind you, we were as early adopter as you could get with Fleet and etcd at the time, and etcd in particular has been significantly better for us in terms of stability/error reporting. > There is no direct upgrade path from v1 to v2 I agree that it sucks there was no upgrade path from v1 to v2, but we felt it was necessary to make breaking changes to move forward from Fleet into the world of Kubernetes. That doesn't change the fact that we never dropped the PaaS product as a whole, though. > the branding was changed (new product name entirely) to coincide with the release of v2 This was actually more to do with us becoming "Deis the company" more-so than the v2 release. Lots of users were getting confused with "Deis the company" and "Deis the github project", so we decided to rename it Workflow to help make it more clear in conversation. > and Workflow is a completely separate and different product. Curious to understand how you feel like v2 is a completely different product. From a user's standpoint the product offering never changed. The API, CLI and `git push` workflows were all still present in v2 and were drop-in replacements, save for backwards-incompatible database migrations (hence v2.0.0). It was just the administration's point of view that changed (Fleet -> Kubernetes, deisctl -> helm). To me it still feels like the same product, but I'm curious to hear from you why you feel differently. :)
    - robszumski 10y ago
      A huge kudos for keeping up your legacy support for 3 years! Making needed but intrusive architectural changes is hard for any open source project, and gets harder when you have paying customers. You typically never get praise for doing the right thing...thank you.
    - yebyen 10y ago
      Please do not take anything I said as an attempt to throw shade or being critical of your team! As a non-paying customer, I have to say I'm extremely happy with the support you've delivered (and consistently.) I wish I could have got my company to throw money at you, but it did not work out. The kind of support I got from Deis the company is really without comparison when it comes to Open Source projects anywhere else. The fact that v2 is a drop-in replacement for v1 really eases the sting of the fact that there is no direct upgrade path. I still have an old Deis v1 kicking around because I left the company, transitioned to hourly, and made an agreement to draw down my hours at this company, where we are in reality hardly using Deis at all. But in the small capacity we are using it, there is what I'd call "VMware Levels of Reliability" and so it successfully became a piece of the infrastructure there. So it is disingenuous for me to say that I was not able to upgrade my v1 installation. The reason I was not able to upgrade is because there was not strong interest in upgrading. The unsupported product is as good as our (also unsupported! but luckily not End-of-Life) VSphere and VSan environment. It is a different product to me, in short because I am the one administering it. It runs on a different platform altogether, it has no distributed filesystem component where the old version did, and it has not really harmed me in any way that there is no upgrade path. It is just a couple of facts that led me to the conclusion that they are in fact distinct and other products that are not directly related to each other, except that they could easily pass for one another if you asked a user. I am really happy for you guys, Microsoft is a real big name compared to EngineYard, and while I could get behind EY+Deis, it's a hard sell for the Design Review Board. But I can tell them "look, Microsoft is doing this now" and they will know what that means instantly. Big guns. No joke software. This is how I've actually felt about Deis from the beginning, but now it's going to be a much easier sell to get Big Wigs to sign off on. Nobody ever got fired for buying Microsoft!
- eudoxus 10y ago
  I think he is just referring to your Deis v1 PaaS before you started on Workflow and k8.
  - bacongobbler 10y ago
    That is true; though technically the Deis v1 PaaS still lives on as Workflow. Internally the v1 PaaS bits are all there in Workflow, just switching out Fleet for Kubernetes. It was just renamed when we became "Deis the company" rather than "Deis the project". I just wanted to clarify that we never "dropped" doing the PaaS thing.

pvsnp 10y ago

I'm somewhat surprised. Why would Microsoft put weight into Deis vs use something like Kubernetes or Mesos? I haven't kept up with Deis's growth and I'm obviously very happy for them, but I'm curious what the gain is. Based on HN posts and other devops forums, Kubernetes eeems to have gained a lot of momentum recently.

Alir3z4 10y ago
https://deis.com/workflow/ https://deis.com/workflow/ & https://helm.sh/ https://helm.sh/ & https://github.com/deis/steward https://github.com/deis/steward All for Kubernetes. edit: links fix
- strictnein 10y ago
  Both of these links are the same?
  - koolba 10y ago
    Though that doesn't make the statement less true.
  - Alir3z4 10y ago
    Fixed the links ;)
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
gabrtv 10y ago
Best to think of Deis as a Kubernetes company. We are much more than the PaaS solution many folks know us for.
- Artemis2 10y ago

edude03 10y ago

Wait what? Didn't the Deis team just join EngineYard last year? Furthermore, why would Microsoft want Deis? They haven't really shown an interest in Kubernetes thus far.

UK-AL 10y ago
Well they've gotten kubernetes running on azure.
- HorizonXP 10y ago
  Yes you can run Azure Container Service using Kubernetes. When we migrated to Azure, we went with this and it worked reasonably well. However, they're using Ubuntu as their base OS, which we weren't the biggest fans of. Instead, we switched to running normal VMs using CoreOS and running Kubernetes on top of that. Same features and stability, but with the auto-update benefits of CoreOS.
  - rattray 10y ago
    Out of curiosity, why'd you choose Azure over GKE?
    - HorizonXP 10y ago
      Cold hard cash. Our Azure credits have a longer expiry date.
      - rattray 10y ago
        Makes sense. Any regrets?
        luka-birsa 10y ago
        Basing on my experience there will be a migration to GCE when credits run out and you total the difference in costs. Azure is fine, but can't compete on price. (We migrated from AZ to GCE & K8S)

Sevrene 10y ago

What!? I never would have expected this, quite a surprise. I hope it works out for them.

devy 10y ago

Does this mean a commitment of Microsoft on k8s ecosystems or simply a talent acquisition or both?

patrickaljord 10y ago
They've just hired one the founder of Kubernetes so my guess would be yes https://www.onmsft.com/news/google-engineer-kubernetes-founder-brendan-burns-joining-microsoft-azure https://www.onmsft.com/news/google-engineer-kubernetes-found...

alpb 10y ago

Congratulations Gabriel! Having worked on containers space in Microsoft Azure before, my opinion is that this is a great move by Microsoft. In the past years, I've seen the company struggle in finding great talent in OSS/Linux stack. Simply, there are a lot of areas Microsoft could expand, but there is not enough talent. Deis will definitely take a ton of expertise in open source software and community to Microsoft. Now that Kubernetes is a big part of Azure’s container service, Deis brings a lot of fresh blood to Microsoft. I hope it works out great for both companies (and the open source Kubernetes community).

ksikka 10y ago

The Deis team was extremely helpful over IRC when I was building on top of their PaaS. Great team and culture, Microsoft is lucky to have them.

deleted 10y ago
[deleted]

WrtCdEvrydy 10y ago

Next week, Flynn to Join Apple. Let the PaaS arms race begin.

dankohn1 10y ago

Congrats to Gabe and the whole Deis team on the acquisition. For folks not familiar with Helm, it's basically apt-get for Kubernetes, but with the ability to deploy complex multi-tier systems. It has now graduated out of the Kubernetes incubator. And their Workflow product (also open source), is basically the smallest piece of software that lets you run Heroku buildpacks on top of Kubernetes. So, you can get a 12-factor PaaS workflow, and still have the full Kubernetes API underneath if and when you need it. Update: And I left out my all-time favorite piece of marketing collateral, their Children's Illustrated Guide to Kubernetes (available both as children's book and video): https://deis.com/blog/2016/kubernetes-illustrated-guide/ https://deis.com/blog/2016/kubernetes-illustrated-guide/ (Disclosure: I'm the executive director of CNCF and Gabe has been a super valuable member.)

mej10 10y ago
How does it compare to DC/OS on Mesos? Interested in hearing from people experienced in both.
andrewstuart2 10y ago
I think Helm is sold short when it's described as apt-get for kubernetes. I think it's probably substantially closer to chef/salt/puppet for k8s, with a little bit of apt-get in the form of service dependency management. Pulling down the binaries is all handled by docker, but reusing and retooling config files is where Helm's real strength is, IMO. I use Helm on a couple different projects as an integral part of CI/CD for templating config files and Ingress resources. Coupled with a good CI/CD system (I'm using GitLab), Helm templating is pretty critical in my workflow for creating demo applications (one per PR) at some specific endpoint/dns but then after integration, moving the updated code out to multiple DNS endpoints, etc. Congrats to the team, and I look forward to seeing where Helm can go from here!
- fredsir 10y ago
  Have you written about your setup anywhere? I'm right now working on porting my manifests + kubectl manual k8s workflow to helm+gitlab-ci(to automatically build and push imagines and then deploy to cluster), but I'm only just at the stage of creating the helm charts, so any literature about how to set up a ci to build the Docker images, push them, bump the chart version, deploy to staging environment for every PR and so on is something I'm very interested in.

ridruejo 10y ago

The industry is consolidating around the Kubernetes ecosystem. This acquisition is an example of many others that will follow as the major players want to build up their offerings and expertise.

xena 10y ago

Congrats on the acquisition, I'm just sad I can't be there to congratulate you.

AlexB138 10y ago

Well, that's definitely a way to buy yourself into the Kubernetes ecosystems. Congratulations to the Deis team!

deleted 10y ago

[deleted]

kayoone 10y ago

Love Deis, we have used V1 and V2 (with kubernetes) at my current job with success, but also had weird stability and reliability issues from time to time.

briandear 10y ago

I really hope Microsoft doesn't hurt this. For example, there are great docs for AWS and Google, but given the way they've ruined Skype, I really hope they don't turn this into some kind of Azure-focused system while dropping support for AWS, etc. Congrats to the awesome Deis team -- let's just hope that Microsoft doesn't just run it into the ground when it comes to non-Azure platforms.

briandear 10y ago

"Microsoft has a storied history of building tools and technologies that work for developers." I'm not sure how I feel about that statement.

RRRA 10y ago

I'm really curious how people administer their K8S clusters for installation, upgrades, etc. I'm very familiar with docker, which we've been using for over 2 years. But now, we're trying to get k8s running, with either kargo, kubeadm, deb packages, etc.: They all failed with different bugs on different set of clouds / settings. (Trying to stick to running it on Ubuntu xenial). Not sure if it's because 1.6.* just came out of the oven when I started...? Thanks to Minikube, I understand how powerful k8s can be, and actually find kubectl quite simple to use, but I'm confused by how fragile and complex installation and setup seems to be. I'm unsure how someone is supposed to maintain this system considering how (overly?) modular it is and the bugs I've encountered. Knowing that docker has a LOT of bugs, and k8s builds on top of it, I'm a bit scared. And there is no clean documentation on how to install it, with sections for all your choices, in a generic/agnostic way (deb+rpm distros, cloud integration or simple abstract VMs, ...) What is you workflow? :)

ben_jones 10y ago
I agree with k8s not being environment agnostic. It's most of the way there but your decision to run on GCP, AWS, or some other platform, can play a large role in decision making and k8s adoption. I feel like right now in particular development is weighting to make k8s more friendly on GCP probably because the GCP team is working really hard and they're using that momentum (and a lot of open source / conference presence) to keep that advantage going forward. I think minikube is a crucial early step in allowing at least agnostic development where a "professional" can then ease it into a cloud provider by turning knobs here and there. It'll probably stay that way for awhile but we'll see.
MattRogish 10y ago
We (ReactiveOps.com) use kops: https://github.com/kubernetes/kops https://github.com/kubernetes/kops It works well with Ubuntu and we are working on CoreOS (although no promises it gets merged back into core). Kops can do upgrades although historically it was safer/easier to stand up another cluster alongside and migrate. Happy to help if you have any questions - Matt [at] reactiveops.com.
pat2man 10y ago
We are using https://github.com/openshift/openshift-ansible https://github.com/openshift/openshift-ansible which gets you a k8s cluster + user management and a great web interface. I actually learned a lot about cluster management from that repo since it goes through all the standard best practices.

rbanffy 10y ago

Every time someone is acquired by Microsoft I can't avoid feeling sad for them. It's true they'll get a decent amount of money, that, from now on, they have infinitely deep pockets, that they'll have some of the best keyboards and mice, but it's also true their wiki will end up in Sharepoint and their e-mails in Exchange.

CydeWeys 10y ago
And what's the fate of their source control system?
- steve-howard 10y ago
  TFS+git would be my guess.
- cronin101 10y ago
  Microsoft is aligning on Git, so it's unlikely that anything will change (and the horror stories of the past are no-longer applicable for new aqui-hires.)
  - CydeWeys 10y ago
    Vanilla git can't handle a repo the size of Microsoft's combined codebase though; surely there must be some additional secret sauce involved?
    - yebyen 10y ago
      Well I'd suggest "repo" -- the tool that goes with Gerrit, and collects many git repos into reviewable release units with a manifest. That's what Android does. (But I'd guess that's probably enough to shoot it down as a tool for Microsoft to ever use, right there. Not rightfully, but likely in fact... maybe that's the old Microsoft though.)
    - jmspring 10y ago
      A lot of development around Azure tools is done in the open under various "groups" -- MicrosoftDx, Azure, etc -- there is no one "source repo" for all products. Even when I was at Skype, the repo for that was separate from that for S4B, etc -- I'm sure this has changed in the last few years. But, there isn't a monolithic repo. Something like Office or Windows, well, that's outside my wheel house of knowledge.

jasonmccay 10y ago

If Deis was that valuable, one could assume that EY agreed to this arrangement because they are low on cash and needed the money. How often is a company, in effect, acquired twice?

sameersbn 10y ago

Congratulations to the Deis Team. It's been a pleasure working with them on the Helm project.

olalonde 10y ago

Congrats to the Deis team! I was an early adopter and the team was just fantastic at answering questions, implementing feature requests and resolving issues on GitHub. PS: I'll take this opportunity to shamelessly promote my web based Deis UI: http://github.com/olalonde/deisdash http://github.com/olalonde/deisdash