simonpantzare

Kong has been working without problems in our (small-scale) setup since we introduced it a few months back. Personally not too fond of the tooling to configure apis and consumers/credentials though. Is there a better way to manage these things than with curl?

I have been playing with Dokku lately. I ran into some problems with the Dockerfile mode (creates tags like myapp:latest but then tries to start dokku/myapp:latest) and the CLI not parsing arguments correctly (had to put extra " chars in strange places). Perhaps the Procfile mode is more polished. Would like to know if there are any alternative single-host PaaSes out there to use for side projects.

I missed the announcement of cross-account access. This seems great, thanks!

STUPS looks interesting. What scares me a bit about these suites that provide many abstractions on top of AWS is how they work in mixed environments where some resources have been set up and are managed out-of-band. I understand that the purpose of STUPS for example is to provide a higher-level interface to AWS, and that having many AWS accounts avoids these mixed environments.

Perhaps it's just me suffering from analysis paralysis. I kind of want there to be one or two leading suites of AWS PaaS tools to choose from, whereas the market today seems fragmented with new tools popping up all the time. For the moment I'm betting on HashiCorp. :)

I can see how having separate AWS accounts for dev/stage/prod makes things easier. Such as not having to think about name conflicts on ECS clusters, SQS queues, roles and whatnot. We use a single AWS account with multiple IAM users and name our resources like Uploads-Dev, Uploads-Stage, Uploads-Prod, and so on but I feel that it clutters the AWS console and makes it difficult to keep IAM and roles (as well as their access policies) simple.

Maybe I have missed some developments in AWS world, but in the screenshot of the AWS Console it says you are logged in as ops-admin @ segment. So you have one AWS account with alias set to segment, right?

Do you use an identity provider to be able to log in as calvin and is ops-account a user in your AWS account named segment? And is ops-account in the segment AWS account then allowed to assume roles in your three other AWS accounts for dev/stage/prod?

If you switch to ops-admin @ stage for example, and then go to the S3 page in the console, will you get a listing of all buckets in the stage AWS account even though your login session as calvin "belongs" to an other AWS account (segment)?

Sorry if my questions are confusing. I am very interested in knowing what the relationships among the identity provider, AWS accounts, and roles look like.

The application I work on most of the time is largely monolithic and usually I have no problems with that. Some parts have been extracted to their own codebases and are deployed separately because of performance reasons.

We also separated the main backend/API codebase from the frontend mostly because the frontend devs work prefer to work within the Node ecosystem instead of Python/Django and so that we don't have to think too much about synchronizing deployments. The tests for the backend code take quite long to run as well compared to the frontend tests, so having this separation is nice for the frontend devs that way too.

What I some times would like to have better infrastructure support for though is throwaway prototypes/projects that can live in their own codebases and have access to all the regular databases, blob storage and so on, as well as databases that are private to the prototype that I can do whatever with with no risk of doing something bad to the important databases/storage.

I would also like these prototypes to be able to register themselves with the load balancer to take care of everything under `/halloween-experiment/` for example and have the load balancer add headers like `X-UserEmail`, `X-UserID`, `X-IsEmployee`, and so on so that I don't have to implement authentication/authorization in every prototype.

Today these types of prototypes need to live next to the "important" code so that they can use the same CI pipeline and easily be made public or visible to employees and use real data.

I'm following projects like https://getkong.org/ with interest, and together with everything happening around Docker such as EC2 container service or Kubernetes, as well as projects for service discover/configuration like etcd or Consul, it feels like we're getting there. There are just so many projects to keep track of, and you need to figure out how to make them all part of your CI pipeline. :)

http://multicorn.org/ is a PostgreSQL extension meant to make FDW development easier. It lets you write them in Python.

Came here to mention this. Aside from now()/transaction_timestamp() and clock_timestamp() there's also statement_timestamp() that returns the start time of the current statement.

Seeing the same thing. Got back from vacation an hour ago, probably related. :)

-Ofair disables task prefetching which will affect throughput negatively if most of your tasks run for a short time (http://celery.readthedocs.org/en/latest/userguide/optimizing...).

Authentication in 0.9 has a high CPU penalty right now: https://news.ycombinator.com/item?id=9810538.

For those of you reading this that are interested in getting on InfluxDB 0.9. If you intend to use authentication and have a somewhat high request rate, I advise you to wait until the fixes related to #3102 (https://github.com/influxdb/influxdb/issues/3102) are included. Without that fix your CPU is killed because InfluxDB is bcrypting on every request.

Out of curiosity, are there reasons why this shouldn't be solved at the browser or even OS level? The only reason I can think of is that solutions at the app level makes it possible for people to refer to a blue line, red bar, and whatnot and it means the same for everybody. But if we need many color profiles anyway because there are many kinds of color blindness, perhaps we should just make the labels pop out or have fewer series per graph (so that we can just refer to these graphs instead of individual series in them).

I put nginx in front and a location /static/ block with a try_files directive that first tries to serve static files from Django (those collected with python manage.py collectstatic) and falls back to serve files that a gulp task generated.

To serve different assets in dev and prod I let gulp generate a manifest and have a custom template tag in Django that expands to different paths depending on settings.DEBUG:

  {% my_static 'css/all.css' %}

expands to either /static/css/all.css or something like /static/css/all.min.abcd1234.css.

If nginx is serving a minified, hashed path it adds a Cache-Control: max-age=31556926 header to the response.

As a long time Django user (first project on 1.1) I want to thank for a great framework and your wonderful release approach!

I often try out new new web dev platforms and frameworks but tend to rewrite projects that get too serious or large in Django, or when I'm starting to miss too many features.

If I know that I am building something that others are going to work on, or if I know that the project will need to be maintained for a considerable amount of time, I tend to go with Django and a few familiar libraries (Celery, Django REST framework, django-extensions) right off the bat, as I feel comfortable that we won't run into issues where some important dependency becomes unmaintained or introduces backwards-incompatible changes. Much thanks to Django's predictable and well thought out releases.

Further, when I pick Django, I know that there is good support in monitoring and crash report systems such as Sentry, New Relic, and others. So that's one less thing to worry about.

The only area where I have started to use other solutions is frontend dev, as I find that the momentum in the Node community is so much higher in this area. I only wish that the Node community wasn't as fragmented and had a more long-term view on releases.

Very nice, congrats on the release! Had it up and running and our Grafana 1.x dashboards imported in about 15min.

I was intrigued reading about the plans for alert support. Any pointers on where to start looking for somebody that may want to help build it? :)

