In one of the previous posts, we described how we host the Invoicebus site and introduced the term Cloud Files and CDN (Content Delivery Network). Because the user base of Invoicebus constantly increases, we decided to deploy the most common content on Akamai CDN, so the users can feel the turbo charge of the bus

This content includes Images, Cascading Style Sheets (CSS) and Javascript files. Let me explain you how does this work.

Let’s assume visitors are coming from 10 different countries all over the world: United States, Canada, Mexico, United Kingdom, Germany, France, China, India, Australia and Philippines. For the example, we will take India in particular.

The primary web server of Invoicebus is located in Chicago, Illinois, US in the ORD1 Datacenter of Rackspace. That means all requests should be propagated thorough dozens of routers around the world, so the package from India can reach the server in the US, and then return way back home. Transferring such data over TCP/IP (read Internet) from India to US can take a while, even though this time is very short and usually expressed in milliseconds. However, when we multiply this time with the total number of requests, the delays can be drastic.

There’s a chance some packages to be lost on long distance routes, so resend will be needed, increasing the overall transfer time. There’re also other factors like intercontinental network congestion during busy hours that contribute for these delays.

That’s when CDN comes in game.
So when you deploy your files on CDN, the content will be retrieved from different servers in that CDN network all over the world. That means the users from India will request the files from the local cache in the nearest geo-located CDN server, and not going all the way to US. That’s why the content can be retrieved goddamn fast, leaving the primary server less engaged, so can easily deal other jobs.

We tested all pages from Invoicebus site, but to simplify the post, we will describe what happened with the login page which actually is pretty lightweight with only 160KB, including all the code, images, CSS and JS.

What we put on CDN from that page was the bus mascot image, a few JS scripts and the global CSS file, or to be precise we distributed content of 102.6KB in total.
Here’re the results of page load time:

Our plan is to optimize the whole app even more, so everything loads blazing fast, nearly as a native desktop app. Please let us know if you have any suggestion or request, we would like to hear from you. You can reach us on twitter whenever you like. We’re always by our laptops so will get you back in seconds.

Author information

Stefan Chachovski

Co-founder of Invoicebus. Huge lover of nature, science, and chocolate cherry cordials. He occasionally writes on this blog about Invoicebus' stuff. Hello him on Twitter or subscribe to his updates on Facebook.

| Twitter | Facebook |

The post Distributing Content via CDN appeared first on Garage.

This is the last part from the security talk series where I’m going to explain you the methods and technologies we use to host and test the web servers of Invoicebus.

When I talk about hosting, the very first things that pop-up in my mind are reliability, speed and redundancy. Three reasons which were plenty enough to choose Rackspace as our back keeper, one of the biggest cloud hosting providers in the world with cutting edge technology and state of the art data centers across the globe. According to Wikipedia its clients include 40% of the members of the Fortune 100 Magazine and its infrastructure platform is 60% bigger than Google’s. But let’s see what actually we are into.

Reliability

The primary data center of Invoicebus is located in Chicago, Illinois, USA and it’s called “ORD1”. To familiarize better, you can visit the gallery and get a quick view of the facility environment. They claim that can provide 100% uptime, so one month before the official launch of Invoicebus, we decided to conduct a test and make sure if the statement is true. We set up the Rackspace server, transfer the domain from the old hosting, re-hosted our early marketing site, and started experimenting.

One of the tools we’ve been using is called Pingdom, an online service that provides analytics for the server up-time, response time and a couple of other stats and tests. We set up to inspect the server repeatedly on one minute intervals by pinging it from 41 different locations around the world. We were checking the stats almost every day for 30 days, but the dashboard constantly was displaying the same boring message: “Last error seen: NEVER”.

The one minute pings are still running, so if something goes wrong, couple of alerts are triggered and sent instantly to our mobile phones via SMS and email. However, during the 94 days period of Invoicebus, we haven’t got any critical alert, so far so good. We decided to share these results with you:

The graphic shows 99.993% of uptime and 10 minutes of downtime due to scheduled regular maintenance of Invoicebus (applying upgrades and new features). Rackspace promise fulfilled.

Speed

To test the speed and response time we used couple of other services. The simplest was Speedtest.net which yielded

