We saved $50k/year with a Go microservice coded in a hackathon • Hacker News Board

Re: We saved $50k/year with a Go microservice coded in a hackathon

#121

Post by silveroriole » Wed, Apr 11, 2018, 7:10 AM UTC

meesterdude wrote: post #84

afterburner wrote: post #82

Earlier quoted context omitted.

While simultaneously "proving" that all projects could get done in one tenth of the time.

Well, what would be the argument against that - if in fact it does deliver code that solves a problem in a short period of time? Why can't you just do that all the time?

Sounds like a good argument for always introducing an artificial fatal flaw into your project before presenting it... so proj management can’t see it and yell “my god, it works! Let’s put this cobbled together, coffee-fuelled mess right onto prod!”

Re: We saved $50k/year with a Go microservice coded in a hackathon

#122

Post by dijit » Wed, Apr 11, 2018, 7:17 AM UTC

peburrows wrote: post #89

attaboyjon wrote: post #78

I've come to the conclusion that the problem in tech is that all the people doing the work are in their early twenties and have no idea what they are doing. Once they get some experience they are quickly promoted to the CTO position. Rinse and repeat. What we have here is a classic dbms problem and no one at Movio seems to know how to deal with that. Instead of migrating from Mysql to something serious (Postgres) the…

Overall, I agree with the sentiment of your comment, but the assertion that MySQL isn’t a serious database is just flat out wrong.

I disagree with your assertion that MySQL /is/ a serious database.

The questions I usually ask myself when evaluating database solutions is:

* Does it accept invalid data?

* Does it change data on error?

* Does the query planner change drastically between minor versions?

* How strong is transaction isolation? can I create constraints, columns or tables in a transaction?

* Does it scale vertically above 40~ CPU threads and 1M IOPS?

The answer to all these questions, for MySQL is "No". You could argue the value of some of them, but a lot of them highlight architectural or development procedural misgivings.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#123

Post by zaarn » Wed, Apr 11, 2018, 7:23 AM UTC

bufferoverflow wrote: post #113

attaboyjon wrote: post #78

I've come to the conclusion that the problem in tech is that all the people doing the work are in their early twenties and have no idea what they are doing. Once they get some experience they are quickly promoted to the CTO position. Rinse and repeat. What we have here is a classic dbms problem and no one at Movio seems to know how to deal with that. Instead of migrating from Mysql to something serious (Postgres) the…

Can you demonstrate that Postgre is significantly faster than MySQL on average? Highly doubt so. The problem is in the way data model was architected and implemented.

PG isn't usually faster than MySQL on any naive database (which is 90% of database in the world I suppose)

Most E-Shops will be fine running MySQL or MariaDB.

The one thing PG excels at however is that you can tune it much more to your workload and it allows tuning the workload much more finely than MySQL/MariaDB. That and the ability to extend PG arbitrarily (try adding native functions to mysql without recompiling) via the C-FFI offered. You can write and define your own index methods that let you use an index that is perfect for the workload or you can add a new data type to support a new input with validation.

You can sink a lot of work into getting the most out of a PG database, MySQL not so much. But again, for most people MySQL will provide the same (or even better) performance than PG. (I still trust PG over MySQL after MySQL nulled out all entries of a table with only NOTNULL columns after a nasty crash)

Re: We saved $50k/year with a Go microservice coded in a hackathon

#124

Post by rickycook » Wed, Apr 11, 2018, 7:28 AM UTC

dbrgn wrote: post #117

DCoder wrote: post #97

Earlier quoted context omitted.

This is a pretty popular pattern known as Entity-Attribute-Value [0]. It's used by many products where a) data model needs to be very flexible and allow new attributes without schema changes, or b) a typical entity has a large number of possible attributes that may or may not be set for all entities ("sparse" attributes). WordPress uses this to store post metadata, Magento uses this to store product attributes and mo…

Sounds like a great case for Postgres hstore (like OpenStreetMap does it)?

i think that’s basically what it was designed for :p

Re: We saved $50k/year with a Go microservice coded in a hackathon

#125

Post by indigochill » Wed, Apr 11, 2018, 7:28 AM UTC

attaboyjon wrote: post #78

I've come to the conclusion that the problem in tech is that all the people doing the work are in their early twenties and have no idea what they are doing. Once they get some experience they are quickly promoted to the CTO position. Rinse and repeat. What we have here is a classic dbms problem and no one at Movio seems to know how to deal with that. Instead of migrating from Mysql to something serious (Postgres) the…

Well, a problem in tech certainly. An alternative possibility (and another problem in tech) could be some mid-level developer could have figured out the problem at the start but because of artificial time pressure to deliver they didn't have the time to, so went with the first bad idea that popped into their head without taking the necessary time to evaluate it.

