With a highly-competitive software development market, it’s becoming increasingly harder to find engineers to work along and develop great apps. In light of this issue, many startups and enterprises are turning to look at alternatives to hiring, being nearshoring one of the most common practices.
Let’s face it: developing scalable front-end code isn’t piece of cake. No matter how well-structured the framework/architecture you’re using is, everything will be converted to ye olde HTML, CSS and (vanilla) JS.
Well, the good news is the open-source community already created solid frameworks (like AngularJS and ReactJS) to make your life incredibly easier, so you can work on high-level code and nevermind the hardcore stuff.
This brings up a new scenario, though – after getting used to building things the old-fashioned way (or not-so-old-fashioned, with tools like Backbone.js or Ember.js), you’ve decided to try what is trending on front-end development now: ReactJS, using the Redux architecture. You got excited with the possibilities this opens (and – oh my! – the ability to ditch jQuery once and for all), and, after working for a few weeks you realize that your code is a total mess.
We all use a lot of web applications, such as Gmail, Evernote, LinkedIn or Telegram as productivity enhancers in our daily lives. However, there are not-so-rare moments that these services go down for a variety of circumstances.
In a recent event, due to Brazil’s Department of Justice decision to block access to WhatsApp in the whole country for 48 hours, millions of Brazilian users suddenly migrated to Telegram, generating a huge (and unexpected) load in their servers. Since this is not the first time this happens, Telegram was well-prepared and handled the usage peak gracefully (even though there was an SMS service bottleneck).
However, in a previous user base sprout, Telegram had a 2-hour outage in some parts of the world, as they said in their official Twitter.
Don’t get me wrong: I think Telegram was totally on top of this. The fact that they could solve this issue in a 2-hour window says they were prepared for cloud scaling – which unfortunately isn’t always true for all web services.
So how can you prepare for scaling? How can you be sure the cloud service you’re creating is prepared to handle a big user base (or a sudden increase in access) without going down?
When developing a mobile or web application, it is often necessary to build a web server that will integrate with your product. This part is often called the backend and, in simple words, it is the running piece of software that stays remote to all users – the center where the database is located and the place where the clients (iOS apps, for example) retrieve data from.
Although invisible from the user perspective, the backend is fundamental for any data-driven application – it is the component that users usually don’t directly interact with but, if it ever goes down, it might cause all of your client apps to stop working. The backend has a couple of other more famous nicknames: “the server” or – when it’s remotely located – “the cloud“.