Why you should care about this project:
You wouldn't spend months building your own Linux distribution, so why spend time reinventing the wheel with chef/puppet/ansible?
We're not building a PaaS. Like a Linux distribution, we're integrating open source building blocks (logging, service discovery, scheduling) so that you can focus on app development and analytics instead of sysadmin tasks.
I would really love to know more as I'm investing quite a bit of my time on this stuff.. I'll not be in NYC (unfortunately), could you please share you're slide then? Or maybe having a chat?
"When Mesos Met Consul" is a great topic for a talk, because I don't understand why you'd use both. Doesn't Mesos/Marathon remember what jobs it is running and where?
tl;dr: mesos/marathon run the tasks, consul exposes the tasks in DNS.
Both Mesos and Marathon store different views of task state on the cluster.
How do we use this data to make it easy for jobs to find one another? Can we use this information to automatically configure things like Load balancers?
This is where tools like consul and mesos-dns come in. They populate a DNS store, so that task-name becomes something like task-name.example.com. If you are running 10 copies of a service across different hosts, DNS will have 10 entries.
If a container moves to another system, DNS is updated on the fly.
We can embed health checks with consul, so that if a service is unhealthy, it gets pulled out of DNS.
Consul also is nice because the edges perform the checks (instead of a central server), so the load is distributed.
In ansible.cfg, is a default of "host_key_checking = no" and "record_host_keys = no" a good idea? Shouldn't one ship things as secure by default and let the user disable host keys?
They have the same non-technical business benefits, of charging per-usage, preventing piracy and decompilation/reverse-engineering etc.
Although microservices are more trouble to manage and have more (serialization/transport) overhead than a local lib, if it's all hosted in the same cloud, it can be OK - and even a multicore advantage (if you can parallelize).
I'd expect cloud providers and library/service vendors to be pushing microservices, even when the purely technical benefits don't quite add up...
Here's how you would deploy it in microservices-infrastructure:
1. You'd deploy the cassandra mesos framework, giving you HA cassandra. Instead of setting IPs, you'd connect to this as cassandra.service.consul
2. You'd launch a Kong container in marathon. It would show up in dns as kong.service.consul for other apps to find, so you don't have to hard code IPs in your config.
We're not building a PaaS. Like a Linux distribution, we're integrating open source building blocks (logging, service discovery, scheduling) so that you can focus on app development and analytics instead of sysadmin tasks.
I'll be giving a talk to the NYC Mesos user group this Wednesday June 17th: http://www.meetup.com/Apache-Mesos-NYC-Meetup/events/2229328...