Running on Google Container Engine or Elastic Container Service

Rafał Sobota

unread,

Mar 12, 2016, 4:31:57 PM3/12/16

to Lagom Framework Users

Hi!

Do you have any experience with running Lagom on Google Container Engine or Elastic Container Service?

Russ White

unread,

Mar 13, 2016, 3:40:35 PM3/13/16

to Lagom Framework Users

+1 Would love to see how to use Lagom in a truly elastic (auto scale-in/out) cloud deployment environment (AWS in particular) either with ConductR or without. ECS is of particular interest.

Christopher Hunt

unread,

Mar 13, 2016, 6:43:17 PM3/13/16

to Lagom Framework Users

The ConductR perspective on this is that 1.2 (in progress) will incorporate auto scaling both within an existing cluster and also of infrastructure. We will be integrating with EC2 with regards to infrastructure scaling.

We are integrating with Lightbend monitoring in order to make scaling decisions based on metric thresholds for services. They'll be a blog and webinar when toward 1.2 being released.

Russ White

unread,

Mar 14, 2016, 12:21:35 AM3/14/16

to Lagom Framework Users

Being limited to scaling within a static AWS EC2 cluster is not anything close to being "elastic". :) You would have access to (and pay for) the same raw compute capacity all the time - why not use it all? Scale-in is as important as scale-out unless infrastructure cost is not a factor

What about using CloudWatch metrics/API which already exist for AWS to trigger infrastructure scaling events? Is that integrated into Lightbend Monitoring?

In any case I hope to here more about ConductR 1.2 soon. These are the last few details I need to know to really be sold.

Thanks!
Russ

Rafał Sobota

unread,

Mar 15, 2016, 5:27:03 PM3/15/16

to Lagom Framework Users

I like the idea of this kind of opinionated framework. It could be the modern Ruby on Rails for big things. Furthermore it could be the framework for most of things. Startups could be scalable from day one instead of changing technology and rebuilding everything from time to time. It could have vibrant community and open-source microservices on Github. I could use it for big and small projects at work or for hobby.

I could at least believe in it and I would be sold if proprietary deployment technology was optional. Do you have plans to make it easy to deploy Lagom without ConductR as Google did with Cloud BigTable and Cloud Dataflow?

Christopher Hunt

unread,

Mar 15, 2016, 7:17:39 PM3/15/16

to Rafał Sobota, Lagom Framework Users

On 16 Mar 2016, at 8:27 AM, Rafał Sobota <ravs...@gmail.com> wrote:

I could at least believe in it and I would be sold if proprietary deployment technology was optional. Do you have plans to make it easy to deploy Lagom without ConductR as Google did with Cloud BigTable and Cloud Dataflow?

Lagom itself is agnostic to ConductR. We’re hoping that the community will help target it to other deployment technology. We can certainly help and advise, but we do not have the resources to perform this activity right now.

Our production overview document should help a little in terms of explaining what you need to provide, and what you should be looking for in a deployment technology: http://www.lagomframework.com/documentation/1.0.x/Overview.html.

Thanks for the question.

Nico Huysamen

unread,

Apr 9, 2016, 3:27:57 AM4/9/16

to Lagom Framework Users

+1 Would just like to throw my vote in there. Having FOSS Lagom running in Kubernetes instead of having to use ConductR would make this a game changer.

Mirco Dotta

unread,

Apr 9, 2016, 4:08:15 AM4/9/16

to Nico Huysamen, Lagom Framework Users

https://github.com/lagom/lagom/issues/59

PR welcomed! :-)

-- Mirco

Sent from mobile

--
You received this message because you are subscribed to the Google Groups "Lagom Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lagom-framewo...@googlegroups.com.
To post to this group, send email to lagom-f...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lagom-framework/d29f8e87-6454-439b-933a-f8f0057800d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Christopher Hunt

unread,

Apr 9, 2016, 10:07:31 AM4/9/16

to Mirco Dotta, Nico Huysamen, Lagom Framework Users

PR also started:

https://github.com/huntc/kubernetes-lib/tree/master

I'll get to this a bit more very soon.

You received this message because you are subscribed to a topic in the Google Groups "Lagom Framework Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lagom-framework/h2e45aaSBWE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lagom-framewo...@googlegroups.com.

To post to this group, send email to lagom-f...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lagom-framework/55CE2928-7048-48BF-B67B-9DE8B3E28EC4%40gmail.com.

Nico Huysamen

unread,

Apr 21, 2016, 12:25:51 AM4/21/16

to Lagom Framework Users

Please correct me if I'm wrong, but wouldn't one be able to use this in Kubernetes in a simple way by just piggy-backing off K8s built in service location? Is there some simple way in which you can tell the Lagom service locator to use environment variables to determine the service addresses? I have only skimmed over the docs (busy trying out some things now) but it seems it should be relatively easy for external services, but you don't really want to declare your internal services as external. That feels wrong.

Or am I missing something here?

On Saturday, March 12, 2016 at 11:31:57 PM UTC+2, Rafał Sobota wrote: