Red Bull Stratos Skydive Rescheduled for today - <AUTHOR> http://www.redbullstratos.com/the-mission/launch-progress/ <comment><USER2> FYI, this is the anniversary of Chuck Yeager breaking the speed of sound in the Bell X-1 in 1947:

<https://en.wikipedia.org/wiki/Bell_X-1>

<comment><USER3> How appropriate, today is the day Felix Baumgartner broke the speed of sound in a pressurized suit.

</comment></comment><comment><USER4> Could someone explain to me whether this is a marketing stunt and nothing more or whether there is some substance behind this? Put another way: Will any scientists or engineers (at least potentially) learn something interesting from this?

It's cool no matter what, but it would be even cooler if there were some substance behind it.

<comment><USER5> Besides proving our thoughts on what happens to the human body going through the speed of sound, there's an aspect of safety as well.

If successful jumping at 120,000 feet, that means that NASA could deploy these same space suits as an exit plan for astronauts in an emergency.

<comment><USER6> >that means that NASA could deploy these same space suits as an exit plan for astronauts in an emergency.

What? For exit plan you need a way to slowdown astronaut from orbit first.

<comment><USER7> That might not be necessary... won't atmosphere provide enough lateral braking too? Either way, that's easier to do and requires far lesser equipment and prep than a re-entry capsule.

<comment><USER8> The lateral braking provided by the atmosphere causes objects to burn up.

<comment><USER9> Just cover the suits in ceramic tile.

<comment><USER10> I don't know if you are joking or not (I'm guessing you are), but I'll take a bite at this.

Those ceramic tiles have to be placed in the right alignments to dissipate heat. So we are now talking about a rigid 'suit'. So for the rigid structure we'll need reinforcements and ways to move and handle stress and structural load at high velocities - we don't want that transmitted into the human body. (We've tested supersonic velocities, but not re-entry)

The parachute will also have to expand in size to handle the extra weight. Going down this line I we soon get to a point where we may as well call the whole thing a pod and be done with it.

All of it pretty much hinges on ceramic tiles needing to be oriented and then added structural weight.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> His parachute deployed! :D

And he landed! <http://i.imgur.com/l8z0k.png>

There was some issue with his heat visor, but that was resolved.

Edit: More images I screen-snapped (sorry about the low-quality, I'm sure HQ images will be out soon):

<http://i.imgur.com/ZWvSs.png>

<http://i.imgur.com/ZNQu2.png>

<http://i.imgur.com/ZFRIq.png>

<http://i.imgur.com/eZBhB.png>

</comment><comment><USER12> LIVE NOW! <http://www.redbullstratos.com/live/>

</comment><comment><USER13> For those that are curious, the stream is being narrated by Robert Hager [1][2].

[1] [http://www.msnbc.msn.com/id/3688609/ns/nbcnightlynews/t/robe...](http://www.msnbc.msn.com/id/3688609/ns/nbcnightlynews/t/robert- hager/)

[2] <https://en.wikipedia.org/wiki/Robert_Hager>

<comment><USER14> Thanks. I didn't recognize the voice but I was really glad that they had a nice narrator for all of this live internet coverage.

</comment></comment><comment><USER2> Joseph Kittenger's Project Excelsior jump: <https://en.wikipedia.org/wiki/Project_Excelsior>

<comment><USER15> wow. is he that white haired guy in base station? seems he was also that guy who has set the previous freefall record in the 60s.

<comment><USER2> Yes, Kittinger is the man walking Felix through the procedures. This is the Dynamic Duo of high altitude jumping. I felt a shiver listening to them, this is a day I think I will tell my children about.

p.s. Kittinger is 84!

<comment><USER16> Looks like the freefall duration record wasn't beaten :(

<comment><USER2> I'm personally wondering of Felix did that deliberately to leave Joe in the record books.

<comment><USER17> He was also complaining just before that that his visor was fogged over. Perhaps he deployed because of that.

</comment></comment></comment></comment></comment></comment><comment><USER18> Does someone know the reason behind the poor quality of audio coming from Felix? You'd think they had the resources to put in a decent microphone, and data transfer -- judging by the high quality video -- shouldn't be a problem.

<comment><USER19> I often wondered about a possibly connected thing about airplane pilot's microphones:

Why is it that pilots, when addressing the fliers over intercom always have terrible sound quality? You'd think that airlines could afford a high-quality microphone considering the cost of the plane and the pilot's time. Air traffic control should appreciate quality audio as well.

There could be some ruggedness requirement to these microphones that takes precedence over audio quality. Maybe they must withstand decompression?

<comment><USER20> Maybe the raw sound input is run through a band pass filter that attenuates all noise outside of the human vocal range. This would make the voice sound "bad" but it would actually make it clearer to understand, especially in noisy environments.

<comment><USER18> That's actually a very likely explanation. Thank you.

</comment></comment></comment></comment><comment><USER21> Felix's helmet heating apears to be broken. They've also cut the radio talk between Felix and Joseph.

<comment><USER22> yea I heard that too, and then the live feed stopped working as they were talking about the problem... freaked me out! But the feed is back on now.... Was the heating fixed?

(edit: the feed cutting was probably just me, just saying it was an unfortunate time for it to do so)

edit 2: They just said that the problem is specifically for the visor (to prevent fogging and icing), not the whole helmet... They still haven't found out what's wrong.

<comment><USER23> Last I saw his breath was still fogging the screen so not yet

</comment></comment></comment><comment><USER24> Just incredible to watch something like that live. Held my breath the whole time, particular through free fall. When you see him sitting up there from 120,000 feet like he's on a rocking chair, it sort of puts into perspective any time you think you were brave in your life!

</comment><comment><USER25> People, I've just made this little hack to show the location in a map:

Go to <http://www.redbullstratos.com/live/>

and open the console to run:

      $("body").append('')
      $("body").append("

")

then (once openlayers.js is loaded), run this:

      CreateMap = function ()
      {
          var lat            = 33.3405;
          var lon            = -103.7601;
          var zoom           = 14;
          var fromProjection = new OpenLayers.Projection("EPSG:4326");   // Transform from WGS 1984
          var toProjection   = new OpenLayers.Projection("EPSG:900913"); // to Spherical Mercator Projection
          var position       = new OpenLayers.LonLat(lon, lat).transform( fromProjection, toProjection);

          map = new OpenLayers.Map({
          div: "Map",
          projection: "EPSG:900913",
          layers: [
              new OpenLayers.Layer.XYZ(
                  "OpenStreetMap",
                  [
                      "http://otile1.mqcdn.com/tiles/1.0.0/osm/${z}/${x}/${y}.png",
                      "http://otile2.mqcdn.com/tiles/1.0.0/osm/${z}/${x}/${y}.png",
                      "http://otile3.mqcdn.com/tiles/1.0.0/osm/${z}/${x}/${y}.png",
                      "http://otile4.mqcdn.com/tiles/1.0.0/osm/${z}/${x}/${y}.png"
                  ],
                  {
                      attribution: "Data, imagery and map information provided by MapQuest, Open Street Map and contributors, CC-BY-SA  ",
                      transitionEffect: "resize"
                  }
              ),
              new OpenLayers.Layer.XYZ(
                  "Imagery",
                  [
                      "http://oatile1.mqcdn.com/naip/${z}/${x}/${y}.png",
                      "http://oatile2.mqcdn.com/naip/${z}/${x}/${y}.png",
                      "http://oatile3.mqcdn.com/naip/${z}/${x}/${y}.png",
                      "http://oatile4.mqcdn.com/naip/${z}/${x}/${y}.png"
                  ],
                  {
                      attribution: "Tiles Courtesy of MapQuest. Portions Courtesy NASA/JPL-Caltech and U.S. Depart. of Agriculture, Farm Service Agency. ",
                    transitionEffect: "resize"
                  }
              )
          ],
          center: [0, 0],
          zoom: 1
      });
      map.addControl(new OpenLayers.Control.LayerSwitcher());

      //    map = new OpenLayers.Map("Map");
      //    var mapnik         = new OpenLayers.Layer.OSM();
      //    map.addLayer(mapnik);

          markers = new OpenLayers.Layer.Markers( "Markers" );
          map.addLayer(markers);

          marker = new OpenLayers.Marker(position);

          markers.addMarker(marker);

          map.setCenter(position, zoom);
      };

      CreateMap();

      setInterval(function()
      {
      	markers.removeMarker(marker);
      	var lat = parseFloat( $("#latitude").html());
      	var lon = parseFloat( $("#longitude").html());

      	var fromProjection = new OpenLayers.Projection("EPSG:4326");   // Transform from WGS 1984
      	var toProjection   = new OpenLayers.Projection("EPSG:900913"); // to Spherical Mercator Projection

      	var position       = new OpenLayers.LonLat(lon, lat).transform( fromProjection, toProjection);
      	marker = new OpenLayers.Marker(position);
      	markers.addMarker(marker);
      	map.setCenter(position, map.zoom);

      },2000)

Now, at the bottom of the page, you have a map with a marker showing the current location.

Update: [Added] Go first to <http://www.redbullstratos.com/live/>

Update 2: Replaced tiles, with the ones from MapQuest, code for mapquest extracted from: <http://openlayers.org/dev/examples/mapquest.html>

Update 3: fixed little bug introduced ;) Sorry! And placed the map below the video now, so it's easier to view.

<comment><USER26> Wonderful! Thank you so much. I know it's a bit too much, but there is a way of making a 'route' of the positions?

<comment><USER25> Sorry, I just relaxed and just watched the live stream :), I'll see if I can do it before the jump.

<comment><USER26> No problem. I just can't relax watching it!

<comment><USER25> :) Sorry man that I couldn't deliver, I was just too excited watching, lol :P

And then, when I had it almost done, they were about to start, and then, they removed the lat/lon info on the page.

</comment></comment></comment></comment></comment><comment><USER5> Delayed by 20s in case a tragic accident occurs.

</comment><comment><USER27> Here's the live video feed: <http://www.youtube.com/redbull>

</comment><comment><USER28> 3,749,231 watching now popele watching live on youtube, this must be a record?

Update: 4,924,693 watching now Update: 5,056,344 watching now

<comment><USER29> 3.2M now, never seen it so high.

<comment><USER28> 3,694,025 watching now!!! WOW

<comment><USER30> For comparison, Monday Night Football is usually low 20,000,000 range.

</comment></comment></comment></comment><comment><USER31> Here's the JSON endpoint with the data from the launch: <http://services.redbullstratos.com/LiveData/Get>

</comment><comment><USER32> At first glance, skydiving from 10k feet and 100k feet seem like they wouldn't be any different. I'm sure there are intricacies that make the jump very difficult, but it _seems_ like you just let gravity do the work, and the chute automatically deploys for you. Can anyone help me understand what the intricacies are?

EDIT: nevermind, seeing him spin but regain control removed my doubt of the difficulty.

<comment><USER33> Air temperature and pressure are much different at the higher altitude.

<comment><USER9> Is that a diver challenge or a suit challenge?

</comment></comment></comment><comment><USER34> How much bandwidth do 5.4 mio viewers consume? Can someone give me a number?

<comment><USER35> 360p uses 0.5Mbit/s.

5.4M * 0.5Mbit/s = ~330 GB/s

<comment><USER36> It went as high a 8 mio viewers, so ~488 GB/s. Maybe a new record for Youtube?

<comment><USER37> I and many others were streaming in HD, though, so surely the total bandwidth must be much higher.

</comment></comment></comment></comment><comment><USER38> Unfortunately I barely missed the live jump. Will a recorded video be posted, or is there one already available?

<comment><USER39> Yes, the video will be posted youtube.com/redbull in the next few hours.

</comment></comment><comment><USER40> All in the name of selling sugary sodas. Noble.

<comment><USER41> No. The sugary soda is what pays for this inspiring and informative break from the shit on the learning channel.

<comment><USER40> It's interesting, for sure. But the goal is to get you to drink more Red Bull. It's a very unique ad, but still an ad. For a sugary beverage people should probably actually be drinking less of, not more.

<comment><USER41> You're right, it's an ad at the end of the day.

But there are much worse (debatable) products that spend money on really shitty ad campaigns. So this isn't really bad.

I personally respect Red Bull for having found a niche (crazy adventure sports of all sorts) and making possible whole careers in these amazing sports.

At the end of the day, not a lot of people believe you NEED Red Bull to make this jump, but thousands of kids around the world are being inspired right this minute.

<comment><USER40> I agree, but then I get worried that the same kids don't understand what sponsorship means, and that they'll assume that drinking Red Bull is what people like this do, and then they'll start up a very unhealthy and addictive habit (drinking lots of Red Bull). Which is pretty bad.

<comment><USER42> Because no one other than you can see through the marketing spin?

<comment><USER40> If marketing didn't work, they wouldn't do it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER43> I really liked the mission timeline page: <http://www.redbullstratos.com/the- mission/mission-timeline>

</comment><comment><USER44> It seems like some of YouTube's region-based relay stations are down. Temporarily changing DNS to a US-based ISP is advisable. (Viewing from Japan)

</comment><comment><USER45> The original scheduled launch on the morning of 9 October 2012 was delayed and cancelled because of a 25-mile-per-hour (40 km/h) gust of wind at the launch site. Technicians at the launch site also found that one of the capsule's communications radio was faulty.

<http://en.wikipedia.org/wiki/Red_Bull_Stratos>

</comment><comment><USER46> I am having terrible problems using youtube to view the live stream. I am getting "stops" for about 5-10 seconds constantly. Sometimes I have to refresh the whole youtube page to get it working again. Earlier they said that over 100 sites are streaming the event... does anybody know about the best working site?

<comment><USER47> See ServusTV with german commentary: <http://www.servustv.com/cs/Satellite?pagename=Stratos/Layout>

</comment></comment><comment><USER25> IS someone else having trouble with youtube, showing "static" ? (can't connect to live stream)

<comment><USER48> For me it wouldn't load in Chrome but works perfectly in Firefox (on OSX)...

<comment><USER49> yep - wouldn't work on my locked-down Firefox, but did fine on my vanilla Safari.

</comment></comment></comment><comment><USER50> Can someone explain why they say it will take 2 hours for him to reach his altitude? Right now he's 12.5 miles up after 35:26 minutes.

Will he slow down as his altitude increases?

I keep hearing them talk about dropping ballast -- is there a danger in ascending too fast?

<comment><USER5> 12.5 miles is 66k feet. He's at 44k.

EDIT:

But yes, he will also slow down as he goes up. The balloon will also change shape and expand greatly in size.

<comment><USER50> Ok, I didn't realize the number to the right of the clock was meters and not miles. I guess the decimal instead of the comma threw me off.

</comment></comment></comment><comment><USER51> Once again, title creators succumb to the power of relativity. My eyes keep on skimming on this topic, and it makes me want to laugh and cry at the same time. "Today" is awesome.

</comment><comment><USER52> Freefall live on YouTube: <http://www.youtube.com/user/redbull?v=MrIxH6DToXQ>

</comment><comment><USER53> Almost 5 million people watching live now. Compare to presidential debate with 67 million viewers - not bad!

<comment><USER35> The debate should have taken place suspended from a weather balloon.

<comment><USER54> Yes, and every time a statement's "fact-check" that comes back as false, they move a little closer to the edge.

</comment></comment></comment><comment><USER42> 11AM EST is the current estimated launch time..

Anyone know how long the ascent is going to last before he actually jumps?

<comment><USER2> Two hours?

<https://twitter.com/BBCPallab/status/257483119807045632>

</comment></comment><comment><USER55> Where is the outside camera located?

</comment><comment><USER56> He has a lot of external stuff on his suit I'm worried at Mach 1 it will be torn off.

<comment><USER57> That's Mach 1 in nearly no atmosphere. Nothing there to tear stuff off.

<comment><USER56> I thought even at that altitude there would still be a significant amount of atmosphere but apparently not. Even 39km there's still a lot of atmosphere to go but I guess it's pretty thin.

When interviewed Kittinger said something _"To all those who said Baumgartner suit would tear apart I salute you with a middle finger!"_ I laughed but thought it was unnecessary harsh since at some point he may enter thicker atmospheric region going 1,340km/h.

The design of aircraft are angled to near points and aircraft skin of supersonic craft are made of exotic materials to withstand thousands of degrees Celsius. I figured Mach 1 in a bulky suit thin atmosphere or not at some point something may tear, give way or heat up suddenly.

</comment></comment></comment><comment> brown9-2 In the US at least, you can also watch live on TV on The Discovery Channel.

</comment><comment><USER58> Question - is he going to land in the same country he took from?

<comment><USER59> Looks like he's still over Roswell, NM; presumably so.

</comment></comment><comment><USER60> Just landed!

</comment><comment><USER61> roughly in 1hr from now he will get to the desired altitude.

</comment><comment><USER62> The guy commenting on the video seems absolutely clueless.

</comment><comment><USER63> To Red Bull: fix your coverage next time! Your website and Twitter feeds weren't really ever carrying the latest information pre-launch, and your blog was 24 hours out-of-date whenever I checked. (Also YouTube was buffering, it wasn't my connection). Bit of a mess from the PR-masters imo.

<comment><USER64> Are you positive it wasn't your connection? It worked perfectly for me, as well as (seemingly) quite a few others.

I'm going to go buy a Red Bull now.</comment></comment>


The stack you know or the stack that's trending? - <AUTHOR>

For work I've primarily been on a MS stack; I'm very comfortable there. However, I started on an idea in node and mongo. So far I've learned a lot, but it feels way too slow and I don't feel comfortable that if this thing blows up I'll be able to manage it. Granted, that would be a good problem to have, but I'm questioning my decision. So should I start fresh on a MS stack that I am comfortable with and can move very fast on, or should I stick with the trendy stack and continue to learn but move slow? <comment><USER2> "Trendy" stack? Languages and frameworks come and go, but that's because they bring something new to the programming mainstream. Dismissing the new as merely "trendy" hugely misguided. (I wouldn't want to write software in a world where we're stuck writing DOS programs in C!)

Good programmers (ones that I'd like to work with, anyway) are always reaching outside their comfort zone. Try to dismiss those doubts about the new stuff, and keep up the good work! You'll thank yourself later.

<comment><AUTHOR> Good points. But there's also something to be said for getting your product out there as fast as possible to test the waters right? I guess that is a pretty important facet of my question. I'm all about exploring and learning new things, but does that have a place when building a product?</comment></comment>


Analysis of chronic fatigue syndrome study casts doubt on published results - <AUTHOR> https://www.statnews.com/2016/09/21/chronic-fatigue-syndrome-pace-trial <comment><USER3> I had a sibling who struggled with CFS for years. Even before this bad study came out the usual reaction from doctors was _you 're suffering from mental illness/try exercising/you're faking_. It sounds almost like this study was constructed for the convenience of doctors so they could point to the publication and keep suggesting what they had already suggested.

It's hard living with a debilitating medical condition that doesn't have good treatments or a clear cause. It's even harder when the doctor says "I think it's all in your head" instead of "sorry, we really don't know how to treat this yet." That sort of consistent dismissal/borderline victim-blaming from real doctors is what I think pushed my mom toward bogus alternative health practices. There appears to be nothing medically valid about chiropractors but at least they don't call you crazy just for telling them about the experiences you've been having.

<comment><USER4> That sounds awful.

There's a phenomenon that I wish I had a name for. Or even a good description of. It's when people imagine that your issue is just something they've experienced, even when the magnitude is very different. E.g., when people who have been sad at some point tell clinically depressed people that they should just cheer up. When they tell somebody with an anxiety disorder that they should calm down. Or, as with your sibling and CFS sufferers that they should just get a little exercise and it'll all be fine.

I can sort of forgive that in regular folk. But in doctors? It's shameful.

<comment><USER5> My folks are like that too. They never experienced any psychic or physic trouble at any point in their 70 years long life, so they cannot fathom that people may strongly suffer from any of these problems, which are in their opinion not real problems and can be solved with cheering up and _making an effort_ , because that's how they solved their own 5-minute 'problems'.

<comment><USER6> > They never experienced any psychic or physic trouble at any point in their > 70 years long life

How can you tell?

</comment></comment></comment></comment><comment><USER7> As a near 10-year sufferer of severe ME/CFS, I can confirm this study has done unbelievable damage to the cause and should absolutely be retracted in full. Recent research has identified unquestionable, tangible and severe abnormalities in immune and metabolic function that are unique and consistent to ME/CFS sufferers, and this is no longer realistically up for debate. Most doctors though still dismiss the condition as psychological, and because of this (and even though the burden has been shown worse than other immune disorders like AIDS in many cases) funding is virtually non-existent. This study has been so widely disseminated and taught to medical professionals, the damage will take some time to undo unfortunately.

<comment><USER8> A couple of points:

\- the study hasn't done "unbelievable damage", unless you're firmly in the camp that CFS must be organic.

\- "severe abnormalities in immune and metabolic function" doesn't rule out psychosomatic causation (as the stress system also controls the immune system and mitochondria, for example).

\- there is no "unique and consistent to ME/CFS sufferers" dysfunction, except perhaps in HPA axis (the main stress system) responsiveness (but even this is somewhat up for debate).

\- Saying it is psychological is not "dismissing" it. From what I can tell (having suffered from it, and researched it), psychosomatic causation does seem the most plausible. The symptoms, abnormalities, triggers and cures match perfectly with what you would expect from exhaustion due to chronic stress.

<comment><USER9> > \- there is no "unique and consistent to ME/CFS sufferers" dysfunction, > except perhaps in HPA axis (the main stress system) responsiveness (but even > this is somewhat up for debate).

This is at odds with the current scientific consensus. Table 1 of "Myalgic encephalomyelitis: International Consensus Criteria" (2011) describes one primary dysfunction (postexertional neuroimmune exhaustion) and several secondary dysfunctions [1].

Furthermore, post-exertional malaise, which is similar to postexertional neuroimmune exhaustion, has been described as a "hallmark" symptom of ME/CFS at least as far back as 2007 [2].

[1] [http://onlinelibrary.wiley.com/doi/10.1111/j.1365-2796.2011....](http://onlinelibrary.wiley.com/doi/10.1111/j.1365-2796.2011.02428.x/full)

[2] [http://www.tandfonline.com/doi/abs/10.1300/J092v14n02_07](http://www.tandfonline.com/doi/abs/10.1300/J092v14n02_07)

<comment><USER8> The OP specifically mentioned "immune" and "metabolic" dysfunction, not symptoms. You are correct that postexertional is likely common to all CFS sufferers, although even that isn't fully agreed on and there is no way of objectively measuring it (repeat CPET might be an objective measure, but that needs more research).

Neuroimmune exhaustion has not been objectively defined. The ICC says "rapid" malaise, but it's typically 24 or 48 hours later.

<comment><USER9> > The OP specifically mentioned "immune" and "metabolic" dysfunction, not > symptoms.

Fair enough.

> The symptoms, abnormalities, triggers and cures match perfectly with what > you would expect from exhaustion due to chronic stress.

Based on your research, what are the cures for "chronic stress"? The treatments discussed in the PACE paper (CBT, GET, etc.)? I'm genuinely interested -- my sister was diagnosed with CFS over a year ago and has made little progress since then.

<comment><USER8> >Based on your research, what are the cures for "chronic stress"?

Well the first thing is to obviously get rid of the chronic negative stress. However even then, many people don't recover (hence the fact that they have long-term CFS, rather than a temporary burnout which they then recover from after removing the stress).

As for why people don't always recover after removing the negative stresses? I think there are a couple of possibilities:

[1] Negative stress from the illness itself (a vicious circle).

[2] The brain gets stuck in the fatigued state, until it gets a "kick" out of it, in the form of a positive stressor. (Basically the fatigue state is a protection mechanism against negative stress that the organism can't cope with, and it requires evidence of a positive development in the future outlook in order to remove the "brakes").

Even though I suffered from CFS, it's hard to pin down exactly which one makes most sense. However the effective cures seem to address both (i.e. getting the patient to do a positive activity). (I should clarify that there are no truly effective "official" cures, only unofficial ones that people like me and others figure out by ourselves).

The problem is that CBT and GET aren't based on valid etiologies of the illness, so at best they might be a placebo that just happens to kick the person out of the exhaustion state on some occasions. The problem is that CBT and GET can be inherently stressful (especially if the person is convinced of an organic etiology), which will likely just make things worse.

<comment><USER10> I suffered from ME many years ago, and I was looking for something - <USER2> - to help me cope with the continual fatigue, muscle pain, insomnia, night sweats, tinnitus etc. I went to learn meditation, and the instructor told me that for many chronic illnesses, the stress of being ill can slow down recovery.

Once I started practicing meditation, I felt a slow improvement in my condition, and most of the symptoms had sufficiently eased after 10 months that I was living a fairly normal life again. I did experience a couple of mild relapses years later (both times by not easing up on intense exercise when suffering a throat infection), but the symptoms were more mild and I recovered each time after about 4 months.

I an not advocating meditation as a cure, but it did make living with ME more bearable.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> It saddens me how bad science will be so quickly defended if it confirms preconceived notions that a marginalised group should be dismissed, and then whoever protests this will be slurred as opposing science, as if there could not possibly be a scientific basis to object to it.

This is hardly the first time it has happened.

<comment><USER12> This, very much. The attitudes described in the paper really make my blood boil. From refusing to share research data on bogus grounds to dismissing patients as "unhinged", then publishing its own "revised research" just before being forced to release the raw data.

The proper response from the scientific community should be to disqualify every study from Queen Mary University of London until the university owns up to its mistakes, instead of digging in.

</comment></comment><comment><USER8> Just be aware that the author of this article is a writer who is basically "out to get" the PACE trial, and she has some slightly strange ideas about CFS ([http://www.healthrising.org/blog/2014/05/02/constant- vigilan...](http://www.healthrising.org/blog/2014/05/02/constant-vigilance- julie-rehmeyers-mecfs-recovery-story/)).

From what I can see from the reanalysis released by QMUL ([http://www.wolfson.qmul.ac.uk/images/pdfs/pace/PACE_bimodal_...](http://www.wolfson.qmul.ac.uk/images/pdfs/pace/PACE_bimodal_CFQ_analysis_final_8_Sept_2016.pdf) and [http://www.wolfson.qmul.ac.uk/images/pdfs/pace/PACE_publishe...](http://www.wolfson.qmul.ac.uk/images/pdfs/pace/PACE_published_protocol_based_analysis_final_8th_Sept_2016.pdf)), the main difference from the original trial was the "recovery" measure, which is a pretty arbitrary value anyway (as recovery can mean various things). However the average fatigue scores don't seem to be much changed from the original trial as far as I can see, and that is the more important result.

A lot of people are out to kill PACE, but releasing lots of frothy press releases with the worst possible interpretation isn't terribly useful for anyone.

<comment><USER13> First, the article in STAT is not a press release...it's a reported commentary/opinion piece where the author has clearly done a lot of reporting.

Second, setting a functional level on measure you're talking about is arbitrary. But the the PACE authors picked a very lo value for "recovery." And they dropped that level after beginning the trial - a very poor practice known as outcome switching. At the end, they defined "recovery" below the physical functioning level for most heart failure patients - and below their entry criteria. That is, a CFS patient could enter the trial, _get worse_ , and get called recovered - all while functioning worse than a heart failure patient. Pretty shady stuff.

<comment><USER8> >Second, setting a functional level on measure you're talking about is arbitrary

Yes, and the PACE recovery paper does say this.

>But the the PACE authors picked a very lo value for "recovery."

How exactly is 1sd below the mean of the general population "lo"?

>At the end, they defined "recovery" below the physical functioning level for most heart failure patients

Again, it's 1sd below the mean of the general population. Congestive heart failure has a _mean_ value of physical functioning around 1sd below the mean for the general population. The person who first threw out this "congestive heart failure" meme probably didn't understand statistics.

>That is, a CFS patient could enter the trial, get worse, and get called recovered

The point is that the entry criteria was an upper limit and the recovery criteria was a lower limit, so it makes sense that they're different. I don't think you can have patients who didn't improve being classed as "recovered" as recovery also included various other measures (e.g. not meeting Oxford criteria). The main point of the study was to show the differences in recovery between the treatment groups.

The other point is that the recovery results weren't even in the PACE trial, they was in a second paper. The paper does mention that there is no agreed definition of recovery, and they were just trying to get a handle on it using various measures.

Overall, apart from the recovery results (which are somewhat arbitrary) the PACE trial results are in line with all the other CBT trials.

There are certainly problems with the PACE trial (the main one being that CBT and GET are based on dubious etiologies), so I think CFS advocates would be better off actually delving into the real problems with the treatments, rather than putting up these strawmen.

</comment></comment></comment><comment><USER14> Apart from the article's importance in exposing some bad science, its author is skilled in narrative, in making an essay readable. A worthwhile read.

</comment><comment><USER15> Western medicine is AWESOME for traumatic injuries. The state of the art moves forward at an impressively steady clip. But our grasp of chronic conditions like this is pathetic, and worse, physicians are usually very uninterested in exploring these conditions with patients.

<comment><USER16> Indeed. "Syndromes" are very hard because there's no real way to test for them. Once there is, the condition can be classified as a disease (or whatever) and progress can be made. It's very hard to make progress without being able to test well. And that is true across disciplines (I'm looking at you, Education).

I think in the _early_ days there was a lot of initial skepticism because, if there were real cases they were diluted by people complaining to their (chronically tired, overworked and stressed) doctors that they were tired. Doctors thoughts were, "welcome to the club." And there is a certain subset of the population who complain constantly about medical conditions- indeed it is the foundation of most conversation it seems- so with no good way to conclusively test for the condition it was often dismissed.</comment></comment>


MonolithFirst - <AUTHOR> http://martinfowler.com/bliki/MonolithFirst.html <comment><USER2> For me the big takeaway is this:

Refactoring across the call stack is orders of magnitude easier than refactoring across a socket.

Sacrificial or not, you can still write the Monolith as "Service Oriented", just that boundary is the call stack. Especially if you're comfortable with IoC and DI.

Building on the latter I've had success with that. Stubbing out hardcoded concepts that I know will come from a as-yet-unwritten service in the future. Then you start pushing those hardcoded things "down and out"; e.g. it was hardcoded in App A, but now App A requests it from App B, but App B just has the hardcoded thing.

<comment><USER3> > Refactoring across the call stack is orders of magnitude easier than > refactoring across a socket.

That's assuming that things haven't become deeply coupled within the "call stack". Separating things across a socket often forces a separation of concerns, which does tend to make refactoring easier.

<comment><USER4> In my experience communications across a socket does not force a separation of concerns. It doesn't even encourage it.

Heck, because asynchronous communication in a non-deterministic environment is so hard to deal with, my experience is that such communications encourage shortcuts to be taken, so yes, I think it encourages tight coupling.

The only thing that somewhat encourages a separation is having different people responsible for different modules and because people are selfish, they'll fight for their components to have less responsibilities, not more. So it becomes a territorial thing. But this happens only if you have seniors that know what they are doing, otherwise rookies or less competent folks end up cooperating to "get things done".

<comment><USER5> Weird reasoning, that. I hardly see how a selfish, "territorial" and noncooperative approach could benefit anybody. Sure people might cooperate, but that doesn't mean they will take shortcuts and mess things up.

</comment></comment></comment></comment><comment><USER6> The companies/stacks Fowler encounters are generally in a problematic state. Thoughtworks, like other consulting companies, is generally hired when things are already going wrong. If they are hired to assess a broken monolith stack, the refactoring to microservices is naturally going to yield positive results, and it's easy to come to the conclusion that microservices are an improvement when refactoring from a monolith stack. When they are hired to assess a broken microservices stack, it's easy to come to the conclusion that starting with microservices is broken. What they don't usually see is the hundreds of instances of microservices (and monoliths) working as intended, as there is typically no need to call in a very expensive consultant in those cases. How many times in the case of badly-organized Microservices was the solution to migrate to a single monolith? I imagine the solution is more often to re- organize the services. If that's true, then one cannot say that microservices- first fails -- just that badly-organized microservices-first fails.

Starting with microservices first, especially in a small team of developers (but more than 1), helps things move much quicker than it did with everyone sharing responsibility for the same codebase. Organizational structure tends to reflect its products' structure. Microservices requires that the splitting of responsibilities between teams or developers roughly matches the split of responsibilities among services. Otherwise, you're just working on micro- monoliths.

An actual study needs to be performed before deciding on a "Right Approach" as this piece does.

<comment><USER7> This. The key thing missing from Fowler's blog post is context. If you are a small team/company then microservices is probably not sensible unless you are highly skilled - the overhead is too high and the benefits less too.

If you are a bigger organisation though, with lots of teams, microservices are required to decouple teams and enable agility/exploration in products and services.

Lastly, it's easy to advocate the monolith ('only to start') when you're a consultant, as you've left by the time it becomes a problem. Or, you get called in down the line when it's all gone pete tong because the monolith 'prototype' has become a monster.

Note, I've spent the last two years working on microservices (which has involved a big learning curve but now yielding benefits) and also old monoliths (that have sucked up so much time it's unbelievable).

<comment><USER8> OT: what does "it's all gone pete tong" mean?

<comment><USER9> "It's all gone a bit wrong", but normally in a dramatic way.

[http://en.wikipedia.org/wiki/It%27s_All_Gone_Pete_Tong](http://en.wikipedia.org/wiki/It%27s_All_Gone_Pete_Tong)

</comment></comment></comment></comment><comment><USER10> I had great success converting a "microservices" architecture to a monolith at the BBC back in 2003/2004\. The result was ~100-1000 times faster (speed was an issue with the original), had a fraction of the code, used 1 machine instead of a dozen, was more maintainable, had effectively zero failures over several years versus several a day, was trivial to install (copy this jar over here) etc.

<comment><USER11> Wasn't Plenty of Fish run on two machines? And Github Pages?

If you're building a MVP, you're probably going better with the monolithic approach. It's easier to develop and 99% of businesses can probably scale enough with bigger boxes.

<comment><USER12> Plenty of Fish ran for the first 8 months on the guys home computer.

<comment><USER12> Also impressively in 2008 they were serving '30+ million hits per day, 500-600 per second' on 5 machines with one engineer. They were the '#13 website in the United States' for hits at the time. I think their machine / engineer situation has expanded substantially since - fancier matching algorithms and instant messaging complicated things.

[http://blog.codinghorror.com/my-scaling- hero/](http://blog.codinghorror.com/my-scaling-hero/)

</comment></comment></comment></comment><comment><USER13> I once worked for a company that was sunk by a microservice-first architecture. The "architect" in charge was a big Fowler fan who would quote him to justify every decision. Every developer knew the architecture was wrong (and many said so - but the architect had the authority to overrule them, which is maybe the real problem).

I guess it's good to finally see some acknowledgement, but this is too late for that particular organization. Beware of hyped architecture bandwagons?

<comment><USER14> Any specifics you can share about why the architecture was so obviously wrong? This is a really interesting topic for me!

<comment><USER13> It really slowed down development because it made the feedback loops really long - you might have to start up five different JVMs, which would each take a while to register itself with Hazelcast before you could start the next that depended on it, before you could test your change. The service boundaries we had initially come up with weren't always correct (as you'd expect really), but it was a massive effort to refactor something across a service boundary, because each component was released and versioned separately.

Maybe there are ways to work in such an environment, but if so we didn't find them and no-one had the experience to know them.

<comment><USER2> > because each component was released and versioned separately.

For SOA a mono-repo with synchronized releases is a huge help.

In one commit you can refactor a shared module and update all apps that depend on it. And you know when you deploy to staging or prod that all machines got the latest code

<comment><USER15> At what scale? At Google we had to version everything _within_ a commit, i.e. files that were pushed to different binaries had to make sure they were backwards- and forwards-compatible with the previous version. Your code had to work even if it was talking to another server that was stuck on the previous commit, or even several releases back.

The reason is that when you have 1000s of machines, the push _will_ fail for some. Either the machine will be offline and out of service when the new version is released, or its network connection may be down, or a cosmic ray may flip a bit and make the process crash when installing, triggering a rollback. Particularly when handling user data, you need to code defensively around these and not assume that the server you're talking to has the same code you just wrote in your commit.

Obviously these problems don't manifest when you're pushing to 1-3 machines, but if your deployment is that small, why not run it all in-process with a monolithic app anyway?

<comment><USER2> Great point. Different scale needs different things for sure. Even at the scale that I've found this successful in you still have to consider that backward/forward compatibility, albeit at a much coarser grain.

</comment></comment></comment></comment></comment></comment><comment><USER16> Alternately: design your application as a bunch of Service objects with clear APIs that make (the moral equivalent of) RPC requests to one-another. Do this all in the same process. Whenever a Service turns out to need separate scaling, hoist the code for it out (no need to change it) and replace the "null modem" RPC layer between it and the rest of your code with a real socket-based gateway.

Hey! You've just invented Erlang!

<comment><USER17> That "with clear APIs" is where you are going to fall on your face. Hard. And is the point. At the beginning, you often don't know where the actual useful boundaries will be. You probably know where you want them, but ultimately that is just an aspirational point.

<comment><USER18> This is where types come in handy. With types you are _constantly_ declaring APIs, publicly and with confidence, so it's easier when one starts to bear real load.

<comment><USER17> Oddly, this is just another place this same problem can hit you. Sometimes, cleanly defining your types is not easy at the outset.

<comment><USER19> _" Oddly, this is just another place this same problem can hit you. Sometimes, cleanly defining your types is not easy at the outset."_

The problem ("you don't entirely understand the space your solution will inhabit; some of what you build will be wrong") will hit you regardless of how coupled or decoupled, typed or untyped. The question is, "do your tools help you adapt", and having defined your interfaces with types your tooling will quickly tell you - when you change the interface - everything you broke. Without types, this is tremendously more painful (feeling this in Python presently).

<comment><USER17> This only applies if the only tool you have is your type system. It is not inconceivable to have a system that verifies you do not pass anything to a function that can not satisfy the methods that you call on it. For all functions you have in your system.

Is this close to 100% inferred types. Yeah. But that is ultimately the point. Explicitly typing your code can be error prone. And, yes. So can leaving out all types. Far as I am aware, nobody has found a silver bullet, yet.

<comment><USER19> Your comment is incoherent.

First, it applies so long as a type system _is an effective tool_ at telling you this, and so long as that tool is not completely (or at least substantially) _supplanted_ by other tools. In no way does it have to be "the only tool" \- there are lots of tools I find useful to tell me when things are going wrong in my code: types, tests, assertions, linting. Even with the other three, types cover meaningful territory.

Second, as you half note, the system you describe _would be a type system_ (and sounds somewhat similar to core.typed in clojure, though my understanding thereof is tremendously superficial).

The rest of your comment just seems not to follow.

Type systems aren't silver bullets for keeping agility in the face of changes, in the same way that hammers aren't silver bullets for driving nails. You can use them wrong, you can hurt yourself, but you sure want one (... but probably not the weird shaped one with a loose head over there labeled "Java"...).

<comment><USER17> I was specifically referring to where you said "having defined your interfaces with types your tooling..." The implication being that types are required for this to work. I question that implication.

<comment><USER19> People are pounding nails with rocks. You say "hammers are just another thing to smash your fingers." I point out that hammers help you smash your fingers _less often_ , and you question my implication that hammers are the only way of reducing finger smashing.

This is idiotic; I'm done with this thread.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Experience Report: We just went through the decision to build as a monolith or via microservices. The original decision was to go with microservices as the rest of our systems are designed that way.

As the time pressure mounted the microservices that communicated naturally combined. The driving force was just the cycle time. Testing and deploying microservices took longer. Mind you, not minutes vs hours. Just a few extra minutes makes a difference if you do it often enough.

One decision that give us confidence we will be able to split the system back out again was to use the stuartsierra/component library. By using DI we can be fairly confident we don't build dependencies we aren't aware of. We simply substitute a client that talks over the network in for the one that does the calculation locally.

We are still in the stabilization zone but have already started to split out services. Code velocity is the driving force for the splitting. Certain components are well understood and fairly robust other still young and poorly understood. We want to limit our ability to accidentally screw up something we have already gotten right. So the components that haven't changed in a while get spun out.

<comment><USER21> It must be a sign that I am getting old, but your story of considered pragmatic compromise warms my heart. :)

</comment></comment><comment><USER22> I've wondered about how to grow a rails app. Really, you can get pretty far on one server. I think people go SOA too soon, instead of just trying to throw more resources at it (which is easier). I mean, basecamp isn't SOA and they handle plenty of traffic. Not that everyone is them of course; but most aren't amazon, either.

Really, I have no qualms with a monolith, but having 100 models to look at / understand is not easy. Chunking them up in some way, even if only by name (like product_sku, product_image) can really go a long way in understanding how an app works; thats really what I found attractive about SOA; but I could certainly do without the socket inbetween.

<comment><USER23> I'm in the same situation. About to try the 'component based architecture' approach: [http://teotti.com/component-based-rails-architecture- primer/](http://teotti.com/component-based-rails-architecture-primer/)

<comment><USER22> That looks interesting - it does look like it takes some effort, and does lead to additional maintenance, but that tradeoff might be worth it for the right app.

Still, that's a stack extraction; which would work for something like an admin section, but maybe not so much for things more entwined? But then you have to adjust the component antytime you want to make a change...

I could see it working out. I Would be interested to hear of your results once you have an assessment of it as an approach.

</comment></comment></comment><comment><USER18> There are two orthogonal concerns with microservices. First is the scaling aspect. A microservice architecture has many potential scale point as each independent service can be horizontally scaled independently. Unfortunately, while achieving this is possible in a microservice architecture it's an enormous added layer of complexity today.

The second aspect is, I think, more obviously compelling in that microservices force large scale modularity boundaries into your application. These are at some level entirely semantic boundaries, but the nature of microservice isolation forces them to be complete boundaries involving isolation, serialization, dirty checking, published APIs/interfaces, etc.

This, I feel, is unambiguously fantastic.

The trick is of course that this can be achieved in a "monolith" just the same. It's merely often not because people take advantage off _too many_ features of monolithic development. Shared memory and shared effect space, guaranteed communication causing you to weaken interfaces, fast response time causing you to never be public about the interfaces to a particular submodule. These together lead toward spaghetti code and the interlocking danger of monolithic design.

So, avoid them and make a monolith. Breaking it apart later will be easy if there are already logical cuts in your design. Don't rely on shared effects, shared state, or "hidden" API layers. You can use REST even within a single system.

</comment><comment><USER24> I think a lot of people tend to over-estimate how "scalable" they need their platform to be. Or worse, they spend so much effort on what they think will be a bottleneck, only to find they spent optimizing something which could have run on a single core.

I tend to think monolith first makes sense, unless you thoroughly understand the problem-space.. even then, monolithic POC might be worth it just to confirm things.

<comment><USER25> very related: [http://yourdatafitsinram.com/](http://yourdatafitsinram.com/)

</comment></comment><comment><USER26> Conway's Law comes into play a little here. Microservices provide organization level flexibility at the cost of operational and development complexity. For small teams and especially at the start of a project, organizational flexibility is usually not needed. Paying the extra ops and dev cost is unnecessary and even dangerous.

In the above, when I say microservices incur ops and dev cost here's what I'm talking about

* Debugging tools need to function across machine boundaries

* Deployments potentially need to be scheduled in multiple stages based on the service dependency graph

* Developer and test environments become more complex.

* The number of failure modes increases due to the network.

All this means we need more code, tools and processes. This investment is worth it and even required for large organizations. They usually have the infrastructure in place and the financial resources to invest. When I was at Google building a microservices based system was so much easier with Borg, Dapper, etc. This kind of tooling is only now emerging in a useable form in the open source world.

EDIT: formatting, grammar

</comment><comment><USER27> I think one of the essential reasons to start with a monolith is cultural. When you have an existing project/product and you are making incremental improvements to that project, there's a lot of shared understanding (everyone knows what the product already does), and so a small group can go off and work in isolation and get some efficiency from that.

When the product doesn't even exist, there is not shared understanding. It takes constant communication to prioritize correctly, and to understand the purpose of all the pieces, and to detect cases where an implementation is diverging from the purpose. In a kind of inverted Conway's Law, the architecture of the application will affect the communication structures of the team. You don't want the team to communication like microservices communicate. You want the team to communicate like a monolith, where everyone is always in everyone else's business, where conflict is frequent, but conflict resolution cannot be avoided.

I'm in the middle of a greenfield project where there's lots of little pieces communicating to each other over message channels. It's not an architectural preference, it's just how the environment works. Every single-page-app-style website has at least two services with a message channel. It's interesting to look at how this can be technically reminiscent of microservices, but culturally completely different. Those message channels don't make my project any less of a monolith (just a kind of annoying to debug monolith). But that's because they are deployed together, developed together, no individual has a responsibility that ends at one of those boundaries, there's no contract across those boundaries, there's few principles applied to the design of those communication channels (experiential and intuitive principles I suppose). That team structure, and that shared relation to the code, feels absolutely right for a new project.

</comment><comment><USER28> Seems like reality is settling in.

I mean, it makes sense to me: a team should keep its code well-factored but in a single codebase that's integrated and ready to deploy (as one or more deployable units) for as long as is tolerable/possible.

I think a trigger for splitting a module off from a monolithic codebase would be when its value or resource utilization has become disparate enough from the rest that it deserves its own infrastructure and/or its own maintenance crew.

<comment><USER29> The deciding factor probably isn't technological but rather human. If you want to keep your teams to 5-10 people and you want to maintain autonomy for teams as you scale, you'll need to split up your monolith.

<comment><USER28> That seems reasonable. I can think of many human/organizational/rule reasons that would force the breakup of a monolith representing many separate-but- related concerns.

</comment></comment></comment><comment><USER30> The article misses an important aspect of microservices: They're reusable!

Almost all of the swathe of microservices we've developed internally are general-purpose. We've built a dozen or more user-facing apps on top of them. If I wanted to build a new app today, I would typically sit down and write a Node + React app with no backend code needed because I can just call our existing services.

For example, we have a microservice dedicated to storing documents. With this I can create a todo list, a blog app, a Reddit-type link aggregator with comments, etc. If I need login, there's a microservices that mediates between an identity data model and an OAuth account registry. If I need an upvote/downvote system, we have a microservices optimized just for that. We have services for sending notifications across different transports (email, SMS); "followings" and sending digests about updates to things you're following; organization trees; verifying email addresses and mobile phone numbers and other verification sources; processing photos, audio and video; collecting events for aggregating in an analytics store; etc.

This ability to "pick and mix" functionality you need is the real beauty of microservices, in my opinion. It's a huge time saver. We just whipped up a new site recently where 95% of the work was purely on the UI, since all the backend parts already existed; the remaining 5% was just code to get data I to the system from a third-party source.

This does require that you plan every microservices to be flexible and multitenant from day one. It's a challenge, but not a big one.

<comment><USER31> Out of curiosity, what management tool do you use to orchestrate all these microservices?

<comment><USER30> Right now, a combination of Puppet and a simple custom-built tool written in Ruby. The tool inspects the metadata from Puppet about which nodes should run what apps, and the tool uses SSH connections to clone from Git, write config files, restart daemons, etc.

At the same time, developers run a local Vagrant VM that is configured identically to the production/staging clusters, and can run every single app (controlled using the same deployment tool). We also made it simple to mount an app you're working on, with code hotloading automatically taken care of. If you want to work on a microservice or an app, you just modify the code on your local machine and reload the page (or do an API request).

It works really well. It's not perfect, though. Since we're deploying directly to the servers, every node has to install packages, compile modules, package assets, etc., and everything has to wait on the slowest node; we'd like to transition to a system where we build a "release tarball" (or even a Docker image) once, and then push it to the cluster. Also, we're looking into using something like Mesos to better orchestrate apps and move away from role-based nodes; Puppet is way too rigid and too "opsy"; we'd like to use Puppet for controlling the base OS, and let the microservice/apps world be more dynamic.

<comment><USER31> Makes sense! Have you considered Ansible?

<comment><USER30> Ansible doesn't give us any benefits over our current system. (Salt would be a better choice. Not a fan of YAML templating, to be honest, nor the tight integration with Python.)

Configuration management systems like Ansible and Salt and Puppet are fairly rigid; they are basically modular recipes for placing files and starting services on remote servers. What you get from Mesos (combined with its frameworks) is something that can run your services, keep them running, and handle the several state transitions that affect any running application: Transitioning from one version to another, for example, or restarting a failing app.

We've tried using supervisord as a stopgap solution, but it, frankly, sucks. Doesn't follow forks (no cgroups), isn't capable of cleaning reloading its config, can't do master/worker replacement, doesn't support syslog in any meaningful way.

<comment><USER31> all those help with the infrastructure part, take a look at [http://github.com/mashape/kong](http://github.com/mashape/kong) for helping with the code.

<comment><USER30> I don't know Kong very well, but having look at the documentation, feels a little too much like a framework to me.

The nice thing about Mesos etc. is that it makes almost no assumptions about what your system is. You pick and mix the functionality you need. For example, Marathon is basically just a process manager. You wire it up the way you want; the application can be anything, from a web server to a one-off script.

Kong seems to be "Rails for microservices". Which is probably useful to someone, of course.

</comment></comment></comment></comment></comment></comment></comment><comment><USER4> I do agree with this article. We are working on a project based on a micro- services architecture and my experience matches.

First of all splinting functionality in multiple services is really hard and the first version of your architecture is probably flawed. It's also really hard to establish the responsibilities of each component, the boundaries, whereas it is really easy to take shortcuts that invalidate the modularity or the re-usability of those components.

Of course, these wouldn't be such big of a deal, except that refactoring becomes really difficult, because refactoring now often involves changes in how these services communicate and moving responsibilities around. Also, we are often talking about teams of more than two or three people, since two or three people will almost always choose to execute a monolith first - so in such teams the responsibilities are often divided between people, with people having an incomplete view of the whole system, so refactoring across the whole stack becomes a real bitch - next to impossible actually if the management or the clients are not acquainted with how software development works, as the development of new features is always preferred over dealing with technical debt (non-software folks do not understand technical debt).

Therefore I agree wholeheartedly with what is being said. It's not that micro- services don't work, however you need very senior people that know how to design such systems and you still have to throw away the first version of the entire system. And if you think you're one of those people that think they get it, but never had a failure, then have some patience, as you'll get there :-)

</comment><comment><USER32> Micro services Architecture seems to be the new hotness. I feel it to be yet another case of premature optimisation. :(. For me the best way has been writing a monolithic rails app and then writing rack/Sinatra apps to break them apart depending upon production bottlenecks. This has helped manage performance as well as code.

<comment><USER33> I don't understand why this is considered new; Roger Sessions described something extremely similar in his "Software Fortresses" book back in 2003 - [http://smile.amazon.com/Software-Fortresses-Modeling- Enterpr...](http://smile.amazon.com/Software-Fortresses-Modeling-Enterprise- Architectures/dp/0321166086/ref=sr_1_1?ie=UTF8&qid=1433350843&sr=8-1&keywords=software+fortresses)

<comment><USER34> Clothing fashions are almost never truly "new" either.

</comment></comment></comment><comment><USER35> Premature optimization is the root of all evil.

If you were able to accurately predict the future so you could know what your pain points would be as you grew, you would be wasting your talent writing software. You should be playing the lottery.

<comment><USER36> If you were utterly unable to predict any of the potential pain points in the things you build, I would seriously question your expertise. The fact that you cannot predict the future perfectly does not mean that the future is wholly unknowable.

<comment><USER35> It's not that pain points are impossible to predict. It's that you'll get some predictions wrong. False positives will cost you from the start and false negatives will bring you problems when they surprise you.

Instead of planning for future predicted problems, plan for change. Embrace the fact you know little about the future and that both the problems and the way you tackle them will always be mutating.

<comment><USER36> What you're saying is basically "the only constant is change", which is fine and dandy, but also kind of a useless truism. You are attempting to predict the future by building a product/project. You are assuming that the thing you build will continue to be useful and valuable into the future. By the very act of building, you are asserting some knowledge about the future.

Sure, you shouldn't go crazy and build a complex and expensive solution you don't need today and may never need, but it's disingenuous to claim that a lack of perfect clarity into the future justifies a complete lack of planning for the future.

</comment></comment></comment></comment><comment><USER37> Evolutionary design doesn't just work, it's the only kind of design there is. Design is not done in a vacuum. We fool ourselves when we write software, thinking that we're creating something ex-nihilo, plopping it down in Eden and declaring that it is good.

<comment><USER38> You're getting at the difference between top-down and bottom-up. Evolution is bottom up, starting with what exists and looking to improve. Top-down is starting with what you want to exist and moving things in that direction.

You need both. If all you do is evolutionary, then you lose the sense of why you're even there in the first place. If all you do is top-down, then you'll get deep into yak-shaving territory before you know it.

</comment></comment><comment><USER31> This is so true in our case. We started building Mashape, the marketplace for APIs in 2011. Two years later it become +100k loc of spaghetti Java code. We started a big re-write/de-coupling phase in 2014 which also opened new business opportunities since we were able to spin off some features as single products.. and this was not expected but definitely created advantages not only from the code/productivity side but from a business side too.

We have embraced Nginx and built KONG[1] as the main API Gateway for managing our microservices. It made our transition much faster and easier since we were able to orchestrate common functionalities across services, such as logging and authentication, in a few lines of code.

[1] A month ago we've released Kong open source: [https://github.com/Mashape/kong](https://github.com/Mashape/kong)

</comment><comment><USER39> Do whatever feels best for your company at the moment.

Monolith - Easier and straightforward, less thought on architecting the puzzle, and more about solving the issue at hand. Later down the line, this will cause pain points, should you be able to justify that pain with momentary momentum then this is the option for you.

Multi-tier - Decoupled monolithic application, generally happens after second iteration of a monolithic application.

Microservices - Modular, and requires more thought behind the interactions and architecture of the system. More thought should be put into also the deploy, and scaling of the system as well. Eventually you will have to do this. It is very obvious this is the natural progression of things as something grows.

</comment><comment><USER40> There was an interesting discussion on a recent Bikeshed Podcast episode about Monolith vs Microservices, featuring DHH: [http://bikeshed.fm/14](http://bikeshed.fm/14) \- worth a listen (you can skip the bits about ActionCable if you aren't a Rails user!)

<comment><USER41> Great listen!

</comment></comment><comment><USER42> This fits in very neatly with Casey Muratori's "Compression Oriented Programming" which is essentially Write your usage code first, keep YAGNI in mind, then Refactor.

I was once asked in an interview whether, on a new project, I would start with a monolithic app or some sort of SOA. ("Microservices Architecture" is the new SOA)

I answered that I would start with a monolith because usually you're trying to find product/market fit as quickly as possible, and having an SOA would likely slow you down due to its upfront cost. (How many services? Any redundancy? What do they do? How many databases? How do you keep them up? How do you diagnose when they're failing? etc)

They responded that they always do SOA, that the benefits are clear, that monolithic apps are idiotic, etc.

I didn't want the job... but I was confused about our differing opinions.

What I've learned since then is basically: are you constructing a building, or making an art installation?

Construction is thousands of years old. Contractors have huge tables of how long each part of the process takes, in what order, down to the quarter-hour (in some cases) and are fairly accurate in their estimations. (They're still hilariously wrong on occasion either in time or budget, building _anything_ is pretty difficult)

In this case, architecting SOA would work out since you've done it before. You know about how long it takes, what the pitfalls are, what support infrastructure you need, etc.

When you're making art, making something new, with new materials, without a manual, with only some best practices in mind, time becomes essentially unbounded.

Upfront architecture in this case would be poorly suited to the situation - you'll probably end up changing it a lot, and each time you introduce a bit of "rigor" to the system it becomes a bit more difficult to change. Especially over socket boundaries and different API versions.

I also feel like bad code has a survivorship bias - you only hear about it because the company took off. To get the company to take off, the code perhaps was necessarily rushed just so the company could stay around long enough to make money.

"Ah, but if we could have done it right in the first place!"

You don't hear about the companies who die, no matter the quality of their code.

</comment><comment><USER43> As someone who is starting a new project and thinking about microservice first (and first time in general), this is interesting. Im wondering if there are any success stories so far for this case? I like the idea of having just a few coarse services (e.g. users, content, gateway, message queue, web/client)

Another interesting thing is how to handle microservices orchestration, development, deployment early on without significant investment of time. We've been looking at docker/docker-compose and it seems like it should handle it but also seems more geared towards multi-container single-service apps. I'm wondering if anyone else is using same technology and has input? Maybe as things develop it will handle build/mananage/orchestrate multi-decoupled services

</comment><comment><USER44> I really hate people advocating micro services/libraries because they just migrated and "everything got much better". No, everything got much better because the known/actual problem domain changed and system is re-adjusted accordingly. When you start with very little knowledge of the problem domain, any fine-grained architecture is premature optimization, and what you really want is to rapidly expand your understanding of the problem.

Projects can fail in many ways, not trying to understand the problem better and not trying to re-adjust after are typical pitfalls. Migrating from monolith to micros is just a natural transition between SOME stages, and it shouldn't happen until you hit those stages. You may hit those stages very early, or sometimes never.

</comment><comment><USER45> I think there's an economic angle here.

"Bad" code (like a monolithic system - allow me to beg the question a little) can be cheaper to write, in many cases, than good code. But it is more expensive to scale, maintain, extend and debug.

But it means there's a lower investment of time to get a product out.

So I'd expect monolithic systems to have a higher success rate being converted post-hoc, because the systems that get that far have proven their worth.

Investing more to build a system 'right' isn't necessarily a good move, if you're not sure of the return.

Or, put another way, investing 5X in 5 cheap-hacky products, and then spending Y >> X to make the one that works un-hacky is often a better strategy than spending that Y up front.

</comment><comment><USER46> This is pretty much in line with my philosophy of functionality first _then_ infrastructure. The problems that inevitably sprout while building the functionality will influence future infrastructure / plumbing decisions. Of course, some care has to be taken to not entangle everything, but this shouldn't be too hard if you take a simple services-oriented architecture or even forego services and just store all your functionality in model classes. Regardless of the approach, the first thing that should be written are the tests that validate the functionality. Getting those passing is the highest priority; _how_ they pass comes after.

</comment><comment><USER47> I sometimes wonder if cloud computing would exist as it exists today without relatively inefficient monoliths that _had_ to scale. Once they'd scaled, the developers could afford to start peeling off the layers, thus only scaling pieces that needed to, leaving them with spare hardware.

"Hey, let's rent this crap," said some guy. And cloud computing was born.

Obviously I have no evidence of this at all, but I do still wonder, since at least two of the common vendors (Amazon and Google) were tech companies before they offered hosting.

<comment><USER48> It would be a cool story if it were true, but in fact AWS existed before Amazon was using it internally. They were selling their ability to run large datacenters, not their existing spare capacity.

<comment><USER49> Source? I'd also heard the "AWS was Amazon's extra capacity since they only use it all on black Friday" story.

<comment><USER50> It's a common misconception. Chris Pinkham and Ben Black created it, and it never had anything to do with excess capacity. [http://blog.b3k.us/2009/01/25/ec2-origins.html](http://blog.b3k.us/2009/01/25/ec2-origins.html)

</comment></comment></comment></comment><comment><USER51> We experienced similar to this at our company. When my coworker and I first arrived, the prior engineers had built the system as a set of microservices but it was completely overarchitected. Our first act was to pull all the parts together into one application.

Now that it's grown, we're starting to look at the microservice approach again, but it's been almost four years since we pulled everything together so it makes much more sense given the load/functionality we have now relative to then.

</comment><comment><USER52> ModularFirst, defer the decision to create a monolith or a microservice architecture. Start with a single application and focus on your software design being modular. One way dependencies, single responsibility, and simple interfaces make a big difference here. Breaking out microservices will be simple if you need to, and if you stick with a single app you'll have an app that will grow as a monolith well.

</comment><comment><USER53> I've been part of three teams who attempted monolith->microsystem transitions. Two succeeded (though at wildly different costs in terms of engineering time and delay) and the other was abandoned after person-years of effort.

The common aspect of the successful migrations was their incremental nature: rather than "killing" the monolith all at once, there was a careful and gradual migration of performance-critical sections into services running atop dedicated machines/storage/etc.

Neither of the successful moves happened all at once, or indeed ever 100% replaced the monolith.

It wasn't just a question of planning, either. The failed migration had a team of three engineers spend ~six months writing detailed component specs, migration plans, etc. The business simply couldn't stop (or even maintain the status quo) to let them build the shiny new V2, so it kept getting pushed out and restarted long enough that the plans and specs bit-rotted and the whole thing got scrapped.

<comment><USER54> Indeed, the mistake that gets made (and I've made enough times) is to think that any kind of restructuring of code is required to be done in a gigantic monolith.

</comment></comment><comment><USER55> Refactoring a system built of microservices is slow and costly, according to the article; the recommendation follows from this. Why can't it be fast and easy? Is it essence or accident? (Like, do skilled Erlang programmers agree?) How does refactoring happen in the systems he's talking about?

</comment><comment><USER56> This also seems like the idea of throw away the first one, you will anyway. The experience of building it as a monolith shows you what micro-services you need. Or maybe avoiding optimization before you need it.

</comment><comment><USER57> I've seen many startups that begin as micro services and have no problem as they scale up. Martin's company Tyrpesafe probably only works with companies that find themselves in trouble.

<comment><USER58> Different Martin.

This article is from Martin _Fowler_ who works for ThoughtWorks. Martin _Odersky_ is with Typesafe.

<comment><USER57> Ah ok, but I'm not sure that changes what I said — perhaps makes the bias even stronger towards projects and companies in trouble. Thanks for the correction.

</comment></comment></comment><comment><USER59> What about testing? And working with large teams? I imagine large software and teams would be abstracted into separate interfaces. Is communication between teams just more difficult to manage? Is reality different from theory? Shouldn't each segment be testable and debug-able? How do you effectively execute a large project? Is mashing it all together more of a proof of concept than the final product? As an investor am I on the hook for more than I bargained for? Is technical debt a non-issue?

</comment><comment><USER60> Taking the monolith-first idea even further, what percentage of web apps would run just fine on SQLite, MySQL in embedded mode, or (for JVM-based projects) H2?

</comment><comment><USER61> A hybrid approach is a better strategy once you have product/market fit. You should build your core domain as a monolith but have auxiliary infrastructure services built as microservices. The hybrid approach has the advantage of safely investing in microservices architecture that would later allow you to refactor your monolith once you truly understand your bounded contexts.

</comment><comment><USER62> If you're a web developer working with Rails and have large monolithic projects gone unwieldy or tending to go unwieldy, please give 'Growing Rails Applications in Practice' a try. [https://leanpub.com/growing- rails](https://leanpub.com/growing-rails).

(i'm not affiliated with the authors)

</comment><comment><USER63> I agree with Fowler, and this also fits perfectly with the central idea of the Lean Startup movement we saw last years.

</comment><comment><USER64> I finally read something that Fowler wrote that I can agree with and that isn't abstract (or overly abstract).

<comment><USER65> Ah I see you're talking about the OverlyAbstract pattern.

</comment></comment><comment><USER59> Macro and micro is relative. A monolith is a kitchen sink and expensive. Take a look at the API space for successful SaaS products especially when they are oriented in business software. It's hard to pivot a monolith or even monetize when it ignores the ecosystem it exists in. When it communicates well with other micro services it has natural discovery as a solution to a problem that the customer is looking for. Trello, Harvest, Basecamp, Pivotal, and tons more are all successful because they communicate well outside of their problem space and solve for the problem in their own scope. I do agree that you shouldn't be over aggresive on abstractions off the start but you should also consider the players in your space and ask if a segment of you application is solving something of value to others or if your recreating a service that your shouldn't compete with but cooperate with.

</comment><comment><USER66> Yes, mostly.

If you are putting up an API that needs to be available 24/7 you need to have the system sufficiently decoupled so that you can go read-only and make schema and infrastructure changes without needing to stop the world.

</comment><comment><USER67> > 1\. Almost all the successful microservice stories have started with a > monolith that got too big and was broken up.

This is pure survivor bias. The majority -- by far -- of 'failure stories' I know of in the software industry are ones in which a company tried to take their monolithic code base and modularize or microservice-ize it.

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

This is not because microservices-first is inherently flawed. This is purely a skill set issue. Microservices demand a greater skill set. A 'monolithic' approach puts much less of a demand on the engineer's skill set.

For a simplistic but illuminative example, if all you know how to do is build systems that operate on global mutable state (most newbie programmers), then of course you will run a lot further in a monolith than if you are trying to do this in a microservices pardigm.

This is a simplistic example because effective use of microservices requires much more of a skill set than not using global variables. The truth is that effective use of microservices (knowing how to build architecturally sound software) is way beyond the reach of MOST smart, senior level engineers that I've met in my career. If this sounds arrogant, it's not; there's a definitive architectural skill set that CAN BE LEARNED but that is missing from most software practitioners. (Our industry/academies need to learn how to teach it.)

This is the elephant in the room in our industry--and why we spin so many wheels talking about everything else. All of the energy we spend talking about patterns, processes, languages, etc etc do so much less for our industry than if we trained our practitioners in how to construct architecturally sound software systems.

<comment><USER68> > This is not because microservices-first is inherently flawed. This is purely > a skill set issue. Microservices demand a greater skill set. A 'monolithic' > approach puts much less of a demand on the engineer's skill set.

> The truth is that effective use of microservices (knowing how to build > architecturally sound software) is way beyond the reach of MOST smart, > senior level engineers that I've met in my career. If this sounds arrogant, > it's not; there's a definitive architectural skill set that CAN BE LEARNED > but that is missing from most software practitioners.

If this skill set exists, and almost nobody can or does possess it, then your argument is purely semantic.

Who cares if there's an ivory tower of geniuses out there spinning out perfectly formed microservice architectures in novel domains? We're talking about rules of thumb for practitioners here, not laws of physics.

<comment><USER67> I never said genius. And "perfectly formed" is not the objective. Tractability is. Go visit companies with medium-sized codebases and find me one that isn't lamenting how difficult it is to grow and maintain it.

I wouldn't consider myself that smart. But I have spent 20 years in this industry with what some might call a sick obsession for understanding how to compose and evolve systems and I've acquired some skills that I believe (1) very much matter to our productivity; and (2) can be mentored and taught, but (3) are not being taught.

My guess is that academy can't teach it because they don't have enough real- world experience behind their pedagogy. And industry can't teach it because it takes quite a while to learn and master -- and what business can afford to do that with their juniors who are just going to leave them in a few years anyway :)

<comment><USER68> I've certainly never worked for a company that did not have a laundry list of complaints about its software, all reasonably successful ones too.

And it usually only takes a couple of beers to draw the same laments from people working in the sort of companies a lot of developers aspire to.

If you think you've acquired a teachable, repeatable set of skills that aren't being taught then it sounds like you've got a gold mine on your hands :) As a relative industry junior (about 10 years) I haven't been introduced to a codebase that wasn't lousy. Certainly all were lousy to one degree or another when I left them, but they served customers all while drawing down the ire of developers (including myself).

<comment><USER67> > I've certainly never worked for a company that did not have a laundry list > of complaints about its software, all reasonably successful ones too.

Either this is a necessary problem (nothing to be done) or this is because of a lack of tools and skills (i.e., our industry is still immature). I believe very strongly in the latter.

> If you think you've acquired a teachable, repeatable set of skills that > aren't being taught then it sounds like you've got a gold mine on your > hands.

I might some day figure out how to teach this in a larger (non mentoring) scale.

What the skill set looks like and how to acquire it is actually the lesser problem. The harder part is proving to people, quantitatively, the _value_ of the skill set. I know and I think we all know (on some level) the extreme cost of architecturally-unsound software. But it takes a lot of work to learn & master the skill set, so most people bail on doing the work it takes to learn it. (The industry does not reward the growth or reward the mastery enough.)

Only when industry can connect the value of the skill set (and also be able to hire to the skill set) will more people put in the work to acquire it. (The value to industry is enormous but I think it would take some work, research, creative thinking to make the value explicit & tangible and give industry a way to test for the skill set.)

If someone builds me a house I can walk around and test the beams and come up w/ a general idea how well they did and how well the house will withstand the weather. In today's software world, two people with drastically different skill sets can produce a code base -- and it's really hard for the people with the money to see what they've been built and how sound it is.

<comment><USER15> In my experience, the reason all companies have shitty codebases is because of risk-compensation. When a company does _not_ have a shitty code base, it quickly throws all of its resources into improving the product and user experience for its customers, which increases its market share, revenue, and moat against competitors. This continues until all the new complexity makes the code shitty again, where they stage a cleanup & architectural fixit to be able to make forward progress. If the codebase is _not_ shitty, it means that they're leaving money on the table, and will continue to get shittier until code quality starts costing them money again.

Companies like Google, Microsoft, and Facebook actually do adopt (and often discover) many of the industry best practices. Their codebase is still shitty; the reason is that any cleanliness and rationality in their architecture is quickly eaten up by new features and products that drive the industry forward. As consumers, we see the benefits; as employees, we just muddle along as best as we can.

The only way to break this cycle is for engineers to pay companies instead of getting paid by them. I don't think this is what you had in mind. (Although, some engineers do make this bargain. This is why Haskell/Erlang/Ocaml/Lisp salaries are often lower than they would be for equivalently-skilled Java and C++ engineers: you take a pay cut to work in a language that's actually enjoyable to program in.)

Barring that, the way out is to learn some negotiating skills and at least get paid for putting up with a sucky codebase. If you frame it as "employing my skills will let your other employees implement the features you've been asking for for a year, which will make you $XM in revenue", you can make quite a pretty penny. I know some senior engineers that regularly get paid a couple million in restricted stock for a couple years worth of work.

</comment></comment></comment></comment></comment></comment><comment><USER69> Try writing your app in elixir/phoenix in the first place, easy modularized code like in monoliths, and scalable like a bunch of small separate services. best of two worlds I'd say.

</comment><comment><USER70> Is this not the same as 1) make your code work, 2) refactor? The only difference here is the author is talking about architecture instead of application code?

</comment><comment><USER71> I have a very different perspective. With tools like Heroku, building systems as microservices is no more time consuming than building a monolithic system. And it's much easier to iterate on and improve. Conversly, pulling apart a monolithic system into services is not a fun task.

<comment><USER72> What do you do when the interface between those components was wrong and you have to refactor multiple services at once?

</comment></comment><comment><USER73> key takeaway: Although the evidence is sparse, I feel that you shouldn't start with microservices unless you have reasonable experience of building a microservices system in the team.

</comment><comment><USER74> tl;dr;

Microservices first is premature optimization.

</comment><comment><USER75> Microservices: here be dragons.

</comment><comment><USER74> tl;dr; Microservices first is premature optimization.

</comment><comment><USER76> If my understanding of bounded contexts is correct, a bounded context represents the smallest level of granularity when it comes to a service component e.g. a 'customer' in one domain is not the same thing as in another (and there is therefore no universal reusable 'customer' service, but instead a much richer service representing a sales or support model in his example).

So going by the article, shouldn't the direction of travel therefore be from monolith to bounded context (as each domain boundary emerges) - which could be described more accurately as a macroservices architecture?

</comment><comment><USER77> Yup, get to market, incur technical debt, pay it off with cash.

</comment><comment><USER78> I want to give him the benefit of the doubt and say the " _a:link ,_ " in the following css is a mistake:

        a:link, a:visited {
          color: #94388e;
          text-decoration: none; }

...but I'm pretty sure it's not, and this guy really does want to break how unvisited links are displayed.

<comment><USER79> He just loves purple (look at his logo) and fashion over function.

</comment></comment><comment><USER80> My main problem with twitter and the stalled new user base.

1\. The onboarding social experience is just hard. Finding relevant information of what I want is difficult I wish there was a pane of tweets regarding interests ie gaming, politics etc. Everything in one thread is mind numbing once you follow too many people.

2\. Context - finding anything is difficult. I don't know what a trending hashtag is and the ones presented to me usually are gossip in nature for some reason?

3\. Some people get so many @'s that they simply drop off the earth.

4\. Whats the point of favoriting a tweet? I still don't get it.

5\. Why is it so difficult to use the API since those changes in what 2012?

6\. 140 characters is just so dang hard for me. I can understand a limit but just 140? I want just a little more space :(

<comment><USER81> What?</comment></comment>