Container Solutions, an Amsterdam cloud consultancy, blogs about containers, Linux capabilities, Raft, GitOps, and microservices.
HN commenters recommend its Raft explainer and its Linux capabilities deep dive by Adrian Mouat; it also appears in hiring threads.
Container Solutions | Amsterdam, Berlin, London, Zurich | ONSITE | FULLTIME | container-solutions.com
We help clients build confidence with cloud technologies and transition to microservices. We work with cloud native vendors on next-generation open-source tools. We're growing our Amsterdam (HQ) and Zurich offices and creating new engineering teams in Berlin and London. We are hiring for potential, not for skills.
We are looking currently for:
Cloud Native engineers (all offices)
Background in development or operations with some experience in microservices, CI/CD, technologies like Docker, Kubernetes, Mesos, cloud (AWS, Google, Azure), cloud automation and provisioning (Terraform, Ansible, Cloud Formation etc). We value consultancy skills and community work (open-source projects, meetups and conference talks, blogging).
Expect mainly short-term projects (2-4 months) mostly delivered from our offices. We automate the infrastructure of our customers and deploy on top of it orchestration layers for running apps and data. We work in small self-managed teams that take full responsibility for the projects. We're not tech/cloud service resellers, we mix the best open-source tools and services that make sense for the project.
All our engineers are encouraged to share their knowledge at conferences and within the company. We consider ourselves a continuous learning company. Switching between projects/roles/offices is possible and quite common.
Front-End Developer…
Not sure exactly but any job ads I've seen for the likes of Monzo and Starling talk about backend engineers that have a deep knowledge of CI/CD and you don't do that on a mainframe.
Also, Monzo are heavy users of Kubernetes, so again, no mainframe. [0][1]
Starling use AWS and GCP [2]
In addition, the cost of entry of a mainframe system is a high bar when you can spin up a server on Azure in seconds and deploy code to it in a handful more seconds and then scale it to the heavens in yet just a few more seconds... all for less than the hourly cost of the IBM salesman.
I've yet to see any jobs that mention mainframes, Cobol or the like.
[0] - https://monzo.com/blog/2016/09/19/building-a-modern-bank-backend
[1] - https://www.8bitmen.com/an-insight-into-the-backend-infrastructure-of-a-modern-digital-bank-monzo-architecture/
[2] - https://blog.container-solutions.com/starling-how-to-build-a-bank-in-a-year
Amsterdam, Container Solutions, http://container-solutions.com. Docker, Mesos, Microservices consultants.
We are looking for the best developers and ops engineers to help our clients to deliver their software faster.
Our main business is consulting in the Programmable Infrastructure/DevOps/Continuous Delivery area with the focus on Docker and Mesos.
Our consultants almost never work more than 3-4 days a week at clients and spend the rest of the time building great stuff, hacking, drinking beer and trying to build new exciting products.
We are looking for both software developers and sysadmins but we especially welcome people that can do both, writing code and making it run in production at large scale.
We encourage our engineers to open source as much as possible, write about it and speak at conferences and meetups.
> The minimal Ubuntu 12.02 image is 627MB. Add your own application layer, and your container will most likely weight more than 1GB.
I've read that using Debian (or if possible Busybox) helps in this area. See http://container-solutions.com/2014/11/6-dockerfile-tips-official-images/ and http://jonathan.bergknoff.com/journal/building-good-docker-images for tips.
> Every time your application is updated, check the Gemfile md5 and see if it’s different from the latest build
Wouldn't you need to check Gemfile.lock? With optimistic/pessimistic version constraints you could get newer gems without updating the Gemfile.
Nix
https://jakob.gillich.me/post/2016-03-22-self-contained-development-environments-using-nix/
https://ariya.io/2016/06/isolated-development-environment-using-nix
You can easily automate provisioning and deployment with Nixops:
http://container-solutions.com/step-towards-future-configuration-infrastructure-management-nix/
But if you need to share/deploy what you worked on, in some place where you might not have Nix available, you can just as easily create Docker containers out of your Nix expression:
http://lethalman.blogspot.co.uk/2016/04/cheap-docker-images-with-nix_15.html
I can even use manifest lists and have the same FROM for different archs: http://container-solutions.com/multi-arch-docker-images/ - that's what I meant saying that it's here. Just that it isn't advertised.
The problem is, Docker official images (e.g. alpine, ubuntu, debian, python, node, etc) don't do this, so every Dockerfile that uses those as a base needs to be edited by hand, and you have to trust someone for unofficial base images (or build and maintain them on your own).