A startup in the clouds

For all startups out there, I think that picking a decent platform that will do the job until money starts raining is a critical decision.

Amazon is where it's at

When I started warpcore.io, I had experience with AWS, they had a free tier, and Startup Weekend gave me another $100 bucks of AWS credit - so there I went.

The AWS platform is quite stable, way overpriced like all clouds (by my calculations it's about 20 times the cost of physical servers), but it's a cloud.

It takes 1 minute to launch a server, 5 seconds to share an AMI with a customer, 1 minute for them to have their own server running your latest deliverable... it works.

Amazon doesn't want my business

About a year later, the free tier was over, the credit didn't last long and I had to register another AWS account with another credit card, migrate, ...

Really easy, but still troublesome.

Another year later, I've got an actual product, website, domain name, some sales and marketing work done, and another year of Free Tier expiring.

I contacted Amazon to ask if they had anything for startups and after insisting quite a bit, we exchanged a few mails and they stuck to their policy of helping accelerator startups only, which brought me two days before the end of the free tier.

No problem though, I had yet another credit card (my girlfriend's this time...) so I migrated in a few minutes and that's that.

A long term solution

A few weeks ago, warpcore.io was accepted into BizSpark, which means I've got about 600 euros worth of Azure Cloud credits to spend each month, for the next three years.

I don't really like Microsoft, despite the fact that they make the best desktop operating system, and I had never considered Azure.

But in this situation, I'll be moving warpcore.io to Azure, because AWS doesn't give a shit and Microsoft does.

Because Microsoft gives me enough free credit to run a redundant dev and prod environment, automated scalability tests, servers for customers, whatever.

Parting words

So there you go, if you're going to do something without an accelerator, I would say pick Azure, at least Microsoft seems to want our business, and on top of that you get five MSDN ultimate subscriptions, i.e. 80 x 5 Windows 8 licenses plus all the Microsoft Software you'll ever want to use (if any).



Never thought I'd say that, but thank you Microsoft for your intensive tech seeding.

Data Model Request

If you want to request a Data Model, some information about your project will be required.

Features

Examples: "user profile management", "search for classifieds", "add a friend", "send a message to another user", ...

Data

Examples: "user information: name, last name, email, date of birth", "classifieds ad: title, keywords, detailed description, pictures", ...

Permissions

Examples: "users can only see their own profile", "users can only send messages to their friends", "level 2 administrators can manage projects for their company", "level 1 users can only manage their own projects", ...

The first Data Model request for a project is free (for a limited time at least), further requests are priced based on feature complexity.

Making the request

To make the request, send an email with all the information mentioned above to contact@warpcore.io

What's a Data Model ?

A Data Model is a document that summarizes all the data your application is going to manage.

Here's a relatively simple Data Model that would fit the core features of facebook:

In this example, the boxes are "items", and the arrows are "relations" between these items.
They've been given names to explain their purpose in terms of features users can see.

A Data Model also includes information about whether a Message can be sent by only one User, or to only one User.

And lastly, it includes all the information bits that are gathered for every "item", e.g. for Users, we'd like to have their first name, last name, email, mobile number and date of birth.

If you don't have a Data Model yet / would like assistance with creating one, click here.

Web Application Architecture

There are many ways to build web applications, from the old-style google prior to auto complete, to what we do here at Kanpeki.

Here's an explanation of the different levels in the evolution and the benefits gained at each level.

Level 1: PHP tags inside HTML markup

This is the simplest way to create a web page with dynamic content.  Starting from a standard pure HTML document, PHP (or any other script language) tags are inserted instead of some of the static content (like replacing "Peter" by <?php echo $firstname;?>).

This makes it possible to write just one web document for all users  instead of one per user, which would make projects like google or facebook simply impossible.

The disadvantage is that inserting tags inside markup is messy, and very limited because this approach considers the document a static one with some dynamic bits, instead of a fully dynamic (generated) page that takes advantage of all the possibilities offered by programming.

Level 2: HTML echo'd by PHP (or any other language)

This is the second step in the evolution, and it has the major benefit of considering the whole page generation process as a program, and not just parts of it.

That approach reveals a lot of cases where templating, markup generation, and other techniques can largely simplify and clean up the page generation logic and code.  This not only means that much more can be achieved with less, but also that the resulting solution will be much easier to maintain because of its smaller size.

The disadvantage of this approach is that this increases server costs massively, partly because most web languages are notoriously inefficient, and partly because more work is being done on the server.

Level 3: Pure AJAJ (JSON, not XML)

There are many benefits to switching to such a technique, the first of which is the major decrease in server costs and the consequent increase in usage of client-side resources.

In this case, the only thing that ever transfers between the server and the application front end is the data itself, i.e. the strict minimum that you can transfer in order to have an interactive application.

The page rendering process happens entirely on the client-side, no markup is generated server-side, and the little HTML that is required to start the application is simply cached as a static file, freeing up lots of server capacity.

Because so much more happens on the client side, many client-server trips are simply eliminated, and the user interface becomes incredibly more snappy, especially in higher latency regions.

This style has yet to become standard though, and most current web applications are still stuck between level 2 and 3, like for example google or facebook, who both use some AJAX/AJAJ (Level 3) but still base the core of their applications on server-side rendered HTML (Level 2).

Level 4: And beyond...

There are still good ways to improve on Level 3, most of which will focus on improving the architecture of the front end itself, a necessary upgrade as its complexity increased with the increased responsibilities.

Some good first steps are to create a front end API, which will be the channel through which all API requests are made, or a front end storage, which will enable advanced caching and save even further on server costs while offering even better snappiness.

Other approaches to automate the markup generation, bind data to its representation, and generally remove data from the markup enable us to consider it more as a pure presentation layer, resulting in a much cleaner, efficient and maintainable solution.

At Kanpeki, all of our projects are Level 4 and we are continually developing improvements on Level 4, in the hope of one day finding yet another critical improvement (Level 5) to deliver more value to our customers.

What's in a Web Application ?

General Structure

Most Web Applications will have a data storage component, a web server component, and a client-side component.

Data Storage is often done using a database but one could use an XML or CSV or any kind of structured text document all the same.

The Web Server is necessary to answer HTTP (web) requests and can also be used to tailor the HTTP response, usually by letting a program control the contents of the response entirely.

The contents that are received by the browser then form the client-side component, which is the only visible part and can be more or less complex depending on the design choices.

What's a Web Application ?

What is a Web Application ?

Almost every website is a web application nowadays.

Anything that uses web technologies (HTML (+JS/CSS)) and has dynamic content is a web application.

Dynamic content means that the HTML page is generated by an application based on data that is susceptible to change, like a google search page, or a facebook profile.

What isn't a Web Application ?

Following that definition, the only websites that cannot be considered web applications are static HTML documents which are not influenced by user interaction, like a "website under construction" page.

What can a Web Application do for you ?

Every application that can be a web application is always better as a web application, thanks to data centralization and major increases in simplicity and agility in the development process.

Some applications cannot be made into web applications though, such as those that need 3D graphics or instant feedback, such as video games, CAD programs and Computer Assisted Surgery equipment for example.

An application using such technologies will still make use of other Web Applications though, for game progress storage, multiplayer games, online or networked CAD file management, and in general any kind of data management.