Cybernetics
549 karma · joined April 13, 2011
Also if you find any mistakes I'd be happy to correct them!
We're not using zoom, but google meet - but yes, these happen completely online now.
I find that people that are doing interesting stuff often _want_ to talk about it. However, a big part of Shopify culture is "do things, tell people" - it is definitely encouraged to spend time spreading context.
It's not directly part of any rewards framework, but one metric that goes into promotions is the area of impact. By giving a talk to the guild, you can have impact on a group that's larger than your team, potentially the whole organization. It counts.
But another reward is the positive feedback, interesting discussions and new connections that you make through this.
I should have included this in the blog post: The number of components _needs_ to be kept small. Shopify's main monolith is 2.8 million lines of code in 37 components, and I'd actually like to get that number _down_.
I like to compare this to the main navigation that we present to our merchants. It's useful if it has 8 entries. It's not useful if it has 400.
In a way, components are the main navigation to our code base. A developer should be able to look at what's in our "components" folder and get a general impression of what the system's capabilities are.
Can you expand on that? I'm not sure I follow.
Also, the first try of drawing boundaries will always be varying degrees of wrong. If you have very strong boundaries at this stage, iterating on them, moving responsibilities around, can be harder.
Also, with the right tooling it's definitely possible to harden monolith internal boundaries to a comparable level.
I can see though how many smaller companies would not be in a position to build that tooling.
Anyway... there is no either / or here, as I've explained in another comment. What if you have components within a monolith, but each component has its own database, for example? What if test suites are completely isolated, so that tests for component A can not access code in component B?
You can get pretty strong boundaries with a few comparably simple tricks.
We don't use "hardware" or "VMs" to facilitate modularity.
- same database - same runtime - same deployment - same repository
That said, I don't think this is an either/or. It's a spectrum. you can have components within the same runtime and repository that have separate databases, or components that are using the same database but live in separate repos, etc.
From one monolithic app towards fully separated microservices is a spectrum, and I think developers should be enabled to move freely around that spectrum.
Thank you for the praise.
Ours kind of organically grew over time, but as I've been keeping it alive for the last few years I have a pretty good idea of how I would start it fresh.
You probably have some people in the company who either know much more about architecture than others, or are working on projects that are more interesting in terms of architecture. Find one of them, convince them to give a 15 min talk.
Announce the talk widely within the company, tell people to come to the new "architecture guild" slack channel you created to get the details / invites.
Schedule an hour to give plenty of time for discussions after the talk.
Repeat biweekly.
However, there are more interesting specifics here about things like all engines sharing a database, but having exclusive ownership of tables, as well as splitting HTTP routing over multiple engines etc.
Long story short, Rails and dependency inversion equals lots of friction. The whole framework is built on the assumption that it's OK to access everything from everywhere, and over the years we've built lots of tooling on top of those assumptions.
E.g. we heavily use https://github.com/Shopify/identity_cache with active record associations that cross component boundaries.
We also have a GraphQL implementation that is pretty closely coupled to the active record layer and _really_ wants to reach into all the components directly.
All of those problems can be overcome, but this is definitely an area where we have to working against "established" Rails culture, and our own assumptions from the past.
Erlang also has optional type annotations via the dialyzer tool and all types are by default non-nullable.
Generally I think that the dart language implementors should try harder not to copy language design fails from Java / C++, like null-pointers or half-baked enumeration types.
Just speculation ;-)
With this and steam linux edition, the future looks bright for linux gamers.
Playing colonization on linux this evening :-)
The size increase is due to a complete rewrite based on chromium.
edit: Taken from official statements on the opera desktop blog, http://my.opera.com/desktopteam/blog/