We are looking for software engineers who are excited about containers, and container orchestration with Kubernetes. Who also have a passion for building DevOps tools that make it easier for people to build, deploy and scale their software on the Azure cloud.
Experience with container runtimes such as Docker, Rkt, runC, containers and how they are enabled by the underlying OS components.
* Experience with workload/container orchestration using Kubernetes or similar platforms.
* Experience with Golang.
* Experience with Linux.
* Experience with terraform or ansible.
* Experience with building, shipping and operating reliable, distributed solutions.
* Ability to engage in site-reliability engineering practices.
I'm sure this is going to increase the competition for these roles, but heads up that the `icims.com` links weren't working for me, so you may need to use https://careers.microsoft.com/us/en/job/590350/Software-Engi... , which seems like the same position.
We are looking for software engineers who are excited about containers, and container orchestration with Kubernetes. Who also have a passion for building DevOps tools that make it easier for people to build, deploy and scale their software on the Azure cloud.
Experience with container runtimes such as Docker, Rkt, runC, containers and how they are enabled by the underlying OS components.
* Experience with workload/container orchestration using Kubernetes or similar platforms.
* Experience with Golang.
* Experience with Linux.
* Experience with terraform or ansible.
* Experience with building, shipping and operating reliable, distributed solutions.
* Ability to engage in site-reliability engineering practices.
Sure, that’s a valid concern. I think there are some other aspects of projects to consider than only the the org vs individual distinction though.
For example, I first wrote about nginx-proxy and docker-gen 4 years ago (http://jasonwilder.com/blog/2014/03/25/automated-nginx-rever...). Since then, both projects have gone through continued releases with bug fixes, updates and new features. Between the two projects, there are about 110 different contributors and I am no longer the top contributor on one of them.
The projects are MIT licensed and free to be forked or maintained independently if neeeded.
There’s a large community of users that write blogs, help with issues, and even create derivative works inspired or derived from the project.
Finally, I’d add that a lot of orgs behind projects are really just an individual that wants to make a useful closed source project open for others. The org or company name attached doesn’t necessarily mean a company is going to support it any better than a dedicated individual or community that cares about it.
I wrote https://github.com/jwilder/docker-squash to remove things that I know I don't need in the final image such as curl, wget, temp files, various packages, etc..
I've managed to get most images to basically the size of the base image + my app.
This process is sort of the reverse of building a single binary and adding it to a minimal image. I like that approach but it's not always straightforward w/ some applications.
Ah yes, I've played with docker-squash and like it, I wish there was a built-in docker solution for squashing layers (perhaps any contiguous string of instructions starting with ~ would be squashed into one layer?).
Mostly the problem I've run into is figuring out what to remove without b0rking the containerized app.
I believe the author was really focusing on "operational" complexity more than code complexity and language features.
For example, a language choice like using Python can add accidental complexity because it usually requires a container (uwsgi, gunicorn, etc..), sometimes a front-end reverse proxy (nginx, etc..), some way to package up your application and dependencies (tarballs, virtualenv, etc.). You also have to deal with deployment host issues like is Python2.6 required and available on your OS, do you have multiple apps with conflicting shared libraries that need to co-exist on the same host, do you need some system libraries installed on the hosts, are components compatible w/ each other (nginx x.y.z + uwsgi a.b.c) and can developers run that on Macs (dev laptop) and prod (linux).
I believe this is the accidental complexity the author is trying to highlight that can be avoided with Go.
I think if you look at the overall system (dev workstations, deployment envs, OS choices, CI, config management, ops, etc..), projects that use Go tend to have fewer components to manage and integrate and result in a simpler overall system.
Run that on your host and start your other containers on the host with VIRTUAL_HOST env variables and it will set up virtual host mappings via nginx automatically.
Bonus points that via a trie, vulcand can scale in performance linearly to 10s of thousands (or more) of urls with 0 performance impact. (I requested that feature)
We are looking for software engineers who are excited about containers, and container orchestration with Kubernetes. Who also have a passion for building DevOps tools that make it easier for people to build, deploy and scale their software on the Azure cloud.
Experience with container runtimes such as Docker, Rkt, runC, containers and how they are enabled by the underlying OS components.
* Experience with workload/container orchestration using Kubernetes or similar platforms.
* Experience with Golang.
* Experience with Linux.
* Experience with terraform or ansible.
* Experience with building, shipping and operating reliable, distributed solutions.
* Ability to engage in site-reliability engineering practices.
Senior Software Engineer: https://industryuseng-ms.icims.com/jobs/590353/senior-softwa...
Software Engineer: https://industryuseng-ms.icims.com/jobs/590350/software-engi...