• 350+ Mbit/s Download (Rackspace claims it’s unlimited, or as much as the test server supports)
• 30Mbit/s Upload

constant rates initiated from the ORD1 datacenter, which means from the user’s perspective download and upload would be reversed. However, this was just out of curiosity, because it doesn’t mean anything especially when you deal with concurrent connections from different parts of the world. That’s why, we took in consideration a few other parameters, and most of them depend on the server hardware.

Currently, our server runs on:

• Quad-core AMD Opteron 2375HE @ 2.33 GHz
• 1GB of RAM Memory
• Windows Server 2008 R2 64 Bit

To stress test the web server we’ve used a service called Blitz that initiates so called “rushes” – parallel connections generated from multiple points of presence around the world, so you can calculate how much load your web server can handle in a given period.

The Blitz analysis showed the following:

This went awesome, but what about response times and error rates?

The error rate was 0.
The response time peak was 1.6 sec at 240users/second, which is pretty high.
The average response time was 733ms which also is considerably higher than most other.

Our goal is to keep the response time below 250ms, which means our upper limit would be 120users per second or 7200 in a minute (if we assume uniform distribution on interval between 0 and 60 seconds). If the number of users / visitors increases more than 120/second, we should upgrade our server probably with additional RAM memory (1GB+), so we can maintain the response time within the desired range and keep our customers bright and happy.

Upgrading the Rackspace server is very straightforward and fast process, but for now, this hardware configuration is plenty enough.

What’s on tap?

Reduce the load
Currently our marketing site and web-app are on the same physical machine, however, as the number of visitors/customers increases, we plan to separate them on different machines and reduce the load.

Cloud files via CDN
Cloud files is a service of Rackspace that provides an online storage for files which can be delivered across the globe at blazing speeds over Akamai’s content delivery network (CDN). This CDN caches content at global edge locations saving users time as the requested content is received from within the region instead of coming from the origin server. Let me explain what it means.

The cloud files keep caches of the web-app files (Images, CSS, JavaScript etc.) at different locations around the world and are served depending on the user’s current location. For example, if the user/visitor is located in India, than the content will be requested from the nearest data server in Asia; or if the user is in Germany, the files will be requested from the data server in Europe, regardless if the origin server is located in Chicago, Illinois, US.

Redundancy

Invoicebus creates database backups on a daily basis and here’s how: The backup procedure is scheduled automatically at a specific time of the day when the traffic is least congested, and the server is minimally engaged. The whole database is archived, encrypted (additionally), and uploaded to cloud flies, thereafter replicated to 8 datacenters across the globe on 3 different continents:

The data in each of these 8 nodes is mirrored to three storage disks instantly with dual power supplies and round the clock surveillance.

We’ve been keeping backups from the very first day, which means today we have exactly 94 copies of the database for all of our users, regardless if they run a premium or free plan. If the database drastically increases in future, we plan to implement additional logic for creating backups only from the new or modified data, and not the whole data set.

I believe I’ve covered the most interesting aspects and techniques we’ve been using for our hosting and I hope you’ll find some of them useful.

Now it’s your turn.
Have any suggestions or personal experiences with cloud serves?
Share with us your story; we’re eager to hear how you manage your hosting and backups.

Author information

Stefan Chachovski

Co-founder of Invoicebus. Huge lover of nature, science, and chocolate cherry cordials. He occasionally writes on this blog about Invoicebus' stuff. Hello him on Twitter or subscribe to his updates on Facebook.

| Twitter | Facebook |

The post Sleep tight, your data is secure, part 5 – Hosting Server Security appeared first on Garage.

Invoicebus is built to make you feel comfortable while doing your business, as we shown you with our previous security posts. First and foremost we have to emphasize that for processing payments we’re using third party payment processor gateway Moneybookers (soon to be rebranded to Skrill), so that means your financial transactions are secure and Invoicebus don’t have a clue about your credit card information. Look for card payment providers that offer customizable solutions and compare them. Skrill is the most famous European payment processor with headquarters in London, UK; have over 24.5 million users at the time of writing this and is still growing with about 100 000 new users every weak.

Here is short description about Skrill from their site:

Simplified flow of your payment process look like this:

