Hacker Newsnew | past | comments | ask | show | jobs | submit | bcbroussard's commentslogin

Intertie | Lead Full-Stack Software Engineer | Hybrid (SF Bay Area) | Full-time

We're a clean tech startup working with solar/storage systems, backed by top tier VCs including True Ventures. We've developed an AI driven energy management system along with our own UL certified battery based energy storage systems for commercial properties. We also have ancillary products (EV charging, sales tools, etc) to make building and operating clean energy systems easier. We're running a number of live sites, have a good pipeline, and just finished raising our Series A.

We believe great software is the core of great products, especially when working with hardware. We're looking for a strong senior full stack software engineer to anchor our software team as we grow.

Lead Full-stack Software Engineer - Go/Golang, Python - Javascript, Devops, energy domain experience a plus Reach out to me (BC, CTO) at jobs+hn [at] intertie.com to make a difference in the world and help build a great company (no recruiters please).


seems lovely


Intertie | Lead Full-Stack Software Engineer | Hybrid (SF Bay Area) | Full-time

We're a clean tech startup working with solar/storage systems, backed by top tier VCs including True Ventures. We've developed an AI driven energy management system along with our own UL certified battery based energy storage systems for commercial properties. We also have ancillary products (EV charging, sales tools, etc) to make building and operating clean energy systems easier. We're running a number of live sites, have a good pipeline, and just finished raising our Series A.

We believe great software is the core of great products, especially when working with hardware. We're looking for a strong senior full stack software engineer to anchor our software team as we grow.

Lead Full-stack Software Engineer - Go/Golang, Python - Javascript, Devops, energy domain experience a plus.

Reach out to me (BC, CTO) at jobs+hn [at] intertie.com to make a difference in the world and help build a great company (no recruiters please).


Intertie | Lead Full-Stack Software Engineer | Hybrid (SF Bay Area) | Full-time

We're a clean tech startup working with solar/storage systems, backed by top tier VCs including True Ventures. We've developed an AI driven energy management system along with our own UL certified battery based energy storage systems for commercial properties. We also have ancillary products (EV charging, sales tools, etc) to make building and operating clean energy systems easier. We're running a number of live sites, have a good pipeline, and just finished raising our Series A.

We believe great software is the core of great products, especially when working with hardware. We're looking for a strong senior full stack software engineer to anchor our software team as we grow.

Lead Full-stack Software Engineer - Go/Golang, Python - Javascript, Devops, energy domain experience a plus

Reach out to me (BC, CTO) at jobs+hn [at] intertie.com to make a difference in the world and help build a great company (no recruiters please).


Here's the doc for resource constraints, called "limits" in Kubernetes. https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...

The Kubernetes scheduler looks at "fit" and "resource availability" to determine the node a pod will run on. Nodes can also have labels like "high-mem" or "ssd", so you can request a particular type of server (via the the nodeSelector field). More details are in the link above.


The page you linked to describes a slightly different feature, namely the ability to restrict and override the resource requirements of Pods at the time they are submitted to the system. So it's part of the admission control system, not part of the scheduling.

The documentation on resource-based scheduling is at https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...


Thanks davidooo - I was specifically referring to the section on "limits at the point of creation" which gives a practical example of using limits in a multi-namespace (multi-tenant) environment. (https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...).

The new documentation you linked to has good explanations in it as well.


Disclosure: co-founder of Kismatic

We've spent a lot of time working with the Kubernetes community. I can only speak to our experience, but Brendan, Craig, and the rest of the team at Google have 100% lived up to the commitment of treating the Kubernetes project as truly open and independent.

Our Kubernetes dashboard was recently merged into Kubernetes [1]. We brought our own vision of a web ui to the project, and we could have gotten bogged down defending technology decisions, and philosophical nits. Instead, the response from Google, RedHat, and others in the community, was basically "Awesome! How soon can we get it in?"

All of the key players have the right approach, and that gives me confidence in the project's longevity.

[1] UI Demo video - https://www.youtube.com/watch?list=PL69nYSiGNLP2FBVvSLHpJE8_...


The "Frameworks stopped receiving offers after a while" bug is concerning, I wonder when it will be fixed.


Why is this awesome?

Production ready Mesos hosted in the cloud.

Now I dont have to run a $500M company to cut server costs and save dev ops time. Apache Mesos is a system predominatly used by large companies, to more efficiently utilize servers in their data centers.

The traditional way of organizing your servers requires a certain number of servers per cluster. For example: 50 webservers for your web app in one cluster, 5 servers for your database in another cluster, and 10 servers for redis, etc. On average, you'd utilize 50% of each cluster, but have the extra capacity for spikes.

Mesos makes your servers way more efficient by treating them as raw power, allowing any server to run any kind of app/task. It chops a server up into many linux containers and can shuffle around your tasks, so that a web app, redis server, and database server could all be running in different areas of the same "physical" server. I read that one company saved ~40% of their server costs and served the same load just by switching to Mesos.

Marathon is made by Mesosphere and acts as the brains or controller for your servers. You can allocate what percentage of resources go to certain apps/tasks, and it also handles deployment, scaling, failover and restarting.

Mesos supports Docker, so converting an existing app to run this on DO with Mesosphere is simple. Some applications are built for Mesos already, like Spark (MapReduce replacement), and will be inherently faster without the Docker overhead.

I found Mesosphere's tutorial useful for setting up a dev environment and trying things out - https://mesosphere.com/docs/getting-started/playa-install/


>Apache Mesos is a system predominatly used by large companies, to more efficiently utilize servers in their data centers.

I love Apache Mesos as much as the next person, but this isn't true. It's predominantly used by Mesos devs. It's one of the up and coming hot technologies, but it hardly has enough users to say it's predominantly used by anyone more than enthusiasts and devs.


It's powering huge infrastructures as we speak; Twitter, Airbnb, and many others: http://mesos.apache.org/documentation/latest/powered-by-meso...


Last time I checked very few of them relied critically on Mesos (Twitter, some parts of Netflix, and Airbnb did IIRC). Most are just test deployments or non-critical applications. (e.g. I know Ebay and Paypal are also OpenStack users because they try all the new things).

Other than those, none of those are really huge companies. I have nothing against Mesos, but I hate overhyping something when it's still clearly in an early adopter phase. The side effect of overhyping is that the tooling isn't mature/simple enough for less ambitious people so they get a bad association with the project because they tried it too early after someone implied that it was mainstream already.


>>> Mesos is a system predominatly used by large companies, to more efficiently utilize servers in their data centers.

Mesos is used by companies of all sizes in their own datacenters and in public clouds, and in production.

URX and Sailthru are merely two examples of growth stage startups that are operating on Mesos. It's not just about improved resource utilization, it's also about fault-tolerance, high availability, ease of operations and developer workflow.


Sailthru doesn't operate on Mesos. While it does utilize it, it is in a very specific part of the company.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: