Did I read that right or did you mean €1,300/month? 
€1.3 million a month? 
Can you share what kind of app is it and how many requests per second? I think (I’m guessing) even WhatsApp’s server costs are nowhere near that 
What about making use of BEAM goodies like ETS or Mnesia? For speed I’d want to utilise in-memory stores if at all possible (not sure how suitable this would be for an e-commerce shop tho).
I’m with you on this one. Database access tends to dominate esp. in these kinds of applications; and the OPs mention of ‘mindblowing business logic’ is suggestive of that.
@mendicm Hi there and welcome to the forums. Migrating this project (which from the sound of it is the company’s main product) to a new tech stack sounds riskier than it needs to be. Perhaps it would be safer to first try to extract small pieces of this into separate services using Elixir to get a good feel for the technology and see what production and support looks like. That could boost your and your team’s confidence before attempting to port the eshop- plus, if you’ve already broken some pieces out of it, it should be easier than trying to port all of it at once
€1.3mil is the monthly cost for the whole company, not just any single app. It’s a very big company with thousands of developers and dozens of products. The team I’m working with spends around €5k/month on AWS for all their apps, databases and other associated infra (like EMR clusters and such).
Keeping stuff in memory is fine, but there’s little perceivable difference to a user between a Redis Cache and an ETS cache. It’s another one of those “10x faster” situation, but it’s 20ms vs 2ms. I don’t even think the difference is that big, though.
I wouldn’t use mnesia for something where losing data isn’t an option… It’s just not meant for that.
I know you probably don’t agree that it’s a viable comparison, but there’s a reason that most “modern” cloud architectures look an awful lot like the BEAM’s supervision and concurrency models, just on a large scale. K8s, Serverless and the like are essentially OS level BEAMs with less efficient message passing and process spawning.
If folks are on the cloud, proper parallelism matters a whole lot less in practice.
The place where it makes the biggest difference is in embedded systems, which is the last place the BEAM is essentially uniquely qualified to be. I would never tell someone to write an embedded application in anything other than a BEAM language.
What about complementing the platform with OTP like features? For example using F# along akka.net or protoactor sounds reasonable 
I understand that an incredible advantage of BEAM languages is that they already come with OTP (less configuration, faster development cycle).
Haven’t really tried it (and don’t know the trade offs fully) but CubDB sounds good enough for simple use cases.
Ah I see, that makes sense. (Although I’d consider building my own DC at that scale.)
Being able to do so much of it in Elixir/Erlang is great tho 
From Elixir In Action (Manning) (for the benefit of the OP):
They had their own DC, but are nearly done moving to AWS because their DC was just in one region but they’re live in multiple regions now, and they didn’t want to have to build and manage 5 data centers around the world.
Yes, and I discovered another one, Crimson Ecommerce by @amacgregor , but its in very early days.
Do you mind telling us what other options your team is considering, and why? Just for context.
Thank you
Oh, I’m just a consultant. They don’t involve me in those sorts of decisions.
Developer behind CrimsonCommerce here, been working on the ecommerce domain for 13 years or so with Magento, Shopify, Workarea, and many others.
Happy to answer any questions or bounce any ideas.
I am very interested if you ever written – or you are aware of somebody else who did – a list of mandatory features for each e-commerce; I am not talking easy stuff like orders and customers and products but also product variants (colours, sizes), product bundles (20% off when you get 10 of something), different taxing rules per country or state, all of that.
I have always been a bit interested in e-commerce but I’d appreciate some ruleset because otherwise things get very chaotic in projects (and I’ve been in 3 e-commerce projects).
I would look at Shopify’s API to begin with as a reference. They paved the way with all of the data models for that. You can use that as a guide to design your own models and relationships.
Not really, the main performance issue is model hydration from no-sql database like elasticsearch, it consumes a big slice of the pie, the other big slice is the framework bootstrap. We minimized queries like crazy and real query time is about 40ms max. of the entire 800ms request. Surely we can squeeze this system a little more but with big structural changes that maybe deserve an entire framework change.
Thanks!
Phoenix is quite minimal and has been proven to be almost of no overhead (lost the links, sorry!).
I’d be interested in how would you dig deeper in finding how do your request finish in 800ms.
Wow, that’s incredible. I know some of these ORMs can be really slow, but that’s just an unbelievable amount of overhead to instantiate some objects!
So, in this case it doesn’t look like it’s the language that’s the problem, per se, but the framework, and yes, Phoenix (and Ecto in this case) is going to offer you a significant improvement. Unless you’re doing really expensive custom type casting (which you can totally do if you want), it’s going to be relatively quick to pull thousands of records from some data store and turn them into structs.
Also, have you tried dropping the ORM and going to something a layer lower? I’ve done that for a Python project recently and it made a huge difference.
We use tools like https://blackfire.io/ or simply the laravel debugbar to see where the time is wasted. We can see the number of queries performed, time per query, a detailed function stack trace rendered as a tree with number of times a function is called and time executing, i/o, memory consumption, etc.
I’m curious about what is the library used to fetch this data from Elastic Search.
This is one:
https://github.com/danielberkompas/elasticsearch-elixir
There may be more, but I trust Daniel’s work.
I don’t think there is such a list the tricky thing is that even the stuff you called easy is not always so, take product variants fairly standard yet platforms like Shopify have a limitation of only 3 attributes and max 99 variants, Magento in the other hand let’s you have as many as you want but the architecture supporting that is complex.
© Copyright Elixir Forum | Terms | Privacy & Cookies