The fact this had to happen in a hackathon suggests a typical disconnect between management and development (and probably poor prioritization by management). Because development knew this was a problem and how to fix it (evidenced by the fact they fixed it), but it took removing management (aka a hackathon) to give development the space to fix it. And now the company pats itself on the back for having the vision to host a hackathon instead of structuring and prioritizing correctly in the first place so this would just get fixed on the clock.

I do think the author's takeaway about the value of simplicity and pragmatism are on point, but that applies not just to code but to management as well.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#126

Post by aaronbrethorst » Wed, Apr 11, 2018, 7:36 AM UTC

ksec wrote: post #116

attaboyjon wrote: post #78

I've come to the conclusion that the problem in tech is that all the people doing the work are in their early twenties and have no idea what they are doing. Once they get some experience they are quickly promoted to the CTO position. Rinse and repeat. What we have here is a classic dbms problem and no one at Movio seems to know how to deal with that. Instead of migrating from Mysql to something serious (Postgres) the…

If I ever be a CEO of the company / Startup, that one criteria I made is either I decide on all the technologies we use, or there is no CTO so i make those decision. And that criteria of technologies could be summed into one sentence. Use something boring . No Hyped programming languages / DB / tools allowed. Of course some would argue you would be doing it wrong even if it was using old tech / programming / tools. W…

I'm a fan of taking a 'one new technology' approach. When I'm building something new, I get to choose zero or one new technologies to play with, depending on whether I want to get shit done or learn something new.

By choosing at most one new thing, you can better control for how your stack should work and how you expect it to respond to certain unexpected circumstances, which means you should be able to more effectively solve issues as they crop up than you'd be able to if you were using multiple new technologies.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#127

Post by zaarn » Wed, Apr 11, 2018, 7:38 AM UTC

matte_black wrote: post #83

vishnugupta wrote: post #73

Earlier quoted context omitted.

The stack has to bottom our somewhere and it's usually at the application code

If that’s where they bottom out they should be called “mid stack” rather than full stack. If you are claiming to be full stack you better be prepared to go all the way.

I would describe myself full stack under that definition. Most "full stack" people I know that sit in my Uni courses have mostly learned Java EE + Oracle DB or Javascript + /dev/null^w^w MongoDB. Most of them would probably not be able to construct a relational database or libc from scratch.

Granted, such knowledge isn't immediately useful since it's something I or anyone is likely to do but it grants insight into systems. I know roughly how a query optimizer does and what it can, and more importantly, can't do.

When you know a system you can optimize for it. When you don't know a system you can only follow someone else's advice on how to optimize for it.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#128

Post by maloga » Wed, Apr 11, 2018, 7:39 AM UTC

firasd wrote: post #42

sankyo wrote: post #18

what did the Go solution replace? I only read about DB changes, and cannot draw any conclusions.

Right. The blog post is a good narrative over time but isn't super clear about how they solved the problem. If I understand correctly they broke down the big MySQL query into separate queries that the Go service processes/caches?

Blogpost author here. That is correct. Sorry if the explanation isn't super clear; for this particular question, you can consider the two diagrams as a before and after. They pretty much convey what you have explained here.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#129

Post by foepys » Wed, Apr 11, 2018, 7:42 AM UTC

bobwaycott wrote: post #41

hippich wrote: post #14

What else it shows - how expensive AWS hardware vs hosting own hardware. I guess you have to consider how often you have to scale, but hetzner offers dedicated servers with 64Gb and NVMe drives starting from 54 euros per month - https://www.hetzner.com/dedicated-rootserver?country=us - compare that to $580 per month these guys were paying for i3.2xlarge instance..

I’ve heard mention of Hetzner no less than a dozen times in the last couple days. What’s their deal? I’m not quite sure I grok this server auction thing they do, or how they’re so cheap.

Hetzner got in the news recently because they now offer a "cloud" product for VPS. Not in the sense like AWS where you can shut down instances and pay less but in the sense that you can buy, provision, and delete VPS via an API and pay per hour. They are also dirt cheap and offer 20 TB egress traffic with even their cheapest VPS.

How they do it? I don't know. They are using Xeon processors and not i7 like some others.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#130

Post by mhd » Wed, Apr 11, 2018, 7:42 AM UTC

matte_black wrote: post #77

nstart wrote: post #69

Earlier quoted context omitted.

Oh gosh this pattern. The first time I encountered it was in my first job where we used Magento. Super flexible. Also super slow. Does anyone have any advice how to make a db design like this work faster? Generally I thought when data is arranged like this it might be a prime candidate for document based storage. But I'm no dba so I have no idea if that would be correct.

If you are using Postgres, the JSONB datatype will let you do exactly this while still using the full power of SQL. Simply create a column where you keep a JSON object full of random user properties, if flexibility is what you want. You can even index properties.

Or just create ad hoc tables with user fields. Quite often it's not that a customer has n different fields for n entities, but a few that apply to the majority (like internal ERP ids, classifcation etc.). Put them in a few tables, index them, join them. If you don't want to parse internal DB descriptors, create a set of "schema" tables to build queries from.