GitHub's journey towards microservices and more: 'We actually have our own version of Ruby that we maintain' GitHub has described efforts to break down its monolithic application architecture into microservices – and revealed that it still runs some services on AWS, even after the 2018 acquisition by Microsoft. Sha Ma, VP of Software Engineering at GitHub spoke on the subject at the November Qcon Plus virtual developer event and …
I know I'm too old to be agile and am insensitive to the Zeitgeist, but I got a distinct whiff of "Emperor's new clothes" from this interview.
We would then rewrite these queries into multiple queries that respect the domain boundaries and perform any necessary joins at the application layer
Nothing screams "modularity" like building a knowledge of your transient database schema into your applications.
For the foreseeable future we're going to remain with MySQL just because we have a lot of expertise there
If you had more expertise available with a database that facilitated doing joins across multiple data sources, you might not have had to build that into your applications. Shouldn't you be looking at the expertise you need, rather than the expertise you have, especially on a "foreseeable future" timeline?
I'm 54 and I love Agile. I worked in many places where "agile" was done badly before finding somewhere that actually made it work so I used to be as cynical as you about it.
If you can find a place to work where they understand that the business has to be agile, not just the dev team, then you stand a chance of seeing what the fuss is about!
The point I think I failed to make is that "agile", like every development methodology, is a trap, it's just a trap of a different kind.
If you're firing out frequent updates, you're pretty much constrained by the skillset of the people you have to hand (because you haven't time to reskill/rehire) and you end up with dreadful decisions (like adding cruft to your applications to do database joins) because the frequent release cycle that allows you quickly to add functionality means that long-term architecture changes have to be approached crabwise and likely with much ultimately unneeded effort to keep each iteration functional in its temporarily incomplete state.
Constant incremental change is fine right up to the point that the premises on which your development is based turn out never to have been valid, or have become invalid over time. It seems a little optimistic to assume that one development approach should be appropriate at all stages of a project lifecycle.
> "We actually have our own version of Ruby that we maintain,"
What?
Is standard Ruby inadequate? Is there some enhancement that they want to keep proprietary? Is it just Microsoft's long-standing policy of breaking things solely to disadvantage their competitors?
I doubt the answer will be enlightening (let alone enlightened).
This post has been deleted by its author
Too young to not have been around the block before then?
Ma is actually wrong in her claim that "The first step towards breaking up a monolith is to think about the separation of code and data based on feature functionality"; the first step was the architectural decision to break up the monolith into microservices. I hope they have some clarity of thought about what those microservices might be. Personally at this stage I wouldn't be thinking about what the current code and data does in that much detail, but about envisaging what it needs to do, given what we know now about the space gitHub occupies. Ie. follow normal systems thinking and enterprise architecture practises...
I would suggest that Ma's approach carries the real risk that what GitHub ends up with is a monolith of microservices, ie. something that is just as inflexible as a monolith.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
