Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CircleCI Down

status.circleci.com

Post reply on HN
Print view View original

51–60 of 60 posts

Re: CircleCI Down

#51

Post by justin_oaks »

CSSer wrote: post #50
justin_oaks wrote: post #30

Earlier quoted context omitted.

I agree with the sentiment that people should evaluate whether or not they need an external service to run their builds. That said, there are a number of reasons to not use the Jenkins server in the office: 1) Someone on staff needs to maintain it. 2) A single hardware failure can cause significant downtime. 3) Your office internet service may have limited bandwidth and be a bottleneck for your build or artifact depl…

Not to change the subject but point one is such a sticky point that a lot of the non-technicals or semi-technicals get overly hung up on in my experience. It's a very valid concern, and personally in this case I would say even more so because the potential pitfalls of maintaining physical hardware are no joke. However, I keep running into situations where that point is touted out for even compromising, intermediary a…

You make valid points.

I cited problems with hosting something on-site, but didn't list the problems of integrating with a service too.

When you integrate with a service you need a member of staff to maintain that integration too. Of course we hope that the integration is easier than maintaining a server but that is not always the case.

You also take on the risk of the SaaS being flaky, like we see with CircleCI.

The SaaS can always raise their prices or go out of business, requiring your company to switch off of that service.

Maybe the SaaS is a security risk. What happens to your company data and builds if/when they get breached?

There's no silver bullet, there's just a set of trade-offs. You get to decide which is best for your use-case.

Re: CircleCI Down

#52

Post by aftbit »

CircleCI used to be an absolutely awesome way to set up CI. The default images just worked for the vast majority of cases. Sure, it always took a bit of fiddling with YAML, but IMO was way ahead of Jenkins et al when it came out.

Then they reworked their YAML format to enable pipelines (and make everything way more complicated, and break all our existing flows). Then they reworked their images to make them more efficient or something, but now there is almost never an image that has everything I need, so I have to build my own image in docker (with yet another CircleCI job). Now that Github Actions exists, we have been slowly migrating everything off CircleCI. Too bad they lost the simplicity that brought us there in the first place.

Re: CircleCI Down

#53

Post by justin_oaks »

egwor wrote: post #35
justin_oaks wrote: post #30

Earlier quoted context omitted.

I agree with the sentiment that people should evaluate whether or not they need an external service to run their builds. That said, there are a number of reasons to not use the Jenkins server in the office: 1) Someone on staff needs to maintain it. 2) A single hardware failure can cause significant downtime. 3) Your office internet service may have limited bandwidth and be a bottleneck for your build or artifact depl…

And also consider the cost of running it there too (heat/energy/noise/space costs)

Good point. Those are very real problems too, especially in small office environments.

You don't want that server in some spot where someone can accidentally kick it and suddenly the server goes offline. You also don't want it in an unventilated closet where it'll overheat.

As for noise... in this day and age of open office spaces and chatty coworkers, you'll be lucky if the server noise is your biggest problem. Unless everyone is working from home, and now the problem is physically accessing the server if it goes down or needs other physical maintenance.

Re: CircleCI Down

#54

Post by justin_oaks »

xyst wrote: post #48
Nextgrid wrote: post #25

I wonder how much it's going to take before people realize that maybe a single server somewhere in the office running Jenkins isn't that bad of an idea after all. Unless you're Google, "scale" will inherently not be a problem, and risks of operator error can be reduced by scheduling maintenance at times where an accidental outage won't impact your business.

in some cases that single server is bob's 2016 MBP because management is too cheap to buy a dedicated server

Extra points if management is too cheap to buy a dedicated server, but is willing to pay for 3rd party services.

Re: CircleCI Down

#55

Post by CSSer »

justin_oaks wrote: post #51
CSSer wrote: post #50

Earlier quoted context omitted.

Not to change the subject but point one is such a sticky point that a lot of the non-technicals or semi-technicals get overly hung up on in my experience. It's a very valid concern, and personally in this case I would say even more so because the potential pitfalls of maintaining physical hardware are no joke. However, I keep running into situations where that point is touted out for even compromising, intermediary a…

