211–220 of 536 posts
Earlier quoted context omitted.
> You take your monolithic app and you split it into like 12 services. The non-web world has been doing this with message queueing for about 15 years. Maybe more.
You do know the author is a taking the piss out of the practice, right?
"-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…
That said, in places where it doesn't make sense we didn't try to force it. Our main game API is somewhat monolithic, but behind it we have almost 10 other services. Here's a quick breakdown:
- Turn based API service (largest, "monolithic")
- Real-time API service (about 50% the size of turn-based)
- config service (serves configuration settings to clients for game balancing)
- ad waterfall service (dynamic waterfall, no actual ads)
- push notification service
- analytics collection service (mostly a fast collector that dumps into Big Query)
- Open graph service (for rich sharing)
- push maintenance service (executes token management based on GCM/APNS feedback)
- help desk form service (simple front-end to help desk)
- service update service (monitors CI for new binaries, updates services on the fly - made easy by Go binary deployment from CI to S3)
- service ping service (monitors all service health, responds to ELB pings)
- Facebook web front-end service (just serves WebGL version of our game binary for play on Facebook)
- NATS.io for all IPC between services
But don't get too caught up on the "micro" part. Split services where domain lines naturally form, and don't constrain service size by arbitrary definitions. You know, right tool for the job and whatnot.
I know it's tongue-in-cheek but few if any of these new fangled things are critically dependent on one another.
"-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…
> You take your monolithic app and you split it into like 12 services. The non-web world has been doing this with message queueing for about 15 years. Maybe more.
I mean, the infamous "UNIX way" of "do one thing, do it well" (something we nearly lost with popularity of "do everything in a manner incompatible with how others do it" approach in too many modern systems), when complex behavior was frequently achieved through the modularity of smaller programs communicating through well-defined interfaces.
Heck, microkernels are all about this, and their ideas haven't grew out of nowhere. And HURD (even though it was never finished) is quarter a century old already.
Earlier quoted context omitted.
How do you write "foo | bar" in Python?
bar(foo) When you're not writing shell, just use the tools the language gives you. For the matter, I think a shell script is cleaner than a python script for devops; but I don't think the composability of unix tools is that much of an advantage compared to the amount of python libraries out there.
I'm likely to be using Python programs and other programs in those shell scripts. The beauty of shell is that it makes it so easy to compose programs written in different languages.
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…
Honest advice: Stop working for/with stupid companies/people and start working for smart ones.
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,…
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.
When it comes to micro service, it would be interesting to know simple things like what kind of services were created, how large are, how communiction is handled, how large team(s) behind the service etc.
For some companies these are of course trade secrets, but sometimes opening things up might be good marketing. An example is Backblaze with their very detailed descriptions of their storage pods.
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?