If you’re wondering what is going on in the picture, here is the explanation:

1. From Invoicebus you are redirected to secure Skrill web page. From there you can make your payment with various credit and debit cards;
2. After you make your payment Skrill contacts your credit card issuing bank;
3. Then funds (the amount depends on your selected plan) are transferred from your bank account to your Skrill e-wallet;
4. At the end funds from your e-wallet are sent to Invoicebus Skrill account and you are redirected back to Invoicebus where you can continue making invoices.

TIP: When you are making online payments never forget to check the URL for secure data transfer with SSL. Checking this is very simple, just see if your browser address bar starts with https.

Author information

Dimitar Stojanov

Co-founder at Invoicebus

Dimitar is co-founder of Invoicebus, an online invoicing tool for easy invoice management. He's passionate about creating beautiful and simple web applications and occasionally writes on this blog about web design, online business, and fighting the status-quo. Follow him on Twitter and Facebook.

| Twitter | Facebook | Google+ |

The post Sleep tight, your data is secure, part 4 – Payment Processing Security appeared first on Garage.

Data Storage Security

In our case, data storage security refers to the way of keeping and managing customer’s data within the database: invoices, quotes, clients, company details etc.

These kinds of sensitive information are kept in a form that is encrypted by the Advanced Encryption Standard (AES) – first open symmetric-key cipher approved by the National Security Agency (NSA) and used by the US federal government for storing secret information.

The human way of showing how this thing works is by the picture below:



We use the words lock, unlock as a way to visualize the meaning of encryption, decryption process of the powerful AES algorithm respectively.

The security key is kept encrypted (with RSA algorithm) in a separate, isolated place (on a different server protected by other security mechanisms and firewalls). Every time when AES needs to lock/unlock data, it requires the decrypted form of his key.

Hypothetically spoken, if security breach happens to the database server, the attacker would not be able to retrieve any meaningful data without this key, unless he has Dan Brown’s TRANSLATR at home.

Other aspects of Data Storage Security

Backups and redundancy are closely related to the Data Storage Security, but will be covered in the upcoming part 5 – Hosting Server Security.
Part 4 and 5 of this security talk series will be continued after the Invoicebus launch.

Author information

Invoicebus Team

We're a team comprised of a few die-hard code freaks, lovers of beautiful design, stewards of simplicity, and passionately dedicated to the user experience. Invoicebus is a great vehicle to express what we do best. Click here to learn more on our business philosophy and how we actually do it.

| Twitter | Facebook |

The post Sleep tight, your data is secure, part 3 – Data Storage Security appeared first on Garage.

For storing passwords Invoicebus uses something called one-way encryption with salted hash functions. Why is it called one way? Because it can not be decrypted ever, actually it’s not even an encryption. It’s a hash that is completely different thing. In fact, this is one way ticket algorithm for which there is no returning path. This is too awkward explanation of hashing and it might sounds like a rocket science, so with a couple of diagrams we will try to explain as simple as we can what it’s all about.

Password Creation

This process happens every time you enter new password, you sign up, reset or change your password.

• Step 1: Generating random text called random salt, unique for every user.
• Step 2: Generating hash value from both your plain text password and the salt. The hashed salt will be stored in the database (DB) for validating the password in future (at login).
• Step 3: Generating hash value of the concatenated hashes from the previous step. This is the final password hash that will be stored in the database (DB).

The entered password is transformed to a binary value which looks like random gibberish, and nobody, absolutely nobody can retrieve the original plain text back, at least not with today’s technology.

What if two users choose exactly the same password? Will their passwords be represented with same binary values in the database? – No! That’s what salt ensures, unique and hardened passwords, so every password is absolutely unique in the database. Even if you try to reset the old password by entering a new one that is exactly the same as the old password, its representation would be completely different in the database.

Example:
Old password: invoicebus123 —–> generated as: 8de0c3c519
New password: invoicebus123 —–> generated as: bc9fe98a12

Password Validation

Let see how the password is validated during the login process.

• Step 1: Generating hash value for your plain text password. Retrieving the stored salt form the database for that particular username.
• Step 2: Generating hash value of the concatenated values from the previous step.
• Step 3: Comparing the final hash password from the second step with the final password retrieved from the database. If they match the user is authenticated to access the system.

