A Working Cloud Architecture for 2014

Over the course of the last couple of years, I have put out a fair number of web sites and cloud based backends, and I have ended up with a stack that I think works very well.  Development is fast without compromising future extensibility , scalability is quite high, and the resulting codebase has proven quite maintainable.  In short, this is the architecture that I would recommend for almost any new project as a starting point, and I personally would need a very good reason to diverge from it on any large scale, serious new project. I suspect it will be comically out of date within 6 months.

Disclaimer: This is an opinion piece. It is about what I have found to be working, which might be different from what you have found to be working.  I write it in part because it took me a long time to find the right mix of technologies that work together in a way that matches all of the requirements listed above.  Hopefully if someone new to cloud architecting happens upon this article in can provide a good starting point. And if you have a better stack, I would love to hear about it and experiment with it!


The Server

For almost all of my projects, I have landed on using a Java based Google App Engine cloud app. Everything that I have read leads me to believe that the Python based Google App Engine is extremely good as well.  First a note about the Java aspect – Java tends to get a lot of hate.  It’s a very old language, and developers like new things, so that’s perfectly understandable.  Startup time on new VMs tend to be quite slow, and as far as I know, no one has ever written an app that people love using Java for the client side.  Unfortunately, there is nothing quite like it for the server side in terms of a corpus of extant knowledge (See chart below).  People know how to build servers in Java.  If you want a server side library, chances are really good that at least 3 versions already exist in Java.  And at this point, it’s not that bad in terms of performance either. Unless you are running at least tens of millions of monthly users, you will probably never get to the point where it is worth it to optimize beyond what Java is capable of.  Java is statically typed – obviously this is a religious point on which there is profound disagreement, but my $.02 are that the sort of compiler tooling and strong definition of interfaces that static typing provides are essential in any large server project.


The Middleware/Framework

Don’t. Just don’t. Ok, if you really have to, then use Jersey. Most server middleware, especially in the Java space, was created at a time when servers were all about serving up some sort of dynamic HTML template.  In 2014, HTML and Javascript clients are within an order of magnitude of capability of a desktop application, which means they don’t need the server to handhold them anymore.  And I would argue, that in almost every case, you don’t want to.  The HTML/Javascript client should be its one thing and the server should be another.  Your Javascript app should connect to your server in the same way that your iOS app does – with REST endpoints.  By fully embracing the power of your Javascript, you can completely separate your languages in a way that beautifully simplifies your whole architecture.  No more getting your server to output a bizzarre, templated mixture of html, css, and javascript.  The Java does Java things, and the Javascript does Javascript things.  

The Communication Mechanism

JSON.  There’s not even that much debate on this topic anymore, and I couldn’t even tell you why.  I’ve certainly seen analysis that indicates that XML is actually in some cases smaller and more efficient than JSON, but just about anyone who has worked with it (unless they’re dyed in the wool .NET developers) will tell you that JSON is easier than XML.  In Javascript, JSON is parseable natively, so that’s an easy win. And in Java, there are libraries like Gson or the slightly more efficient but harder to use Jackson.  The end result is that what once could have been hundreds of lines of code or an indecipherable middleware library to communicate between your clients and your server now turns into:

This of course is yet another reason why middleware is much less necessary than it once was and quite possibly not worth the complexity and obtuseness that comes with it.



Authentication is one area where we (the technology industry) has made a lot of progress. In particular, all of the big names have started coalescing around an authentication mechanism known as OpenID Connect which really is an awesome technology.  In OpenID Connect a javascript client carries fetches (usually through redirection) an authentication token.  These tokens are similar to OAuth2 Tokens with the slight modification that in addition to carrying permissions, they also carry identity. The client can then store this information locally, typically in the form of a JWT.  That authentication is then placed into the header where the server can validate the user’s logged in state.  The beauty of this system is that in no case does a user ever need a session to be logged in which means they are never tied to any particular server instance which is a dramatic boon when scaling.


The Client

This is probably the most controversial section of the bunch and also the one with the worst suggestion.  My suggestion is an AngularJS (with UI Router for routing. )  My take on AngularJS is that it is the worst of the html client side technologies, except for every other one that has ever been invented. If anyone on the Angular team ends up reading this, let me clarify that I think that Angular is brilliant and one of the best things to happen to the web in quite some time, but as great as it is, there are still a lot of things lacking.  There is no good way to expect a particular type from a server.  Intellisense-like IDE extensions just don’t exist. What the heck is $error? No one knows. To the Angular team’s great credit, they are aware of these issues and are working to fix them in Angular 2.0, but Angular 2.0 is a long way off unfortunately and may not work on any older browsers you are targeting.  I won’t really say anything about alternatives because there are a *lot* of them, and many of them have very good ideas.  All I can say in an article this broad is that I have tried quite a few of them and been most productive with Angular.



One last point not be overlooked is the CSS layout. For me, this almost always turns into Bootstrap 3.0.  Bootstrap is relatively simple and works everywhere that you want it to. It includes all the most common layout mechanisms and makes it simpler than re-inventing the CSS yourself. If you look under the hood, you often find a ghastly horror show, but that’s CSS.  Newer frameworks like Ionic are much cleaner and sometimes more powerful, but are targed at new, mostly mobile browsers and won’t yet work if you need common desktop browsers to work as well.


The Bonus Section

If you’ve ever needed a quick icon or loader, let me introduce you to FontAwesome.  Your icon is almost certainly there and absolutely trivial to include.  Enjoy!