olingern

Not sure why the contempt with an opinion.

I get that microservices are trite, and most people think they need them long before necessary; however, they have uses beyond scale.

I'm sure that there are ways to mitigate every point I can make within monoliths.

My points are just opinions.

30+ requests/sec

Some would consider it light, but I work alongside a company that is currently struggling to get beyond that mark.

> This goes to his point, the time spent considering these points is time gained in delivering an MVP to market.

In undiluted markets where you're entering 'new territory' -- sure. Get a product in user's hands and let it evolve how it should. There are different scenarios where companies already have a user base and you have to be able to respond to that load within your MVP.

Referring to what I said in my original comment, there are always trade-offs, and monoliths have their place. If you have the luxury of time and money, I would say that a monolith is less than ideal.

> You don't need that level of scaling potential in an MVP, and you get to have something out -- in time. While if you had started with a microservices approach you would still be off in that corner trying to get something usable out. Now you have a product in the hands of users, and your refactoring can consider that feedback.

Don't disagree with this at all. Context of your market probably dictates whether you'll be in a corner or still figuring out service boundaries.

> There's nothing that should be preventing your monolithic application from handling significant load.

I don't disagree at all. As with most things in life, throwing money at the problem will solve this. In a lot of positions I've been in, this cost becomes "the cost of doing business" that everyone assumes rather than, "we can do better, but for now this is our reality."

> Monolithic applications don't encourage naive approaches;

Perhaps, naive is a poor choice of words. Maybe, an example is better:

You develop a large system that's going to support an entire state's childrens meal plans. You can easily do this in a monolithic architecture, but is it worth investing time to save on peeling apart the obvious points of high use now?

Children / parents only have to sign up once, but they need access to their meal plans everyday. I see two services here in this simple example, and if I'm strapped for time -- I defer a user management service to some sort of SAAS / PAAS so I don't have to deal with that overhead.

I see a great deal of value to everyone in investing in the optimizations that have high return, but minding Knuth's rhetoric that "premature optimization is the root of all evil."

> Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

I wholeheartedly disagree with this point.

I've found that if I build monolith first, it becomes harder to draw the line of how to separate endpoints, services, and code within the system(s).

If I design in a "microservice first," or just a service oriented design -- I find that there is much more clarity in system design. In terms of exposing parts of a system, I find that the microservice first approach makes me consider future optimizations, such as caching policies, whereas, in a monolith, I would proceed in a naive, "I'll figure it out later" approach.

Each school of thought has its downsides. Monoliths move fast and abstracting parts of the system later that arise as bottlenecks is a tried and true pattern; however, there aren't too many product / business folks who want to hear:

"Hey, we just built this great MVP for you. It probably won't handle significant load, so we're going to go off in a corner and make it do that now. Oh yeah, we won't have time to develop new features because we'll be too busy migrating tests and writing the ones we didn't write in the beginning."

The flip side is, microservice first has a lot of overhead, and (as things evolve in one system) refactoring can be extremely painful. This is an okay trade off where I'm at... for others, maybe not so much.

Pinback has recently helped me write a ton of code.

Tool, A Perfect Circle, Ashes Divide for a mellow, metal mood.

Vitamin String Quartet when I want something familiar, but classical in taste

Nicklecreek, Chris Thile, Old Crow Medicine Show, Punch Brothers for a folk fix.

Kid Ory when a need a New Orleans Jazz pick-me-up

Hmm... can't tell if this is an attempted Node slam, but figured I would add that you can mimic threads / concurrent tasks by utilizing the child_process or cluster modules.

> Dynamic import() expressions

This is exciting. About a month ago, I tried this just expecting it to already be supported. I was sad to learn it wasn't.

Kudos to the Typescript team for the awesome, continual improvements.

As a person who has spent a couple of years in college with Japanese, leisure time, and time in Japan -- I can tell you that it's one of the richest cultures I've come into contact with to date. Mind you, that's completely subjective.

One of the things that exists in their culture that doesn't exist in the US is the notion of "oneness." If you get on the train in the morning and observe people going to their jobs, you'll notice that there's almost a "uniform" - very similar suit, haircut, and overall style. In America, individuality has become a disease that has lead to everyone feeling the need to be special and different. I'd argue that this 'disease' is the plague of our politics and economy, as companies nor politicians typically think about society's greater good ( save a handful who are now trying to align business with humanitarian efforts ).

Also, embedded in the language is respect. You use different words and sentence structures to address your friends vs. your boss.

So, what is the value? Probably experiencing life in a different way, and gaining more perspective.

I worked for a toxic CEO roughly three years ago, and, to answer the article's rhetorical question - he/she has to behave badly enough to hurt long time investors' pockets.

