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

341–350 of 536 posts

Re: “It's The Future”

#341

Post by voltagex_ »

chewbacha wrote: post #332
mseebach wrote: post #289

Earlier quoted context omitted.

Someone once suggested to me that 'big data' begins when it doesn't fit in RAM in a single rack any more.

Yup, that's essentially what looking that byte-size means. However, just because it doesn't fit in memory might not make it big data if it's just poorly engineered. But many times this happens because of wasted or bloated indexes that aren't useful. Or it happens when data types are picked incorrectly. For example, I once worked on a database where the original developer used Decimal(23, 0) as a primary key. This was…

>Since text fields in mysql are stored as separate files

Bwuh? Over in MS SQL you just go for an NVARCHAR and forget about it. What is the right way to store this data (if you really do need to store the JSON rather than just serializing it again when you get it out of the DB)

Re: “It's The Future”

#342

Post by geggam »

See .... microservices are where you take a process using IPC and force it to go over a network and use TCP ...then you pretend it will run better and scale more but avoid the whole 10x infrastructure growth and the fact the devops team has tripled in size to manage the frankenstein ... dont forget to add in the whole SDN layer the network guys absolutely love

Re: “It's The Future”

#343

Post by piva00 »

oneplane wrote: post #276
piva00 wrote: post #170

Earlier quoted context omitted.

It's all about simplifying deployment. That's it, that's what's so good about using containers. I don't know if you understand what Docker really is when you say something like this: "Run only one process in one brand new kernel", the kernel is shared between containers, that's the whole idea, you package the things your application need and be done with it. The current problem with containerization is that there are…

It seems to me that you're confusing configuration management and containers... Deployments, installations etc. are pretty easy, it's not something containers are actually good at solving. At best you containerize the configuration management itself, which simply makes it harder to work with.

I've been working with configuration management for some years now, apart from also working as a developer so I don't believe I'm confusing them as much as I'm admitting that containers make configuration management and deployment easier. I might not have been so eloquent on that point but it's my feeling from using Docker for the past 2 years.

Nowadays all that I do is setup a barebones CoreOS instance and fire away containers at it, be it with kubernetes (and then my config management is a bit more robust so to setup k8s in CoreOS) or just use CoreOS's own fleet if it suffices.

Then I get the goodies of containerization such as process isolation, resource-quotas, etc.

Like I said: it isn't painless, sometimes much the opposite, but it's worked much better for the lifecycle of most of the products and services I've been working on the past couple years.

Even before with automated deployments it wasn't so easy when configuration begins to get hairy. And yes, you can argue that this might be a smell of something else but that's what I've seen happening over and over.

Re: “It's The Future”

#344

Post by discordianfish »

Hype is as bad as seeing a promising technology just as hype without trying understand the problems it might solve.

This is quite frustrating for both people who are aware of those issues and trying to fix them as well as the people missing out on the real advantages of such technologies.

This reminds me of similar sentiment around virtualization and cloud computing later in my peer group:

Some sold VMs as security feature and people focused their criticism on that, without understanding other advantages like quick/self-service provisioning of systems. Later one, cloud computing was trivialized as "it now just somebody elses computer" which completely ignored advantages like no ramp up costs and the ability to problematically manage your systems life cycle.

PS: Considering every new thing a fad probably also makes you consider 'hadoop' the latest shit in big data processing and assume today's tech companies hipster are fighting over wordpress plugins. (Like, really?)

Re: “It's The Future”

#345

Post by zeveb »

lmm wrote: post #83
baq wrote: post #60

Earlier quoted context omitted.

wait. you're comparing $25 with $75. it is 3x but it's still accounting noise by any standard imaginable unless you're running a charity server for an open source project.

What about the standard of "I'm young and this is a side project I'm doing in a couple of hours at the weekends"? Of course once you have a real company with more than two customers $75 is nothing. But version 0.1 is often a tool that's only useful to you.

> What about the standard of "I'm young and this is a side project I'm doing in a couple of hours at the weekends"?

Well, even someone who's young (for values of 'young' older than high-school age) is probably spending more than that every month on beer, food & entertainment each …

Re: “It's The Future”

#347

Post by zeveb »

numbsafari wrote: post #117
nathan_f77 wrote: post #76

I've spun up a lot of kubernetes clusters to test it out. A few months ago I also tested out Flynn, Deis, Deis Workflow, Openstack, and a lot of other options. I still haven't found a simple bootstrap script that gets everything set up on AWS and lets me simply deploy my application. And it's true that storage still seems to be an unsolved problem with kubernetes. Heroku is great, and free for small services. On the…

So, why not ditch AWS and use GCP? Kubernetes cluster setup in one command, or use AppEngine. Maybe the problem is AWS.

> So, why not ditch AWS and use GCP?

It's a Google product offering, which means it could be EOLed tomorrow. Or this afternoon. Or maybe it already has — better go check their blog.

Re: “It's The Future”

#348

Post by carsongross »

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…

Micro-services are the current-year deity of the cargo-cult that is Silicon Valley.

Unlike the natives, however, who simply wasted some time building extraneous fake runways, in the Valley people are royally screwing up their own core architecture.

I'm old enough to find this more humorous than frustrating.

Re: “It's The Future”

#349

Post by CaptSpify »

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…

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 from getting too abstract. Your writing pretty close and specific to what you want it to do, not "how it should be".

They are typically standalone. It's really easy to have 1 script that solves one problem, and another script that solves another. You don't need a giant code-infrastructure to keep things going.

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.

Re: “It's The Future”

#350

Post by kbutler »

tom-lord wrote: post #142
tormeh wrote: post #89

Earlier quoted context omitted.

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

Shell/batch scripting can often be useful in the devops world, where you have no guarantee that any additional tools (python, ruby, perl, powershell, whatever) wil be available. Shell scripts are guaranteed to be runnable on all machines. Unfortunately the shell "language" sucks, but still...

So you're running 'sh' scripts, right? none of that new-fangled bash stuff...

Oh, and be very careful of the commands your script invokes!

shell scripts have no guarantee of portability (often less than Python, which has a rich standard library available on all platforms).

Post reply on HN