This is actually pretty awesome for any of the Java devs out there that are concerned that Java is dying and Ruby/Rails/Flavor-of-the-Month is rising up to replace it… it seems that the huge professional social networking site (no, not MySpace) LinkedIn is actually written in 99% Java except for some in-memory C++ caches that they use.
The major focus points are:
- Spring / Spring MVC
- Lucene for Search
- Jetty (no shit?!)
- Eclipse + Mylyn for Development
- JIRA for Issue Tracking / Tasking
I don’t know about you, but I love reading about enterprise technology stacks and what the “big boys” are using, along with tips and tricks on how to scale technology like that to the level of 22 million users and millions of hits a day.
IIRC there was another article done a year or so ago covering the Java technology stack that runs eBay; it was pretty epic and almost every part of it was custom from what I remember. There was no “EJB 3 Beans” or anything standard, is was just end-to-end custom stuff.
GWT/Java backs a lot of Google’s services as well, but I’ve never run across a doc covering what or how Google builds out it’s bigger enterprise Java services like Gmail/Adsense/etc. but I’d be hugely interested in knowing.
From the Web Java developers in the crowd that don’t love JSF/JSPs or GWT, you might be interested to know that IBM has been reviewing Wicket for a while now for including into their official consulting technology stack with some other commercial interests slowly beginning to glom onto the hugely intuitive web framework.
Check out some slides from LinkedIn’s presentation on Agile practices.
Do you have a favorite web framework or technology stack you want to share something about?
One of my favorite things from that presentation was that LinkedIn reported they don’t waste their time with an ORM framework. That they use straight JDBC. So JDBC and Jetty. Who knew?
Erik, I had actually skipped over that part and hadn’t seen it, very interesting!
I wonder if it was the overhead involved in invoking the calls, or the complexity of the calls that the persistence frameworks were generating that they didn’t want to deal with?
As bad as this sounds, for my next project, if I have enough time, I might try and go the JDBC route and just see what happens… maybe the performance improvement would be a nice throw-back to the early years for me?
Also as far as Jetty is concerned… I *have* to see a presentation on how they roll out and configure Jetty to host that… is there some proprietary clustering tech they are using or does Jetty support all that?
Pretty awesome if you ask me.
I’ll admit, for the most part I attend the church of the Spring Framework. That said, when it comes to JDBC, I really like using their JDBCTemplate. I just worked a short, quick Facebook development project. I had two new entry level consultants and didn’t want to try to teach them an ORM framework so we just used Spring JDBC. It worked great. I kind of wish I was using it on this big, enterprise project.
Erik, not knowing Spring, what does JDBCTemplate give you? Does it do any sort of mapping, even like iBatis, or is it just a super-easy way to get and work with a JDBC connection?
The main thing JdbcTemplate does for you is it hides all the try/catch, create connection, stmt, resultset, and cleanup code. Take a look at this page and then ping me back if you have any questions.
http://static.springframework.org/spring/docs/2.5.x/reference/jdbc.html
Erik, thanks for the link. I might give Spring a go in my next project, I do like how there are levels of abstraction you can choose from.
Do you have any experience with Spring MVC and/or WebFlow? I’m not clear on the differences, but from what I saw in MVC, it looks like a super-simple version of Struts… or in a similar family as Struts… not too different.
Not sure if I read that right.
No problem. I a big fan of Spring. I started and lead a Spring user group here in Dallas so I’m always looking to promote Spring when I can.
Yes, I have experience with Spring MVC. I’m using it *right* now on a project. Spring MVC is just a “better” Struts. When the Spring guys were working on Spring, they found Struts just wasn’t “cutting it” so they wrote their own MVC framework and then added it to Spring.
Spring WebFlow is a “stateful” framework that can be used with Spring MVC for “wizard” type functionality.
Here is a good tutorial for getting started with Spring MVC: http://static.springframework.org/docs/Spring-MVC-step-by-step/
Erik
You rock Erik, much appreciated.
I can see a lot of comments on JDBC. That’s great as I’m a big fun of pure JDBC as well but anyone notice that they’re using Grails as well? At least for prototyping and if we’re on groovy – support for JDBC is just great, if not the fact of some missing features from ORM’s I wouldn’t need one.
Jakub,
I’ve actually been surprised recently at some of the large-scale projects I’m seeing move away from the persistence frameworks and go back to straight JDBC… I guess for performance issue? I’m really not sure why persistence frameworks are getting the buck like they are, can’t you tweak out Hibernate or JPA pretty seriously now-adays or is the framework overhead itself just implicitly quite a bit heavier?
I know general app startup times bounce up quite a bit when using something like Hibernate or Toplink but I don’t have any benchmarks showing the real-world implications of that. Also having all that automated session management is really nice too, but I suppose that Spring’s JDBCTemplate gives that to you but with JDBC.
firstly there is no difference between a “enterprise” app and the apps your building in your basement. Its all the same thing, they just have more expensive servers, more bandwidth and more RAM than you do. Hearing you say that makes you sound like such a noob.
@Riyad Kalla frameworks are heavy and will FOREVER be heavy. Eventually all code comes down to “lines of code” verses “work”.
Owen,
I’m not sure the attitude is necessary, unless of course you just reserve that for insulting random people on technical blog posts around the net?
I’ll also have to go ahead and disagree with your assessment that enterprise app development is the same as “basement app development” — I’m assuming you mean smaller scale app development? There are quite a few different problems that have to be solve when your app gets millions of hits a day instead of thousands.
@Riyad no, its not a insult
enterprise apps have enterprise problems? All I’m saying is that there is not need to define a class of applications which are called “enterprise”. It sounds ridiculously noobish.
Owen,
I’m having a hard-time grokking what you mean here.
So eBay is the same class as application as the little webapp I setup for my soccer team to post messages to each other?
I just see the actual scope and problem set between the two apps so fundamentally different (not the functionality of the apps… but the hurdles that have to be cleared) that I don’t see how you could group them together.
Maybe I’m misunderstanding you? Once you get past a certain level of users or hits-per-day, no single server, regardless of power, can drive your webapp and you fall into the realm of what I would consider “enterprise development”, where you have to worry about things like Amazon, eBay, Twitter, Google, Facebook, etc have to worry about.
I’m talking about usage so heavy that load-balancing, db replication, 0% downtime are just the tip of the iceberg. These are all complex problems that can require a completely different design approach to your app that a smaller app would never encounter or be designed to work in such an environment.
Thoughts?
Riyad
All I’m saying that people with small apps use these tools to build their small apps everyday so that they are “scalable”. Its not some miraculous “secret” type of application design that they are doing. The only thing that really separates these applications from the applications that you yourself are building are the amount of users and the hardware you have available.
I blame my pointless rant on this line from the article:
” but I love reading about enterprise technology stacks and what the “big boys” are using “
+1 for Riyad. Enterprise apps absolutely have all kinds of considerations that need to be attended to that aren’t present in “basement” apps.
However… I would say that cutting corners on “basement” apps doesn’t make sense either. There are proven design patterns that should be used in all development efforts.
Owen,
The two grades of apps are most definitely different animals. And yes, there *is* some miraculously different design and development techniques that *must* be used in order for an app to scale past a certain level.
You don’t just take an app using say Spring MVC, Struts, JSF, whatever-you-want and move it to “bigger hardware with more memory”; as I mentioned at some point the grade of computer you can buy to singly host that app will hit a wall and you will need to scale your application past that.
Now you need load-balanced master/slave database servers, and CDNs hosting up static content, and load-balanced web servers that can shuffle sessions across each other if necessary.
The version 1.0 of your Spring MVC app that ran on the single 1U server that you started with, and the Facebook (or “big boys”) version 2.0 app you end up with that can handle enterprise-level load are significantly different beasts that wouldn’t resemble the original implementation at all and would have a significantly different design.
I doubt very many of us have every had the opportunity to need to scale an app to that level though, which is why it might seem like a non-existent thing. That’s one of the reason I love those breakdowns of insanely-large systems, just to peek in on the types of solutions these guys have to employe in order to meet the demand.
You look at World of Warcraft when it launched, and they were running prototype Cisco hardware to even meet the demand 80% of the time, they were crashing the other 20% of the time… it’s insane to think that some service might have so many hits and so much traffic that there isn’t technology to handle it.
Anyway, that’s a bit OT.