“It's The Future” • Hacker News Board

Re: “It's The Future”

#471

Post by shados » Wed, Aug 17, 2016, 10:16 PM UTC

SonicSoul wrote: post #290

shados wrote: post #202

Earlier quoted context omitted.

Yeah, we do micro services, the "real" kind. Not the "SOA with a new name kind", but the "some services are literally a few douzan lines of code and we have 100x the amount of services as we do devs" kind. The thing is, you need a massive investment in infrastructure to make it happen. But once you do, its great. You can create and deploy a new service in a few seconds. You can rewrite any individual service to be la…

what are the big infrastructure costs?

Deployment has to be easy. Create a new service from scratch, including monitoring, logging, instrumentation, authentication/security, etc, and deploying it to QA/Production with tests has to take minutes from the moment you decide "Hey, I need a service to do this" until it's in prod.

Because individuals may be jumping through dozens of services a day, moving, refactoring, deploying, reverting (when something goes wrong), etc. It has to be friction-free, else you're just wasting your time.

eg: a CLI to create the initial boilerplate, a system that automatically builds a deployable on commit, and something to deploy said deployable nearly instantly (if tests passed). The services are small, so build/tests should be very quick (if you push above 1-5 minutes for an average service, it's too slow to be productive).

Anyone should be able to run your service locally by just cloning the repo and running a command standard across all services. Else having to learn something every time you need to change something will slow you down.

That infrastructure is expensive to build and have it all working together.

Re: “It's The Future”

#472

Post by shados » Wed, Aug 17, 2016, 10:18 PM UTC

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...

beyond just the docker environment, you only need to be able to run the service you're working on locally. Anything you don't run local should hit some shared dev/QA infrastructure (which share a db with local). Whatever you use to develop should be able to detect what you have running locally and prefer those when available.

Anything you're not running locally just hits the shared infra.

Re: “It's The Future”

#473

Post by jules » Wed, Aug 17, 2016, 10:24 PM UTC

imtringued wrote: post #452

jules wrote: post #307

Earlier quoted context omitted.

That's soon going to be on the order of 100 terabytes, so there will be only a handful of companies doing big data ;-)

I'm only aware of servers up to 12TB. Care to elaborate?

He/she said a whole rack of servers. I actually took 30 servers of 2TB each and rounded up to 100. With 12TB per server it will already be over that.

Re: “It's The Future”

#474

Post by catchmrbharath » Wed, Aug 17, 2016, 10:32 PM UTC

lmm wrote: post #336

mbrock wrote: post #234

Earlier quoted context omitted.

Thanks. Maybe I'll make a public Gist that's a kind of "foo | bar" cookbook for different languages...

What you actually do in Python is use https://github.com/kennethreitz/envoy

Looks like its not maintained.

Re: “It's The Future”

#475

Post by pyre » Wed, Aug 17, 2016, 10:33 PM UTC

artellectual wrote: post #398

mamcx wrote: post #321

Earlier quoted context omitted.

This is how we manage this problem at the times when Visual Basic was the king and we use instead Visual FoxPro. People want theirs apps to be made with Visual Studio (BTW, FoxPro was part of the package). So they ask: "In what is the app made"? "In Visual, Sir." Done. End of story (like most of the time, obviously some times people are more dangerous and press it ;) ). ---- The point is not focus in the exact word b…

I think the buzzword abuse exists because of people who don't want to take the time to learn to real skill, and just want shortcuts to sound smart and relevant. I am very skeptical of people who are "BizDev" or "Project Managers" or "Managers" or "Scrum Master" they generally don't know what they're talking about and rely on buzzwords.

I'm wondering why you have managers in scare quotes. Are you suggestion that they aren't really managers or that managers as a position is just some sort of fraud?

Also Project Manager and Scrum Master are just positions that describe roles and responsibilities an organization / on a team. The people filling those roles needn't be clueless.

Re: “It's The Future”

#476

Post by pyre » Wed, Aug 17, 2016, 10:35 PM UTC

coldtea wrote: post #442

discordianfish wrote: post #323

Earlier quoted context omitted.

Another way to signal others that you, too, are an insider is by calling a current trend a hype.

From 20+ years of experience and having seen tons of trends just die, most are just that, hype.

But calling everything that's new "hype" and pointing to the past as the only things that are "real" or "solid" is also a form of groupthink.

Re: “It's The Future”

#477

Post by jacques_chester » Wed, Aug 17, 2016, 11:03 PM UTC

invaliduser wrote: post #402

jalfresi wrote: post #240

Earlier quoted context omitted.

Have to admit, as a fellow Go dev, with single binary static compiles, I don't really GET why I need docker... all it seems to offer is an increased workload and complicated build proc

In my humble case, Docker solves the problems I have to manage the systems on which my application runs (and that's mainly it). A single dockerfile of 20-30 lines describes a whole system (operating system, versions, packages, libraries, etc), and cherry on the cake, I can version it in my git repository. This is not revolutionary in itself, but having the creation and deployment of a server being 100% replicable (+…

> having the creation and deployment of a server being 100% replicable

The problem of ensuring that upstream dependencies can be reproducibly installed and/or built is, of course, left as an exercise for the reader.

Re: “It's The Future”

#478

Post by Almaviva » Wed, Aug 17, 2016, 11:11 PM UTC

I think words are very powerful, in particular "microservices" vs "monolith". By accepting those words, we imply the conclusion: microservices sound sexy and lean and elegant - who can argue with separation of concerns? And a monolith is a big unchangeable rock.

I think we need a better word for apps that are single tight self-contained systems than "monolith". You can design elegant interfaces, and avoid creating a sloppy mess, with function calls or objects too.

Re: “It's The Future”

#479

Post by jacques_chester » Wed, Aug 17, 2016, 11:11 PM UTC

brightball wrote: post #246

As the author of that "Docker is the Heroku Killer" post that was popular a couple of years ago I have to say that I agree with this. When I wrote that article it was largely focused on the potential for Docker to create a bunch of Heroku competitors as well as a simplified development experience across multiple languages. The businesses aren't there yet although a ton are trying. The local dev experience has not mat…

> The local dev experience has not materialized yet either

Have a look at PCFDev.

Disclosure: I sit next to the PCFDev team and use it in my dayjob.

Re: “It's The Future”

#480

Post by Alex63 » Wed, Aug 17, 2016, 11:21 PM UTC

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 don't know if the community will consider this example to be microservices as currently defined, but many years ago I wrote client-server systems using a PC-based fat client application, and transactions running on a CICS server. I think this was pretty similar to what people currently think of as a microservices architecture, although we didn't have to worry about running/monitoring multiple servers (all the transactions/services ran on a single mainframe server), and the transaction monitor managed things like start-up and shutdown pretty simply. This approach worked really well for us, and we built several robust, scalable applications using this approach. To be clear, we numbered our users in hundreds, not thousands or millions. I can well understand how scaling this approach across many servers could be very challenging.