If ever happen to forget your password, Invoicebus would be unable to retrieve it in its original plain text representation. That’s why an email is sent with a link where you can enter a new password.

Be aware of online services that retrieve your password in plain text when you try to reset it. That indicates they don’t use hashing; probably they have some poor password encryption or don’t have an encryption at all. And even hashing is used, it’s a good advice to always choose unique and strong password for every online account you own.

Author information

Invoicebus Team

We're a team comprised of a few die-hard code freaks, lovers of beautiful design, stewards of simplicity, and passionately dedicated to the user experience. Invoicebus is a great vehicle to express what we do best. Click here to learn more on our business philosophy and how we actually do it.

| Twitter | Facebook |

The post Sleep tight, your data is secure, part 2 – Password Storage Security appeared first on Garage.

• Data Transfer Security
• Password Storage Security (upcoming)
• Sensitive Data Storage Security (upcoming)
• Payment Processing Security (upcoming)
• Hosting Server Security (upcoming)

Author information

Invoicebus Team

We're a team comprised of a few die-hard code freaks, lovers of beautiful design, stewards of simplicity, and passionately dedicated to the user experience. Invoicebus is a great vehicle to express what we do best. Click here to learn more on our business philosophy and how we actually do it.

| Twitter | Facebook |

The post Sleep tight, your data is secure, part 1 – Data Transfer Security appeared first on Garage.

Usually free web hosting is not always as reliable and secure as it’s presented, however we decided to give it a try. There are a lot of hosting companies that offer absolutely free hosting like www.000webhost.com, www.weebly.com, www.webs.com, etc. with limited resources. We chose 000webhost.com because it offers 1500 MB disk space, 100 GB monthly transfer, your own domain name, and support for PHP and MySQL. It seemed more than enough for start.

This is great deal for all start-up companies, actually who wouldn’t like an offer like this? So we signed up and uploaded our early marketing site and blog, but after a while we noticed that invoicebus.com is not accessible for a short period of the day, and this was happening almost every day. Their site says they have 99% uptime which is not very convenient for serious web hosting. If we have 30 days every month with simple math we get 7.2 hours downtime every month (30 days * 24 hours = 720 hours a month; 1% of 720 is 7.2) so on a yearly basis you get more then 80 hours of downtime. This was unacceptable for us, even for our early marketing site, and from this experience we decided that we can’t host our site on another free web hosting, so started searching alternative paid hosting providers, with reliability in mind.

There are a lot of hosting companies so choosing the right one is not very straightforward process. We started reading various reviews for hosting companies, and in most reviews we saw the same hosting companies. What caught our eyes was a hosting company named Fatcow founed in 1998, which servers and offices are powered with 100% wind energy.

They are specialized for hosting personal and small business sites, and offer one unlimited plan, with unlimited disk space, bandwidth, domains, mail accounts, MySQL databases, and plenty of other stuff. For all the things you get, the price is quite decent, with discount for the first year. One of the greatest thing about them is their rock solid support team with quick and friendly responses.

What we really like about them was the fact that they don’t offer many confusing hosting plans, but "One Fat Account", so we picked them. Another thing that we like is their highly clear and very intuitive control panel vDeck. Also we insist on hosting provider with secure data centers located in the United States. So far we are very pleased with their service and support, we’ve never experienced downtime, or any other interruption about our site and we highly recommend them for simple web hosting.

We definitely are planning dedicated hosting account for our invoicing web application, with much better performances. We are considering taking scalable cloud hosting account but at this time we are still working on the details about that.

The lesson we learned in the past period is that if you want to have a good business start you have to spend a couple of bucks, so don’t hesitate about money when it comes to quality web hosting.

Hosting struggle – round 1 over: 1:0 for Invoicebus

Author information

Invoicebus Team

We're a team comprised of a few die-hard code freaks, lovers of beautiful design, stewards of simplicity, and passionately dedicated to the user experience. Invoicebus is a great vehicle to express what we do best. Click here to learn more on our business philosophy and how we actually do it.

| Twitter | Facebook |

The post Hosting Struggle – Round 1 appeared first on Garage.