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

“It's The Future”

circleci.com

Post reply on HN
Print view View original

421–430 of 536 posts

Re: “It's The Future”

#421

Post by 6DM »

collyw wrote: post #300
6DM wrote: post #247

Earlier quoted context omitted.

On a positive note, it sounds like proprosals to use newer technology are welcome. I keep seeing the opposite, "No this is too different, could break stuff."

If it ain't broken, why fix it?

In my case, usually something is broken or breaking in production frequently enough to warrent some changes. Plus, there are other reasons you can make a change even though it's not broken.

Sometimes it can make you more productive. Or though your site is still responding to current customer demands in a timely fashion, you know that the mobile experience could be significantly improved now that browsing via cell phone is on the rise.

Another thing to consider is employability both from a company and individual perspective. If you can keep up with moderately current (not the latest and greatest) trends, you'll attract people who want to grow in their careers. I wouldn't want to work on C# 2.0 using Visual Source Safe. It's hard to convince a company that you can learn git on the job.

In general I like to move without introducing breaking changes. I'm not a cowboy coder, it's really exhausting working with one. I do think there's merit in realizing when it's time to change though.

Re: “It's The Future”

#423

Post by Semiapies »

pbiggar wrote: post #334

Author here. To answer some questions: yes this is obviously poking fun at Docker, but I also do really believe in Docker. See the follow-up for more on that: https://circleci.com/blog/it-really-is-the-future/ In a self-indulgent moment I made a "making of" podcast about this blog post, which is kinda interesting (more about business than tech): http://www.heavybit.com/library/podcasts/to-be-continuous/ep... And if y…

I have to admit, I was startled to get to the "we sell these services" blurb at the end, because that was such a well-done unsell.

Re: “It's The Future”

#424

Post by neeleshs »

bpicolo wrote: post #392
neeleshs wrote: post #311

Earlier quoted context omitted.

It is a matter of tooling. One data center or ten, it does not matter much with proper tooling. We deploy to seven data centers with a click of a button, with rollback, staggered deployment etc. Centralized logging using ELK gives us great visibility in to each DC, without worrying about individual microservice instances.

Easy until you realize you need to somehow manage + configure hundreds of services to run your dev environment...

Dockerized apps make it simple to run on dev environment, which is what we do. Of course , one cannot run everything on a laptop, we have a dev cluster

Re: “It's The Future”

#425

Post by CaptSpify »

CrLf wrote: post #388
CaptSpify wrote: post #349

Earlier quoted context omitted.

An un-researched opinion from someone who replaced chef/ansible/puppet with his own shell-script config-management system: I don't have to rewrite my shell-scripts every 6 months when a new version comes out. New updates usually only happen when security issues arise. Shell-scripts tend to be simple. There's not a lot of magic hand-holding going on, which means not a lot of complexity to break things. It keeps you fr…

> I think config-mgmt tools can be extremely useful if your running a widely-ranged environment. But, you probably shouldn't be running a widely-ranged environment. If you keep things simple, and run as homogeneous as possible, you probably don't need all the added complexity. This applies to small environments. If the environment is large the situation almost reverses. Deploying automation throughout a large homogen…

Well, it depends ;)

I don't think large/small is a good deciding factor. You can be large and homogeneous, or small and diverse. I think similar/dissimilar is a better decider for config-mgmt vs shell-scripts.

I'd argue that config-mgmt usually does a better job if your setup is large and complex. No need to write a script that checks if it needs to install a .deb, .rpm, or whatever, if your config-mgmt tools have already done that work.

Also, if you build your shell-scripts right, they can ensure that your system is kept the same.

Re: “It's The Future”

#426

Post by lj3 »

CaptSpify wrote: post #374
lj3 wrote: post #363

Earlier quoted context omitted.

It took me years to realize the reason programmers do this is because the tools that "seem cool" make their lives easier at the expense of everything else. This is where the popular traits of "laziness and hubris" become a liability instead of an asset. More programmers need to embrace the suck.

> tools that "seem cool" make their lives easier at the expense of everything else. I'd argue the opposite. Instead of spending time reflecting on how cool and useful their code is, or hardening it up, devs spend too much time reinventing the wheel. All this work to learn the next new fad is killing productivity.

Easier might not be the right word. 'tools that allow them to be lazier' might be more accurate. Gluing together pieces somebody else wrote and trying to get them all to work with as little effort as possible and are surprised when it doesn't work well.

> devs spend too much time reinventing the wheel

I'd argue the opposite. They spend too much time not reinventing the wheel. They strap factory made bicycle wheels onto a car and are surprised when the wheels break. They could benefit from spending more time trying to make a better wheel.

Re: “It's The Future”

#428

Post by prodigal_erik »

nbevans wrote: post #206
amelius wrote: post #87

Earlier quoted context omitted.

The problem with microservices is that your state is spread over multiple systems. You completely lose the concept of transactional integrity, so you will have to work around that from the start. The advantage though is that APIs (system boundaries) are usually better defined. Perhaps one should use the best of both worlds, and run microservices on a common database, and somehow allow to pass transactions between ser…

Idempotency, event sourcing and sagas with compensations are ways to solve your problem. A shared database is an anti-pattern in distributed systems. Similarly, distributed transactions (ala. DTC) is an anti-pattern. Distributed systems aren't hard. They're just different.

Say you sell a widget. You want to update both your cash account and your inventory, and never one without the other. Which is easier to understand and more reliable: doing them atomically, or making sure you have designed in 2^n intermediate states and all the code required to complete work that should happen but hasn't yet?

Re: “It's The Future”

#429

Post by prodigal_erik »

driusan wrote: post #308
droidist2 wrote: post #133

Earlier quoted context omitted.

So true. Why people often use "it's backed by Google" as an argument in favor of anything is beyond me.

"it's backed by Google" is the reason I avoided Go for years and is still the only reason I'm nervous using it.

If it's free software it won't just disappear. If it's proprietary and hosted by an org that isn't making real money from it, that's a different story....

Re: “It's The Future”

#430

Post by linkregister »

I actually learned a couple of things from this article even though it's satire. I struggled through the de-monolithing of an application into microservices and then into Docker containers. Do people actually do this without having pressing issues that haven't lead them to this path? Is there any reason to spread into microservices unless the monolith is not keeping up with requests?

I would have never considered Docker containers unless artifact preservation/isolation and deployment issues hadn't forced me to look toward a solution.

Post reply on HN