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

191–200 of 536 posts

Re: “It's The Future”

#191

Post by collyw »

huuu wrote: post #160
rajeshp1986 wrote: post #109

The article perfectly summarizes my frustration and sentiment. These days I hear these buzzwords all time. I work as a consultant for an enterprise product and most people whom I meet they somehow catch these buzzwords and blurt it out in front of everyone during meetings and discussions to either showoff that they know technology and things that are in the market these days(also latest iphone, apple news, tesla, spa…

"I am frustrated by the industry as a whole" Unfortunately I have to agree as a developer. My job is to make a fast, reliable, stable product but at the same time I'm questioned the tools I use by people who don't have any knowledge but heard the latest trend. But sometimes it's also very easy to please people. Big data: just insert 10M records in a database and suddenly everyone is happy because they now have big da…

As long as the database isn't relational, I guess.

Re: “It's The Future”

#192

Post by miend »

nicolas_t wrote: post #43
mrhektor wrote: post #31

"-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do. That seems excessive" A 100 times yes. We tried to split our monolithic Rails app into micro-services built in Go. 2 years and many fires later, we decided to abandon the project. It was mostly because the monitoring and alerting were now split in…

I think that splitting into micro services is valuable if and only if you reach a scale where it makes sense to split into micro services. By scale, I mean the number of people on the team (if you have a lot of people, it can make sense to split into micro-services to limit communication bottlenecks between developers) or in term of traffic, in which case microservices can be very useful to better optimize the system…

I'd also add that microservices have increased value if you begin with such an architecture in the first place. It's much more difficult to "gracefully" rip an existing monolith into modular pieces than to build modularly from the start.

Re: “It's The Future”

#193

Post by totally »

jules wrote: post #154
nicolas_t wrote: post #43

Earlier quoted context omitted.

I think that splitting into micro services is valuable if and only if you reach a scale where it makes sense to split into micro services. By scale, I mean the number of people on the team (if you have a lot of people, it can make sense to split into micro-services to limit communication bottlenecks between developers) or in term of traffic, in which case microservices can be very useful to better optimize the system…

In practice micro services mean that you turn a function or method call into a network request. This doesn't really limit communication bottlenecks. It is often more difficult to argee on a network interface than on a simple function or object interface. It's also more difficult to change. You introduce a whole new set of failure modes due to going over the network. Debugging is more difficult since you now can no lo…

Yes, but there's another dimension here. If another team breaks your build in a monolithic repo, you may or may not be able to resolve this quickly. You're in a contract with them about the state of the repo and thus your service.

With microservices, the production version of their service would conceivably be stable. It moves the contract from the repo to the state of production services.

Re: “It's The Future”

#194

Post by IshKebab »

mbrock wrote: post #183
tormeh wrote: post #89

Earlier quoted context omitted.

Why not use Python instead? Shellscript is so... chaotic.

How do you write "foo | bar" in Python?

How often do you actually need to do that. 99% of `foo | bar` command could easily be `foo > a && bar < a` which is pretty trivial to do in Python.

Re: “It's The Future”

#195

Post by nickjj »

goldenkey wrote: post #164
nickjj wrote: post #69

Earlier quoted context omitted.

Once you finish taking my Scaling Docker on AWS course, you'll have access to a magic command that deploys your app and you're free to optionally run migrations. http://nickjanetakis.com/courses/scaling-docker-on-aws It covers using RDS, ElastiCache and also handles load balancing your app + much more.

You should mention it costs $20 for information that can be found for free anywhere on the web. While other users answer the question, you simply refer to your piggy bank, shameless.

> You should mention it costs $20 for information that can be found for free anywhere on the web. While other users answer the question, you simply refer to your piggy bank, shameless.

Yep, it costs $20. Basically the cost of chinese food for 2, to ensure guaranteed victory in learning the essentials of AWS' platform while having a guided tour on how to deploy a fault tolerant web app with Amazon ECS from start to finish.

You can definitely learn everything for free, but the value in a course is that you're getting a cohesive learning path that was carefully planned and tested. You get a system that you can apply to your own projects and plenty of source code to reference.

You're paying the $20 so you can avoid spending 6 months trying to figure out everything on your own while stringing together a bunch of half-assed blog posts and tutorials.

You pay the small fee for certainty and it's well worth it because your time (and sanity) is not infinite.

Re: “It's The Future”

#196

Post by acveilleux »

CrLf wrote: post #91
xchaotic wrote: post #37

I think I will be fine, thanks. I'll stick to my shell scripts, so far they've outlived any other devops fad.

I worry when I can't tell if a comment like this is based on fact or just trying to be funny. Because I've seen my share of nasty "legacy" automation but, surprisingly, I still think a good set of well thought-out shell scripts written by someone that understands what's being automated still beat modern tools, even when the person doing the automation is the same. I don't quite know why this is, but there's something…

My take is that the shell script does not have any unspoken assumption or magic that is performed by the tool.

It all has to be in the script building up strictly from well-understood and long stable basic bricks (and the few places where you don't it's even worse with devops tools.)

Any issue, any question can be answered by reading the damn shell script and you're never dependent on a cookbook/recipe/playbook/component that you got off of some github repo that you need 5% of to do X.

Re: “It's The Future”

#197

Post by drdaeman »

mrweasel wrote: post #50
mrhektor wrote: post #31

"-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do. That seems excessive" A 100 times yes. We tried to split our monolithic Rails app into micro-services built in Go. 2 years and many fires later, we decided to abandon the project. It was mostly because the monitoring and alerting were now split in…

>Any positive experiences with micro-services here? It makes sense for some thing. We run a webshop, but have a separate service that handles everything regarding payments. It has worked out really well, because it allows us to fiddle around with pretty much everything else and not worry about breaking the payment part. It helps that it's system where we can have just one test deployment and everyone just uses that d…

Totally agree.

We had almost the same story with payments. Except for we've jumped to a payment-processing SaaS but got dissatisfied (all those SaaSes I saw don't work with PayPal EC without so-called "reference transactions" enabled) and decided that wasn't a good idea and we have to jump back to in-house implementation.