Would love to buy a coffee or beer some time in Stockholm.

We have used RethinkDB in production for a handful of months now. 100M docs, 250 GB data spread out on two servers.

We added it to the mix because it got increasingly difficult to tune SQL queries involved in building API responses, especially for endpoints that needed to pull data from many tables.

Our limited experience of MySQL operations was also a factor. We're on 5.5 and couldn't do some table operations that seemed promising without service disruptions. There were solutions to perform the actions we wanted without downtime but they scared us a bit. We also looked into upgrading to 5.6 or MariaDB but that seemed like it would take a long time and need much testing, while there were no guarantees that we would see performance gains.

We looked for alternative solutions and found RethinkDB. We reused the parts that serialize data for the API and put the resulting documents in RethinkDB. Then we had our API request handlers pull data from there instead of from MySQL and added indexes to support various kinds of filtering, pagination, and so on. We built this for our most problematic endpoint and got the two-server cluster up and running in about a week, tried it out on employees for another week, and then enabled it for everyone (with the option to quickly fall back to pulling data from MySQL).

This turned out to work well and we saw good response times, so we did the same thing for other endpoints.

There's some complexity involved in keeping RethinkDB docs up to date with MySQL (where writes still go) but nothing extreme and we haven't had many sync issues.

RethinkDB has been rock solid and it's a joy to operate.

Django is much larger with its ORM, template system, admin site, and so on.

Feature-wise it seems close to Flask. I suspect that Flask is more opinionated than Falcon: it requires the Jinja2 template library and your project may end up with a tight coupling with Flask if you use its blueprint system or don't think through how you use Flask's context variables flask.request and flask.g (Flask tries to be too clever here IMO).

Falcon looks more like a library than a framework to me and its design seems less likely to affect how you structure projects compared to Django in particular but also Flask.

It's not like Django + TastyPie just because it uses OO. If you are building a service with two or three endpoints, that combo is overkill. “You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” comes to mind. It's closer to Flask feature-wise.

It seems to be, by and large, the work of a single person on his spare time. Very impressive!

Well, AWS CLI is built on botocore. I've used boto sinne 2012 and never got the feeling it's a second class citizen. Mitch's leaving Amazon didn't slow things down. Nowadays when new services are released there is usually a new version of boto available immediately.

The Law of Jante is nowhere to be seen. Hooray! /Swede

My understanding of Amazon's new container service is that it lets users spawn a bunch of instances that the service manages (job scheduling and so on). This is not maximizing tenants per server nor maximizing revenue per server, IMO, as it mainly lets users increase the workload per instance. Without the container service, unless they run the similar infrastructure themselves, users would have to run additional instances to have the same isolation and ease of deployment (if they use Puppet, Chef, Ansible, or whatnot instead of some Docker cluster management software).

"Lock-in through the range of services" is key. You can go all-in on AWS and use RDS, Directory Service, EMR and still be able to move off AWS and use the open source systems beneath. Granted, there are services like S3 that are proprietary but on the other hand you can move to something Riak CS that provides API compatibility with S3.

And blodpudding (http://sv.wikipedia.org/wiki/Blodpudding) is still common in Sweden.

Same goes for Swedish kids. AFAIK blodpudding (~black pudding) is still served in many school kitchens.

I deployed a three node RethinkDB cluster the other day. The process was very smooth and I love the web UI. If operating the cluster proves to be as simple, they have managed to remove so many pains that you need to deal with with other vendors that paying for a hosted version makes little sense.

The problem is not that people call out bad code but that they attack the person who wrote it. I bet that the voices criticizing Stallman now will not praise him for GNU next time they cash in on projects built on it.

I think Ben Golub plays a part in that. As superuser2 says, enterprises make up a large chunk of Docker's market. Github is also tapping into this segment—most of their recent hires are extensions to their enterprise support, sales, and account management teams.

That is one of the big things Django 1.7. "There's a new built-in schema-migration framework."

I got interested in building something like this when I saw Docker issue 410[1]. If my understanding is correct Mesos uses Zookeeper to keep a Mesos master available. Zab, Zookeeper's distributed consensus algorithm, is similar to Raft which has a popular Go implementation[2] written by Ben Johnson. Perhaps Flynn agents can use this implementation.

1. https://github.com/dotcloud/docker/issues/410

2. https://github.com/benbjohnson/go-raft