I only made it a year under a micromanaged, 'everything is urgent' environment. It all stemmed from the CEO. He was in every meeting, including dev initiatives. Not only did he have no significant technical knowledge -- he also lacked in areas where I would expect most CEOs to excel: market strategy, branding, and finance management.

My exit was a large blow to the company, as a lot of co-workers saw me as the unicorn who would 'fight the good fights' for everyone else. And, I did -- until my health started to decline from the stress.

The story ends with me perusing LinkedIn one day, after five+ former co-workers had left, with him stepping down as CEO. He would have never made this decision on his own (pride, control), so I know that external investors definitely dictated this.

So, I would say pay gets clawed back when CEO's consistently make poor business decisions and over promise/ under deliver to investors in order to obtain more funding.

Funny, I went to their status page before coming here, and it definitely was "all systems go."

Apples and tangerines.

> I wish you had elaborated on this.

Sure. I've held jobs in one or two other fields prior to entering software development, and each one of them (in my opinion) contributes to a perspective that you see the world through. Our brains change with habit, and, naturally, the thoughts and feelings that frequent your mind will become mainstays of your daily life. It took two years for me to stop feeling like every time I rode my bike to and fro, that it was imperative I do it as fast as possible.

This is going to sound silly, and I'm okay with that. But, being an engineer again, the patterns and ways my brain solves problems for work permeates into daily life. For instance, I view boiling water, laundry, and texting as asynchronous tasks that can have their own thread and let me know when they're ready. Ridiculous, I know, but I feel like our brains seek these things out to strengthen the existing connections we have and to put life into contexts we understand most. Take this with a grain of salt, because this is just my experience and I have no research to link to, at the moment.

The other interesting thing about how it changed me was, prior to being a bike messenger, I was pretty naive of classism and what it looked / sounded like; however, only now is it obvious. I make conscious choices to treat all people in service industries well because I only now understand how privileged I am as an engineer. Tipping and saying "May I have xyz" are large parts of this, as vocations such as baristas, delivery personnel, and food workers are very underpaid. I can't really change the world, but I'd like to think I can make the people in front of me a little happier by treating them well.

I think it's because people actually _wrote_ there. Since blogging has become a part of the "presence" everyone has to have, a lot of garbage and uninspired things are written on the internet. I wasn't a regular reader, but the things I did read seemed to be more visceral and well written than your average blog post you see today. The guy who wrote, "A Coder in Courierland" had pretty amazing prose.

I read a kuro5hin post about a programmer turned courier, "A Coder in Courierland," (http://atdt.freeshell.org/k5/story_2005_3_19_133129_548.html) and became pretty infatuated with the idea over a five or six months. The recession hit, lay offs began, and then I was a courier.

I did it for a little over three years. It had its ups and downs. I returned to software development and have found a cosier community in the Javascript realm (pre-courier, .NET).

Takeaways that stick with me till this day:

- You can develop an incredible amount of strength from just cycling.

- Air quality is a long term concern.

- (More sun + more exercise) - LEDs = great sleep

- Excessive amounts of exercise != great health

- Learn your machine, and do your own work.

- Fixed gears are extremely useful in dense traffic.

- The type of work you do affects your outlook on life.

- There is a substantial amount of pride amongst messengers who show up, especially on the worst of days. Most people tend to avoid the harsh realities of life, and everyone can learn something from just taking life one delivery or line of code at a time.

- There is something to be said for sitting on a park bench and admiring the beauty around - people, man-made, or nature.

I miss it, but don't recommend it to anyone, as it's a job that requires a lot of grit and is low paying. I wouldn't change my experience at all, though. It aged my mind and soul in a really positive way.

I will say, returning to software development raises some eyebrows. Some will scrutinize the hole in your resume, others will congratulate you on being different.

He could, but I agree with his logic that overall quality of the codebase could degrade without his attention to core. The core project is a result of his ideas and vision, so having others jump in and take over would be difficult.

Parse is in a similar state. Stable, maintained by the community, but no longer under a company umbrella. It had a lot of promise, and it's unfortunate Facebook decided to spin it down.

A lot of these tools will fall to the wayside as other more efficient, shiny tools replace them, i.e. Angular 1.

In general, tool turnover is quite high in the Javascript community. I would expect Hapi to share the same fate as every other Javascript framework that stopped being actively maintained.

This is garbage.

This.

I was integrating Braintree a year ago when some of the documentation was unclear. They're technical support was amazing on the phone, and cleared anything the documentation was lacking up.

Also, talking to them wasn't like talking to a tool. Didn't feel like a megacompany, but just another person on the other side of the line.