I didn't want to re-integrate the payments code back to the monolith - thought it would take me more time and make code messier. So I wrote a service (it's small but to heck with "micro" prefix) that resembled that SaaS' API (the parts we've used). It had surely evolved and isn't compatible anymore, but it doesn't matter as we're not going back anyway.

Works nicely and now I'm feel more relaxed - touching the monolith won't break payments.

On the other hand, I see how too many services may easily lead to fatigue. Automated management tooling (stuff like docker-compose) may remedy this, but also may bring their own headaches.

Re: “It's The Future”

#198

Post by hellofunk »

paride5745 wrote: post #22
hellofunk wrote: post #18

I assume this entire article is one piece of sarcasm. Because after reading it, how could any sane person not prefer Heroku?

From your comment I see you didn't read the post. Read it, it's a lovely 5 minutes piece of writing.

It looks like I was not the only one to be confused: https://circleci.com/blog/it-really-is-the-future/

Re: “It's The Future”

#199

Post by sandGorgon »

jacques_chester wrote: post #132
sandGorgon wrote: post #14

show me an easy way to push a rails application to aws (with docker) that uses RDS ? is there ANY way i can spin up a server, add the ssh keys to some configuration file somewhere and just "docker-magic push" and have my rails application running ? or do "docker-magic bundle exec db:migrate" and have that command run on the server. Or push a Procfile with worker definitions and have the PAAS automatically pick it up,…

Cloud Foundry is probably what you want. To the point that the Ruby buildpack code is a soft fork of Heroku's (source: I work on the Cloud Foundry buildpacks team). It'll run on AWS, vSphere, OpenStack, Azure, GCP is coming and others to follow. There is, however, still a hump to get over in installation -- you need to learn what BOSH is, install BOSH, then install Cloud Foundry with BOSH. In the long run, for a prod…

thanks for this ! how do you look at deis.io vs Cloud Foundry. Do you see yourself subscribing to one of the popular camps out there... or will you stick to Cloud Foundry in the long term ?

Re: “It's The Future”

#200

Post by imron »

gmfawcett wrote: post #178
vertex-four wrote: post #161

Earlier quoted context omitted.

"We rolled out this update with 220 changes. There's a breaking bug. Where is it? We need to find out in the next 5 minutes, revert, and deploy. Otherwise we have to revert the whole thing- we're losing money." Git doesn't really help with that. More granular deployments do, and if microservices help with more granular deployments, go for it.

Git-bisect does, doesn't it?

It helps with the find part. The revert and deploy not so much, especially say if it's the middle commit if 200 and you'd still like to deploy all the commits before and after.
Post reply on HN