jadeklerk
Also, regarding point 3, I'm confused with two things:
- You want "free form" data, but you're talking about protos in the context of Go. How would you define this "free form" data in Go?
- You explain that "free form structured data is important for systems that accept foreign data ... where the schema isnt known". Why are you using protobufs for this usecase? Protobufs are specifically meant to make the schema known, and be enforced by serialization.
I think hosted kubernetes was easily the better option for us.
For PaaS products, GAE is comparable to AWS Beanstalk (or Heroku, or CloudFoundry, etc).
For "serverless" products * , AWS Lambda/Step Functions are comparable to Google Cloud Functions.
* Serverless in the product sense rather than the literal sense.Panasonic is building a connected vehicle system for car-to-car, car-to-operator, operator-to-car, and accident/weather/etc detection. We're still a fairly small team within the larger Panasonic, but we're growing and are looking for someone senior to take the frontend.
The frontend app is Go in the back and react/redux in the front using google maps to do some of the heavy lifting, and several custom layers on top of gmaps. The app (back and front) has to stream data at super high rates over websocket (alongside traditional REST) (cars send a lot of data!) and have it available in near real-time, so there are many interesting high-data-flow visualization, correlation, and aggregation problems that ends up happening in or near the frontend. The future probably holds a fair amount of svg drawing work, which should be pretty cool (graphs, animations, that sort of thing).
Auxilliary technologies include Karma/Jasmine/Enzyme for testing (which is also quite interesting on this project, given the high data flow and reliance on drawing tools), webpack and babel for build, concourse.ci for CI and automated deploy, AWS as our IaaS.
If you're interested in talking to an engineer about what we do, hit me up at [email protected].
If you're interested in applying or talking to a recruiter about the job, hit up Jessie at [email protected].
runC is the most commonly used - it is used by containerd (which is docker's wrapper), garden (which is cloudfoundry's wrapper), and CRI-O (which is kubernete's wrapper).
rkt is another container company, whose wrapper is (afaik) just called rkt, and whose runC equivalent is systemd-nspawn, which does not meet OCI spec last time I checked.
You can save targets.
Also, if you want logs to appear somewhere you can pretty easily set up a after-fail job to ftp em somewhere.
I've used concourse as a consumer for 3 years and I've very, very rarely seen any of the problems you're describing, even on the older versions and certainly not in the last year or so.
> no scheduling to speak of
Concourse has a massive scheduling system built into it.. https://github.com/concourse/atc
Furthermore, you can configure jobs to run in serial (default is parallel).
> ui freezes
Put your `web` binary on a decently-sized VM and your problem should disappear. Also, don't have your workers on the same VM as your `web`.
I've used teamcity, jenkins, gocd, circleci, concourse, and travisci. For multi-project systems, concourse is king. (I like travisci for by-itself, non-system projects)
> The UI is clunky.
What? You just said the UI looks good... It's simple and clean; everything is async javascript (no page loads).
> The abstraction layer is too low and leads to a lot of repeated YAML. Which leads to YAML programming.
Which is an intentional choice. If you don't like YAML, use one of the MANY yaml abstraction layers of your choice...
> There are simple scenarios like deployment rollbacks who are hard to do.
First of all, a CI system shouldn't be your answer to rollbacks. Your deployment system should handle that. Secondly, assuming your deployment system can do rollbacks, concourse has on-fail jobs that can trigger rollbacks just fine.
> For some reason they decided to develop their own container engine which leads to all sorts of trouble and maintenance issue. It's generally slow and we had 100% CPU usage when the worker was doing almost nothing.
garden is used because cloudfoundry builds it. It is not slow... it is a light layer on top of runc (as opposed to docker which is a rather heavy layer on top of runc). You should pretty much never have to care about it, and in 3 years of using concourse I haven't had to - and we have some pretty gnarly large pipelines.
Also I call rubbish on your 100% CPU. I have two workers t2.xlarge workers running 22 and 30 containers (like, right NOW) and neither is above 10% CPU (which, actually, I should make those a lot smaller). Don't run workers on a potato and you'll be fine.
> Gitlab CI is much better. Or even Jenkins is better.
Ohhh you're trolling.
What? It's just STDOUT.. Are your logs going to a file or something?
A CI that runs one job (test) for lots of branches is differnet than a multi-pipeline CI that runs lots of jobs for a single branch (which is what concourse aims to be).
Are you running it on a potato? :) We have massive builds that have never had problems in the UI.
Panasonic is building a connected vehicle system for car-to-car, car-to-operator, operator-to-car, and accident/weather/etc detection. We're still a fairly small team within the larger Panasonic, but we're growing and are looking for someone senior to take the frontend.
The frontend app is Go in the back and react/redux in the front using google maps to do some of the heavy lifting, and several custom layers on top of gmaps. The app (back and front) has to stream data at super high rates over websocket (alongside traditional REST) (cars send a lot of data!) and have it available in near real-time, so there are many interesting high-data-flow visualization, correlation, and aggregation problems that ends up happening in or near the frontend. The future probably holds a fair amount of svg drawing work, which should be pretty cool (graphs, animations, that sort of thing).
Auxilliary technologies include Karma/Jasmine/Enzyme for testing (which is also quite interesting on this project, given the high data flow and reliance on drawing tools), webpack and babel for build, concourse.ci for CI and automated deploy, AWS as our IaaS.
If you're interested in talking to an engineer about what we do, hit me up at [email protected].
If you're interested in applying or talking to a recruiter about the job, hit up Jessie at [email protected].