

IT experts question architecture of Obamacare website - arikrak
http://uk.reuters.com/article/2013/10/05/us-usa-healthcare-technology-analysis-idUKBRE99407T20131005

======
gavingmiller
Throwing some actual qualitative points on this grossly overstated article: it
scored 92/100 on page speed [1], and 76/100 on YSlow [2].

Our companies site uses a mix of static/dynamic javascript which can cause as
many as 100+ requests to be made and we're able to keep page load time < 2secs
for the heaviest of pages. # of request doesn't automatically equal a slow
website. Add the fact that this gov't site was likely mandated to support some
ungodly old version of IE and you can easily see why there are so many js
files.

[1]:
[http://www.webpagetest.org/result/131007_5J_T8/](http://www.webpagetest.org/result/131007_5J_T8/)
[2]:
[http://gtmetrix.com/reports/www.healthcare.gov/1mQBgaqI](http://gtmetrix.com/reports/www.healthcare.gov/1mQBgaqI)

------
primigenus
Developmentseed posted about exactly how and why they designed the
architecture the way they have a few months ago:
[http://developmentseed.org/blog/2013/06/25/healthcare-
launch...](http://developmentseed.org/blog/2013/06/25/healthcare-launches-in-
the-open/)

In summary: static website served via Jekyll and pushed into CDN, little to no
content management outside of Prose.io, open source on Github, etc.

These "IT experts" aren't impressed, huh? Well, this "IT expert" is. So they
went down the first time they took a ridiculous traffic spike? So what? If it
_didn 't_ go down under 8.6 million unique load I'd be suspicious.

------
micro-ram
"the Canadian contractor that built HealthCare.gov"

I am speechless...

No offense to our neighbors to the North, but we should have built that in the
US. Maybe it's a way to shift more blame?

~~~
gavingmiller
None taken :D -- it actually happens a lot up here too! My city routinely
sends major projects to designers, architects, contractors, etc. outside of
the city, province, and/or country.

The likely culprit here is lowest bid != best product

------
shawn-furyan
This strikes me as overblown piling on. The website seems to be working
reasonably well now that the surge has died down a bit. I imagine that the
website launched much more quickly than it would have if the developers had
not used a bunch of javascript libraries. Now that the initial surge is over,
the site likely will never see that kind of traffic again, and so the shortcut
of using those libraries strikes me as a reasonable tradeoff.

I'm sure their going through the process of pruning the unused code and adding
caching. I don't really see what all the fuss is about.

Also, anyone who launches to that kind of traffic is bound to have some launch
day issues no matter how well they've designed the site.

------
zzzeek
"IT experts analyze newly released Obamacare website and determine, 'this
application is _perfectly_ architected. we can find no flaws whatsoever. Kudos
to the builders of this site for producing a flaw-free architecture on day
one.'"

very typical for a site that just launched three days ago!

------
arikrak
It seems there were specific flaws in their approach that cannot be totally
excused by large amounts of traffic:

"Five outside technology experts interviewed by Reuters, however, say they
believe flaws in system architecture, not traffic alone, contributed to the
problems."

Which means they may have been a little too triumphant back in June:

"It's fast, built in static HTML, completely scalable and secure," said Bryan
Sivak, chief technology officer of HHS, in an interview.
[http://www.theatlantic.com/technology/archive/2013/06/health...](http://www.theatlantic.com/technology/archive/2013/06/healthcaregov-
code-developed-by-the-people-and-for-the-people-released-back-to-the-
people/277295/)

