[HN Gopher] Encountering some turbulence on Bitbucket's journey ...
___________________________________________________________________
Encountering some turbulence on Bitbucket's journey to a new
platform
Author : daigoba66
Score : 42 points
Date : 2021-07-08 17:13 UTC (5 hours ago)
(HTM) web link (bitbucket.org)
(TXT) w3m dump (bitbucket.org)
| rossdavidh wrote:
| So, bitbucket is not going to self-host, they're moving to an AWS
| based Atlassian product.
|
| For many companies, it makes sense to use AWS (or a product based
| on it). For a company like Bitbucket, that is almost like if AWS
| decided to stop self-hosting, and use Google or Microsoft's cloud
| products instead, with their "product" just a wrapper on top of
| that. What is the point of Bitbucket, again? It's now a wrapper
| around a wrapper (Atlassian) around a wrapper. Except, it doesn't
| work that well.
| otabdeveloper4 wrote:
| Yeah, running a datacenter is their core business. The UI
| around git hosting is not that important, despite what people
| think. (People overestimate UI in general; like medicine,
| government and sports, everyone has an opinion on how to make a
| computer UI done right, though strangely nobody can deliver.)
| maximilianroos wrote:
| > our engineers implemented a solution where we would proactively
|
| > our engineering teams prioritized their efforts to ensure that
| Bitbucket
|
| It's not a coincidence that company that refers to "our
| engineers" rather than "we" is having basic engineering problems.
| ahmedfromtunis wrote:
| I don't view this a bad thing; just a sign of recognition for
| the teams that did the job. Using "we" may come off as if the
| management is taking credit for the job. Or at least, that's
| how I see it.
| dtao wrote:
| I wrote this post and that's definitely how I meant it! Our
| engineers are awesome. I think the word "we" appeared more in
| earlier drafts and I changed it in a few places because
| frankly I don't deserve any credit for the majority of
| incredible work they did.
| mdoms wrote:
| I worked for Atlassian for 3 years. They are a VERY
| engineering-focused organisation. Both of the CEOs have
| engineering backgrounds and the whole company is organised
| around engineering teams. I think you're looking too deeply
| into some off-handed phrasing there.
| meragrin_ wrote:
| > As we planned for this migration
|
| > Our focus was primarily on read operations
|
| > In contrast, we accepted that there would be increased
| latency for writes
|
| It didn't sound like they were throwing the engineers under the
| bus at all to me. They seemed to be highlighting that
| engineering executed well on the items management wanted them
| to focus on.
| stereosteve wrote:
| Running a git server is a bit more challenging than running a
| traditional stateless web app because git is all filesystem
| centric. If you use NFS, pages that require many git operations
| can be very slow. Or if the storage servers have a low-level API
| some page loads might require many round trips and increased
| latency or long queues can make things bad.
|
| Gitlab went thru a similar journey from NFS to a high level git
| api called gitaly:
|
| https://about.gitlab.com/blog/2018/09/12/the-road-to-gitaly-...
|
| https://gitlab.com/gitlab-org/gitaly
|
| There are some other projects like this one that seek to address
| the problem:
|
| https://github.com/takezoe/gitmesh
|
| Git is already good and synchronizing between peers, but it's not
| low latency, so does require an extra management layer to make
| sure everything is correct.
| handrous wrote:
| I was on a project for which I built a kind of git hosting (as
| a side-effect of, or to support, other features of the product
| --we weren't a git-host-as-a-service, exactly) and ran into two
| things:
|
| 1) Locking. It's a pain in the ass. You're probably going to
| need to take it over or otherwise work around it, some how. I
| never did[0], but likely should have. At scale and with
| unreliable HTTP operations and all kinds of crazy stuff
| triggering writes to repos, you're going to end up with locking
| problems at some point.
|
| 2) Caching. Cache the hell out of metadata. Cache entire repo-
| wide metadata read operation output. Cache commits. Cache
| archives. Cache, cache, cache. Cache early, cache often.
|
| [0] in my defense, I built the whole thing solo and there are
| only so many hours in a day, and that _was not_ the only thing
| I was working on.
|
| [EDIT] this was, like, 2011 or 2012 or something, so there was
| a lot less info floating around about how to do this, too.
| otabdeveloper4 wrote:
| Atlassian is truly an embarrassing company.
| sgt wrote:
| Why?
| fennecfoxen wrote:
| I use Atlassian Jira regularly. The UI is actively hostile to
| coders, making things like code blocks hard to work with, and
| layering on a few gratuitous stupidities like rendering the
| common Python filename __init__.py as an italic-_init_ dot
| py, or O(n) as an O and a thumbsdown emoji.
|
| It's a good thing people don't use Jira to write softw-- oh.
| Y_Y wrote:
| Still better than Confluence.
| helldritch wrote:
| This has been really frustrating me lately.
|
| Sometimes I just want to quickly merge a small change (maybe a
| small config change, 1/2 lines) and then pull on master, branch
| off and start working again.
|
| I'm regularly having to wait several minutes for the merge and
| while I know that there are ways around this locally it just
| annoys me that something so simple is taking so long.
|
| This feels less like an apology and more like Atlassian saying
| "Us changing a platform which has worked a certain way for years
| and that breaking your workflow is YOUR PROBLEM. It's you looking
| at this wrong, merges have been asynchronous all along." despite
| our many combined millennia of experience being entirely to the
| contrary.
| xunn0026 wrote:
| So they are migrating to an internal Atlassian Cloud and the
| production deployment (after 1 year of development) is hitting
| some performance issue.
|
| Seems to be expected. Things rarely deploy flawlessly.
|
| Sadly BitBucket isn't what it used to be ever since they dropped
| Mercurial and Microsoft acquired GitHub (and introduced the super
| generous Actions / build servers). I see no reason nowadays to
| recommend them.
| gremlinsinc wrote:
| I was honestly worried about Microsoft/Github...but I'm
| pleasantly surprised out how much better Github is now than it
| was a few years back even.
| hkchad wrote:
| This right here is why we will not be moving our Self-Hosted BB
| to their 'cloud'. I can't afford these kinds of outages and being
| 'small' we can yell and scream all we want and they won't care.
| I'd much rather have the control in my hands when something goes
| wrong. Goodbye BB!
| bsagdiyev wrote:
| Don't worry, yelling and screaming as a larger self hosted
| customer doesn't work either!
| softwaredoug wrote:
| People can hate on BB, but this is a very well written and
| transparent update on what's happening, why, and when to see
| resolution to the issues.
| ralph84 wrote:
| It seems like Bitbucket has always been the afterthought in
| Atlassian's stack. Are Bitbucket Cloud and Bitbucket Data Center
| still two separate code bases with different APIs?
| bsagdiyev wrote:
| Yes. And data center is a huge pain to work with in a clustered
| environment, it almost feels like they want you to not use it
| and use their cloud offering instead.
| ArchOversight wrote:
| The same is true for any of their other products.
| JIRA/Confluence are the ones that I am most familiar with.
___________________________________________________________________
(page generated 2021-07-08 23:01 UTC)