You make valid points. I cited problems with hosting something on-site, but didn't list the problems of integrating with a service too. When you integrate with a service you need a member of staff to maintain that integration too. Of course we hope that the integration is easier than maintaining a server but that is not always the case. You also take on the risk of the SaaS being flaky, like we see with CircleCI. The…

> When you integrate with a service you need a member of staff to maintain that integration too.

I really like the way you worded this. I think in hindsight it's obvious but you conceptualized it in a way that I've found hard to communicate to others so far. I see now that this is probably because I've been so zeroed in on my own idiosyncratic technical issues with a given service when applicable rather than expressing it through the criteria the people I report to must consider when evaluating solutions brought to them, so thank you for that!

Re: CircleCI Down

#56

Post by nerdjon »

tauntz wrote: post #39
nerdjon wrote: post #29

I still fail to see the heavily opinionated appeal of CircleCI over running a dockerized Jenkins instance (and agents) in AWS. (Or GitHub Actions or any other managed CI environment) We get all the customization I want and it scales just fine. But I am also still annoyed that when CircleCI announced their templates, they did not offer you the ability to have private templates (or something along those lines, it left…

There are _a lot_ of companies/teams that don't need/want to manage the complexity that comes with setting up and configuring generic CI environments. They want to get going as fast as possible and never have to think about what's going on behind the scenes - that's especially true in some specific areas. For example mobile apps. 90% of people aren't too happy about managing all the complexity that comes with having…

I will admit that needing to build mobile apps in CI is one particular challenge I have never needed to deal with.

But I can see that specific use case being a good one for an opinionated CI environment.

I largely work with Docker containers and Serverless. 2 areas that I don't see any advantages going outside of Jenkins (and see many downsides)

Re: CircleCI Down

#57

Post by tedmiston »

watermelon0 wrote: post #43
tedmiston wrote: post #36

Earlier quoted context omitted.

I used CircleCI a long time ago, just before and after 2.0, and thought it was fine. These days GitHub Actions is awesome and full featured and does everything I want though without getting in the way. I doubt I'd use anything besides GHA unless I wanted to decouple from GitHub as a dependency. Even then, I wouldn't be surprised if someone else hasn't already come up with an open source or local runner for the GHA ya…

Two downsides of GHA that I could find: - you are limited to 2 core / 7 GB instance, whereas CircleCI offers up to 16 cores / 64 GB (for example, building software usually scales proportionately to machine size, and this can in theory be up to 8x faster on CircleCI) - no support for ARM instances

The details you listed sound accurate for the built-in GitHub-hosted runners.

GHA also supports bringing your own self-hosted runners [1][2] where you install their agent, so you could, e.g., use an ARM instance on AWS with tons of cores. It looks like CircleCI offers this as well.

[1]: https://docs.github.com/en/actions/hosting-your-own-runners/...

[2]: https://github.com/actions/runner

Re: CircleCI Down

#58

Post by tedmiston »

brightball wrote: post #42
tedmiston wrote: post #31

Earlier quoted context omitted.

To be fair, DMARC quarantining is actually a pain in the ass and will likely break things for people outside of engineering or IT. In a growing or big company, there are always more and more legitimate emails from third-party senders added all the time. I agree that reviewing is the first step, but not everyone needs to take further steps. And I highly doubt CircleCI is unique here. I think it's a massive leap to con…

Everyone absolutely needs to take the next step. Without it, you're inviting direct phishing against your user base. For an core devops tool, that's not okay.

I don't disagree with you about the value of its security benefits from a technical perspective. But if you tested this against the top 100 websites to see how many have actually implemented it... well, I'd be curious to see the results.

Re: CircleCI Down

#60

Post by vageli »

tedmiston wrote: post #58
brightball wrote: post #42

Earlier quoted context omitted.

Everyone absolutely needs to take the next step. Without it, you're inviting direct phishing against your user base. For an core devops tool, that's not okay.

I don't disagree with you about the value of its security benefits from a technical perspective. But if you tested this against the top 100 websites to see how many have actually implemented it... well, I'd be curious to see the results.

This may satisfy your curiosity: https://dmarc.org/stats/alexa-top-sites/dmarc/
Post reply on HN